2

I would like to ask for help with figuring out exactly what triggers a weird phenomenon concerning rendering of textstyle fractions in certain fonts with dvisvgm (version 2.6.3, distributed as part of the package texlive-bin 2019.51075-3 on Arch Linux).

(I stumbled across this when playing around with the animation library manim, which renders formulas by running them through LaTeX and then converting the dvi to svg using dvisvgm.)

Here's a very minimal example causing trouble, svgtest.tex:

\documentclass[preview]{standalone}
\usepackage{fourier}
\begin{document}
$y = \sin \frac{1}{x}$
\end{document}

Processing this with

latex svgtest.tex; dvisvgm svgtest.dvi -n -o svgtest.svg

produces the following file, svgtest.svg:

<?xml version='1.0' encoding='UTF-8'?>
<!-- This file was generated by dvisvgm 2.6.3 -->
<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='33.871205pt' height='12.091864pt' viewBox='0.498134 -8.571499 33.871205 12.091864'>
<defs>
<path id='g3-49' d='M3.990416 0V-0.26481L3.22338 -0.32873C3.03162 -0.346993 2.922044 -0.420044 2.922044 -0.776168V-6.154555L2.876387 -6.209343L0.995321 -5.889745V-5.66146L1.84454 -5.561015C1.999774 -5.542752 2.063693 -5.469701 2.063693 -5.204891V-0.776168C2.063693 -0.602672 2.036299 -0.493095 1.981511 -0.429175C1.935854 -0.365255 1.862803 -0.337861 1.762358 -0.32873L0.995321 -0.26481V0H3.990416Z'/>
<path id='g1-198' d='M5.798431 -1.305788V-1.835409H0.776168V-1.305788H5.798431ZM5.798431 -3.314693V-3.844314H0.776168V-3.314693H5.798431Z'/>
<path id='g8-120' d='M3.518509 -0.957701C3.351952 -0.645407 3.164576 -0.277594 2.97026 -0.277594C2.838403 -0.277594 2.782884 -0.437211 2.630207 -1.054859L2.408131 -1.96398C2.657966 -2.408131 3.011899 -2.96332 3.213155 -2.96332C3.275614 -2.96332 3.331133 -2.94944 3.407471 -2.907801C3.47687 -2.880042 3.546268 -2.852282 3.629547 -2.852282C3.782224 -2.852282 3.927961 -2.998019 3.927961 -3.185396C3.927961 -3.400531 3.768344 -3.48381 3.574028 -3.48381C3.206215 -3.48381 2.893921 -3.150696 2.651026 -2.762064L2.345673 -2.290154H2.331793L2.054198 -3.45605L2.012559 -3.48381L0.867482 -3.136817L0.888302 -2.97026L1.408792 -3.004959C1.533709 -3.011899 1.582288 -2.9772 1.658626 -2.657966L1.908461 -1.651687L1.714145 -1.318573C1.415731 -0.811964 1.158957 -0.451091 0.9924 -0.451091C0.923001 -0.451091 0.853603 -0.47885 0.791144 -0.51355C0.721745 -0.548249 0.631527 -0.617648 0.51355 -0.617648C0.333113 -0.617648 0.215136 -0.437211 0.215136 -0.270655C0.215136 -0.069399 0.381692 0.083278 0.659287 0.083278C1.131197 0.083278 1.401852 -0.388632 1.686386 -0.853603L1.96398 -1.311633H1.97786L2.102777 -0.770324C2.234635 -0.215136 2.366492 0.083278 2.720425 0.083278C3.227035 0.083278 3.490749 -0.437211 3.698945 -0.860543L3.518509 -0.957701Z'/>
<use id='g13-121' xlink:href='#g8-121' transform='scale(1.315788)'/>
<use id='g18-105' xlink:href='#g3-105'/>
<use id='g18-110' xlink:href='#g3-110'/>
<use id='g18-115' xlink:href='#g3-115'/>
<use id='g15-49' xlink:href='#g3-49' transform='scale(0.760001)'/>
</defs>
<g id='page1'>
<use x='0.498134' y='0' xlink:href='#g13-121'/>
<use x='7.333545' y='0' xlink:href='#g1-198'/>
<use x='15.633477' y='0' xlink:href='#g18-115'/>
<use x='19.628496' y='0' xlink:href='#g18-105'/>
<use x='22.29848' y='0' xlink:href='#g18-110'/>
<use x='30.405611' y='-3.925267' xlink:href='#g15-49'/>
<rect x='30.136829' y='-2.846123' height='0.531591' width='4.232511'/>
<use x='30.288264' y='3.437093' xlink:href='#g8-120'/>
</g>
</svg>

This svg renders as follows in every program that I've tested (Firefox, Inkscape, Emacs):

Faulty svg rendering

Looking at the svg code, we see for example that the first <use> tag in the 'page1' group, which is supposed to be the “y” character, refers to the element g13-121, which a few lines earlier is referring to the element g8-121, which isn't defined anywhere, so it's no wonder there is only whitespace instead of a “y” in the picture.

Contrast this with the same example using the default Computer Modern font, which works as expected:

\documentclass[preview]{standalone}
\begin{document}
$y = \sin \frac{1}{x}$
\end{document}
latex svgtest.tex; dvisvgm svgtest.dvi -n -o svgtest.svg
<?xml version='1.0' encoding='UTF-8'?>
<!-- This file was generated by dvisvgm 2.6.3 -->
<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='38.131002pt' height='11.852377pt' viewBox='0 -8.416865 38.131002 11.852377'>
<defs>
<path id='g0-121' d='M4.841843 -3.795766C4.881694 -3.935243 4.881694 -3.955168 4.881694 -4.024907C4.881694 -4.204234 4.742217 -4.293898 4.592777 -4.293898C4.493151 -4.293898 4.333748 -4.234122 4.244085 -4.084682C4.224159 -4.034869 4.144458 -3.726027 4.104608 -3.5467C4.034869 -3.287671 3.965131 -3.01868 3.905355 -2.749689L3.457036 -0.956413C3.417186 -0.806974 2.988792 -0.109589 2.331258 -0.109589C1.823163 -0.109589 1.713574 -0.547945 1.713574 -0.916563C1.713574 -1.374844 1.882939 -1.992528 2.221669 -2.86924C2.381071 -3.277709 2.420922 -3.387298 2.420922 -3.58655C2.420922 -4.034869 2.102117 -4.403487 1.603985 -4.403487C0.657534 -4.403487 0.288917 -2.958904 0.288917 -2.86924C0.288917 -2.769614 0.388543 -2.769614 0.408468 -2.769614C0.508095 -2.769614 0.518057 -2.789539 0.56787 -2.948941C0.836862 -3.88543 1.235367 -4.184309 1.574097 -4.184309C1.653798 -4.184309 1.823163 -4.184309 1.823163 -3.865504C1.823163 -3.616438 1.723537 -3.35741 1.653798 -3.16812C1.255293 -2.11208 1.075965 -1.544209 1.075965 -1.075965C1.075965 -0.18929 1.703611 0.109589 2.291407 0.109589C2.67995 0.109589 3.01868 -0.059776 3.297634 -0.33873C3.16812 0.179328 3.048568 0.667497 2.650062 1.195517C2.391034 1.534247 2.012453 1.823163 1.554172 1.823163C1.414695 1.823163 0.966376 1.793275 0.797011 1.404732C0.956413 1.404732 1.085928 1.404732 1.225405 1.285181C1.325031 1.195517 1.424658 1.066002 1.424658 0.876712C1.424658 0.56787 1.155666 0.52802 1.05604 0.52802C0.826899 0.52802 0.498132 0.687422 0.498132 1.175592C0.498132 1.673724 0.936488 2.042341 1.554172 2.042341C2.580324 2.042341 3.606476 1.135741 3.88543 0.009963L4.841843 -3.795766Z'/>
<path id='g1-120' d='M1.736488 -0.739228C1.66675 -0.502117 1.436613 -0.125529 1.080946 -0.125529C1.060025 -0.125529 0.850809 -0.125529 0.704359 -0.223163C0.990286 -0.313823 1.011208 -0.564882 1.011208 -0.606725C1.011208 -0.760149 0.892653 -0.864757 0.732254 -0.864757C0.536986 -0.864757 0.334745 -0.697385 0.334745 -0.439352C0.334745 -0.09066 0.72528 0.069738 1.066999 0.069738C1.387796 0.069738 1.673724 -0.132503 1.84807 -0.425405C2.015442 -0.055791 2.399004 0.069738 2.677958 0.069738C3.47995 0.069738 3.905355 -0.801993 3.905355 -0.99726C3.905355 -1.08792 3.814695 -1.08792 3.793773 -1.08792C3.696139 -1.08792 3.689166 -1.053051 3.66127 -0.969365C3.514819 -0.488169 3.096389 -0.125529 2.705853 -0.125529C2.426899 -0.125529 2.280448 -0.313823 2.280448 -0.578829C2.280448 -0.760149 2.447821 -1.39477 2.643088 -2.168867C2.782565 -2.705853 3.096389 -2.880199 3.326526 -2.880199C3.340473 -2.880199 3.556663 -2.880199 3.703113 -2.782565C3.47995 -2.719801 3.396264 -2.524533 3.396264 -2.399004C3.396264 -2.245579 3.514819 -2.140971 3.675218 -2.140971S4.065753 -2.273474 4.065753 -2.566376C4.065753 -2.956912 3.619427 -3.075467 3.340473 -3.075467C2.991781 -3.075467 2.712827 -2.84533 2.559402 -2.580324C2.433873 -2.866252 2.113076 -3.075467 1.72254 -3.075467C0.941469 -3.075467 0.495143 -2.217684 0.495143 -2.008468C0.495143 -1.917808 0.592777 -1.917808 0.613699 -1.917808C0.704359 -1.917808 0.711333 -1.945704 0.746202 -2.036364C0.920548 -2.580324 1.3599 -2.880199 1.701619 -2.880199C1.931756 -2.880199 2.12005 -2.75467 2.12005 -2.419925C2.12005 -2.280448 2.036364 -1.931756 1.973599 -1.694645L1.736488 -0.739228Z'/>
<path id='g3-49' d='M2.336239 -4.435367C2.336239 -4.623661 2.322291 -4.630635 2.127024 -4.630635C1.680697 -4.191283 1.046077 -4.184309 0.760149 -4.184309V-3.93325C0.927522 -3.93325 1.387796 -3.93325 1.771357 -4.128518V-0.571856C1.771357 -0.341719 1.771357 -0.251059 1.073973 -0.251059H0.808966V0C0.934496 -0.006974 1.792279 -0.027895 2.050311 -0.027895C2.266501 -0.027895 3.145205 -0.006974 3.29863 0V-0.251059H3.033624C2.336239 -0.251059 2.336239 -0.341719 2.336239 -0.571856V-4.435367Z'/>
<path id='g2-61' d='M6.844334 -3.257783C6.993773 -3.257783 7.183064 -3.257783 7.183064 -3.457036S6.993773 -3.656289 6.854296 -3.656289H0.886675C0.747198 -3.656289 0.557908 -3.656289 0.557908 -3.457036S0.747198 -3.257783 0.896638 -3.257783H6.844334ZM6.854296 -1.325031C6.993773 -1.325031 7.183064 -1.325031 7.183064 -1.524284S6.993773 -1.723537 6.844334 -1.723537H0.896638C0.747198 -1.723537 0.557908 -1.723537 0.557908 -1.524284S0.747198 -1.325031 0.886675 -1.325031H6.854296Z'/>
<path id='g2-105' d='M1.763387 -4.403487L0.368618 -4.293898V-3.985056C1.016189 -3.985056 1.105853 -3.92528 1.105853 -3.437111V-0.757161C1.105853 -0.308842 0.996264 -0.308842 0.328767 -0.308842V0C0.647572 -0.009963 1.185554 -0.029888 1.424658 -0.029888C1.77335 -0.029888 2.122042 -0.009963 2.460772 0V-0.308842C1.803238 -0.308842 1.763387 -0.358655 1.763387 -0.747198V-4.403487ZM1.803238 -6.136986C1.803238 -6.455791 1.554172 -6.665006 1.275218 -6.665006C0.966376 -6.665006 0.747198 -6.396015 0.747198 -6.136986C0.747198 -5.867995 0.966376 -5.608966 1.275218 -5.608966C1.554172 -5.608966 1.803238 -5.818182 1.803238 -6.136986Z'/>
<path id='g2-110' d='M1.09589 -3.427148V-0.757161C1.09589 -0.308842 0.986301 -0.308842 0.318804 -0.308842V0C0.667497 -0.009963 1.175592 -0.029888 1.444583 -0.029888C1.703611 -0.029888 2.221669 -0.009963 2.560399 0V-0.308842C1.892902 -0.308842 1.783313 -0.308842 1.783313 -0.757161V-2.590286C1.783313 -3.626401 2.49066 -4.184309 3.128269 -4.184309C3.755915 -4.184309 3.865504 -3.646326 3.865504 -3.078456V-0.757161C3.865504 -0.308842 3.755915 -0.308842 3.088418 -0.308842V0C3.437111 -0.009963 3.945205 -0.029888 4.214197 -0.029888C4.473225 -0.029888 4.991283 -0.009963 5.330012 0V-0.308842C4.811955 -0.308842 4.562889 -0.308842 4.552927 -0.607721V-2.510585C4.552927 -3.367372 4.552927 -3.676214 4.244085 -4.034869C4.104608 -4.204234 3.775841 -4.403487 3.198007 -4.403487C2.470735 -4.403487 2.002491 -3.975093 1.723537 -3.35741V-4.403487L0.318804 -4.293898V-3.985056C1.016189 -3.985056 1.09589 -3.915318 1.09589 -3.427148Z'/>
<path id='g2-115' d='M2.072229 -1.932752C2.291407 -1.892902 3.108344 -1.733499 3.108344 -1.016189C3.108344 -0.508095 2.759651 -0.109589 1.982565 -0.109589C1.145704 -0.109589 0.787049 -0.67746 0.597758 -1.524284C0.56787 -1.653798 0.557908 -1.693649 0.458281 -1.693649C0.328767 -1.693649 0.328767 -1.62391 0.328767 -1.444583V-0.129514C0.328767 0.039851 0.328767 0.109589 0.438356 0.109589C0.488169 0.109589 0.498132 0.099626 0.687422 -0.089664C0.707347 -0.109589 0.707347 -0.129514 0.886675 -0.318804C1.325031 0.099626 1.77335 0.109589 1.982565 0.109589C3.128269 0.109589 3.58655 -0.557908 3.58655 -1.275218C3.58655 -1.803238 3.287671 -2.102117 3.16812 -2.221669C2.839352 -2.540473 2.450809 -2.620174 2.032379 -2.699875C1.474471 -2.809465 0.806974 -2.938979 0.806974 -3.516812C0.806974 -3.865504 1.066002 -4.273973 1.92279 -4.273973C3.01868 -4.273973 3.068493 -3.377335 3.088418 -3.068493C3.098381 -2.978829 3.188045 -2.978829 3.20797 -2.978829C3.337484 -2.978829 3.337484 -3.028643 3.337484 -3.217933V-4.224159C3.337484 -4.393524 3.337484 -4.463263 3.227895 -4.463263C3.178082 -4.463263 3.158157 -4.463263 3.028643 -4.343711C2.998755 -4.303861 2.899128 -4.214197 2.859278 -4.184309C2.480697 -4.463263 2.072229 -4.463263 1.92279 -4.463263C0.707347 -4.463263 0.328767 -3.795766 0.328767 -3.237858C0.328767 -2.889166 0.488169 -2.610212 0.757161 -2.391034C1.075965 -2.132005 1.354919 -2.072229 2.072229 -1.932752Z'/>
</defs>
<g id='page1'>
<use x='0' y='0' xlink:href='#g0-121'/>
<use x='8.009276' y='0' xlink:href='#g2-61'/>
<use x='18.525356' y='0' xlink:href='#g2-115'/>
<use x='22.455073' y='0' xlink:href='#g2-105'/>
<use x='25.222482' y='0' xlink:href='#g2-110'/>
<use x='33.886483' y='-3.922607' xlink:href='#g3-49'/>
<rect x='33.613201' y='-2.68991' height='0.398484' width='4.517787'/>
<use x='33.613201' y='3.435512' xlink:href='#g1-120'/>
</g>
</svg>

Correct svg rendering

But here's comes the really weird part. Going back to the Fourier font, all of the following formulas do work as expected (one at a time, although I've put them all in one example here for simplicity):

\documentclass[preview]{standalone}
\usepackage{fourier}
\begin{document}
$$y = \sin \frac{1}{x}$$
$y = \frac{1}{x}$
$y = \sin \frac{z}{x}$
$y = \sin \left( \frac{1}{x} \right)$
\end{document}

But this one doesn't work (the result looks pretty much like the first example above):

\documentclass[preview]{standalone}
\usepackage{fourier}
\begin{document}
$y = \sin ( \frac{1}{x} )$
\end{document}

With

\usepackage{mathpazo}

the results are the same as with Fourier. On the other hand, with

\usepackage{newtxmath}

everything works as it should, just like for Computer Modern.

All the dvi files look fine with xdvi, dvips, dvipng, etc., but apparently there's something in the dvi files for

$y = \sin \frac{1}{x}$

and

$y = \sin ( \frac{1}{x} )$

with the fourier and mathpazo packages that differs from all the other examples in a way that triggers this strange behaviour (bug?) in dvisvgm. Since dvi is a binary format, I haven't been able to decipher exactly what this mysterious property is, but maybe some TeX guru out there can help?

  • Add dvisvgm option --font-format=woff. – AlexG Nov 13 '19 at 19:10
  • I can't reproduce the issue here. The initial example works as expected, i.e. all characters are present in the SVG -- also when using option -n. Do you get any warning messages? If possible, check if a more recent version of dvisvgm leads to better results on your system. – Martin Nov 13 '19 at 19:48
  • @AlexG: That made no difference, the svg files that I get are identical. – Hans Lundmark Nov 13 '19 at 20:20
  • @HansLundmark For me they look ok. dvisvgm-2.6.3, TeXLive-2019. – AlexG Nov 13 '19 at 20:22
  • @Martin: No warning messages at all. I downloaded version 2.8 from dvisvgm.de, and I can compile it, but unfortunately I'm not TeX savvy enough to know how to install and/or run it “locally”. (I don't want to interfere with the system-wide texlive packages.) I've tried a few different things, but I keep getting lots of error messages about config/font/postscript-header files that can't be found. I looked at this question, but that didn't help... – Hans Lundmark Nov 13 '19 at 21:03
  • @HansLundmark The most critical aspect when building dvisvgm is to link the correct kpathsea library. It must match the one of your TeX Live installation. As far as I know, Arch Linux provides all required development files for libkpathsea. If you used these, the resulting dvisvgm should work and find the PS header files. Unfortunately, I don't have an Arch Linux system available at the moment and can't help you with this. Apart from that, I don't understand why the path definitions are missing and no warning is issued. – Martin Nov 13 '19 at 21:45
  • Could you run valgrind on dvisvgm processing your initial example and check if it reports any memory issues? – Martin Nov 13 '19 at 21:46
  • @Martin: For what it's worth, I took the dvi file from the first example and ran it through dvisvgm on my job computer (CentOS 7, dvisvgm version 1.15.1(!)), and that gave a correct result. And LaTeX on that computer produces a dvi file which (except for some trivial metadata) is identical to the one from my Arch Linux system, so it doesn't seem to be the case that my Arch setup somehow would produce faulty dvi files in some cases. – Hans Lundmark Nov 14 '19 at 10:07
  • @Martin: Regarding version 2.8, this morning I tried './configure --enable-bundled-libs --program-suffix="-hans"' and installed to /usr/local. Now, when running 'dvisvgm-hans', at least I don't get any complaints about not finding kpathsea configuration files, but I do get warnings about not finding font files futsy.mf/futmii.mf/futr8t.mf and PostScript header files tex.pro/texps.pro/special.pro/color.pro, and then it aborts with 'PostScript error: undefined in TeXDict'. – Hans Lundmark Nov 14 '19 at 10:08
  • @Martin: And in fact those font files don't exist in the file system; for example, I have futmii.tfm and futmii.vf, but not futmii.mf. The PS header files do exist. – Hans Lundmark Nov 14 '19 at 10:14
  • @Martin: And with version 2.6.3, "valgrind dvisvgm svgtest.dvi -n -o svgtest.svg" on the first example says "LEAK SUMMARY: definitely lost: 33,780 bytes in 1,004 blocks, indirectly lost: 2,705 bytes in 193 blocks, possibly lost: 0 bytes in 0 blocks, still reachable: 6,864,250 bytes in 257,906 blocks, suppressed: 0 bytes in 0 blocks". Running with "--leak-check=full" produces way too much output for a comment. Would it help if I pasted that into the question? – Hans Lundmark Nov 14 '19 at 10:14
  • Thanks for the additional info. I guess it's too complicated to examine your dvisvgm binary on a memory level by sharing debugger output here. Nonethless, you could paste the valgrind output to Pastebin or a similar site and provide the link here. Since dvisvgm 2.6.3 works correctly on my Fedora, Ubuntu, and Windows system, and AlexG couldn't reproduce the issue either, it seems to be a local one. Alternatively to the Arch packages, you could try the original TeX Live packages that usually work pretty reliably. – Martin Nov 14 '19 at 16:46
  • @Martin: Here it is: https://pastebin.com/9M0LFB1u. Yes, it might be something Arch-specific. I tried on another computer of mine, also running Arch, with the same results. Maybe someone else will be able to reproduce this issue and shed some more light, but for now I think I'll just ignore the problem and hope it goes away in a future update. Thanks for the input anyway! – Hans Lundmark Nov 14 '19 at 17:19
  • The valgrind output looks normal. libkpathsea creates a lot of memory leaks since it doesn't free the allocated blocks from the heap. So that's expected. If you convert the DVI with dvips, does the created PS file show all characters? – Martin Nov 14 '19 at 17:47
  • @Martin: Yes, as I wrote in the question, the other dvi tools that I've tried for comparion (dvips, dvipng, xdvi) produce correct results. – Hans Lundmark Nov 14 '19 at 18:45
  • Ok, sorry, I missed that info. What about dvisvgm -fwoff svgtest rather than dvisvgm -n svgtest? Are the characters missing in that SVG too? – Martin Nov 14 '19 at 19:04
  • @Martin: With WOFF it looks fine. (But that's not how manim does it, it needs the font shapes as paths in order to animate the drawing of the characters.) (And regarding my reply to AlexG's first comment above, I took his words literally and just added the WOFF option, keeping the -n option, which I now realize is a bit meaningless...) – Hans Lundmark Nov 14 '19 at 19:13

1 Answers1

5

After some further investigations I finally found the cause for the missing characters. Contrary to what I mentioned in the comments, I was now able to reproduce the issue with dvisvgm 2.6.3 and could bisect the changesets. It's actually a bug in dvisvgm that was already reported but only occurred sporadically and only with multi-page DVI files – until now. I fixed it a couple of months ago in version 2.7.3. So, unfortunately, there isn't much you can do except waiting for a more recent release.

Martin
  • 2,628
  • OK, great! Thanks for investigating! – Hans Lundmark Nov 15 '19 at 11:21
  • You're welcome. I also wanted to know what was going on there. :-) – Martin Nov 15 '19 at 11:27
  • @Martin When running tlmgr, I often see other binary packages being updated in between the yearly TL releases, recently dvipdfmx for example. Would it be possible to submit a new dvisvgm and ask Karl to include it as well? – AlexG Nov 15 '19 at 12:06
  • @AlexG I usually upload the sources to CTAN shortly after a new release of dvisvgm. Since I'm not a TL maintainer, someone from the TL team has to adapt the sources to the build environment, commit them to the SVN repo and trigger new builds for all target platforms. To my knowledge, binaries of an already released TL version are only updated in exceptional cases due to the required effort. – Martin Nov 15 '19 at 12:22
  • @AlexG I've updated the TL sources to the latest dvisvgm release. Norbert Preining has committed them to the trunk of the SVN repo. – Martin Nov 22 '19 at 07:55
  • Yay, thank you, @Martin. And this will restore compatibility with GS-9.50. – AlexG Nov 22 '19 at 09:30