GNU bug report logs - #40845
SVG rendering issues

Previous Next

Package: emacs;

Reported by: Clément Pit-Claudel <cpitclaudel <at> gmail.com>

Date: Sat, 25 Apr 2020 12:20:01 UTC

Severity: normal

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org
Subject: bug#40845: SVG rendering issues
Date: Sat, 25 Apr 2020 17:38:31 +0000
On Sat, Apr 25, 2020 at 4:10 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sat, 25 Apr 2020 15:48:39 +0000
> > Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org
> >
> > On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii <eliz <at> 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.




This bug report was last modified 4 years and 271 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.