GNU bug report logs - #51556
29.0.50; Poor contrast of Customize SVG icons with dark backgrounds

Previous Next

Full log

Message #56 received at 51556 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: 51556 <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
Subject: Re: bug#51556: 29.0.50; Poor contrast of Customize SVG icons with
 dark backgrounds
Date: Tue, 2 Nov 2021 11:43:58 -0700

On 11/2/2021 11:01 AM, Eli Zaretskii wrote:
> If the solution you propose only works for SVG that specify no
> foreground, then it won't be able to solve all of the situations where
> a different theme makes an icon barely visible or unpleasant to the
> eye.  Which is why I think a better solution would be to allow themes
> to specify different icons where necessary.

I think it might help to break this problem down into parts. There are a 
few cases I can think of where the question of how to color an SVG might 
come up:

1) Single-color SVGs

Some SVGs are just a single-color shape, like the Customize arrows. 
There's no *particular* color that's right for these, aside from "what 
looks good". In some ways, these SVGs are like an ordinary textual 
glyph, except that we've defined our own fancy shape to use. In this 
case, I think it makes sense to be able to specify what color to use for 
the SVG independently of the shape so that themes can adjust it as-needed.

This case is the one initially described in this bug.

2) Multi-color SVGs

Some SVGs have many colors. There's a particular set of colors that 
makes sense for this SVG, as defined in the file by the author. It would 
be difficult to programmatically alter the colors of such an SVG and 
maintain a good result, so we probably shouldn't try. This is a case 
where it may be nice to let themes specify a completely-different SVG to 
use.

I'd consider this lower priority, since I'm not aware of a specific SVG 
in this category that's causing visual issues with themes.

3) Dynamically-colored SVGs

This could be considered a variant of (1). Sometimes, we might want to 
define a particular shape, but give it different colors in different 
contexts. For example, if we wanted to use SVGs to display something 
similar to the circles in the fringe that mark GDB breakpoints, we could 
have a single breakpoint.svg file that we color bright red or gray 
depending on the breakpoint's state.

This is another case where it would be convenient to be able to set an 
SVG's color independently of its shape.

4) Third-party packages

Some packages might want to provide SVG icons to use in one way or 
another, along the same lines as the Customize arrows (i.e. a 
single-color SVG). If you're the author of a little-known package, you 
can't really expect theme authors to provide customized icons for your 
package that fit with the theme. However, themes *do* specify at least a 
handful of faces. As a package author, it would be convenient to be able 
to say "render this icon using the foreground color of the `error' 
face", for example. Then your package looks good with most themes 
without requiring anyone to provide custom SVGs.

Previous Next

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