From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: "Why is emacs so square?" Date: Fri, 05 Jun 2020 23:54:08 +0200 Message-ID: <87zh9hrxfj.fsf@logand.com> References: <863691n4xl.wl-me@enzu.ru> <86blno9yle.wl-me@enzu.ru> <87d0845msg.fsf@yahoo.com> <87h7xgjasw.fsf@yahoo.com> <875zdwjais.fsf@yahoo.com> <6a198677-41b6-4dbd-39d0-2b01550d53cf@yandex.ru> <32f6a2ce-e30f-059f-dcd4-233d666a10a1@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="52882"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org, Steinar Bang Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 05 23:55:21 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhKJ6-000Deu-U9 for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 23:55:21 +0200 Original-Received: from localhost ([::1]:48572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhKJ5-0006L8-VI for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 17:55:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50692) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhKI8-0005s7-V2 for emacs-devel@gnu.org; Fri, 05 Jun 2020 17:54:20 -0400 Original-Received: from logand.com ([37.48.87.44]:58702) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhKI3-0003zv-R7; Fri, 05 Jun 2020 17:54:20 -0400 Original-Received: by logand.com (Postfix, from userid 1001) id 025BF1ACD99; Fri, 5 Jun 2020 23:54:10 +0200 (CEST) X-Mailer: emacs 26.3 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/05 17:54:12 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251918 Archived-At: Richard Stallman writes: > When I write a pamphlet using Libre Office, I need to see how it > will appear on the page. I need to see where line breaks and paragraph > breaks appear. > > I want Emacs to be able to do tect processing that way. What are the missing pieces? I think there are many and they would be useful for other use-cases. Some of the use-cases I am interested in: 1) Sometimes, I need to write a letter which does not need to be an art work. I wrote emacs-pdf (see ) to address that. It creates a PDF document from an Emacs buffer. Only plain, monospace ASCII text works so far, but it can already break and count pages and insert headers and footers. It is very short (about 400 lines of elisp including comments) and requires no dependencies and no graphics. a) The next step will be unicode. It seems that there is some code in Emacs dealing with unicode fonts in order to generate postscript files. Any pointers where to start with this? b) After that, emacs-pdf will understand font metrics so it will be possible to do layout. It should be possible to render HTML for example, and create graphical web browser as an alternative to eww. It should also be possible to render other formats like abw, odt, etc. At least roughly, depending on how much detail in the corresponding spec people want to address. I have explored simple conversion to text in pure elisp in emacs-unoffice . It should be possible to write a direct PDF backend for org-mode and maybe enriched-mode. Internally, probably some kind of html like sexp based format should be used. I used a sexp based format in emacs-pdf (transient cons tree representation) but for document processing, the format should not be so low level (e.g. no PDF drawing primitives but something like HTML primitives; or maybe mixed). c) It should not be difficult to add raster images and vector graphics to the PDF drawing code. d) It should be possible to add for example SVG backend. Non-console Emacs can already draw SVG. At least at the beginning, this would also avoid the need for image rasterisation if vector format like PDF or SVG is used. Maybe this could be used for real-time preview, before we get WYSIWYG. Or maybe use pdf-tools to view the generated PDF. 2) Printing is an issue in Emacs. I will try to implement an alternative which will use IPP and PDF. No PostScript, no CUPS, if possible no complex configuration. 3) I use Emacs on the console a lot. All the above should work there too. In order to view images in console Emacs, I wrote . So far there are a few functions that draw images using w3mimgdisplay from the w3m console web browser. It fits images on the screen, unlike graphical Emacs where image display is unuseable. a) I would like image-mode just work with this emacs-framebuffer image drawing. Any ideas, how to plug emacs-framebuffer into image-mode? b) It is a shame, that I need to reimplement such basic functions like image-size: (image-size (create-image "/tmp/a.jpg")) => (error "Window system frame should be used") framebuffer-image-size at https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html#l95 does not require any dependencies and computes image size for png, jpeg, bmp, gif, tiff and pnm in elisp. It would be nice to eliminate or at least reduce the need for such dependencies so that many Emacs features are useable in different environments, like for example console. c) There are functions frame-width and frame-height. Are there also functions something like buffer-width and buffer-height and or a way to compute x and y position relative to frame origin, which would allow me to position images exactly in the buffer similar to what w3m browser does? 4) Emacs is missing some kind of canvas, where things could be drawn and which would handle pixel precise input. For example, I would like to browse OpenStreetMap in Emacs. I wrote a console based OSM browser osmq and web-based OSM browser at . I would prefer an Emacs based map browser. However, I have not figured out how to lay out images in Emacs in a grid and how to detect which image was clicked. A bonus would be, where exactly was clicked. Any ideas what should I look into? Emacs canvas should probably work like HTML canvas, which is rather similar to PDF or PostScript in terms of drawing interface. I have explored this space in the PostScript interpreter in JavaScript . Not sure how difficult it would be to plug some kind of portable canvas into Emacs. This seems rather low level C work. It seems to me that these points are precondition for a WYSIWYG document editor feature in Emacs. Do these points resonate here? Is somebody already implementing anything mentioned? Or what is already implemented? Would there be an interest in incorporating emacs-pdf, emacs-unoffice and emacs-framebuffer (the framebuffer-image-size function?) into Emacs? Regards, Tomas