Bounding box info only shown for the *first* page

[tecosaur]

Hello!

Preamble

I'm attempting to make dvisvgm the premiere LaTeX preview system in Emacs' org-mode. I'm really excited about this work, and it can produce some terrific results. Here's an example of an Emacs buffer using dvisvgm-generated image overlays on the LaTeX fragments:

Unfortunately in the process I've run into a few minor bugs/deficiencies in dvisvgm, which I'm hoping might be able to be addressed.

The actual issue

When running dvisvgm on multiple pages, bbox information is only emitted for the first page.

MWE

DVI file

org-tex-pojDTY.dvi.zip (zipped because GitHub will not accept .dvi files)

dvisvgm command

~$ dvisvgm --page=1- --no-fonts --bbox=preview --scale=1.168 -o org-tex-pojDTY-%9p.svg org-tex-pojDTY.dvi

stdout

pre-processing DVI file (format version 2)
processing page 1
  applying bounding box set by preview package (version 13.1)
  width=8.8695pt, height=7.156192pt, depth=.714655pt
  graphic size: 8.8695pt x 7.870847pt (3.117273mm x 2.766286mm)
  output written to org-tex-pojDTY-000000001.svg
processing page 2
  graphic size: 7.377455pt x 8.919271pt (2.592879mm x 3.134765mm)
  output written to org-tex-pojDTY-000000002.svg
processing page 3
  graphic size: 6.388364pt x 6.609455pt (2.245253mm x 2.322958mm)
  output written to org-tex-pojDTY-000000003.svg
3 of 3 pages converted in 0.0760341 seconds

converting each page individually

~$ dvisvgm --page=1 --no-fonts --bbox=preview --scale=1.168 -o org-tex-pojDTY-%9p.svg org-tex-pojDTY.dvi
pre-processing DVI file (format version 2)
processing page 1
  applying bounding box set by preview package (version 13.1)
  width=8.8695pt, height=7.156192pt, depth=.714655pt
  graphic size: 8.8695pt x 7.870847pt (3.117273mm x 2.766286mm)
  output written to org-tex-pojDTY-000000001.svg
1 of 3 pages converted in 0.073993 seconds

~$ dvisvgm --page=2 --no-fonts --bbox=preview --scale=1.168 -o org-tex-pojDTY-%9p.svg org-tex-pojDTY.dvi
pre-processing DVI file (format version 2)
processing page 2
  applying bounding box set by preview package (version 13.1)
  width=8.8695pt, height=9.462981pt, depth=.714655pt
  graphic size: 8.8695pt x 10.177636pt (3.117273mm x 3.57703mm)
  output written to org-tex-pojDTY-000000002.svg
1 of 3 pages converted in 0.073971 seconds

~$ dvisvgm --page=3 --no-fonts --bbox=preview --scale=1.168 -o org-tex-pojDTY-%9p.svg org-tex-pojDTY.dvi
pre-processing DVI file (format version 2)
processing page 3
  applying bounding box set by preview package (version 13.1)
  width=7.876586pt, height=7.156192pt, depth=.714655pt
  graphic size: 7.876586pt x 7.870847pt (2.768303mm x 2.766286mm)
  output written to org-tex-pojDTY-000000003.svg
1 of 3 pages converted in 0.073736 seconds

System information

• OS: Linux (6.0.8), openSUSE Tumbleweed 20222-11-28
• dvisvgm: 2.13.3

[mgieseki]

Thank you for your work on this. The screenshot looks really nice. I've fixed the issue regarding the evaluation of the preview data so that it should work now. The patch will be also part of the next release.

[tecosaur]

Thanks for the quick fix! I'll look forward to the 3.0 release.

[tecosaur]

Hmm, I was hoping to give the fixed version a spin, so I tried autoreconf -i then make and got hit with some compilation errors like

dvisvgm.cpp:87:48: error: ‘CommandLine’ does not name a type
   87 | static string get_transformation_string (const CommandLine &args) {

Should I just wait for 3.0 to come out properly, or is there a quick/easy fix to this?

In case it helps, the full log: https://0x0.st/oRUF.txt

[mgieseki]

I guess something went wrong with the generation of src/CommandLine.hpp. Is this file empty in your build directory? If so, the script opt2cpp.py failed to create it and it should help to revert CommandLine.hpp from the repository. Do you get any further error or warning messages during the build?

[tecosaur]

Thanks for the pointer, CommandLine.hpp was 0B. When I manually run pyhon3 opt2cpp.py no stdout/stderr is produced though. After resetting CommandLine.hpp though, no errors, and it works like a charm!

Thanks for the quick fix :grinning:

[mgieseki]

You're welcome. Great to hear you could fix the build issue.

opt2cpp.py requires argument option.xml to create the .hpp file. So it should be used like this:

python3 opt2cpp.py options.xml >CommandLine.hpp

Usually, the build system should automatically take care of that if CommandLine.hpp is out of date.

[tecosaur]

Hmm, if I do python3 opt2cpp.py options.xml > CommandLine.hpp then I get exactly what's currently committed. Perhaps it's just something minor with the build system?

One more thing if I may, do you have a rough idea of when 3.0 might come out? Actually getting correct sizing and baseline information is absolutely lovely, and it would be helpful for working out what to put in the documentation.

I've said it before, but this is working brilliantly, so thanks for not just the fix but dvisvgm. I'm going to put another screenshot here for fun.

Currently, support for recolouring (as in the heading) is done by finding the foreground colour in the SVG file dvisvgm produces and replacing it with currentColor. It would be cool if there was a command line flag for this, but it's not much effort to do it as a second step.

[mgieseki]

Hmm, if I do python3 opt2cpp.py options.xml > CommandLine.hpp then I get exactly what's currently committed. Perhaps it's just something minor with the build system?

I currently can't reproduce the problem. Maybe the timestamps of options.xml and CommandLine.hpp were out of sync for some reason.

One more thing if I may, do you have a rough idea of when 3.0 might come out? Actually getting correct sizing and baseline information is absolutely lovely, and it would be helpful for working out what to put in the documentation.

I'd like to release version 3 sometime this month which is also necessary to get it into TeX Live 2023. Unfortunately, I haven't had much time to test the new stuff that has been added (mainly the new PDF handler and the TTF/WOFF writer). The code works well so far but there could still be some issues that I haven't come across yet.

Currently, support for recolouring (as in the heading) is done by finding the foreground colour in the SVG file dvisvgm produces and replacing it with currentColor. It would be cool if there was a command line flag for this, but it's not much effort to do it as a second step.

I really like the look of the output -- especially, the font is quite nice. Have you already tried to change the color in the LaTeX file rather than in the SVG? It might be a bit easier because you just have to add something like

\special{color rgb 0.5 0 0.5}

directly after \begin{preview} which sets the default text color for that page. I might add a command-line option for this in the future as well but can't promise it yet.

[tecosaur]

Have you already tried to change the color in the LaTeX file rather than in the SVG? It might be a bit easier because you just have to add something like...

I'm doing that for dvipng (because of the limited colour stack, actually), but it's much nicer with currentColor because then it "just works" no matter where it's put (body text, heading, etc.) and dynamically adapts to theme changes without having to be regenerated.

https://user-images.githubusercontent.com/20903656/210933495-2ed1139e-896e-4a96-8861-ed0f3ff1f16e.mp4

So for this use case, having a transparent background and currentColor foreground is ideal.

[tecosaur]

Quick question: should I make a new issue requesting a --currentcolor flag?

[mgieseki]

Yes, please open a new ticket for that. Otherwise, I'll probably lose track of it. Please also add some information on what the new option is supposed to do and maybe add a small example.