> I wonder whether there is a way to avoid a double call to latex in case the > legacy route is taken. I tried replacing the above two lines with simply > return legacy_conversion_step2(latex_file, dpi, output_format) > but it did not work. Could you investigate?
Well, the problem is more complex than I imagined. The two LaTeX files have small differences, as if you use dvipng it passes through color_pdf (in lyxpreview2bitmap.py), but if you use the legacy method the .tex file passes through legacy_latex_file (in legacy_lyxpreview2ppm.py). These functions add some headers to show colors correctly, but the second one also adds to the latex-preview package the tightpage option which is problematic: - if absent the legacy method will create full A4 (or whatever) PNG image; - if present dvipng it's never used because that option involves a PostScript special, but I've been able to recognize and ignore it easily; the true problem with dvipng is that, I don't know why, with tightpage the output png image has a "blank" border on the left side of the image (try with an centered AMS context or see the attachment); BTW, dvipng in truth should support tightpage as there's some code specific to that option, but it doesn't :/ This makes me think legacy method never worked when called from legacy_conversion_step2, near the end of lyxpreview2png.py But maybe I'm missing something. So, what to do? 1) simply call latex twice on 2 slightly different .tex files (slow with comples code?); 2) while detecting PostScript literals rewrite the DVI (throgh the DTL) without the tightpage option (if it's even possible) and finally reassembly the DVI with dt2dv, so we can give it to dvipng (too complex and subject to change); 3) abandon the tightpage option and use something else to trim the space from the .ps output (or even in the .png) in legacy mode; can we rely on imagemagick? I spent half of this night over this problem, if you can find a better solution let me know, otherwise I think we should go for solution (3), which seems to be the shortest in development time and processing for the end user. Let me know what you think! venom00
<<attachment: 68lyxpreview1.png>>
