Enrico Forestieri <[EMAIL PROTECTED]> writes:
> 
> Angus Leeming <leeming <at> ...> writes:
> > 
> > Enrico Forestieri wrote:
> > 
> > > I tried dvipng 1.7 on linux and its output is exactly equal to what that
> > > RE matches. So it is not a problem with dvipng itself but seemingly with
> > > the dvipng shipped with MikTeX.
> > 
> >  Then I guess you know who to complain to.
> > 
> > I wonder if the MikTeX version is piping its stderr stream to stdout? (For
> > reasons unknown.)
> 
> No, it is not like that. I can separately capture stderr and stdout.
> I tried compiling dvipng 1.7 under cygwin, which should be more
> reliable, and I am seeing a similar problem:
> 
> $ dvipng ...
> This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
> dvipng warning: cannot find ps2pk.map, nor psfonts.map
> [1 (preview-latex version 11.81) depth=6 height=16]
> 
> The warning should not matter. It is due to the fact that I used the
> cygwin tetex-devel package (for libkpathsea) and simply did:
> 
> $ ln -s /c/texmf /usr/share/texmf
> 
> for using the MikTeX texmf tree, but unfortunately ps2pk.map and
> psfonts.map are not in /c/texmf:
> 
> $ kpsewhich ps2pk.map
> C:/localtexmf/dvips/config/ps2pk.map
> $ kpsewhich psfonts.map
> C:/localtexmf/dvips/config/psfonts.map
> 
> So, I am going to read the libkpathsea documentation for setting some
> environment variable...
> 
> I'll see what it turns out to be. Having the sources, I can use ddd for
> debugging dvipng.

Ok, with the following four soft links I was able to use the cygwin
libkpathsea with MikTeX without messing with env vars:

$ ln -s /c/texmf /usr/share/texmf
$ ln -s /c/localtexmf /usr/share/texmf-local
$ ln -s /c/localtexmf/fonts /var/tmp/texfonts
$ ln -s /c/localtexmf/dvips/config /c/texmf/dvips/config-local

Now to the problem with dvipng. It is related to the version of the
preview-latex package used to produce the dvi file. Indeed, I can
reproduce it in linux when using a dvi file generated by MikTeX,
which uses a more recent version of preview-latex, and conversely,
the problem does not show up when using dvipng on Windows with a
debian testing tetex generated dvi file, which has a previous
version of preview-latex:

$ diff -u preview.sty.tetex preview.sty.miktex
...
@@ -83,6 +85,7 @@
 \DeclareOption{dvips}{%
   [EMAIL PROTECTED]@ne
   [EMAIL PROTECTED]
+      \special{!/[EMAIL PROTECTED]([EMAIL PROTECTED])def}
       \special{!userdict begin/preview-bop-level 0 def%
       /bop-hook{/preview-bop-level dup load dup 0 le{/isls false def%
           /vsize 792 def/hsize 612 def}if 1 add store}bind def%
...


The culprit is the following code from the dvipng special.c source file:

  if (strncmp(buffer,"!/[EMAIL PROTECTED](",18)==0) {
    buffer+=18;
    length-=18;
    while (length>0 && buffer[length]!=')')
      length--;
    if (page_imagep==NULL)
      Message(BE_NONQUIET," (preview-latex version %.*s)",length,buffer);
    return;
  }

  /* preview-latex' tightpage option */
  if (strncmp(buffer,"!/[EMAIL PROTECTED]",19)==0) {
    buffer+=19;
    SKIPSPACES(buffer);
    if (strncmp(buffer,"true",4)==0) {
      if (page_imagep==NULL)
        Message(BE_NONQUIET," (preview-latex tightpage option detected, \
will use its bounding box)");
      flags |= PREVIEW_LATEX_TIGHTPAGE;
      return;
    }
  }
  if (strncmp(buffer,"!userdict",9)==0
      && strstr(buffer+10,"7{currentfile token not{stop}if 65781.76 div")!=NULL)
 {
    if (page_imagep==NULL && ~flags & PREVIEW_LATEX_TIGHTPAGE)
      Message(BE_NONQUIET," (preview-latex <= 0.9.1 tightpage option detected,\
 will use its bounding box)");
    flags |= PREVIEW_LATEX_TIGHTPAGE;
    return;
  }

and I solved it by replacing BE_NONQUIET with BE_VERBOSE in the
previous code. When the dvi file is generated by tetex the outer "if"
in the first block is never triggered due to the missing special in
preview.sty

This code is executed several times, but at a certain point page_imap
gets initialized and then nothing is sent to stdout anymore.

Angus, in a previous post you said that "they're messing up the output
that they devised for us" and indeed this seems to be the case.
However, I don't know what "our" agreement was, so I would be grateful
if you could report to them the story...

Then, still there is the problem that if a font is missing, the output
of the programs that are in charge to generate it is mixed to the
stdout of dvipng, thus confusing lyxpreview2bitmap.py. I think that
they should be launched redirecting their stdout to stderr.

--
Enrico



Reply via email to