mgieseki / dvisvgm

A fast DVI, EPS, and PDF to SVG converter
https://dvisvgm.de
GNU General Public License v3.0
306 stars 33 forks source link

\mathbf etc issue from xdv to svg. #169

Closed jhx000 closed 2 years ago

jhx000 commented 2 years ago

When I tried to use xelatex+dvisvgm to get svg from xdv with depth from \sbox, almost all worked except \mathbf{}, \mathrm{}, \cos, \sin. Other such as \sum_{i=1}^{n} a_i etc all work well. Only \mathbf{}, \mathrm{}, \cos, \sin, maybe other trigonometry went wrong.
Thus, the test.html file from xelatex shows the svg in wrong depth for above four math elements. I tried by latex+dvisvgm to get svg from dvi with depth from \sbox, everything is correct. When I review the svg files from xelatex, I found the svg shown in browser is not top aligned while those svg files from latex shown in browser is top aligned. I am not sure if it is related. Please refer to attached file. dvi2svg_depth.zip

muzimuzhi commented 2 years ago

Caused by the difference between fonts Computer Modern Roman and Latin Modern Roman. The not-yet-checked step is how dvisvgm handles this difference.

% either xelatex or lualatex
\documentclass{article}
\showboxbreadth=10
\showboxdepth=10

\begin{document}
\def\test{\setbox0=\hbox{a}\the\dp0 \showbox0\relax}

% latin modern roman, depth = 0.11pt
\fontencoding{TU}\fontfamily{lmr}\selectfont
\test

% computer modern roman, depth = 0.0pt
\fontencoding{OT1}\fontfamily{cmr}\selectfont
\test
\end{document}
muzimuzhi commented 2 years ago

Hmm, the depth difference doesn't explain the problem. The problem seems to be that if a(n) xdv/dvi produced by xelatex/luatex uses font Latin Modern Roman, then dvisvgm's output svg will be higher than expected.

A simplified example

% test.tex
% - first page uses lmr -> highter svg
% - second page uses cmr -> normal svg
\documentclass[multi=wrapper,dvisvgm]{standalone}
\newenvironment{wrapper}{\ignorespaces}{}
\begin{document}
\begin{wrapper}
a%
\end{wrapper}
\begin{wrapper}
\fontencoding{OT1}\fontfamily{cmr}\selectfont
a%
\end{wrapper}
\end{document}
$ xelatex -no-pdf test.tex
$ dvisvgm -p 1- test.xdv
pre-processing DVI file (format version 7)
processing page 1
  graphic size: 5pt x 14.17pt (1.757299mm x 4.980185mm)
  output written to test-1.svg
processing page 2
  graphic size: 5.000019pt x 4.305553pt (1.757306mm x 1.513229mm)
  output written to test-2.svg
2 of 2 pages converted in 0.10861 seconds

$ dvilualatex test.tex
$ dvisvgm -p 1- test.dvi
pre-processing DVI file (format version 7)
processing page 1
  graphic size: 5pt x 14.17pt (1.757299mm x 4.980185mm)
  output written to test-1.svg
processing page 2
  graphic size: 5.000019pt x 4.305553pt (1.757306mm x 1.513229mm)
  output written to test-2.svg
2 of 2 pages converted in 0.110356 seconds
mgieseki commented 2 years ago

When processing native fonts, like Latin Modern Roman, dvisvgm is limited to the extent values provided by the font file. While the TFM files of the cmr fonts contain information on the height and depth of each glyph, the OTF/TTF files don't. Therefore, dvisvgm uses the common ascender and descender of the font as a rough approximation of these values. That's why the default bounding box is too large here. You can avoid this by using option --exact-bbox (or just -e). It lets dvisvgm compute the actual bounds of the graphics objects present on the current page. When doing so, you get these results:

$ dvisvgm -p1- -e -d3 test.xdv
pre-processing DVI file (format version 7)
processing page 1
  graphic size: 4.83pt x 4.59pt (1.698mm x 1.613mm)
  output written to test-1.svg
processing page 2
  graphic size: 4.93pt x 4.59pt (1.733mm x 1.613mm)
  output written to test-2.svg
2 of 2 pages converted in 0.316492 seconds

$ dvisvgm -p1- -e -d3 test.dvi
pre-processing DVI file (format version 2)
processing page 1
  graphic size: 4.83pt x 4.59pt (1.698mm x 1.613mm)
  output written to test-1.svg
processing page 2
  graphic size: 4.93pt x 4.59pt (1.733mm x 1.613mm)
  output written to test-2.svg
2 of 2 pages converted in 0.251719 seconds
jhx000 commented 2 years ago

"-e" resolved the issue. Thanks!