bug#40845: SVG rendering issues

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 25 Apr 2020 19:41:31 +0000
> Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org
> 
> My use case is to include a glyph which is supposed to look like a
> character, but doesn't actually have a unicode codepoint. (I'm sorry
> if this differs from the use cases you're exclusively concerned with,
> but it appeared to be relevant enough to Clément's problem that I
> assumed he was having a similar issue).
> 
> That means that we want to use an image spec, not a character in a
> font; but that image spec depends on face/font properties, because we
> want to blend in with surrounding text. The most obvious ones are
> foreground and background color and size, but slant and weight would
> also affect properly-rendered character-like images.

If we want to display an image, the logical way would be to use an
image spec, which is already supported, enhancing it as needed.  I
don't see anything in the above attributes that would be hard to have
within the existing framework of how we display images.  I don't
really understand how you can make images "slant" or "bold" (unless
they were like that to begin with), or why would we want to, but maybe
there's some way of interpreting that as well.

None of this requires a new spec or calling Lisp.  All of the metrics
of the current face's font are known by the display code, and there
are many that cannot be obtained from Lisp, like the current line
height.  Doing these calculations in Lisp is IMO the worst possible
way of using Lisp callouts from the display engine: this has all the
disadvantages of calling Lisp, and none of the advantages.

> It seems fairly obvious to me that it's a bad idea to do all the work
> in the display engine or in C code: sub-pixel rendering and
> anti-aliasing are hard to get right.

Aren't we talking about displaying existing images, which someone
already prepared while using all those techniques?  Why would the
display engine want or need to modify the image using them?

> A character-like glyph might need a third color which provides
> sufficient contrast to the foreground and background colors, and
> that color space calculation is complicated enough to be moved to
> Lisp.

Within the context of what these icons are supposed to be used for, I
envision the images coming with bright, catchy colors that should be
left alone, not enhanced by color and contrast tweaking of whatever
happens to be the face colors the user wants.  Those who design such
icons do a much better job than any Lisp program.

> But all these limitations are fixable.

They wouldn't have existed if you used the code which displays images.

So I still don't understand the motivation for this approach.  (Read:
I think it's wrong.)