Closed user202729 closed 4 months ago
It actually works correctly because your example creates a DVI file that contains the PS special header=
which requires the PS handler to be loaded:
[page 1 0 0 0 0 0 0 0 0 0]
push:
xxx: 'header=l3backend-dvips.pro'
pop:
...
You can prevent this e.g. with document class option dvisvgm
. The corresponding DVI file won't contain the PS special.
I try to do the following, and it still would initialize ghostscript.
pdflatex -jobname=d --output-format=dvi << 'EOF'
\documentclass[dvisvgm]{article}
\begin{document}
hello world
\end{document}
EOF
Also, the "textual format" or "dumped format" of the DVI looks interesting, how did you produce that? (edit: okay it's dvitype
.)
I try to do the following, and it still would initialize ghostscript.
dvisvgm checks if Ghostscript is available when registering the PS special handler together with the other special handlers. This requires to dlopen the GS library if it's not directly linked to dvisvgm which could increase the execution time.
The PS handler itself is only initialized before processing the first PS special.
I'm not sure if it's easily possible to defer the GS check as well. I have to look into this. You can completely turn off the GS handler with --no-specials=ps
.
Also, the "textual format" or "dumped format" of the DVI looks interesting, how did you produce that?
That's the output of dviasm
.
I've changed the registration of the PS special handler a bit so that it doesn't require to call Ghostscript any longer. GS functions are now only called when PS specials are processed.
In the source code there's this comment:
Nevertheless, it doesn't work right now and we incur a performance penalty of about 50ms (i.e. the program is 50ms slower than if the deferred initialization were working). (for a simple file on my machine total runtime is 100ms, with the optimization implemented it will be reduced by 50%)
Test: (any simple file will work)