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: Alan Third <alan <at> idiocy.org>
Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: bug#40845: SVG rendering issues
Date: Sun, 03 May 2020 22:17:49 +0300

> Date: Sun, 3 May 2020 19:38:39 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org, pipcet <at> gmail.com
> 
> > > One thing is that it gets the foreground colour from the default face
> > > instead of the current face. I’m not sure how to solve that.
> > 
> > Can you describe the difficulty in using the current face?
> 
> I’m mostly unsure how I access it. I don’t think images or image.c
> have any real concept of where they are in the buffer.

When the 'load' method (in your case, svg_load) is called from
prepare_image_for_display, we have the face information handy.
Usually, at that point we don't call the 'load' method, because the
image is already loaded and cached.  But we could change the logic if
we know that the image must be modified to have a different face.
Then we can pass the color information to the 'load' method.

> I think we’d also have to recreate the image any time the face
> changed.

Yes, because changing the color(s) makes a different image.  But that
is not a problem, I think.

> I feel it would be easier just to have two or more cached images with
> different foreground and backgrounds as required.

Agreed.  At least as the first approximation; we could always change
that later if we find this not to be good enough.

Previous Next

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