Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Tomas Hlavaty <tom@logand.com>
>> 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.

I poked around a bit and it seems that what I did in emacs-pdf
(pdf-buffer function) is similar to what ps-print-buffer function does
in ps-print and ps-mule with ps-multibyte-buffer set to nil.

Now I want something like ps-multibyte-buffer, e.g. pdf-multibyte-buffer
so that I can use non-ASCII characters in the generated PDF.  So I
probably want to implement something similar to ps-multibyte-buffer
cases of non-latin-printer, bdf-font and/or bdf-font-except-latin.

There seem to be ps-bdf so maybe I have to look, if I can reuse
something when generating PDF.

>>    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.

For printing, this might not be an issue.

> 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.

I'll have a look, thanks.

>>    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.

I see.

There is frame-position but no window-position.  Is there a way to get
window position in a frame?

>> 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
>>    <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
>>    <https://osmq.eu/>.  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.

Yes.  Is there an example how to start with this?

> We also support displaying slices of images, in case that helps to
> produce a smarter layout of images.

Great.  Is there an example?

>> 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.

Interesting.  Maybe the pdfterm.c you suggested is kind of canvas I
wrote about.  When there is all that complexity with pixel perfect
drawing and layout, it would be shame to limit it to enriched mode.  But
it is still too early to make decisions in this direction.

Thank you for your help and quick and helpful answers!