bug#40845: SVG rendering issues

[Pip Cet]

On Sat, Apr 25, 2020 at 4:10 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sat, 25 Apr 2020 15:48:39 +0000
> > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org
> >
> > On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > I don't think I understand why we need to call a function for this.
> > > This is about displaying an image with a specific background color,
> > > isn't it?
> >
> > Even if the problem were just the choice of background color, that
> > would require significant and non-trivial changes for some cases: for
> > example, an emoji might have to choose foreground colors that provide
> > sufficient contrast to the background color, and antialiasing and
> > sub-pixel rendering would also need to be taken into account.
>
> We are talking about displaying images, not characters, right?

Correct: images which behave like character glyphs, but don't actually
have character codepoints, and aren't implemented by fonts.

> So why are emoji relevant to this?

An emoji is an example of an image which needs to know face properties
to blend in, or stick out, or whatever it is people who use them want
to happen. The intention was not that you'd use an emoji codepoint and
a font providing a character for that codepoint, which is a silly way
of implementing emoji.

> > I want to be able to define something that behaves like a character,
> > including displaying differently in different frames and depending
> > on different face parameters such as weight, slant, and RTL-ness.
>
> All of that is possible with images, so I don't think I understand why
> we need to handle this as a character.

Yes, my approach uses images, and no, it doesn't "handle this as a
character". It makes the glyph's apparent behavior match that of
character glyphs, while actually displaying an image spec which
changes with the properties of surrounding text, etc.

> This very bug report was filed
> because I said we shouldn't use characters and fonts for these
> purposes, so let's not discuss that alternative, please, at least not
> here.

No one was.