From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "Why is emacs so square?" Date: Sat, 06 Jun 2020 09:35:40 +0300 Message-ID: <83img4aegz.fsf@gnu.org> 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> <87zh9hrxfj.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="22109"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sb@dod.no, rms@gnu.org, emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 08:36:48 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 1jhSRi-0005ej-Gi for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 08:36:46 +0200 Original-Received: from localhost ([::1]:50618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhSRh-0003Or-JH for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 02:36:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37926) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhSQw-0002tB-Gn for emacs-devel@gnu.org; Sat, 06 Jun 2020 02:35:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57120) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhSQu-00025o-8L; Sat, 06 Jun 2020 02:35:56 -0400 Original-Received: from [176.228.60.248] (port=4521 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhSQn-0004Sl-2M; Sat, 06 Jun 2020 02:35:49 -0400 In-Reply-To: <87zh9hrxfj.fsf@logand.com> (message from Tomas Hlavaty on Fri, 05 Jun 2020 23:54:08 +0200) 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:251933 Archived-At: > From: Tomas Hlavaty > Date: Fri, 05 Jun 2020 23:54:08 +0200 > Cc: emacs-devel@gnu.org > > 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? I think you should provide more details about the particular problem you are trying to solve here, because I don't think I understand it. Emacs generally knows only about fonts it uses for its own display, and it needs to load the font before it can provide information about it. Whereas you seem to be talking about fonts to be used in the PDF file, not in Emacs display. > b) After that, emacs-pdf will understand font metrics so it will be > possible to do layout. I very much doubt you can do sensible layout in Lisp. shr.el tries, but the result is slow and incomplete -- and it does that with text displayed by Emacs itself, whereas you are talking about something more ambitious. If you want to do layout for PDF, I think one way forward would be to implement a pdfterm.c "terminal" for Emacs, which produces PDF like the existing *term.c backends do for supported display types. > 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? Yes, there are, but they need a window to compute these metrics. Without a live window, "buffer width" is meaningless, because buffer text doesn't define the fonts (more generally, the typefaces) used for displaying the text. Only a window in which a buffer is displayed provides enough typeface information to do these calculations. > 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 supports "hot spots" on images for this: a click on an image returns information about pixel-resolution offset of the click from the image origin. I think that's what you want, although I'm not 100% sure. We also support displaying slices of images, in case that helps to produce a smarter layout of images. > It seems to me that these points are precondition for a WYSIWYG document > editor feature in Emacs. FWIW, I don't think these points are necessarily preconditions for WYSIWYG features. They are important and useful features, but a WYSIWYG document editor should IMO start with something whose beginning we have in enriched-mode. That mode currently lacks the ability of laying out text in variable-pitch typefaces, which I think is the first extension of enriched-mode that should be worked on. Followed by page layout and page breaks, intelligent sectioning commands, etc. etc. And yes, printing is also important, whether it is done by producing PDF or PostScript or any other intermediate format.