GNU bug report logs - #77841
Some svg image's black color is replaced by emacs's theme foreground color

Previous Next

Full log

View this message in rfc822 format

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77841 <at> debbugs.gnu.org, Billy Lei <LeiYiXia29 <at> outlook.com>
Subject: bug#77841: Some svg image's black color is replaced by emacs's theme foreground color
Date: Sun, 20 Apr 2025 12:19:02 +0000

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>

Previous Next

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