GNU bug report logs -
#77841
Some svg image's black color is replaced by emacs's theme foreground color
Previous Next
To reply to this bug, email your comments to 77841 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Wed, 16 Apr 2025 12:16:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Billy Lei <LeiYiXia29 <at> outlook.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 16 Apr 2025 12:16:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I found this issue when debugging org LaTeX preview, see
https://list.orgmode.org/87cydchjqn.fsf <at> gmail.com/T/#ed7ba8310f82e8be8a2e7360df1568ed485434df3
> When using themes with background color set to #000000, and org-preview-default-process is set to dvisvgm, the LaTeX fragments are displayed incorrectly.
>
> To reduplicate:
>
> 1. Switch to a theme with background color set to #000000 (like Modus Vivendi)
> 2. Set org-preview-default-latex-process to dvisvgm
> 3. Create an org-mode document. Write some LaTeX fragment and press C-c C-x C-l to preview LaTeX fragment.
> 4. The LaTeX preview is displayed as a white rectangle.
>
> After debugging, I found that it is because dvisvgm omitts the default #000 color value when generating SVG file, and emacs has a unique way of displaying the SVG, which caused foreground color to be applied to it.
>
> A solution is to change org-format-latex-options to use transparent background by default. I've attached this fix.
It turned out that emacs displays svg images differently compared to an
image viewer. I can reduplicate this issue when I use emacs to view this
svg image, which emacs replaces the image's black color with the current
theme's foreground color:
https://commons.wikimedia.org/wiki/File:Flag_of_the_German_Democratic_Republic.svg
See also (Chinese): https://emacs-china.org/t/emacs-30-1-svg/29217
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Wed, 16 Apr 2025 12:56:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 77841 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 16 Apr 2025 20:09:46 +0800
> From: Billy Lei <LeiYiXia29 <at> outlook.com>
>
> I found this issue when debugging org LaTeX preview, see
> https://list.orgmode.org/87cydchjqn.fsf <at> gmail.com/T/#ed7ba8310f82e8be8a2e7360df1568ed485434df3
>
> > When using themes with background color set to #000000, and org-preview-default-process is set to dvisvgm, the LaTeX fragments are displayed incorrectly.
> >
> > To reduplicate:
> >
> > 1. Switch to a theme with background color set to #000000 (like Modus Vivendi)
> > 2. Set org-preview-default-latex-process to dvisvgm
> > 3. Create an org-mode document. Write some LaTeX fragment and press C-c C-x C-l to preview LaTeX fragment.
> > 4. The LaTeX preview is displayed as a white rectangle.
> >
> > After debugging, I found that it is because dvisvgm omitts the default #000 color value when generating SVG file, and emacs has a unique way of displaying the SVG, which caused foreground color to be applied to it.
> >
> > A solution is to change org-format-latex-options to use transparent background by default. I've attached this fix.
>
> It turned out that emacs displays svg images differently compared to an
> image viewer. I can reduplicate this issue when I use emacs to view this
> svg image, which emacs replaces the image's black color with the current
> theme's foreground color:
>
> https://commons.wikimedia.org/wiki/File:Flag_of_the_German_Democratic_Republic.svg
>
> See also (Chinese): https://emacs-china.org/t/emacs-30-1-svg/29217
Yes, this is a feature. I think to disable it, you need to include a
:background setting in the image spec. Alan, am I right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Wed, 16 Apr 2025 16:23:06 GMT)
Full text and
rfc822 format available.
Message #11 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 16, 2025 at 03:55:08PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 16 Apr 2025 20:09:46 +0800
> > From: Billy Lei <LeiYiXia29 <at> outlook.com>
> >
> > I found this issue when debugging org LaTeX preview, see
> > https://list.orgmode.org/87cydchjqn.fsf <at> gmail.com/T/#ed7ba8310f82e8be8a2e7360df1568ed485434df3
> >
> > > When using themes with background color set to #000000, and org-preview-default-process is set to dvisvgm, the LaTeX fragments are displayed incorrectly.
> > >
> > > To reduplicate:
> > >
> > > 1. Switch to a theme with background color set to #000000 (like Modus Vivendi)
> > > 2. Set org-preview-default-latex-process to dvisvgm
> > > 3. Create an org-mode document. Write some LaTeX fragment and press C-c C-x C-l to preview LaTeX fragment.
> > > 4. The LaTeX preview is displayed as a white rectangle.
> > >
> > > After debugging, I found that it is because dvisvgm omitts the default #000 color value when generating SVG file, and emacs has a unique way of displaying the SVG, which caused foreground color to be applied to it.
> > >
> > > A solution is to change org-format-latex-options to use transparent background by default. I've attached this fix.
> >
> > It turned out that emacs displays svg images differently compared to an
> > image viewer. I can reduplicate this issue when I use emacs to view this
> > svg image, which emacs replaces the image's black color with the current
> > theme's foreground color:
> >
> > https://commons.wikimedia.org/wiki/File:Flag_of_the_German_Democratic_Republic.svg
> >
> > See also (Chinese): https://emacs-china.org/t/emacs-30-1-svg/29217
>
> Yes, this is a feature. I think to disable it, you need to include a
> :background setting in the image spec. Alan, am I right?
Yes, but in this particular case :foreground, probably.
This behaviour is documented in the elisp manual under "SVG Images"
and is intended to make it easier to insert images into buffers so
they look like native widgets and the like.
We only set the default foreground and background colours, we don't
override explicitly set colours. The easiest work-around for someone
generating an SVG for display in Emacs is to just not set foreground
and background colours at all, and then they'll both match the current
theme (and also work correctly in web browsers).
(IMHO if an SVG needs a specific colour, like the black in the German
flag above, it should be setting the colour explicitly, rather than
relying on the image viewer's default settings.)
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Thu, 17 Apr 2025 10:18:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Does emacs exists some options that can be customized to make svg image spec use black as the foreground color by default? IMO users should be able to change this behavior, so that emacs can be compatible with svg images that don't set the #000000 color explicitly.
发自我的 iPad
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Thu, 17 Apr 2025 11:00:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 77841 <at> debbugs.gnu.org (full text, mbox):
> From: Lei Billy <LeiYiXia29 <at> outlook.com>
> CC: Eli Zaretskii <eliz <at> gnu.org>, "77841 <at> debbugs.gnu.org"
> <77841 <at> debbugs.gnu.org>
> Date: Thu, 17 Apr 2025 10:16:48 +0000
>
> Does emacs exists some options that can be customized to make svg image spec use black as the foreground color by default? IMO users should be able to change this behavior, so that emacs can be compatible with svg images that don't set the #000000 color explicitly.
I don't understand why you say this. Emacs behaves with SVG images as
it does with text: the colors of the face override the default colors.
IOW, it's a feature, not a bug. As Alan says, images that want to
display specific colors should specify that in the image spec.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Thu, 17 Apr 2025 11:24:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Lei Billy <LeiYiXia29 <at> outlook.com> writes:
> Does emacs exists some options that can be customized to make svg
> image spec use black as the foreground color by default? IMO users
> should be able to change this behavior, so that emacs can be
> compatible with svg images that don't set the #000000 color
> explicitly.
I don't think there is an option for this but FWIW, DocView (when
producing SVG) does exactly this with its own face (`doc-view-svg-face')
that forces black on white by default.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 19 Apr 2025 08:59:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> writes:
>> Yes, this is a feature. I think to disable it, you need to include a
>> :background setting in the image spec. Alan, am I right?
>
> Yes, but in this particular case :foreground, probably.
>
> This behaviour is documented in the elisp manual under "SVG Images"
> and is intended to make it easier to insert images into buffers so
> they look like native widgets and the like.
I am still confused.
Consider the attached svg image.
If I emacs -Q org-ltximg_404bde694c76aad6deecfc21e91c044a6afd7948.svg
I see black background and white foreground.
If I
1. emacs -Q
2. (put-text-property 1 2 'display (create-image "/tmp/ltximg/org-ltximg_404bde694c76aad6deecfc21e91c044a6afd7948.svg"))
I see red-ish background and white foreground.
Seemingly, background and foreground are inverted in the second case.
What am I missing?
[org-ltximg_404bde694c76aad6deecfc21e91c044a6afd7948.svg (image/svg+xml, attachment)]
[Message part 3 (text/plain, inline)]
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 19 Apr 2025 10:02:04 GMT)
Full text and
rfc822 format available.
Message #26 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Sat, Apr 19, 2025 at 08:57:55AM +0000, Ihor Radchenko wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> >> Yes, this is a feature. I think to disable it, you need to include a
> >> :background setting in the image spec. Alan, am I right?
> >
> > Yes, but in this particular case :foreground, probably.
> >
> > This behaviour is documented in the elisp manual under "SVG Images"
> > and is intended to make it easier to insert images into buffers so
> > they look like native widgets and the like.
>
> I am still confused.
> Consider the attached svg image.
>
> If I emacs -Q org-ltximg_404bde694c76aad6deecfc21e91c044a6afd7948.svg
> I see black background and white foreground.
>
> If I
> 1. emacs -Q
> 2. (put-text-property 1 2 'display (create-image "/tmp/ltximg/org-ltximg_404bde694c76aad6deecfc21e91c044a6afd7948.svg"))
> I see red-ish background and white foreground.
>
> Seemingly, background and foreground are inverted in the second case.
>
> What am I missing?
The image draws a rectangle in the current foreground colour, black in
the first case and red in the second, and then fills the text with
"#fff".
<g fill='#fff'>
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 19 Apr 2025 11:39:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
>> Consider the attached svg image.
>> ...
>> Seemingly, background and foreground are inverted in the second case.
>>
>> What am I missing?
>
> The image draws a rectangle in the current foreground colour, black in
> the first case and red in the second, and then fills the text with
> "#fff".
>
> <g fill='#fff'>
This image was generated by dvisvgm.
It indeed explicitly draws a rectangle over the page, effectively
inverting background and foreground (Emacs has no reason to apply
background color to the rect object fill).
That's unfortunate, but explains the observed behavior.
Feel free to close this bug report.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sun, 20 Apr 2025 09:12:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Sat, Apr 19, 2025 at 11:37:35AM +0000, Ihor Radchenko wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> >> Consider the attached svg image.
> >> ...
> >> Seemingly, background and foreground are inverted in the second case.
> >>
> >> What am I missing?
> >
> > The image draws a rectangle in the current foreground colour, black in
> > the first case and red in the second, and then fills the text with
> > "#fff".
> >
> > <g fill='#fff'>
>
> This image was generated by dvisvgm.
> It indeed explicitly draws a rectangle over the page, effectively
> inverting background and foreground (Emacs has no reason to apply
> background color to the rect object fill).
I don't understand what you mean, because it doesn't apply the
background colour to the rect. It shows as white on red. Red is the
foreground colour: the surrounding text is red. This is exactly the
same as the first case where the rect is filled with black because
black is the foreground colour.
If you believe Emacs should behave differently then I don't see any
reason why we can't change it, as long as it still allows the use of
SVGs inline as widgets or icons, etc. without forcing the programmer
to explicitly handle changes to colours when faces change, or the
mouse hovers over the line, etc.
I'm not an expert in SVG, so it's quite possible there's a better way
of doing this that I don't know.
If someone does have a proposal I'd suggest it should probably be made
in emacs-devel, because it will be a change to behaviour that will
likely interest anyone who already uses SVGs, and please Cc me in as I
don't read emacs-devel regularly.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sun, 20 Apr 2025 12:21:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
>> This image was generated by dvisvgm.
>> It indeed explicitly draws a rectangle over the page, effectively
>> inverting background and foreground (Emacs has no reason to apply
>> background color to the rect object fill).
>
> I don't understand what you mean, because it doesn't apply the
> background colour to the rect. It shows as white on red. Red is the
> foreground colour: the surrounding text is red. This is exactly the
> same as the first case where the rect is filled with black because
> black is the foreground colour.
You are right, but you may be missing the context I am coming from.
For me, the image is generated from latex fragment \(x^2=2\) by (1)
generating dvi file with foreground and background taken from 'default
face; (2) converting the dvi file to svg.
The tex file roughly looks like
\begin{document}
\definecolor{fg}{rgb}{1,1,1}
\definecolor{bg}{rgb}{0,0,0}
\pagecolor{bg}
{\color{fg}
\(x^2=3\)
}
You see that we set foreground and background explicitly.
The .dvi file still keeps the background color setting
> ...background rgb 0 0 0�color push rgb 1 1 1
However, after passing through dvisvgm, we background color information
is lost because the background is simulated by placing black rectangle:
<?xml version='1.0' encoding='UTF-8'?>
<!-- This file was generated by dvisvgm 3.4 -->
<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='32.302787pt' height='9.867978pt' viewBox='-16.60823 10.605991 32.302787 9.867978'>
...
<g id='page1' transform='matrix(1.165714 0 0 1.165714 0 0)'>
<rect x='-14.247256' y='9.098277' width='27.710724' height='8.465177'/>
<g fill='#fff'>
<use x='-14.536172' y='17.344276' xlink:href='#g0-120'/>
<use x='-8.84224' y='13.728912' xlink:href='#g2-50'/>
<use x='-1.605538' y='17.344276' xlink:href='#g1-61'/>
<use x='8.910542' y='17.344276' xlink:href='#g1-51'/>
</g>
</g>
</svg>
Note that setting fill property directly will yield normal result in the
resulting svg:
<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='32.302787pt' height='9.867978pt' viewBox='-16.60823 10.605991 32.302787 9.867978' fill='#000'>
However, dvisvgm does _not_ use this method simply because it is not
fully portable - some browsers and svg viewers ignore fill
attribute. So, drawing background rectangle is often recommended for
svg. It is also apparently a common practice.
> If you believe Emacs should behave differently then I don't see any
> reason why we can't change it, as long as it still allows the use of
> SVGs inline as widgets or icons, etc. without forcing the programmer
> to explicitly handle changes to colours when faces change, or the
> mouse hovers over the line, etc.
I am not sure if Emacs should behave differently in this scenario or
not. It may be a judgment call and may also be non-trivial to implement.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sun, 20 Apr 2025 12:57:07 GMT)
Full text and
rfc822 format available.
Message #38 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Sun, Apr 20, 2025 at 12:19:02PM +0000, Ihor Radchenko wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> >> This image was generated by dvisvgm.
> >> It indeed explicitly draws a rectangle over the page, effectively
> >> inverting background and foreground (Emacs has no reason to apply
> >> background color to the rect object fill).
> >
> > I don't understand what you mean, because it doesn't apply the
> > background colour to the rect. It shows as white on red. Red is the
> > foreground colour: the surrounding text is red. This is exactly the
> > same as the first case where the rect is filled with black because
> > black is the foreground colour.
>
> You are right, but you may be missing the context I am coming from.
>
<snip explanation>
>
> However, dvisvgm does _not_ use this method simply because it is not
> fully portable - some browsers and svg viewers ignore fill
> attribute. So, drawing background rectangle is often recommended for
> svg. It is also apparently a common practice.
Having reviewed our code we actually set the background the same way,
by drawing a background coloured rectangle then inserting the SVG over
it.
I did a little digging and it looks as though explicitly setting the
foreground colour to black is often considered bad practice, which I
guess is why we see this a lot, although that practice is
inconsistently applied. Even that German flag earlier in the thread
didn't set the fill colour, but did set the stroke colour to black.
> > If you believe Emacs should behave differently then I don't see any
> > reason why we can't change it, as long as it still allows the use of
> > SVGs inline as widgets or icons, etc. without forcing the programmer
> > to explicitly handle changes to colours when faces change, or the
> > mouse hovers over the line, etc.
>
> I am not sure if Emacs should behave differently in this scenario or
> not. It may be a judgment call and may also be non-trivial to implement.
To be frank it probably should, but I don't know exactly *how* it
should behave.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 08:21:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 77841 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 20 Apr 2025 13:56:37 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77841 <at> debbugs.gnu.org,
> Billy Lei <LeiYiXia29 <at> outlook.com>
>
> On Sun, Apr 20, 2025 at 12:19:02PM +0000, Ihor Radchenko wrote:
> > Alan Third <alan <at> idiocy.org> writes:
> >
> > >> This image was generated by dvisvgm.
> > >> It indeed explicitly draws a rectangle over the page, effectively
> > >> inverting background and foreground (Emacs has no reason to apply
> > >> background color to the rect object fill).
> > >
> > > I don't understand what you mean, because it doesn't apply the
> > > background colour to the rect. It shows as white on red. Red is the
> > > foreground colour: the surrounding text is red. This is exactly the
> > > same as the first case where the rect is filled with black because
> > > black is the foreground colour.
> >
> > You are right, but you may be missing the context I am coming from.
> >
> <snip explanation>
> >
> > However, dvisvgm does _not_ use this method simply because it is not
> > fully portable - some browsers and svg viewers ignore fill
> > attribute. So, drawing background rectangle is often recommended for
> > svg. It is also apparently a common practice.
>
> Having reviewed our code we actually set the background the same way,
> by drawing a background coloured rectangle then inserting the SVG over
> it.
>
> I did a little digging and it looks as though explicitly setting the
> foreground colour to black is often considered bad practice, which I
> guess is why we see this a lot, although that practice is
> inconsistently applied. Even that German flag earlier in the thread
> didn't set the fill colour, but did set the stroke colour to black.
>
> > > If you believe Emacs should behave differently then I don't see any
> > > reason why we can't change it, as long as it still allows the use of
> > > SVGs inline as widgets or icons, etc. without forcing the programmer
> > > to explicitly handle changes to colours when faces change, or the
> > > mouse hovers over the line, etc.
> >
> > I am not sure if Emacs should behave differently in this scenario or
> > not. It may be a judgment call and may also be non-trivial to implement.
>
> To be frank it probably should, but I don't know exactly *how* it
> should behave.
Do we have anything else to do here, or should this bug be closed
now?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 09:12:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > I am not sure if Emacs should behave differently in this scenario or
>> > not. It may be a judgment call and may also be non-trivial to implement.
>>
>> To be frank it probably should, but I don't know exactly *how* it
>> should behave.
>
> Do we have anything else to do here, or should this bug be closed
> now?
There is a clear bug - some svgs are displayed differently than
intended. But it is not clear how to solve it best.
Something to do: decide how to solve it. (but I have no good ideas)
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 10:19:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 77841 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Alan Third <alan <at> idiocy.org>, 77841 <at> debbugs.gnu.org, LeiYiXia29 <at> outlook.com
> Date: Sat, 03 May 2025 09:10:16 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> > I am not sure if Emacs should behave differently in this scenario or
> >> > not. It may be a judgment call and may also be non-trivial to implement.
> >>
> >> To be frank it probably should, but I don't know exactly *how* it
> >> should behave.
> >
> > Do we have anything else to do here, or should this bug be closed
> > now?
>
> There is a clear bug - some svgs are displayed differently than
> intended. But it is not clear how to solve it best.
> Something to do: decide how to solve it. (but I have no good ideas)
If we have no idea how to solve this, we should not keep the bug open.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 10:26:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 77841 <at> debbugs.gnu.org (full text, mbox):
在 2025/5/3 17:10, Ihor Radchenko 写道:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>>> I am not sure if Emacs should behave differently in this scenario or
>>>> not. It may be a judgment call and may also be non-trivial to implement.
>>>
>>> To be frank it probably should, but I don't know exactly *how* it
>>> should behave.
>>
>> Do we have anything else to do here, or should this bug be closed
>> now?
>
> There is a clear bug - some svgs are displayed differently than
> intended. But it is not clear how to solve it best.
> Something to do: decide how to solve it. (but I have no good ideas)
>
Perhaps we can let users decide it. We can introuduce a variable to
customize how the svg images are displayed in Emacs, whether to use the
theme foreground color or black.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 11:12:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Billy Lei <LeiYiXia29 <at> outlook.com> writes:
> 在 2025/5/3 17:10, Ihor Radchenko 写道:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>>> I am not sure if Emacs should behave differently in this scenario or
>>>>> not. It may be a judgment call and may also be non-trivial to implement.
>>>>
>>>> To be frank it probably should, but I don't know exactly *how* it
>>>> should behave.
>>>
>>> Do we have anything else to do here, or should this bug be closed
>>> now?
>> There is a clear bug - some svgs are displayed differently than
>> intended. But it is not clear how to solve it best.
>> Something to do: decide how to solve it. (but I have no good ideas)
>>
>
> Perhaps we can let users decide it. We can introuduce a variable to
> customize how the svg images are displayed in Emacs, whether to use
> the theme foreground color or black.
Yes I do think the same. For example, we could have something like
'svg-implicit-black' that is nil by default. It would be one "simple"
step to improve on this issue (the hard part being having this behaviour
in documents and correct widget look and feel at the same time).
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 11:15:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
> Yes I do think the same. For example, we could have something like
> 'svg-implicit-black' that is nil by default. It would be one "simple"
> step to improve on this issue (the hard part being having this behaviour
> in documents and correct widget look and feel at the same time).
Could you tell me more about "widget look and feel"?
Is it about some very specific use case of svgs in Emacs?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 12:11:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Ihor Radchenko <yantar92 <at> posteo.net> writes:
> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>
>> Yes I do think the same. For example, we could have something like
>> 'svg-implicit-black' that is nil by default. It would be one "simple"
>> step to improve on this issue (the hard part being having this behaviour
>> in documents and correct widget look and feel at the same time).
>
> Could you tell me more about "widget look and feel"?
> Is it about some very specific use case of svgs in Emacs?
I was refering to the first comment Alan made in this thread. The
example that comes to my mind is the customize interface: some settings
are toggle buttons that are rendered with SVG provided with Emacs and
that will have the correct (i.e., same as default face) foreground and
background values.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 12:15:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>> Could you tell me more about "widget look and feel"?
>> Is it about some very specific use case of svgs in Emacs?
>
> I was refering to the first comment Alan made in this thread. The
> example that comes to my mind is the customize interface: some settings
> are toggle buttons that are rendered with SVG provided with Emacs and
> that will have the correct (i.e., same as default face) foreground and
> background values.
I see. So, we are talking about svgs that are specifically designed with
current behavior in mind. May those svgs be marked to use foreground
color via image properties?
Alternatively, the proposed variable can be set locally in customize
buffers.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 14:51:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Ihor Radchenko <yantar92 <at> posteo.net> writes:
> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>
>>> Could you tell me more about "widget look and feel"?
>>> Is it about some very specific use case of svgs in Emacs?
>>
>> I was refering to the first comment Alan made in this thread. The
>> example that comes to my mind is the customize interface: some settings
>> are toggle buttons that are rendered with SVG provided with Emacs and
>> that will have the correct (i.e., same as default face) foreground and
>> background values.
>
> I see. So, we are talking about svgs that are specifically designed with
> current behavior in mind. May those svgs be marked to use foreground
> color via image properties?
Maybe there are other use case for such SVG: I cannot pretend I was
exhaustive.
> Alternatively, the proposed variable can be set locally in customize
> buffers.
If anything, I think I'd prefer this approach but maybe the other way
around: which buffers will need to have a default back/foreground to
black?
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 15:32:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Sat, May 03, 2025 at 04:50:24PM +0200, Manuel Giraud wrote:
> Ihor Radchenko <yantar92 <at> posteo.net> writes:
>
> > Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
> >
> >>> Could you tell me more about "widget look and feel"?
> >>> Is it about some very specific use case of svgs in Emacs?
> >>
> >> I was refering to the first comment Alan made in this thread. The
> >> example that comes to my mind is the customize interface: some settings
> >> are toggle buttons that are rendered with SVG provided with Emacs and
> >> that will have the correct (i.e., same as default face) foreground and
> >> background values.
> >
> > I see. So, we are talking about svgs that are specifically designed with
> > current behavior in mind. May those svgs be marked to use foreground
> > color via image properties?
>
> Maybe there are other use case for such SVG: I cannot pretend I was
> exhaustive.
I was thinking about this, but I couldn't remember where to find it.
Some searching helped:
https://github.com/rougier/svg-lib
But on digging into it it looks as though he's setting the SVG's
colours explicitly, probably for backward compatibility, so hopefully
not an issue.
The widgets are designed to be used outside of customize, it's a
separate library. But we can still fix the widget library if
necessary.
> > Alternatively, the proposed variable can be set locally in customize
> > buffers.
>
> If anything, I think I'd prefer this approach but maybe the other way
> around: which buffers will need to have a default back/foreground to
> black?
This is already how it works, the caller can set the foreground and
background to black and white if they want.
Does anyone know anything about "CurrentColor" in CSS? I'm wondering
if that's our solution...
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 15:41:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> Does anyone know anything about "CurrentColor" in CSS? I'm wondering
> if that's our solution...
I do not know much, but from quick googling:
https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#currentcolor_keyword
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 03 May 2025 16:35:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, May 03, 2025 at 03:39:22PM +0000, Ihor Radchenko wrote:
>
> Alan Third <alan <at> idiocy.org> writes:
> > Does anyone know anything about "CurrentColor" in CSS? I'm wondering
> > if that's our solution...
>
> I do not know much, but from quick googling:
> https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#currentcolor_keyword
As far as I an tell the attached patch works for anything that comes
with Emacs itself. It may break any third-party SVG files used as
widgets, or just relying on the fill colour being set. I don't think
there's anything we can do about that if we want to change this
behaviour.
I don't know if anyone is actually using SVG files in that way, so
this may not be a real concern. I'd still suggest we probably want to
discuss this in Emacs devel to get it a little more visibility before
pushing it.
Needs documentation and news entry. But lets see if this actually
works for everyone first.
--
Alan Third
[0001-Change-foreground-color-handling-for-SVG-files-bug-7.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sun, 04 May 2025 17:18:03 GMT)
Full text and
rfc822 format available.
Message #77 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Sat, May 03, 2025 at 03:39:22PM +0000, Ihor Radchenko wrote:
>>
>> Alan Third <alan <at> idiocy.org> writes:
>> > Does anyone know anything about "CurrentColor" in CSS? I'm wondering
>> > if that's our solution...
>>
>> I do not know much, but from quick googling:
>> https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#currentcolor_keyword
>
> As far as I an tell the attached patch works for anything that comes
> with Emacs itself. It may break any third-party SVG files used as
> widgets, or just relying on the fill colour being set. I don't think
> there's anything we can do about that if we want to change this
> behaviour.
>
> I don't know if anyone is actually using SVG files in that way, so
> this may not be a real concern. I'd still suggest we probably want to
> discuss this in Emacs devel to get it a little more visibility before
> pushing it.
>
> Needs documentation and news entry. But lets see if this actually
> works for everyone first.
Thanks Alan. I've tested your patch and here is what I observe. What's
good:
- SVG Emacs "widgets" are still using the default face color and
are updating accordingly when changing theme
- I use Gnus and I see the same behaviour for the SVG icon in the
modeline
- The german flag example provided by Billy is displayed
correctly (filled with black where needed) whatever the theme
in use
- The example from Ihor shows 'x²=2' written in white on black
whatever the theme in use
What's not so good:
I use DocView (with mupdf to generate SVG pages) and I have set
'doc-view-svg-face' to "inherit default" so that DocView buffers are
also following the theme. This used to work but now, with this patch,
it does not render correctly. For example, the text stays black instead
of white with a dark background theme.
Maybe, it is something that should be fixed in DocView (?)
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sun, 04 May 2025 18:12:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, May 04, 2025 at 07:17:46PM +0200, Manuel Giraud wrote:
> Thanks Alan. I've tested your patch and here is what I observe. What's
> good:
>
> - SVG Emacs "widgets" are still using the default face color and
> are updating accordingly when changing theme
>
> - I use Gnus and I see the same behaviour for the SVG icon in the
> modeline
>
> - The german flag example provided by Billy is displayed
> correctly (filled with black where needed) whatever the theme
> in use
>
> - The example from Ihor shows 'x²=2' written in white on black
> whatever the theme in use
Thanks for checking.
> What's not so good:
>
> I use DocView (with mupdf to generate SVG pages) and I have set
> 'doc-view-svg-face' to "inherit default" so that DocView buffers are
> also following the theme. This used to work but now, with this patch,
> it does not render correctly. For example, the text stays black instead
> of white with a dark background theme.
>
> Maybe, it is something that should be fixed in DocView (?)
We could probably fix it by getting Docview to set the :css property
for the SVG image to something like:
svg {
fill: currentcolor;
}
Is the background OK?
The attached might work, but only if you're using librsvg 2.48 or
above... I can think of a way to fix *that* problem, but it'll need a
little more thought.
--
Alan Third
[0001-Use-css-to-set-SVG-foreground-in-docview.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Mon, 05 May 2025 14:45:03 GMT)
Full text and
rfc822 format available.
Message #83 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Sun, May 04, 2025 at 07:17:46PM +0200, Manuel Giraud wrote:
>> Thanks Alan. I've tested your patch and here is what I observe. What's
>> good:
>>
>> - SVG Emacs "widgets" are still using the default face color and
>> are updating accordingly when changing theme
>>
>> - I use Gnus and I see the same behaviour for the SVG icon in the
>> modeline
>>
>> - The german flag example provided by Billy is displayed
>> correctly (filled with black where needed) whatever the theme
>> in use
>>
>> - The example from Ihor shows 'x²=2' written in white on black
>> whatever the theme in use
>
> Thanks for checking.
>
>> What's not so good:
>>
>> I use DocView (with mupdf to generate SVG pages) and I have set
>> 'doc-view-svg-face' to "inherit default" so that DocView buffers are
>> also following the theme. This used to work but now, with this patch,
>> it does not render correctly. For example, the text stays black instead
>> of white with a dark background theme.
>>
>> Maybe, it is something that should be fixed in DocView (?)
>
> We could probably fix it by getting Docview to set the :css property
> for the SVG image to something like:
>
> svg {
> fill: currentcolor;
> }
>
> Is the background OK?
Yes, in DocView, the background follows the theme.
> The attached might work, but only if you're using librsvg 2.48 or
> above... I can think of a way to fix *that* problem, but it'll need a
> little more thought.
I'm using librsvg 2.60 but the attached does not fix the issue: the
foreground is still black no matter what. I have taken care of cleaning
the DocView cache directory before testing.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 17 May 2025 08:18:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 77841 <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>, Billy Lei
> <LeiYiXia29 <at> outlook.com>, Eli Zaretskii <eliz <at> gnu.org>,
> 77841 <at> debbugs.gnu.org
> Date: Mon, 05 May 2025 16:43:53 +0200
>
> Alan Third <alan <at> idiocy.org> writes:
>
> > On Sun, May 04, 2025 at 07:17:46PM +0200, Manuel Giraud wrote:
> >> Thanks Alan. I've tested your patch and here is what I observe. What's
> >> good:
> >>
> >> - SVG Emacs "widgets" are still using the default face color and
> >> are updating accordingly when changing theme
> >>
> >> - I use Gnus and I see the same behaviour for the SVG icon in the
> >> modeline
> >>
> >> - The german flag example provided by Billy is displayed
> >> correctly (filled with black where needed) whatever the theme
> >> in use
> >>
> >> - The example from Ihor shows 'x²=2' written in white on black
> >> whatever the theme in use
> >
> > Thanks for checking.
> >
> >> What's not so good:
> >>
> >> I use DocView (with mupdf to generate SVG pages) and I have set
> >> 'doc-view-svg-face' to "inherit default" so that DocView buffers are
> >> also following the theme. This used to work but now, with this patch,
> >> it does not render correctly. For example, the text stays black instead
> >> of white with a dark background theme.
> >>
> >> Maybe, it is something that should be fixed in DocView (?)
> >
> > We could probably fix it by getting Docview to set the :css property
> > for the SVG image to something like:
> >
> > svg {
> > fill: currentcolor;
> > }
> >
> > Is the background OK?
>
> Yes, in DocView, the background follows the theme.
>
> > The attached might work, but only if you're using librsvg 2.48 or
> > above... I can think of a way to fix *that* problem, but it'll need a
> > little more thought.
>
> I'm using librsvg 2.60 but the attached does not fix the issue: the
> foreground is still black no matter what. I have taken care of cleaning
> the DocView cache directory before testing.
So how should we proceed with this issue? Was it resolved?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 17 May 2025 11:13:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Sat, May 17, 2025 at 11:16:55AM +0300, Eli Zaretskii wrote:
> > I'm using librsvg 2.60 but the attached does not fix the issue: the
> > foreground is still black no matter what. I have taken care of cleaning
> > the DocView cache directory before testing.
>
> So how should we proceed with this issue? Was it resolved?
No, I need to revisit the patch, but I've not got time just now.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Thu, 22 May 2025 20:42:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Mon, May 05, 2025 at 04:43:53PM +0200, Manuel Giraud wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> > The attached might work, but only if you're using librsvg 2.48 or
> > above... I can think of a way to fix *that* problem, but it'll need a
> > little more thought.
>
> I'm using librsvg 2.60 but the attached does not fix the issue: the
> foreground is still black no matter what. I have taken care of cleaning
> the DocView cache directory before testing.
Hi Manuel,
Can you try loading an SVG like this:
(insert-image (create-image "~/Downloads/Flag_of_East_Germany.svg"
'svg nil :width 100 :css "svg{fill: green;}"))
The file I'm using is
https://upload.wikimedia.org/wikipedia/commons/a/a1/Flag_of_East_Germany.svg
and the top third of the flag shows as green. Do you still see it as
black?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Fri, 23 May 2025 10:19:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> writes:
> On Mon, May 05, 2025 at 04:43:53PM +0200, Manuel Giraud wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>>
>> > The attached might work, but only if you're using librsvg 2.48 or
>> > above... I can think of a way to fix *that* problem, but it'll need a
>> > little more thought.
>>
>> I'm using librsvg 2.60 but the attached does not fix the issue: the
>> foreground is still black no matter what. I have taken care of cleaning
>> the DocView cache directory before testing.
>
> Hi Manuel,
>
> Can you try loading an SVG like this:
>
> (insert-image (create-image "~/Downloads/Flag_of_East_Germany.svg"
> 'svg nil :width 100 :css "svg{fill: green;}"))
>
> The file I'm using is
> https://upload.wikimedia.org/wikipedia/commons/a/a1/Flag_of_East_Germany.svg
> and the top third of the flag shows as green. Do you still see it as
> black?
Hi Alan,
Here is what I get:
[2025-05-23T12:15+0200.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Fri, 23 May 2025 10:41:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Fri, May 23, 2025 at 12:18:26PM +0200, Manuel Giraud wrote:
> Hi Alan,
>
> Here is what I get:
Thank you. That's what I see too. Are you able to send me an example
SVG as generated by docview?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Fri, 23 May 2025 11:20:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> writes:
> On Fri, May 23, 2025 at 12:18:26PM +0200, Manuel Giraud wrote:
>> Hi Alan,
>>
>> Here is what I get:
>
> Thank you. That's what I see too. Are you able to send me an example
> SVG as generated by docview?
Sure. Here is some book with light theme and a dark theme (pretty
unreadable ;-)
[2025-05-23T13:15+0200.png (image/png, inline)]
[2025-05-23T13:16+0200.png (image/png, attachment)]
[Message part 4 (text/plain, inline)]
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Fri, 23 May 2025 12:28:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On 23 May 2025 12:19:15 BST, Manuel Giraud <manuel <at> ledu-giraud.fr> wrote:
>Alan Third <alan <at> idiocy.org> writes:
>
>> On Fri, May 23, 2025 at 12:18:26PM +0200, Manuel Giraud wrote:
>>> Hi Alan,
>>>
>>> Here is what I get:
>>
>> Thank you. That's what I see too. Are you able to send me an example
>> SVG as generated by docview?
>
>Sure. Here is some book with light theme and a dark theme (pretty
>unreadable ;-)
Sorry, is it possible to get a copy of the actual SVG file, please?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Fri, 23 May 2025 13:44:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> writes:
> On 23 May 2025 12:19:15 BST, Manuel Giraud <manuel <at> ledu-giraud.fr> wrote:
>>Alan Third <alan <at> idiocy.org> writes:
>>
>>> On Fri, May 23, 2025 at 12:18:26PM +0200, Manuel Giraud wrote:
>>>> Hi Alan,
>>>>
>>>> Here is what I get:
>>>
>>> Thank you. That's what I see too. Are you able to send me an example
>>> SVG as generated by docview?
>>
>>Sure. Here is some book with light theme and a dark theme (pretty
>>unreadable ;-)
>
> Sorry, is it possible to get a copy of the actual SVG file, please?
Here is an example from my docview cache.
[page-1.svg (image/svg+xml, attachment)]
[Message part 3 (text/plain, inline)]
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Fri, 23 May 2025 20:24:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Fri, May 23, 2025 at 03:42:53PM +0200, Manuel Giraud wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> > On 23 May 2025 12:19:15 BST, Manuel Giraud <manuel <at> ledu-giraud.fr> wrote:
> >>Alan Third <alan <at> idiocy.org> writes:
> >>
> >>> On Fri, May 23, 2025 at 12:18:26PM +0200, Manuel Giraud wrote:
> >>>> Hi Alan,
> >>>>
> >>>> Here is what I get:
> >>>
> >>> Thank you. That's what I see too. Are you able to send me an example
> >>> SVG as generated by docview?
> >>
> >>Sure. Here is some book with light theme and a dark theme (pretty
> >>unreadable ;-)
> >
> > Sorry, is it possible to get a copy of the actual SVG file, please?
>
> Here is an example from my docview cache.
Clearly an excellent document.
OK, I'm pretty sure that the first patch that affects image.c is
working right, which means my mediocre lisp skills are biting me here.
Can you try running
(concat "svg{fill:" (face-foreground 'doc-view-svg-face) "}")
and see what it returns?
Although it's only just now occurred to me that I have no idea what
face-foreground might return, presumably things that aren't CSS
compatible?
Hmm...
Can you try replacing line 1680 in lisp/doc-view.el with
:foreground (face-foreground 'doc-view-svg-face)
:css "svg{fill:currentcolor;}")))
I think that's the right number of brackets...
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 24 May 2025 07:49:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 77841 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 23 May 2025 21:23:45 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,
> Billy Lei <LeiYiXia29 <at> outlook.com>, Eli Zaretskii <eliz <at> gnu.org>,
> 77841 <at> debbugs.gnu.org
>
> On Fri, May 23, 2025 at 03:42:53PM +0200, Manuel Giraud wrote:
> > Alan Third <alan <at> idiocy.org> writes:
> >
> > > On 23 May 2025 12:19:15 BST, Manuel Giraud <manuel <at> ledu-giraud.fr> wrote:
> > >>Alan Third <alan <at> idiocy.org> writes:
> > >>
> > >>> On Fri, May 23, 2025 at 12:18:26PM +0200, Manuel Giraud wrote:
> > >>>> Hi Alan,
> > >>>>
> > >>>> Here is what I get:
> > >>>
> > >>> Thank you. That's what I see too. Are you able to send me an example
> > >>> SVG as generated by docview?
> > >>
> > >>Sure. Here is some book with light theme and a dark theme (pretty
> > >>unreadable ;-)
> > >
> > > Sorry, is it possible to get a copy of the actual SVG file, please?
> >
> > Here is an example from my docview cache.
>
> Clearly an excellent document.
>
> OK, I'm pretty sure that the first patch that affects image.c is
> working right, which means my mediocre lisp skills are biting me here.
>
> Can you try running
>
> (concat "svg{fill:" (face-foreground 'doc-view-svg-face) "}")
>
> and see what it returns?
>
> Although it's only just now occurred to me that I have no idea what
> face-foreground might return, presumably things that aren't CSS
> compatible?
>
> Hmm...
>
> Can you try replacing line 1680 in lisp/doc-view.el with
>
> :foreground (face-foreground 'doc-view-svg-face)
> :css "svg{fill:currentcolor;}")))
>
> I think that's the right number of brackets...
Btw, please test these with librsvg v2.40.x, because 2.50 and newer
versions require Rust to build them. So I'd like us to support those
older versions as much as reasonably possible.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 24 May 2025 17:58:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> writes:
> On Fri, May 23, 2025 at 03:42:53PM +0200, Manuel Giraud wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>>
>> > On 23 May 2025 12:19:15 BST, Manuel Giraud <manuel <at> ledu-giraud.fr> wrote:
>> >>Alan Third <alan <at> idiocy.org> writes:
>> >>
>> >>> On Fri, May 23, 2025 at 12:18:26PM +0200, Manuel Giraud wrote:
>> >>>> Hi Alan,
>> >>>>
>> >>>> Here is what I get:
>> >>>
>> >>> Thank you. That's what I see too. Are you able to send me an example
>> >>> SVG as generated by docview?
>> >>
>> >>Sure. Here is some book with light theme and a dark theme (pretty
>> >>unreadable ;-)
>> >
>> > Sorry, is it possible to get a copy of the actual SVG file, please?
>>
>> Here is an example from my docview cache.
>
> Clearly an excellent document.
😅
> OK, I'm pretty sure that the first patch that affects image.c is
> working right, which means my mediocre lisp skills are biting me here.
>
> Can you try running
>
> (concat "svg{fill:" (face-foreground 'doc-view-svg-face) "}")
>
> and see what it returns?
Just to be sure we're on the same page: I'm doing all those test on top
the patches you provided in this thread.
For both a light theme or a dark theme, I get "svg{fill:}".
> Although it's only just now occurred to me that I have no idea what
> face-foreground might return, presumably things that aren't CSS
> compatible?
>
> Hmm...
>
> Can you try replacing line 1680 in lisp/doc-view.el with
>
> :foreground (face-foreground 'doc-view-svg-face)
> :css "svg{fill:currentcolor;}")))
>
> I think that's the right number of brackets...
I was not sure so here is the patch I used:
[my.diff (text/x-patch, inline)]
diff --git a/lisp/doc-view.el b/lisp/doc-view.el
index d3e40e531f8..023409d800b 100644
--- a/lisp/doc-view.el
+++ b/lisp/doc-view.el
@@ -1677,7 +1677,8 @@ doc-view-insert-image
(setq args `(,@args :transform-smoothing t)))
(when (eq doc-view--image-type 'svg)
(setq args `(,@args :background ,(face-background 'doc-view-svg-face)
- :css ,(concat "svg{fill:" (face-foreground 'doc-view-svg-face) "}"))))
+ :foreground ,(face-foreground 'doc-view-svg-face)
+ :css ,(concat "svg{fill:currentcolor;}"))))
(apply #'create-image file doc-view--image-type nil args))))
(slice (doc-view-current-slice))
(img-width (and image (car (image-size image))))
[Message part 3 (text/plain, inline)]
With this and the same SVG I provided, the foreground color of the text
is black using a light theme. Using a dark theme, the foreground color
of the text is white... So that seems to do the trick.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sat, 24 May 2025 20:58:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Sat, May 24, 2025 at 07:57:26PM +0200, Manuel Giraud wrote:
> With this and the same SVG I provided, the foreground color of the text
> is black using a light theme. Using a dark theme, the foreground color
> of the text is white... So that seems to do the trick.
Excellent, thanks.
I've pushed a branch scratch/svg-colors with the various fixes. Can
you please check it's working as you'd expect?
Can someone using librsvg < 1.48 please try it too? I'm including a
small script that should insert an SVG with two boxes, one follows the
theme colours the other stays with black and white.
If this all works then I suppose the documentation needs updated...
(insert-image
(create-image
"<svg viewbox='0 0 100 200'>
<rect x='1' y='1' width='98' height='98'
stroke='currentcolor' stroke-width='3'
fill-opacity='0'/>
<rect x='1' y='101' width='98' height='98'
stroke='black' stroke-width='3'
fill='white'/>
<text x='8' y='15' fill='currentcolor' font-size='9px'>
This text should
</text>
<text x='8' y='25' fill='currentcolor' font-size='9px'>
follow the theme
</text>
<text x='8' y='35' fill='currentcolor' font-size='9px'>
colours.
</text>
<text x='8' y='115' font-size='9px'>
This text should
</text>
<text x='8' y='125' font-size='9px'>
be black text on
</text>
<text x='8' y='135' font-size='9px'>
a white
</text>
<text x='8' y='145' font-size='9px'>
background.
</text>
</svg>"
'svg t))
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sun, 25 May 2025 06:21:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 77841 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 24 May 2025 21:56:59 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,
> Billy Lei <LeiYiXia29 <at> outlook.com>, Eli Zaretskii <eliz <at> gnu.org>,
> 77841 <at> debbugs.gnu.org
>
> On Sat, May 24, 2025 at 07:57:26PM +0200, Manuel Giraud wrote:
> > With this and the same SVG I provided, the foreground color of the text
> > is black using a light theme. Using a dark theme, the foreground color
> > of the text is white... So that seems to do the trick.
>
> Excellent, thanks.
>
> I've pushed a branch scratch/svg-colors with the various fixes. Can
> you please check it's working as you'd expect?
>
> Can someone using librsvg < 1.48 please try it too? I'm including a
> small script that should insert an SVG with two boxes, one follows the
> theme colours the other stays with black and white.
>
> If this all works then I suppose the documentation needs updated...
What needs to be updated in the documentation? I thought this was
about fixing a bug, not changing behavior. What did I miss?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Sun, 25 May 2025 13:03:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Sun, May 25, 2025 at 09:19:53AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 24 May 2025 21:56:59 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: Ihor Radchenko <yantar92 <at> posteo.net>,
> > Billy Lei <LeiYiXia29 <at> outlook.com>, Eli Zaretskii <eliz <at> gnu.org>,
> > 77841 <at> debbugs.gnu.org
> >
> > On Sat, May 24, 2025 at 07:57:26PM +0200, Manuel Giraud wrote:
> > > With this and the same SVG I provided, the foreground color of the text
> > > is black using a light theme. Using a dark theme, the foreground color
> > > of the text is white... So that seems to do the trick.
> >
> > Excellent, thanks.
> >
> > I've pushed a branch scratch/svg-colors with the various fixes. Can
> > you please check it's working as you'd expect?
> >
> > Can someone using librsvg < 1.48 please try it too? I'm including a
> > small script that should insert an SVG with two boxes, one follows the
> > theme colours the other stays with black and white.
> >
> > If this all works then I suppose the documentation needs updated...
>
> What needs to be updated in the documentation? I thought this was
> about fixing a bug, not changing behavior. What did I miss?
I'm trying something slightly different to see if it makes people
happier.
Instead of over-riding the default fill colour we'll set the
"currentcolor" to our foreground colour. This appears to be how web
browsers handle this.
Basically, this means the default foreground colour remains black, but
by setting "fill: currentcolor" in the SVG the foreground colour will
be set to Emacs's foreground colour.
Setting the image's :css parameter to
svg {
fill: currentcolor;
}
will give the same behaviour as we have at the moment.
I'm not sure if this is actually a better approach, but it seems to
align more closely with how SVG's are usually used, so might cause
less confusion.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Tue, 27 May 2025 09:47:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 77841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> writes:
> On Sat, May 24, 2025 at 07:57:26PM +0200, Manuel Giraud wrote:
>> With this and the same SVG I provided, the foreground color of the text
>> is black using a light theme. Using a dark theme, the foreground color
>> of the text is white... So that seems to do the trick.
>
> Excellent, thanks.
>
> I've pushed a branch scratch/svg-colors with the various fixes. Can
> you please check it's working as you'd expect?
Thanks! Here is series of screenshot with emacs -Q from this branch
that illustrates all the correct (IMO) features: SVG images keeps the
default black, Emacs "widgets" follow the theme, DocView could follow
the theme if the user wants.
The first screenshot is with a light theme (modus-operandi). The second
screenshot is with a dark theme (modus-vivendi) and the last screenshot
is with the same dark theme after having set `doc-view-svg-face' to
"inherit from default" only.
[2025-05-27T11:25+0200.png (image/png, inline)]
[2025-05-27T11:26+0200.png (image/png, inline)]
[2025-05-27T11:28+0200.png (image/png, inline)]
[Message part 5 (text/plain, inline)]
I'll try to test with librsvg < 1.48... but I don't have it at hand.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Thu, 29 May 2025 19:49:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 77841 <at> debbugs.gnu.org (full text, mbox):
On Tue, May 27, 2025 at 11:46:20AM +0200, Manuel Giraud wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> > On Sat, May 24, 2025 at 07:57:26PM +0200, Manuel Giraud wrote:
> >> With this and the same SVG I provided, the foreground color of the text
> >> is black using a light theme. Using a dark theme, the foreground color
> >> of the text is white... So that seems to do the trick.
> >
> > Excellent, thanks.
> >
> > I've pushed a branch scratch/svg-colors with the various fixes. Can
> > you please check it's working as you'd expect?
>
> Thanks! Here is series of screenshot with emacs -Q from this branch
> that illustrates all the correct (IMO) features: SVG images keeps the
> default black, Emacs "widgets" follow the theme, DocView could follow
> the theme if the user wants.
>
> The first screenshot is with a light theme (modus-operandi). The second
> screenshot is with a dark theme (modus-vivendi) and the last screenshot
> is with the same dark theme after having set `doc-view-svg-face' to
> "inherit from default" only.
Thanks. It's all looking good to me. I suppose it's really a question
of whether non-core code is relying on the current behaviour (I can
fix core code). My suspicion is no, but I have no actual evidence...
> I'll try to test with librsvg < 1.48... but I don't have it at hand.
Thanks. I don't think I've had it on one of my machines in years now...
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77841; Package
emacs.
(Mon, 09 Jun 2025 17:19:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 77841 <at> debbugs.gnu.org (full text, mbox):
Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
[...]
> I'll try to test with librsvg < 1.48... but I don't have it at hand.
Hi,
I was not able to get my hands on a system with a non-rust librsvg. So
I'm not able to do those tests sorry.
--
Manuel Giraud
This bug report was last modified 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.