> You are right. In the past, we had the dtl sources in our tree and > this problem had been already identified! Indeed, Angus patched > dt2dv.c just to solve this exact issue. I am attaching the diff > between the current dt2dv.c in CTAN and the patched one. > Most probably, for your tests you used the dt2dv program distributed > with the Windows installer (which uses the patched sources, me > thinks), such that you were not seeing the problem...
Don't know, MiKTeX doesn't create that big special in the preamble. However this doesn't exclude that the Windows distribution is fixed. In any case, what's the use of the patch, we can send it to the author, but it will take time before it gets widespread. > > I would go with 2). > > Let's try it, then. Here's the new patch: dvipng encountering PostScript specials was VERY slow (it seems to call GhostScripting internally but failing miserably), so I looked for another solution. Dvipng has "-pp" parameter which allows to choose which pages render, it works great! Simple and effective. I'm using page ranges where possible as, specially under Win32, too long command lines could give problems. The solution is much cleaner: we don't create an alternative DVI and also the metrics generation is much simpler. I've tested it with the latest revision from trunk under Win32 and Linux and seems to work both with Math.lyx and my test file. As usual, I'm interested on how things work on your side and in your comments. > > Maybe we can launch the legacy method in > > parallel with dvipng to reduce the user's delay perception. > > Hmm... Currently, the words parallel and thread bring me out in a > nettle-rash... :) You're right but here the fact would just be leave dvipng run in async, go on with the script (through the legacy method) and before creating the metrics file wait for the termination of dvipng. Parallel development is something to avoid, whenever possible, in Python in particular, but in this case it's pretty straightforward. However we can think about this in a future patch. > > > Some more general remarks: > > > * It solves the speed problem only if a small subset of > > > snippets need the > > > legacy method (however, this would be the case if one has dvipng > > > installed) > > > > Why? We make just two calls to LaTeX, the first for all the IPs and > > the second just for those needing the legacy method. Can't think a > > quicker way. > > It's not the latex calls, it's the ghostscript calls that slow down > things. Yes, it's true. GhostScript doesn't have an option to skip a failing page, I can't see alternatives to "dvips -i". We should ask GhostScript developers to add such a thing, but... I don't know when and even if they'll ever implement that. Pavel! You're right! Depending on external tools is very annoying. :| However, I found a subtle bug in the patch you posted to use "dvips -i", you were using glob.glob, which doesn't sort the results, so the output PNG indexes were messed up. I fixed that with a .sort(). > > I've not yet investigated the XeTeX version of instant-preview, and > > how it works. I'll do it. Not managed in this patch. How many people use XeTeX? I also changed PreviewLoader.cpp to ignore files referenced from metrics file but not actually existing. It was causing a SIGSEV in another part of the code. venom00
ip_error_handling2.diff
Description: Binary data
