[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Why is emacs so square?"

From: Eli Zaretskii
Subject: Re: "Why is emacs so square?"
Date: Sat, 06 Jun 2020 09:35:40 +0300

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]