GNU bug report logs - #40845
SVG rendering issues

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org
Subject: bug#40845: SVG rendering issues
Date: Sat, 25 Apr 2020 21:07:12 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 25 Apr 2020 17:38:31 +0000
> Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org
> 
> 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.

Then I guess I don't understand your implementation at all.

Previous Next

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