background transparent vs opaque white

[nschloe]

When translating a simple TeX-produced PDF like

\documentclass{article}

\begin{document}
abc
\end{document}

e.pdf

with

dvisvgm e.pdf --pdf 

to SVG, the resulting file will have a transparent background:

This is with

dvisvgm --version

dvisvgm 2.13.1

Is possible to force a white (opaque) background?

[mgieseki]

If you don't specify a page color in the LaTeX file, the PDF doesn't contain any background information either and the background gets transparent, even if most PDF viewers display the contents on a white background by default.
The color of a LaTeX page can be set with \pagecolor which is defined in package xcolor. Unfortunately, SVG 1.1 doesn't cover the concept of pages or background colors, so there's no portable way realize it. The current versions of dvisvgm add a colored rectangle to the SVG graphics if the DVI or PDF file set the page color.

Alternatively, you could post-process the SVG file and add style="background-color: white" to the opening svg tag. Most recent web browsers take this attribute into account, but it's not guaranteed that all SVG renderers support it.

[nschloe]

Thanks for the reply.

The current versions of dvisvgm add a colored rectangle to the SVG graphics if the DVI or PDF file set the page color.

I played around with that and found this working for

\documentclass{article}

\usepackage{xcolor}
\pagecolor{green}

\begin{document}
abc
\end{document}

However, when setting the pagecolor to white, the background will again be transparent. A bug?

Edit:
I would use this

\definecolor{offwhite}{RGB}{255,255,254}

as a workaround, but it messes with the autocrop.

[mgieseki]

I can't reproduce this at the moment. \pagecolor{white} adds an opaque, white rectangle to the SVG which precedes all other graphic elements:

<svg version='1.1' ...>
  <g id='page1'>
    <g transform='matrix(1 0 0 -1 0 0)'>
      <path d='M0 0H612V792H0Z' fill='#fff'/>
    ...
    </g>
  </g>
</svg>

If I open the SVG file with Inkscape or load it in an HTML page with a colored background, the white background rectangle is present and everything else from the SVG is drawn on top of it.
What application do you use to view the SVG files? Perhaps it implicitly renders white backgrounds as transparent.

[nschloe]

From the file a.pdf I'm getting the SVG

<?xml version='1.0' encoding='UTF-8'?>
<!-- This file was generated by dvisvgm 2.13.1 -->
<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='612pt' height='792pt' viewBox='0 -792 612 792'>
<g id='page1'>
<g transform='matrix(1 0 0 -1 0 0)'>
<path d='M153.52322 658.121543V658.67936H153.27416V658.121543C153.27416 657.54373 153.0251 657.484043 152.91572 657.484043C152.58697 657.484043 152.54697 657.932168 152.54697 657.982168V659.97436C152.54697 660.39279 152.54697 660.78123 152.18853 661.14967C151.8001 661.53811 151.30197 661.69748 150.82385 661.69748C150.00697 661.69748 149.319472 661.22936 149.319472 660.57186C149.319472 660.27311 149.518847 660.10373 149.77791 660.10373C150.05666 660.10373 150.23603 660.30311 150.23603 660.56217C150.23603 660.68154 150.18635 661.01029 149.72791 661.02029C149.99697 661.36873 150.4851 661.47842 150.80385 661.47842C151.29197 661.47842 151.85978 661.08998 151.85978 660.20342V659.83498C151.35166 659.80498 150.65447 659.77498 150.02697 659.47623C149.279784 659.13748 149.030722 658.61967 149.030722 658.18123C149.030722 657.374355 149.99697 657.125293 150.62447 657.125293C151.28197 657.125293 151.7401 657.52373 151.92947 657.992168C151.96916 657.59373 152.23822 657.175293 152.70635 657.175293C152.91572 657.175293 153.52322 657.314668 153.52322 658.121543ZM151.85978 658.62967C151.85978 657.683105 151.1426 657.344668 150.69416 657.344668C150.20603 657.344668 149.7976 657.693105 149.7976 658.19123C149.7976 658.73904 150.21603 659.56592 151.85978 659.62561V658.62967ZM158.8829 659.38654C158.8829 660.65154 157.90697 661.63779 156.77135 661.63779C155.99416 661.63779 155.56603 661.16967 155.40666 660.99029V664.14811L153.97228 664.03842V663.72967C154.66947 663.72967 154.74916 663.65998 154.74916 663.17186V657.23498H154.99822L155.35666 657.85248C155.50603 657.623418 155.92447 657.125293 156.66166 657.125293C157.84697 657.125293 158.8829 658.101543 158.8829 659.38654ZM158.05635 659.39654C158.05635 659.02811 158.03635 658.43029 157.74728 657.982168C157.53822 657.673418 157.15978 657.344668 156.62197 657.344668C156.17353 657.344668 155.8151 657.58373 155.57603 657.952168C155.43635 658.16123 155.43635 658.19123 155.43635 658.37061V660.42248C155.43635 660.61186 155.43635 660.62186 155.54603 660.78123C155.93447 661.33904 156.48228 661.41873 156.72135 661.41873C157.16978 661.41873 157.52822 661.15967 157.76728 660.78123C158.02635 660.37279 158.05635 659.80498 158.05635 659.39654Z'/>
<path d='M163.6342 658.42029C163.6342 658.51998 163.5349 658.51998 163.5049 658.51998C163.4152 658.51998 163.3952 658.47998 163.3755 658.42029C163.0864 657.494043 162.4389 657.374355 162.0705 657.374355C161.5427 657.374355 160.6658 657.802793 160.6658 659.40654C160.6658 661.03029 161.4827 661.44873 162.0108 661.44873C162.1005 661.44873 162.728 661.43873 163.0764 661.07998C162.6683 661.04998 162.6083 660.75123 162.6083 660.62186C162.6083 660.36279 162.7877 660.16373 163.0667 660.16373C163.3255 660.16373 163.5249 660.33279 163.5249 660.63186C163.5249 661.30904 162.7677 661.69748 162.0008 661.69748C160.7555 661.69748 159.8392 660.62186 159.8392 659.38654C159.8392 658.111543 160.8252 657.125293 161.9808 657.125293C163.3155 657.125293 163.6342 658.32061 163.6342 658.42029Z'/>
<path d='M307.30674 89.364868V89.673618H306.98799C306.09143 89.673618 306.06174 89.783306 306.06174 90.151743V95.74018C306.06174 95.97924 306.06174 95.99893 305.83237 95.99893C305.21487 95.36143 304.3383 95.36143 304.019554 95.36143V95.05268C304.21862 95.05268 304.80643 95.05268 305.32455 95.31174V90.151743C305.32455 89.793306 305.29455 89.673618 304.39799 89.673618H304.079241V89.364868C304.42799 89.394868 305.29455 89.394868 305.69299 89.394868S306.95799 89.394868 307.30674 89.364868Z'/>
</g>
</g>
</svg>

Perhaps that's due to me using an older dvisvgm version. I'll try to update.

[mgieseki]

I get the same result from your PDF file because it doesn't contain a background color. According to the metadata, you created the file with XeLaTeX. It seems xcolor doesn't support XeLaTeX yet or replaces white backgrounds by transparent ones.

[nschloe]

you created the file with XeLaTeX.

I used tectonic which perhaps uses XeLaTeX in the background. I'll post the issue there. (Edit: tectonic-typesetting/tectonic#908)

or replaces white backgrounds by transparent ones.

It'll be that. Colors other than white work.

[mgieseki]

I've just had a closer look into the involved tools. xelatex produces an XDV file that contains a background special which dvisvgm recognizes. So, when converting this file with dvisvgm, the white rectangle is present in the SVG:

  ...
  push:
    right: 62pt
    down: -550pt
    xxx: 'color push gray 0'
    xxx: 'background gray 1'
    down: 10pt
   ...

However, xdvipdfmx which is automatically invoked by xelatex to create a PDF from the XDV file, treats a white background as transparent. Here is the corresponding line of code that handles this case.

[nschloe]

Interesting! I could in fact produce an xdv with

tectonic a.tex --outfmt xdv

This gives

<?xml version='1.0' encoding='UTF-8'?>
<!-- This file was generated by dvisvgm 2.13.4 -->
<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='163.584922pt' height='574.703486pt' viewBox='76.712329 55.931633 163.584922 574.703486'>
<style type='text/css'>
<![CDATA[text.f0 {font-family:lmroman10-regular;font-size:10px}
]]>
</style>
<g id='page1'>
<rect x='76.712329' y='55.931633' width='163.584922' height='574.703486' fill='#fff'/>
<text class='f0' x='76.712329' y='62.764633'>#+<tspan x='231.13325' y='630.635118'>R</tspan></text>
</g>
</svg>

(note the correct #fff-rect) which doesn't render correctly. Instead of abc, it has # and R. Not sure if this is an issue on my side or a different bug.

[mgieseki]

If you process a DVI/XDV file, dvisvgm converts text components to text elements as you can see in your SVG example. Most SVG renderers don't handle them properly, though. Therefore, you should call dvisvgm with option --no-fonts or --font-format=woff. The first one turns text into graphics paths (which is also the case when converting PS or PDF files) and the latter embeds WOFF instead of SVG fonts.

Edit: I just noticed that the glyph definitions are missing in your file. That's probably because dvisvgm can't find the referenced font file. You should get a warning here.

[nschloe]

I've tried with

dvisvgm a.xdv --no-fonts

but this just gives an empty page.

a.xdv.gz

[mgieseki]

What does dvisvgm print to the console when you call it that way?

[nschloe]

dvisvgm a.xdv --no-fonts

pre-processing DVI file (format version 7)
WARNING: font file 'lmroman10-regular' not found
processing page 1
  graphic size: 164.198365pt x 576.858624pt (57.709125mm x 202.742619mm)
  WARNING: can't embed font 'lmroman10-regular'
  output written to a.svg
1 of 1 page converted in 0.0639122 seconds

I suppose

WARNING: font file 'lmroman10-regular' not found

is the culprit. Let me look into it.

Edit: Hm. The fonts seem properly installed. pdflatex has no problems producing the PDF.

[nschloe]

Btw I've posted this on the XeTeX mailing list. https://tug.org/pipermail/xetex/2022-June/028063.html

[mgieseki]

Hm. The fonts seem properly installed. pdflatex has no problems producing the PDF.

Right, there probably was a change in the specification of XDV opcode XFontDef which used to require the full filename of the font file including the suffix. Now the base name seems to be sufficient. This is easy to fix. I've already a working patch for this that I'll commit later today (435767b).