"output written to <file>.svg" sometimes lies

[tecosaur]

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 for output written to <file>.svg lines to replace the foreground color with currentColor 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:

Last line in SVG file starts with: "<path id='g8-139' d='M1.44911…"
Last line in SVG file starts with: "<path id='g8-51' d='M4.913085…"
Last line in SVG file starts with: "<path id='g8-139' d='M1.44911…" [2 times]
Last line in SVG file starts with: "</svg>" [3 times]

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.

[tecosaur]

Minor update: introducing a delay of 0.002s seems to be enough for everything reported to be written to actually be on my machine, 0.001s is not quite enough.

[mgieseki]

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.

[tecosaur]

Is the stream currently flushed before printing output written to <file> ?

[mgieseki]

Yes. The stream object is removed before printing the message and thus gets flushed and closed by its destructor.