Use SVG instead of PNG for formulas
Closed this issue · 12 comments
I played around with dvisvgm a bit.
It also returns width, height and depth. Just like dvipng does. It is just printed in a different way:
dvisvgm -n -e --comments .\eqn012.dvi
pre-processing DVI file (format version 2)
processing page 1
computing extents based on data set by preview package (version 11.91)
width=51.925522pt, height=15.012513pt, depth=10.28363pt
graphic size: 51.925522pt x 25.296143pt (18.249734mm x 8.890578mm)
output written to eqn012.svg
1 of 1 page converted in 0.19 seconds
It returns the values as pt. Those values need to be converted to bp which is more or less the Tex equivalent to px in html. To do so you can just do: bp = pt * (72.27/72)
dvisvgm uses the constant 72.27/72 to convert from bp to pt.
Also the values dvisvgm returns seem to be correct while the values from dvipng seem to be wrong.
dvipng returns this for the same test image:
dvipng --width* --depth* --height* .\eqn012.dvi
This is C:\Program Files\MiKTeX 2.9\miktex\bin\x64\dvipng.exe (dvipng) 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1 (preview-latex version 11.91) (preview-latex tightpage option detected, will
use its bounding box) depth=14 height=21 width=72]
Embedding the created converted image into the html document where it should be the formula converted using dvisvgm fits perfectly into the line while the image created with dvipng is too far at the botom of the line and the aspect ratio seems to be a bit off, too.
Suggested command to convert formulas using divsvgm:
dvisvgm -n -e -o
-n: don't use fonts but pathes. In case some characters are missing in the fonts which would be used otherwise (e.g. the sum character did not work in my tests otherwise)
-e: calculates the exact bounding rect.
Well it's not in master. I didn't see the other branch. Sorry.
are you sure that is correct?
# convert from pt to px
(float(v) * 1.3333333 for v in found.groups())))
You should add -n and -e option.
Line 286 in 3ab8612
on that line add "-n" and "-e"
-n, --no-fonts[=variant] draw glyphs by using path elements [0]
-e, --exact compute exact glyph boxes
It prevents the usage of fonts. I had the problem that not everything was drawn correctly using fonts (e.g. the sum charcter).
Yes, it is. E. g. 7.5pt 10 pt → ~1.333
I think it's not that simple. the pt to px conversion depends on dpi. It is probably a good idea to just use pt in the final HTML document. Well modern browsers asume 96dpi. There 1.33333 is correct.
The stuff I wrote with 72.27 / 72 was wrong as it is just the ratio of TeX points to HTML points. dvisvgm already takes care of it.
Still the formula is placed wrong into the html document. You should use the graphics size for width and height.
As you can see there is a difference in the height:
width=51.925522pt, height=15.012513pt, depth=10.28363pt
graphic size: 51.925522pt x 25.296143pt
When using the height from the first line there will be white spaces left and right fomr the formula and the formula is scaled according to that hight which will make the characters a lot smaller than the surrounding text.
Commit 5f573f6 already introduced
--no-fonts
.
There is no such commit. Also I searched the whole code in master and add_dvisvg_support. I didn't find it anywhere.
Well
s/html/DTP
. Unfortunately, dvisvgm does not take care of this, according
to the author.
I don't get it. Here the code from divsvgm which prints into the console:
_svg.setBBox(bbox);
const double bp2pt = 72.27/72;
const double bp2mm = 25.4/72;
Message::mstream(false) << '\n';
Message::mstream(false, Message::MC_PAGE_SIZE) << "graphic size: " << XMLString(bbox.width()*bp2pt) << "pt"
" x " << XMLString(bbox.height()*bp2pt) << "pt"
" (" << XMLString(bbox.width()*bp2mm) << "mm"
" x " << XMLString(bbox.height()*bp2mm) << "mm)";
Message::mstream(false) << '\n';
For me that formula is applied. It converts TeX pt to the pt we need for the svg. At least I understand it like it and it really just looks fine with the values printed there.
Also: I tried with latest add_dvisvg_support:
TypeError: 'tuple' object does not support item assignment (image.py line 196)
The following does not work because self.__size is a tuple:
self.__size[1] = 12 # 12 pt
I worked around it by just overriding it with a new tuple but this is ugly.
So my results:
- When just using it without any changes the formula is complete but has white spaces left and right. The vertical alignment is off. The formular is too far down. When just opening the svg (wihout the -tag around) some parts of the formula are cut off. I guess --scale=1.2 breaks something (maybe simply the viewbox)
- When applying the values from "graphic size" it more or less fits the line. There are no white spaces and the alignment is just a bit off but the image is then cut off like before when just opening the svg directly.
- When using the values from "graphic size" and removing --scale=1.2 it fits perfectly. The character sizes are the same as in the surrounding text. It is also possible to just open the svg.
Here the simple ugly changes I made:
DVISVGM_REGEX = re.compile(r"^.*depth=(.*?)pt.*")
DVISVGM_REGEX2 = re.compile(r"^.*graphic size: (.*?)pt x (.*?)pt.*")
### ......
# remove --scale=1.2
cmd = ['dvisvgm', '--exact', '--no-fonts', '-o', output_name,
'--bbox=preview', dvi_fn]
### .......
# apply new regex
pos = {}
for line in data.split('\n'):
found = DVISVGM_REGEX.search(line)
found2 = DVISVGM_REGEX2.search(line)
if found:
pos['depth'] = float(found.groups()[0]) * 1.3333333
elif found2:
pos['width'] = float(found2.groups()[0]) * 1.3333333
pos['height'] = float(found2.groups()[1]) * 1.3333333
return pos
This is the formula I tested with:
The "2x" in it perfectly aligns (vertically and in size) with the surrounding text.
was using the one which was installed by miktex 2.3.3. I updated to 2.5 and tried everything again.
The bug that part of the image are cut off is gone when using --scale=1.2 but the characters in the formula are a bit bigger than the surrounding text like this. If this is wanted it is ok though.
The problem with the white spaces left and right is the same. So it is needed to use the values from "graphic size" and everything is perfect.