From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefan@marxist.se>
Cc: 51556@debbugs.gnu.org, kevin.legouguec@gmail.com
Subject: bug#51556: 29.0.50; Poor contrast of Customize SVG icons with dark backgrounds
Date: Tue, 2 Nov 2021 11:43:58 -0700 [thread overview]
Message-ID: <18066bc0-86a6-5901-9a53-e2c6ea13fbc8@gmail.com> (raw)
In-Reply-To: <83a6imjv2o.fsf@gnu.org>
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.
next prev parent reply other threads:[~2021-11-02 18:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 17:56 bug#51556: 29.0.50; Poor contrast of Customize SVG icons with dark backgrounds Kévin Le Gouguec
2021-11-01 19:14 ` Eli Zaretskii
2021-11-01 20:10 ` Kévin Le Gouguec
2021-11-02 12:40 ` Eli Zaretskii
2021-11-01 20:49 ` Jim Porter
2021-11-02 12:49 ` Eli Zaretskii
2021-11-02 14:41 ` Stefan Kangas
2021-11-02 14:59 ` Eli Zaretskii
2021-11-02 15:17 ` Stefan Kangas
2021-11-02 15:26 ` Stefan Kangas
2021-11-02 16:38 ` Eli Zaretskii
2021-11-02 16:43 ` Lars Ingebrigtsen
2021-11-02 17:01 ` Stefan Kangas
2021-11-02 17:13 ` Eli Zaretskii
2021-11-02 17:44 ` Stefan Kangas
2021-11-02 18:01 ` Eli Zaretskii
2021-11-02 18:43 ` Stefan Kangas
2021-11-02 18:53 ` Eli Zaretskii
2021-11-02 19:26 ` Stefan Kangas
2021-11-02 18:43 ` Jim Porter [this message]
2021-11-02 18:58 ` Stefan Kangas
2021-11-02 19:15 ` Eli Zaretskii
2021-11-02 19:44 ` Stefan Kangas
2021-11-02 20:19 ` Alan Third
2021-11-02 22:56 ` Kévin Le Gouguec
2021-11-04 8:11 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18066bc0-86a6-5901-9a53-e2c6ea13fbc8@gmail.com \
--to=jporterbugs@gmail.com \
--cc=51556@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=kevin.legouguec@gmail.com \
--cc=stefan@marxist.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.