bug#40845: SVG rendering issues

[Pip Cet]

On Sun, Apr 26, 2020 at 2:38 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

A more general one, and a more limited and specific one. As it
happens, the fix for the more general one is simpler.

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

Indeed. You're right about that. We should use dynamically-generated
image specs for them. That's what my patch allows for.

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

Yes.

> If so, which one of them can do the stuff
> Clément reported missing?

Err, who said they could? I'm saying they _shouldn't_. It's not the
image backend's job to alter and adapt an image, just to read a
compressed version of a bitmap and uncompress it, interpreting
whatever method of compression (say, vectorization) was chosen.

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

As opposed to doing them when the spec is evaluated?

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

That's what I'm proposing: call a Lisp program to prepare a spec
whenever we display the glyph. Not more often, which is wasteful.

Except you're currently wrong: a Lisp program cannot prepare "the
spec" accordingly, because there might be several required specs in
effect at the same time, for example.

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

Yes, that describes what I'm doing, except for the important point
that the spec is generated per occurence of the glyph rather than once
globally.

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

It's strict containment: my use case is more general.

> > > 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 did read the discussion, and the main thing mentioned about their
colors is that they shouldn't be fixed, i.e. not "left alone".

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

My impression is you're treating extensibility itself as something to
be avoided, not as something on the benefit side of a cost-benefit
analysis (cost: 5 lines of actual code. benefit: solves both the more
specific use case sought here and the more general use case I need).

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

A more general one.

As to how they arise: mathematicians, for example, have a
long-standing tradition of making up symbols. Those new symbols aren't
(and shouldn't be) in Unicode, and there are many other symbols that,
for example, cannot be in Unicode for legal or ethical reasons. Users
should be able to display such symbols in an Emacs buffer and have
them be as close to character glyphs (or different from them) as they
are willing to make them.

I remain convinced that I'm not smart enough to figure out in advance
the precise set of use cases I want a feature for. You shouldn't limit
generality to handle only those cases you're convinced are useful.