[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40845: SVG rendering issues
From: |
Alan Third |
Subject: |
bug#40845: SVG rendering issues |
Date: |
Sun, 26 Apr 2020 22:17:41 +0100 |
On Sat, Apr 25, 2020 at 06:46:51PM +0100, Alan Third wrote:
> On Sat, Apr 25, 2020 at 01:24:13PM -0400, Clément Pit-Claudel wrote:
> > On 25/04/2020 13.02, Eli Zaretskii wrote:
> > > IMO the foreground of an image shouldn't be affected by the
> > > current face's foreground. Images should come with their own colors,
> > > and be displayed like that. I think in the context of the discussion
> > > that led to this bug report it's actually almost a must: we want
> > > images with attractive colors to serve as the icons, we don't want
> > > them to be affected by whatever face happens to be nearby.
> >
> > Yes, of course: if an image has a foreground color, it should be
> > respected. But it's not uncommon for SVG images to not include a
> > foreground color, as shown in the repro. In that case, the image
> > should use the current foreground color, I think. (of course, a
> > :foreground keyword, if any, should take precedence; that is issue
> > 4).
>
> Lars fixed the foreground issue for eww by wrapping svg files in
> another svg. See svg--wrap-svg in shr.el (bug#37159).
>
> I think this is the only practical way to handle svg files with no
> foreground colour set. To do this when loading _any_ svg we’d probably
> have to move it into create-image or image.c.
FWIW, with some experimentation I’ve found that this wrapping method
can easily sort the scaling problems too.
The process would have to go, roughly:
* load the svg code
* parse it with librsvg
* extract the size
* calculate the new size (compute_image_size in image.c should work
fine)
* base64 encode the original svg
* wrap it in the new svg code
* parse
* produce the bitmap
Then we’re probably as well skipping all the matrix calculation stuff,
the same as we do for ImageMagick, as the bitmap should be the exact
size we want.
I’m happy to give this a go, but I’m not sure about base64 encoding.
Do we already have a way of doing that to a char buffer?
--
Alan Third
- bug#40845: SVG rendering issues, (continued)
bug#40845: SVG rendering issues, Eli Zaretskii, 2020/04/25
- bug#40845: SVG rendering issues, Clément Pit-Claudel, 2020/04/25
- bug#40845: SVG rendering issues, Eli Zaretskii, 2020/04/25
- bug#40845: SVG rendering issues, Clément Pit-Claudel, 2020/04/25
- bug#40845: SVG rendering issues, Alan Third, 2020/04/25
- bug#40845: SVG rendering issues, Pip Cet, 2020/04/25
- bug#40845: SVG rendering issues,
Alan Third <=
- bug#40845: SVG rendering issues, Clément Pit-Claudel, 2020/04/26
- bug#40845: SVG rendering issues, Alan Third, 2020/04/27
- bug#40845: SVG rendering issues, Clément Pit-Claudel, 2020/04/27
bug#40845: SVG rendering issues, Eli Zaretskii, 2020/04/26