-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"output written to <file>.svg" sometimes lies #212
Comments
Minor update: introducing a delay of |
I guess that's related to the OS. dvisvgm uses C++ file streams to write the SVG data, and their implementation is compiler- and OS-dependent. Even if all data has been written to the stream and the stream is closed, the OS can delay the physical writing. I currently don't check whether the SVG file is actually present and complete before printing the messages to the console. |
Is the stream currently flushed before printing |
Yes. The stream object is removed before printing the message and thus gets flushed and closed by its destructor. |
Hello,
There's a problem that every now and then popped up with dvisvgm 2.13 that seems to be coming up much more with 3.0-dev.
I'm currently using a process filter to scan the stdout of
dvisvgm
foroutput written to <file>.svg
lines to replace the foreground color withcurrentColor
and display the images as soon as they are created. However, I was finding some LaTeX fragments at random seemed to fail to produce an image.By adding a line to my foreground rewriting function that simply prints the (truncated) last line in the SVG file when its called, I see some output like this:
So it seems like just after
output written to <file>.svg
is printed by dvisvgm, the entire SVG file may not have been printed? I'm about to try adding a timeout, but this behaviour is surprising and a little annoying to deal with.The text was updated successfully, but these errors were encountered: