> The point is that it currently does not work well. Loading
> examples/instant_preview.lyx I get:
> {{{
> Program "dt2dv" version 0.6.0 compiled in standard C.
> dt2dv (read_variety) : DTL variety sequences-6 is OK.
> dt2dv (ls_putb) : ERROR : No more room in Lstring.
> dt2dv (dinfo) : Current DTL input line 28 :
> "fstr{gsave pgfsoa .setopacityalpha stroke grestore}bind def}bind def
> /pgffoa 1 def /pgfsoa 1 def end '
> "
> Read 3321 DTL bytes (1042 in current command), wrote 2125 DVI bytes.
> Successfully interpreted 12 DVI commands.
> dt2dv (dexit) : exiting with status 1.
The problem is that TeX Live puts a special command in the DVI output longer
than 1024, which is the maximum supported for each line by dt2dv (WTF?):
special4 1131 '! /burl@stx null def /BU.S { /burl@stx null def } def /BU.SS {
currentpoint /burl@lly exch def /burl@llx exch def burl@stx null ne {burl@endx
burl@llx ne {BU.FL BU.S} if} if burl@stx null eq { burl@llx dup /burl@stx exch
def /burl@endx exch def burl@lly dup /burl@boty exch def /burl@topy exch def }
if burl@lly burl@boty gt {/burl@boty burl@lly def} if } def /BU.SE {
currentpoint /burl@ury exch def dup /burl@urx exch def /burl@endx exch def
burl@ury burl@topy lt {/burl@topy burl@ury def} if } def /BU.E { BU.FL } def
/BU.FL { burl@stx null ne {BU.DF} if } def /BU.DF { BU.BB [ /H /I /Border
[burl@border] /Color [burl@bordercolor] /Action << /Subtype /URI /URI BU.L >>
/Subtype /Link BU.B /ANN pdfmark /burl@stx null def } def /BU.BB { burl@stx
HyperBorder sub /burl@stx exch def burl@endx HyperBorder add /burl@endx exch
def burl@boty HyperBorder add /burl@boty exch def burl@topy HyperBorder sub
/burl@topy exch def } def /BU.B { /Rect[burl@stx burl@boty burl@endx burl@topy]
} def /eop where { begin /@ldeopburl /eop load def /eop { SDict begin BU.FL end
@ldeopburl } def end } { /eop { SDict begin BU.FL end } def } ifelse '
Note: 1131 is the length of the string.
So even without running the script on it, but just calling dv2dt and dt2dv, the
last one gives the error you receive. Apart from this, it should work under
Linux too.
What to do then?
1) Distribute a customized version of dv2dt which supports more than 1024 bytes
per special (I don't think it's a good idea)
2) Do not call dt2dv and leave the non-working PostScript specials in the DVI
file, which will slow down dvipng a little but won't make it fail; this means
we just use dv2dt to understand which pages will have to go through the legacy
method;
3) Write a custom DVI interpreter, not very complex but time-consuming;
4) Simply remove specials longer than 1024 bytes
5) Maybe special lines can be splitted over multiple lines, but I don't think so
I would go with 2). Maybe we can launch the legacy method in parallel with
dvipng to reduce the user's delay perception.
> 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 doesn't solve the general problem if XeTeX is used, as
> in that case
> a single big pdf file is handed to ghostscript, and thus a
> failing snippet
> still makes a global failure.
I've not yet investigated the XeTeX version of instant-preview, and how it
works. I'll do it.
> * The dtl file manipulation seems to be too simplistic and
> doesn't seem
> to lead to a valid dvi file in some cases (maybe also dependent on
> platform and software versions)
AFAIK was not my fault. However the 2) would solve the problem to the radix.
> If these issues are addressed, I think that this approach is
> better than
> triggering snippet generation only when they appear on
> screen. If they
> cannot be satisfactorily solved, maybe the
> generate-snippet-only-when-it-
> appears-on-screen approach could be restricted to non-math snippets,
> leaving the math case as it is now. After all, we even have
> a preference
> for not applying instant-preview to math insets...
I agree.
I've never been so unlucky! TikZ has a bug, dviselect doesn't work properly,
dt2dv has a bug, what's next?
venom00
