Re: SVG hack for display engine

[Anand Tamariya <atamariya@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

On Tue, Nov 16, 2021 at 7:46 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> > Date: Tue, 16 Nov 2021 15:08:00 +0100
> > Cc: Anand Tamariya <atamariya@gmail.com>, emacs-devel@gnu.org
> >
> > All of these, and probably many more, use cases would be enabled by an
> SVG based display engine.
>
> What is "an SVG based display engine"?  How will it work?  Which parts
> of the existing display engine will it replace, and how?
>
> A serious discussion of these matters should answer all those
> questions and many more.  The Emacs display engine isn't just
> something that takes text and shows it on the screen in different
> colors, it implements a large number of features without which Emacs
> wouldn't be Emacs.  They all need to be supported in any new
> implementation, so we should have a more-or-less clear idea how this
> would be possible with this proposal.
>
Here's some details on how I think it might work. Emacs exposes two Lisp
APIs:
- svg-render (svg x y width height)
svg is a Lisp DOM object as returned by (dom-node). This should use librsvg
to generate a bitmap image of svg of size (width x height) and superimpose
it at position (x, y) on the current bitmap being displayed by Emacs. The
current image API takes either a filename or XML string for SVG. This can
be avoided if svg is a Lisp DOM.

- svg-bbox (node)
This returns the bounding box of the DOM node. This is basically a wrapper
around librsvg API.

Emacs also adds a hook, say, display-svg-hook which runs only on a
graphical display. Any mode can use this hook to display the SVG content
using the above API.

This should mean minimal changes to the display engine and it continues to
run as is for terminals. What do you think?

[-- Attachment #2: Type: text/html, Size: 2433 bytes --]