[Top][All Lists]

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

Re: SVG hack for display engine

From: Anand Tamariya
Subject: Re: SVG hack for display engine
Date: Wed, 17 Nov 2021 10:03:25 +0530

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?

reply via email to

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