bug#40845: SVG rendering issues

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sun, 26 Apr 2020 10:15:39 +0000
> Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org
> 
> > 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 want to display a glyph that looks different depending on its
> textual context. That means it's not "an image", in the traditional
> sense.

Then I guess we are talking about two different use cases.  This bug
report was filed in the context of this discussion:

  https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01386.html

where I said that I think such UI effects should be implemented by
using images, not special characters and special fonts.

> and enhancing image specs to handle such context-dependent
> glyphs is wrong, because it moves code into the image backend that
> applies to all image backends.

"Image backend" in this context is the image libraries, like librsvg
and libpng, is that right?  If so, which one of them can do the stuff
Clément reported missing?

> The enhancement I propose is a layer of indirection, allowing the
> image spec itself to be adjusted to face/font properties.

The kind of adjustments that we need for the use case which prompted
this discussion can be done inside the display engine.  Or at least I
don't see a reason why it couldn't be.

> > 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.
> 
> Because we want the glyph to blend in with surrounding text. Like a
> character.

Not really, not in the use case discussed here.

> And, no, there's no way for an image backend to interpret that. We
> have to use different image specs.

A Lisp program that prepares such display can prepare the spec
accordingly, if needed.  Any effects that cannot be explicitly
produced by Lisp and we'd need the display code to produce can be
communicated using the image spec keywords, like we always do.  For
example, if we want the image to scale with the surrounding face, we
can have a special value of the :scale attribute.  And similarly with
other attributes; we can also invent new keywords for attributes
currently not supported.

> "you want images, not character-like glyphs" isn't an argument, it's
> simply a statement that you don't want my use case to be supported.

It just means your use case is different from what is being discussed
here, and serves purposes other than those which prompted this bug
report.  I don't think we should mix them.

> I'm talking about displaying character-like glyphs.

And I'm not.  This bug report is about a different use case.

> > 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.
> 
> I'm not sure which icons you're thinking about, but I certainly don't
> want my symbols to have "bright, catchy colors that should be left
> alone".

I suggest to read the above discussion, and also look at the UI
look-and-feel that is being sought.  You will see many examples there
of the kind of images that people would like to see.  I think their
vivid colors is one of the main aspects that attract users to such UI.

> I'm still not sure whether you're suggesting anything that would
> handle my use case even remotely, or simply saying it's not a use case
> that Emacs should be extensible to.

I guess I'm saying the latter.  Maybe if you explained when such use
cases arise, I will agree with you.  But in any case, it's a different
use case.