Re: [AUCTeX-devel] preview-latex, dvipng, and LyX

[Jan-Åke Larsson]

Angus Leeming wrote:
>>>However, in recent versions of preview-latex and dvipng the output
>>>devised for LyX's sake gets corrupted in the following way:
>>>
>>>$ dvipng ...
>>>This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
>>>[1 (preview-latex version 11.81) depth=6 height=16]
>>>
>>>this output confuses the script LyX uses for generating preview
>>>snippets, which, instead, is expecting an output like this:
>>
>>A lesson is learnt, but the damage is irreversible.

Well, dvipng has always been chattering about things it does on each
page, even though this particular message will always appear on page 1
from now on. For instance, if the dvi page numbers differ from the
physical page numbers, there will be a heads-up in the form of
"(physical page number)". And if an eps is included you'll see
"<foo.eps>".

All these messages can't be put on stderr because they do belong on
certain pages. I wonder if the lyx people would be so kind as to look
for just the "depth=" and "height=" strings, these will not change
over time. I suppose that

     "\[([0-9]+) .*?depth=(-?[0-9]+) height=(-?[0-9]+)"

would do the trick. Or is there some deep reason for not using ".*?" ?

>>>A second problem that I noticed is that when a font is missing and
>>>mktexpk (or alike) gets called to generate it, its stdout gets
>>>intermixed with that of dvipng, causing a similar (but worse) confusion.
>>>
>>>Is it possible to have the stdout of those helper programs redirected to
>>>stderr?
>>
>>The latter would actually be useful for preview-latex as well, only
>>that it would be nice to direct the output completely elsewhere (Emacs
>>does not capture stderr separately): I often have to run preview-latex
>>several times when new fonts get generated, because the font
>>generating output confuses it.

That pattern would get rid of this problem as well: IIRC the output of
the mktexpk script is always a closed  "[1] [14] ..." in which case the
"\[([0-9]+) " part would only match BOP because of the trailing space
and the "height=(-?[0-9]+)" would match EOP.

Anyhow, the font-generating call is internal to kpathsea, it is not as
if I get to choose where to send output. With glibc redirection should
be easy, but without glibc I think I'll need to fork for every call to
kpse_find_pk, and redirect or gobble output and _then_ call kpse_find_pk
_again_ in the parent. Hmmmmmmmmm. Some overhead, but possible.

Opinions?
/JÅ