Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: Angus Leeming [EMAIL PROTECTED] writes: Oh, that's horrid and the one that follows is worse. What I think you should do is talk to David Kastrup and Jan-Åke Larsson on the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're messing up the output that they devised for us. 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.) -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming [EMAIL PROTECTED] 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. -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
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 (length0 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
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: [ snip the results of some impressive detective work ] 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... Our agreement was simply that David Kastrup and, to a lesser extent, Jan-Åke Larsson created all the hooks needed by LyX in preview.sty and in dvipng. They'll certainly remember, albeit hazily. I was a PITA (that's their arses) for a couple of months ;-) I'm afraid I'm extremely busy tying up lose ends ATM before I start a new job on Monday. Please contact them on the AucTeX mailing list; you'll tell the story so much better than I could ;-) 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. Sounds reasonable. Get them to do so and then add a test to lyxpreview2bitmap.py for dvipng version = 1.8 (as it perhaps will be) and you're done. Welcome to the LyX developer team ;-) -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming [EMAIL PROTECTED] writes: Our agreement was simply that David Kastrup and, to a lesser extent, Jan-Åke Larsson created all the hooks needed by LyX in preview.sty and in dvipng. They'll certainly remember, albeit hazily. I was a PITA (that's their arses) for a couple of months I don't think so. You are listed in the credits section of the dvipng docs ;-) I'm afraid I'm extremely busy tying up lose ends ATM before I start a new job on Monday. Please contact them on the AucTeX mailing list; you'll tell the story so much better than I could Ok, then. Good luck to you with your new job! 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. Sounds reasonable. Get them to do so and then add a test to lyxpreview2bitmap.py for dvipng version = 1.8 (as it perhaps will be) and you're done. Welcome to the LyX developer team Wow! I got promoted on the field! ;-) Then I am sorry that my Christmas holidays are at the end... ;-) -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming [EMAIL PROTECTED] writes: I'm afraid I'm extremely busy tying up lose ends ATM before I start a new job on Monday. Please contact them on the AucTeX mailing list; you'll tell the story so much better than I could Done: http://article.gmane.org/gmane.emacs.auctex.devel/870 -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > >> Oh, that's horrid and the one that follows is worse. >> What I think you should do is talk to David Kastrup and Jan-Åke Larsson >> on the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're >> messing up the output that they devised for us. > > 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.) -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming <[EMAIL PROTECTED]> 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. -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Angus Leeming ...> 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
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: [ snip the results of some impressive detective work ] > 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... "Our" agreement was simply that David Kastrup and, to a lesser extent, Jan-Åke Larsson created all the hooks needed by LyX in preview.sty and in dvipng. They'll certainly remember, albeit hazily. I was a PITA (that's "their arses") for a couple of months ;-) I'm afraid I'm extremely busy tying up lose ends ATM before I start a new job on Monday. Please contact them on the AucTeX mailing list; you'll tell the story so much better than I could ;-) > 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. Sounds reasonable. Get them to do so and then add a test to lyxpreview2bitmap.py for dvipng version >= 1.8 (as it perhaps will be) and you're done. Welcome to the LyX developer team ;-) -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming <[EMAIL PROTECTED]> writes: > "Our" agreement was simply that David Kastrup and, to a lesser extent, > Jan-Åke Larsson created all the hooks needed by LyX in preview.sty and in > dvipng. They'll certainly remember, albeit hazily. I was a PITA (that's > "their arses") for a couple of months I don't think so. You are listed in the credits section of the dvipng docs ;-) > I'm afraid I'm extremely busy tying up lose ends ATM before I start a new > job on Monday. Please contact them on the AucTeX mailing list; you'll tell > the story so much better than I could Ok, then. Good luck to you with your new job! > > 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. > > Sounds reasonable. Get them to do so and then add a test to > lyxpreview2bitmap.py for dvipng version >= 1.8 (as it perhaps will be) and > you're done. > > Welcome to the LyX developer team Wow! I got promoted on the field! ;-) Then I am sorry that my Christmas holidays are at the end... ;-) -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming <[EMAIL PROTECTED]> writes: > I'm afraid I'm extremely busy tying up lose ends ATM before I start a new > job on Monday. Please contact them on the AucTeX mailing list; you'll tell > the story so much better than I could Done: http://article.gmane.org/gmane.emacs.auctex.devel/870 -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming [EMAIL PROTECTED] writes:
Enrico Forestieri wrote:
Perhaps you mean that the dpi variable is *proportional* to
preview_scale_factor. Indeed, when not setting preview_scale_factor I
obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I
don't know the default value of preview_scale_factor (and obviously it is
not equal to 1), so I am not able to evaluate preview_scale_factor from
the knowledge of dpi.
0.9
Uhm... this value is doesn't look right to me. Perhaps it was ok in the
old xforms days, but anyway...
In src/graphics/PreviewLoader.C you'll find:
font_scaling_factor_ = 0.01 * lyxrc.dpi * lyxrc.zoom *
convertdouble(lyxrc.preview_scale_factor);
...
cs pconverter_-command ' ' pconverter_-to ' '
support::QuoteName(latexfile) ' '
int(font_scaling_factor_) ' '
lyx_gui::hexname(LColor::preview) ' '
lyx_gui::hexname(LColor::background);
This is the command used to launch the script. 'dpi' inside the script is
'int(font_scaling_factor_) outside it.
Thereafter, the metrics info is used in setAscentFractions() in the same
file.
Thanks for the pointer Angus, but, perhaps due to the fact that I don't
grok well C++, I was not able to figure out the program flow and
eventually I came to the conclusion that there was any, as everything
seems to be signal driven :-(
However, I did some experiments using the lyx file pasted at the bottom.
In my preference file I have
\screen_zoom 130
\screen_font_roman Times New Roman
and the Screen DPI is at its default value of 96.
Using the default value of 0.9 for preview_scale_factor, the various
n's and H's are not aligned with each other.
Then I changed preview_scale_factor with a step of 0.05, successively
trying the values 0.95, 1.0, 1.05.
At preview_scale_factor=1.05, magically everything lines up and even
the baseline of the previewed images is correctly aligned with the
baseline of the surrounding text!
With these settings I tried other real world lyx files and everything
seems fine.
Things break again if one chooses pslatex fonts. Instead, changing
\screen_zoom to 150, the n's and H's are still aligned with each
other but their baseline does not correspond anymore to that of the
surrounding text.
I think that the conclusion is that there are complex interactions
between too much parameters and it is very difficult to get it right.
I am sorry that my scarce knowledge of C++ and of the LyX sources does
not let me to be of help here, and, frankly, I don't know how much this
effort would be worth.
As regards why we need to use it twice, I don't know the way the images
are imported. What I know is that if leave untouched the value of the
frac variable *and* preview_scale_factor is set to something different
than its default value, then the inlined images do not perfectly line up
with the surrounding text.
Right. But you'll understand that I'm unhappy about making a change I don't
understand.
You're a wise man ;-)
--
Enrico
#LyX 1.4.0pre3 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Standard
\family roman
\series medium
\shape up
\size normal
\emph off
\bar no
\noun off
\color none
\begin_inset Formula $n$
\end_inset
xxx
\family default
\series default
\shape default
\size default
\emph default
\bar default
\noun default
\begin_inset Formula $n_{i}$
\end_inset
xxx
\begin_inset Formula $n^{2}$
\end_inset
xxx
\begin_inset Formula $n_{i}^{2}$
\end_inset
xxx
\begin_inset Formula $H$
\end_inset
xxx
\begin_inset Formula $H_{1}$
\end_inset
xxx
\begin_inset Formula $H^{2}$
\end_inset
xxx
\begin_inset Formula $H_{i}^{2}$
\end_inset
xxx
\end_layout
\end_body
\end_document
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: At preview_scale_factor=1.05, magically everything lines up and even the baseline of the previewed images is correctly aligned with the baseline of the surrounding text! With these settings I tried other real world lyx files and everything seems fine. Things break again if one chooses pslatex fonts. Instead, changing \screen_zoom to 150, the n's and H's are still aligned with each other but their baseline does not correspond anymore to that of the surrounding text. I think that the conclusion is that there are complex interactions between too much parameters and it is very difficult to get it right. That does sound to be the case indeed. (It may even be something wrong in the way Qt/WinFree lines up fonts...) Right. But you'll understand that I'm unhappy about making a change I don't understand. You're a wise man ;-) And you're a patient and methodical one :) I'd suggest that we just leave things as they are. The fix is available to you; you can fudge your script file. Regards, Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Paul A. Rubin [EMAIL PROTECTED] writes:
It may be the format files rather than the package database. The MiKTeX
Options app has a button on the General tab, Format files section
labeled Update Now. Enrico should give that a whirl. I ran into
something similar, albeit not with preview, where METAFONT abruptly lost
the ability to generate fonts. It turned out that I'd updated some core
MiKTeX package(s) and the format files had not been properly updated.
Thanks for the tip Paul! I almost always work from the command line, so
I was missing that button. I am getting close. Now I have:
$ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0
C:\texmf\miktex\bin\dvipng.exe warning: at (0,0) ignored header
\special{!/[EMAIL PROTECTED](11.81)def}
Failed to extract metrics info from dvipng
where the last message is from lyxpreview2bitmap.py, and indeed the metrics
file produced by dvipng is empty. I'll investigate further.
--
Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming [EMAIL PROTECTED] writes: I'd suggest that we just leave things as they are. The fix is available to you; you can fudge your script file. Angus, sorry to be a PITA, but I would like to get your attention to the fact that a regular expression in lyxpreview2bitmap.py may be needs to be revised. After Paul's suggestion, I fixed the problem with dvipng, but the metrics file turned out to be empty. I manually called dvipng and saw that its output is as follows: $ dvipng ... 0lyxpreview.dvi ... [1 (preview-latex beginning-of-page-hook detected) (preview-latex tightpage \ option detected, will use its bounding box) depth=1 height=9] So, I modified the following snippet in lyxpreview2bitmap.py: def extract_metrics_info(dvipng_stdout, metrics_file): metrics = open(metrics_file, 'w') - metrics_re = re.compile(\[([0-9]+) depth=(-?[0-9]+) height=(-?[0-9]+)) + metrics_re = re.compile(\[([0-9]+).* depth=(-?[0-9]+) height=(-?[0-9]+)) and everything was fine. However, changing the document fonts to pslatex, the same problem (empty metrics file) showed up again. Calling manually dvipng on the offending dvi, I got this: $ dvipng ... 0lyxpreview.dvi ... [1 (preview-latex beginning-of-page-hook detected)Trying to make \ PK font psyr (at 512 DPI)... makemf --verbose psyr ttf2pk -q -t psyr Creating psyr.512pk... gsf2pk psyr StandardSymL usyr.pfb 512 psyr.512pk Reading TFM file C:\texmf\fonts\tfm\adobe\symbol\psyr.tfm... Starting Ghostscript: C:\texmf\miktex\bin\mgs.exe -dNODISPLAY -dNOGC -sSUBSTFONT=StandardSymL \ -q -- C:/texmf/dvips/gsftopk/render.ps StandardSymL (C:/texmf/fonts/type1/urw/urwstd/usyr.pfb) brun 512 Writing Pk file psyr.512pk... Trying to make PK font ptmri8r (at 512 DPI)... makemf --verbose ptmri8r ttf2pk -q -t ptmri8r Creating ptmri8r.512pk... gsf2pk ptmri8r NimbusRomNo9L-ReguItal TeXBase1Encoding ReEncodeFont 8r.enc utmri8a.pfb 512 ptmri8r.512pk Reading TFM file C:\texmf\fonts\tfm\adobe\times\ptmri8r.tfm... Starting Ghostscript: C:\texmf\miktex\bin\mgs.exe -dNODISPLAY -dNOGC -sSUBSTFONT=NimbusRomNo9L-ReguItal -q -- C:/texmf/dvips/gsftopk/render.ps NimbusRomNo9L-ReguItal (C:/texmf/fonts/type1/urw/urwstd/utmri8a.pfb) brun (C:/texmf/fonts/enc/dvips/fontname/8r.enc ) run TeXBase1Encoding ReEncodeFont 512 Writing Pk file ptmri8r.512pk... depth=1 height=8] That is what really goes to stdout, so IMO the RE should be changed to account for the possible presence of newlines between [1 and depth= Or, the thing could be changed such that to catch separately the [x and the depth= My first impression is that the dvipng generated previews are much better than those obtained through the ghostscript route. -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: Angus Leeming [EMAIL PROTECTED] writes: I'd suggest that we just leave things as they are. The fix is available to you; you can fudge your script file. Angus, sorry to be a PITA, You're not. but I would like to get your attention to the fact that a regular expression in lyxpreview2bitmap.py may be needs to be revised. After Paul's suggestion, I fixed the problem with dvipng, but the metrics file turned out to be empty. I manually called dvipng and saw that its output is as follows: $ dvipng ... 0lyxpreview.dvi ... [1 (preview-latex beginning-of-page-hook detected) (preview-latex [tightpage \ option detected, will use its bounding box) depth=1 height=9] Oh, that's horrid and the one that follows is worse. What I think you should do is talk to David Kastrup and Jan-Åke Larsson on the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're messing up the output that they devised for us. That is what really goes to stdout, so IMO the RE should be changed to account for the possible presence of newlines between [1 and depth= Or, the thing could be changed such that to catch separately the [x and the depth= Let's see what they have to say first... My first impression is that the dvipng generated previews are much better than those obtained through the ghostscript route. and much faster too. The one limitation it appears to have is its handling of PostScript specials although I'm sure that things have evolved since last I looked. (A couple of years ago...) -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming [EMAIL PROTECTED] writes: Oh, that's horrid and the one that follows is worse. What I think you should do is talk to David Kastrup and Jan-Åke Larsson on the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're messing up the output that they devised for us. 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. -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Enrico Forestieri wrote:
> > Perhaps you mean that the dpi variable is *proportional* to
> > preview_scale_factor. Indeed, when not setting preview_scale_factor I
> > obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I
> > don't know the default value of preview_scale_factor (and obviously it is
> > not equal to 1), so I am not able to evaluate preview_scale_factor from
> > the knowledge of dpi.
>
> 0.9
Uhm... this value is doesn't look right to me. Perhaps it was ok in the
old xforms days, but anyway...
> In src/graphics/PreviewLoader.C you'll find:
>
> font_scaling_factor_ = 0.01 * lyxrc.dpi * lyxrc.zoom *
> convert(lyxrc.preview_scale_factor);
>
> ...
>
> cs << pconverter_->command << ' ' << pconverter_->to << ' '
><< support::QuoteName(latexfile) << ' '
><< int(font_scaling_factor_) << ' '
><< lyx_gui::hexname(LColor::preview) << ' '
><< lyx_gui::hexname(LColor::background);
>
> This is the command used to launch the script. 'dpi' inside the script is
> 'int(font_scaling_factor_) outside it.
>
> Thereafter, the metrics info is used in setAscentFractions() in the same
> file.
Thanks for the pointer Angus, but, perhaps due to the fact that I don't
grok well C++, I was not able to figure out the program flow and
eventually I came to the conclusion that there was any, as everything
seems to be signal driven :-(
However, I did some experiments using the lyx file pasted at the bottom.
In my preference file I have
\screen_zoom 130
\screen_font_roman "Times New Roman"
and the "Screen DPI" is at its default value of 96.
Using the default value of 0.9 for preview_scale_factor, the various
"n"'s and "H"'s are not aligned with each other.
Then I changed preview_scale_factor with a step of 0.05, successively
trying the values 0.95, 1.0, 1.05.
At preview_scale_factor=1.05, magically everything lines up and even
the baseline of the previewed images is correctly aligned with the
baseline of the surrounding text!
With these settings I tried other real world lyx files and everything
seems fine.
Things break again if one chooses pslatex fonts. Instead, changing
\screen_zoom to 150, the "n"'s and "H"'s are still aligned with each
other but their baseline does not correspond anymore to that of the
surrounding text.
I think that the conclusion is that there are complex interactions
between too much parameters and it is very difficult to get it right.
I am sorry that my scarce knowledge of C++ and of the LyX sources does
not let me to be of help here, and, frankly, I don't know how much this
effort would be worth.
> > As regards why we need to use it twice, I don't know the way the images
> > are imported. What I know is that if leave untouched the value of the
> > frac variable *and* preview_scale_factor is set to something different
> > than its default value, then the inlined images do not perfectly line up
> > with the surrounding text.
>
> Right. But you'll understand that I'm unhappy about making a change I don't
> understand.
You're a wise man ;-)
--
Enrico
#LyX 1.4.0pre3 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Standard
\family roman
\series medium
\shape up
\size normal
\emph off
\bar no
\noun off
\color none
\begin_inset Formula $n$
\end_inset
xxx
\family default
\series default
\shape default
\size default
\emph default
\bar default
\noun default
\begin_inset Formula $n_{i}$
\end_inset
xxx
\begin_inset Formula $n^{2}$
\end_inset
xxx
\begin_inset Formula $n_{i}^{2}$
\end_inset
xxx
\begin_inset Formula $H$
\end_inset
xxx
\begin_inset Formula $H_{1}$
\end_inset
xxx
\begin_inset Formula $H^{2}$
\end_inset
xxx
\begin_inset Formula $H_{i}^{2}$
\end_inset
xxx
\end_layout
\end_body
\end_document
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: At preview_scale_factor=1.05, magically everything lines up and even the baseline of the previewed images is correctly aligned with the baseline of the surrounding text! With these settings I tried other real world lyx files and everything seems fine. Things break again if one chooses pslatex fonts. Instead, changing \screen_zoom to 150, the "n"'s and "H"'s are still aligned with each other but their baseline does not correspond anymore to that of the surrounding text. I think that the conclusion is that there are complex interactions between too much parameters and it is very difficult to get it right. That does sound to be the case indeed. (It may even be something wrong in the way Qt/WinFree lines up fonts...) Right. But you'll understand that I'm unhappy about making a change I don't understand. You're a wise man ;-) And you're a patient and methodical one :) I'd suggest that we just leave things as they are. The "fix" is available to you; you can fudge your script file. Regards, Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Paul A. Rubin <[EMAIL PROTECTED]> writes:
> It may be the format files rather than the package database. The MiKTeX
> Options app has a button on the General tab, Format files section
> labeled "Update Now". Enrico should give that a whirl. I ran into
> something similar, albeit not with preview, where METAFONT abruptly lost
> the ability to generate fonts. It turned out that I'd updated some core
> MiKTeX package(s) and the format files had not been properly updated.
Thanks for the tip Paul! I almost always work from the command line, so
I was missing that button. I am getting close. Now I have:
$ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0
C:\texmf\miktex\bin\dvipng.exe warning: at (0,0) ignored header
\special{!/[EMAIL PROTECTED](11.81)def}
Failed to extract metrics info from dvipng
where the last message is from lyxpreview2bitmap.py, and indeed the metrics
file produced by dvipng is empty. I'll investigate further.
--
Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming <[EMAIL PROTECTED]> writes:
> I'd suggest that we just leave things as they are. The "fix" is available
> to you; you can fudge your script file.
Angus,
sorry to be a PITA, but I would like to get your attention to the fact
that a regular expression in lyxpreview2bitmap.py may be needs to be
revised.
After Paul's suggestion, I fixed the problem with dvipng, but the metrics
file turned out to be empty. I manually called dvipng and saw that its
output is as follows:
$ dvipng ... 0lyxpreview.dvi
...
[1 (preview-latex beginning-of-page-hook detected) (preview-latex tightpage \
option detected, will use its bounding box) depth=1 height=9]
So, I modified the following snippet in lyxpreview2bitmap.py:
def extract_metrics_info(dvipng_stdout, metrics_file):
metrics = open(metrics_file, 'w')
- metrics_re = re.compile("\[([0-9]+) depth=(-?[0-9]+) height=(-?[0-9]+)")
+ metrics_re = re.compile("\[([0-9]+).* depth=(-?[0-9]+) height=(-?[0-9]+)")
and everything was fine. However, changing the document fonts to pslatex,
the same problem (empty metrics file) showed up again. Calling manually
dvipng on the offending dvi, I got this:
$ dvipng ... 0lyxpreview.dvi
...
[1 (preview-latex beginning-of-page-hook detected)Trying to make \
PK font "psyr" (at 512 DPI)...
"makemf" --verbose "psyr"
"ttf2pk" -q -t "psyr"
Creating "psyr.512pk"...
"gsf2pk" "psyr" "StandardSymL" "" "" "usyr.pfb" "512" "psyr.512pk"
Reading TFM file "C:\texmf\fonts\tfm\adobe\symbol\psyr.tfm"...
Starting Ghostscript:
C:\texmf\miktex\bin\mgs.exe -dNODISPLAY -dNOGC -sSUBSTFONT="StandardSymL" \
-q -- "C:/texmf/dvips/gsftopk/render.ps" "StandardSymL"
"(C:/texmf/fonts/type1/urw/urwstd/usyr.pfb) brun" "" "512"
Writing Pk file "psyr.512pk"...
Trying to make PK font "ptmri8r" (at 512 DPI)...
"makemf" --verbose "ptmri8r"
"ttf2pk" -q -t "ptmri8r"
Creating "ptmri8r.512pk"...
"gsf2pk" "ptmri8r" "NimbusRomNo9L-ReguItal" "TeXBase1Encoding ReEncodeFont"
"8r.enc" "utmri8a.pfb" "512" "ptmri8r.512pk"
Reading TFM file "C:\texmf\fonts\tfm\adobe\times\ptmri8r.tfm"...
Starting Ghostscript:
C:\texmf\miktex\bin\mgs.exe -dNODISPLAY -dNOGC
-sSUBSTFONT="NimbusRomNo9L-ReguItal" -q -- "C:/texmf/dvips/gsftopk/render.ps"
"NimbusRomNo9L-ReguItal" "(C:/texmf/fonts/type1/urw/urwstd/utmri8a.pfb) brun
(C:/texmf/fonts/enc/dvips/fontname/8r.enc ) run" "TeXBase1Encoding
ReEncodeFont" "512"
Writing Pk file "ptmri8r.512pk"...
depth=1 height=8]
That is what really goes to stdout, so IMO the RE should be changed to
account for the possible presence of newlines between "[1 " and " depth=...".
Or, the thing could be changed such that to catch separately the "[x "
and the " depth=...".
My first impression is that the dvipng generated previews are much better
than those obtained through the ghostscript route.
--
Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > >> I'd suggest that we just leave things as they are. The "fix" is >> available to you; you can fudge your script file. > > Angus, > sorry to be a PITA, You're not. > but I would like to get your attention to the fact > that a regular expression in lyxpreview2bitmap.py may be needs to be > revised. > > After Paul's suggestion, I fixed the problem with dvipng, but the metrics > file turned out to be empty. I manually called dvipng and saw that its > output is as follows: > > $ dvipng ... 0lyxpreview.dvi > ... > [1 (preview-latex beginning-of-page-hook detected) (preview-latex > [tightpage \ > option detected, will use its bounding box) depth=1 height=9] Oh, that's horrid and the one that follows is worse. What I think you should do is talk to David Kastrup and Jan-Åke Larsson on the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're messing up the output that they devised for us. > That is what really goes to stdout, so IMO the RE should be changed to > account for the possible presence of newlines between "[1 " and " > depth=...". Or, the thing could be changed such that to catch separately > the "[x " and the " depth=...". Let's see what they have to say first... > My first impression is that the dvipng generated previews are much better > than those obtained through the ghostscript route. and much faster too. The one limitation it appears to have is its handling of PostScript specials although I'm sure that things have evolved since last I looked. (A couple of years ago...) -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming <[EMAIL PROTECTED]> writes: > Oh, that's horrid and the one that follows is worse. > What I think you should do is talk to David Kastrup and Jan-Åke Larsson on > the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're messing > up the output that they devised for us. 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. -- Enrico
Instant preview in LyX/Win 1.4.0pre3
Hi all!
For some reason the dvipng distributed with miktex (at least the one I have
installed) fails to generate the instant preview images:
$ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0
makepk: METAFONT failed on cmmi12.
C:\texmf\miktex\bin\dvipng.exe warning: font cmmi12 at 512 dpi not found,
characters will be left blank
makepk: METAFONT failed on cmti8.
C:\texmf\miktex\bin\dvipng.exe warning: font cmti8 at 512 dpi not found,
characters will be left blank
makepk: METAFONT failed on cmr12.
C:\texmf\miktex\bin\dvipng.exe warning: font cmr12 at 512 dpi not found,
characters will be left blank
C:\texmf\miktex\bin\dvipng.exe warning: at (1,-15) ignored header
\special{!/[EMAIL PROTECTED](11.81)def} Failed to extract metrics info from
dvipng
$ dvipng --version
This is C:\texmf\miktex\bin\dvipng.exe (dvipng) 1.6 Copyright 2002-2005 Jan-Ake
Larsson
dvipng.exe (dvipng) 1.6
kpathsea version 3.3.2
Copyright (C) 2002-2005 Jan-Ake Larsson.
There is NO warranty. You may redistribute this software
under the terms of the GNU General Public License.
For more information about these matters, see the files
named COPYING and dvipng.c.
So, I tried to force using the legacy_lyxpreview2ppm.py script only to
discover that it can only generate ppm images (as its name implies ;-)).
I propose the patch at the bottom to also allow png generation in the
legacy script. The patch also addresses the problem that when ascent or
descent are zero, then the generated image is not correctly aligned on
its baseline with the surrounding text.
Another problem I faced is the following. When not specifying a
\preview_scale_factor in preferences, the instant-preview inlined equations
are perfectly aligned on the baseline, but specifying, for example,
\preview_scale_factor 1.02 causes the inlined images to be shifted down
by a noticeable amount.
I obviated to this by hardcoding in the conversion script frac = 1.02*frac,
after frac is evaluated in extract_metrics_info(), where 1.02 matches my
\preview_scale_factor. I think that this should be done in the LyX sources
but I didn't had a look at it.
--
Enrico
--- ./lib/scripts/lyxpreview2bitmap.py 2005-09-21 11:22:18.0 +0200
+++ /c/Programmi/LyX-1.4.0/Resources/LyX-1.4.0pre3/scripts/lyxpreview2bitmap.py
2006-01-03 10:55:48.0 +0100
@@ -93,7 +93,7 @@
ascent = string.atof(match.group(3))
frac = 0.5
-if ascent 0 and descent 0:
+if ascent = 0 and descent = 0:
if abs(ascent + descent) 0.1:
frac = ascent / (ascent + descent)
@@ -145,15 +145,11 @@
# This can go once dvipng becomes widespread.
dvipng = find_exe([dvipng], path)
if dvipng == None:
-if output_format == ppm:
-# The data is input to legacy_conversion in as similar
-# as possible a manner to that input to the code used in
-# LyX 1.3.x.
-vec = [ argv[0], argv[2], argv[3], argv[1], argv[4], argv[5] ]
-return legacy_conversion(vec)
-else:
-error(The old 'dvi-ps-ppm' conversion requires
- ppm as the output format)
+ # The data is input to legacy_conversion in as similar
+ # as possible a manner to that input to the code used in
+ # LyX 1.3.x.
+ vec = [ argv[0], argv[2], argv[3], argv[1], argv[4], argv[5] ]
+ return legacy_conversion(vec)
pngtopnm =
if output_format == ppm:
--- ./lib/scripts/legacy_lyxpreview2ppm.py 2005-09-21 11:22:18.0 +0200
+++
/c/Programmi/LyX-1.4.0/Resources/LyX-1.4.0pre3/scripts/legacy_lyxpreview2ppm.py
2006-01-03 11:43:58.0 +0100
@@ -95,7 +95,7 @@
descent = string.atoi(match.group(3))
frac = 0.5
-if ascent 0 and descent 0:
+if ascent = 0 and descent = 0:
ascent = float(ascent) + tp_ascent
descent = float(descent) - tp_descent
@@ -226,8 +226,14 @@
dpi = string.atoi(argv[2])
output_format = argv[3]
-if output_format != ppm:
-error(This script will generate ppm format images only.)
+if output_format == ppm:
+ gsdevice = pnmraw
+ gssuffix = ppm
+elif output_format == png:
+ gsdevice = png16m
+ gssuffix = png
+else:
+error(This script will generate png or ppm format images only.)
fg_color = argv[4]
bg_color = argv[5]
@@ -272,12 +278,12 @@
alpha = 2
# Generate the bitmap images
-gs_call = '%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pnmraw ' \
- '-sOutputFile=%s%%d.ppm ' \
+gs_call = '%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=%s ' \
+ '-sOutputFile=%s%%d.%s ' \
'-dGraphicsAlphaBit=%d -dTextAlphaBits=%d ' \
'-r%f %s' \
- % (gs, latex_file_re.sub(, latex_file), \
- alpha, alpha, resolution, ps_file)
+ % (gs, gsdevice, latex_file_re.sub(, latex_file), \
+
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: Hi all! For some reason the dvipng distributed with miktex (at least the one I have installed) fails to generate the instant preview images: $ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0 makepk: METAFONT failed on cmmi12. You need to refresh the MikTeX databases. It's some obvious entry in the package manager's menus. If you can't find it then this is a FAQ on the MikTeX list. (Sorry I can't be less vague :() So, I tried to force using the legacy_lyxpreview2ppm.py script only to discover that it can only generate ppm images (as its name implies ;-)). What would be *clever* would be to use pvipng if it exists and to parse its error stream for any unable to handle PostScript special type messages, falling back on the dvips-ppm/png conversion route. I propose the patch at the bottom to also allow png generation in the legacy script. The patch also addresses the problem that when ascent or descent are zero, then the generated image is not correctly aligned on its baseline with the surrounding text. Another problem I faced is the following. When not specifying a \preview_scale_factor in preferences, the instant-preview inlined equations are perfectly aligned on the baseline, but specifying, for example, \preview_scale_factor 1.02 causes the inlined images to be shifted down by a noticeable amount. I obviated to this by hardcoding in the conversion script frac = 1.02*frac, after frac is evaluated in extract_metrics_info(), where 1.02 matches my \preview_scale_factor. I think that this should be done in the LyX sources but I didn't had a look at it. Hm. But we already pass preview_scale_factor to the script in the form of the dpi variable. Why do we need to use it twice? The patch looks good to me but I guess that this block in legacy_lyxpreview2bitmap.py (renamed ;-)) will need to be specialised for ppm files only... # Crop the images if pnmcrop != None: crop_files(pnmcrop, latex_file_re.sub(, latex_file)) I guess that's there's going to be some interaction between this cropping and the veracity of the metric info... -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming [EMAIL PROTECTED] writes: You need to refresh the MikTeX databases. It's some obvious entry in the package manager's menus. If you can't find it then this is a FAQ on the MikTeX list. (Sorry I can't be less vague :() Easy, Angus. I wasn't asking for help there ;-) It is not that simple, I'll have a look at it. Btw, the MikTeX databases can also be refreshed from the command line by initexmf -u. Another problem I faced is the following. When not specifying a \preview_scale_factor in preferences, the instant-preview inlined equations are perfectly aligned on the baseline, but specifying, for example, \preview_scale_factor 1.02 causes the inlined images to be shifted down by a noticeable amount. I obviated to this by hardcoding in the conversion script frac = 1.02*frac, after frac is evaluated in extract_metrics_info(), where 1.02 matches my \preview_scale_factor. I think that this should be done in the LyX sources but I didn't had a look at it. Hm. But we already pass preview_scale_factor to the script in the form of the dpi variable. Why do we need to use it twice? Perhaps you mean that the dpi variable is *proportional* to preview_scale_factor. Indeed, when not setting preview_scale_factor I obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I don't know the default value of preview_scale_factor (and obviously it is not equal to 1), so I am not able to evaluate preview_scale_factor from the knowledge of dpi. As regards why we need to use it twice, I don't know the way the images are imported. What I know is that if leave untouched the value of the frac variable *and* preview_scale_factor is set to something different than its default value, then the inlined images do not perfectly line up with the surrounding text. The patch looks good to me but I guess that this block in legacy_lyxpreview2bitmap.py (renamed ) will need to be specialised for ppm files only... # Crop the images if pnmcrop != None: crop_files(pnmcrop, latex_file_re.sub(, latex_file)) You're right, I overlooked that. But it is easy to fix, isn't it ? ;-) # Crop the images - if pnmcrop != None: + if pnmcrop != None and output_format == ppm: crop_files(pnmcrop, latex_file_re.sub(, latex_file)) I guess that's there's going to be some interaction between this cropping and the veracity of the metric info... I don't think so. The images are cropped to the left and to the right, so the vertical dimensions are preserved. As the only information that is passed back through the metrics file is the percentage of the height with respect to the sum of height and depth, there should be no interaction. -- Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote: Perhaps you mean that the dpi variable is *proportional* to preview_scale_factor. Indeed, when not setting preview_scale_factor I obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I don't know the default value of preview_scale_factor (and obviously it is not equal to 1), so I am not able to evaluate preview_scale_factor from the knowledge of dpi. 0.9 In src/graphics/PreviewLoader.C you'll find: font_scaling_factor_ = 0.01 * lyxrc.dpi * lyxrc.zoom * convertdouble(lyxrc.preview_scale_factor); ... cs pconverter_-command ' ' pconverter_-to ' ' support::QuoteName(latexfile) ' ' int(font_scaling_factor_) ' ' lyx_gui::hexname(LColor::preview) ' ' lyx_gui::hexname(LColor::background); This is the command used to launch the script. 'dpi' inside the script is 'int(font_scaling_factor_) outside it. Thereafter, the metrics info is used in setAscentFractions() in the same file. As regards why we need to use it twice, I don't know the way the images are imported. What I know is that if leave untouched the value of the frac variable *and* preview_scale_factor is set to something different than its default value, then the inlined images do not perfectly line up with the surrounding text. Right. But you'll understand that I'm unhappy about making a change I don't understand. The patch looks good to me but I guess that this block in legacy_lyxpreview2bitmap.py (renamed ) will need to be specialised for ppm files only... # Crop the images if pnmcrop != None: crop_files(pnmcrop, latex_file_re.sub(, latex_file)) You're right, I overlooked that. But it is easy to fix, isn't it ? ;-) # Crop the images - if pnmcrop != None: + if pnmcrop != None and output_format == ppm: crop_files(pnmcrop, latex_file_re.sub(, latex_file)) I guess that's there's going to be some interaction between this cropping and the veracity of the metric info... I don't think so. The images are cropped to the left and to the right, so the vertical dimensions are preserved. As the only information that is passed back through the metrics file is the percentage of the height with respect to the sum of height and depth, there should be no interaction. It's been a long time since I last looked at this ;-) -- Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming wrote: Enrico Forestieri wrote: For some reason the dvipng distributed with miktex (at least the one I have installed) fails to generate the instant preview images: $ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0 makepk: METAFONT failed on cmmi12. You need to refresh the MikTeX databases. It's some obvious entry in the package manager's menus. If you can't find it then this is a FAQ on the MikTeX list. (Sorry I can't be less vague :() It may be the format files rather than the package database. The MiKTeX Options app has a button on the General tab, Format files section labeled Update Now. Enrico should give that a whirl. I ran into something similar, albeit not with preview, where METAFONT abruptly lost the ability to generate fonts. It turned out that I'd updated some core MiKTeX package(s) and the format files had not been properly updated. Cheers, /Paul
Instant preview in LyX/Win 1.4.0pre3
Hi all!
For some reason the dvipng distributed with miktex (at least the one I have
installed) fails to generate the instant preview images:
$ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0
makepk: METAFONT failed on "cmmi12".
C:\texmf\miktex\bin\dvipng.exe warning: font cmmi12 at 512 dpi not found,
characters will be left blank
makepk: METAFONT failed on "cmti8".
C:\texmf\miktex\bin\dvipng.exe warning: font cmti8 at 512 dpi not found,
characters will be left blank
makepk: METAFONT failed on "cmr12".
C:\texmf\miktex\bin\dvipng.exe warning: font cmr12 at 512 dpi not found,
characters will be left blank
C:\texmf\miktex\bin\dvipng.exe warning: at (1,-15) ignored header
\special{!/[EMAIL PROTECTED](11.81)def} Failed to extract metrics info from
dvipng
$ dvipng --version
This is C:\texmf\miktex\bin\dvipng.exe (dvipng) 1.6 Copyright 2002-2005 Jan-Ake
Larsson
dvipng.exe (dvipng) 1.6
kpathsea version 3.3.2
Copyright (C) 2002-2005 Jan-Ake Larsson.
There is NO warranty. You may redistribute this software
under the terms of the GNU General Public License.
For more information about these matters, see the files
named COPYING and dvipng.c.
So, I tried to force using the legacy_lyxpreview2ppm.py script only to
discover that it can only generate ppm images (as its name implies ;-)).
I propose the patch at the bottom to also allow png generation in the
legacy script. The patch also addresses the problem that when "ascent" or
"descent" are zero, then the generated image is not correctly aligned on
its baseline with the surrounding text.
Another problem I faced is the following. When not specifying a
\preview_scale_factor in preferences, the instant-preview inlined equations
are perfectly aligned on the baseline, but specifying, for example,
"\preview_scale_factor 1.02" causes the inlined images to be shifted down
by a noticeable amount.
I obviated to this by hardcoding in the conversion script "frac = 1.02*frac",
after frac is evaluated in extract_metrics_info(), where 1.02 matches my
\preview_scale_factor. I think that this should be done in the LyX sources
but I didn't had a look at it.
--
Enrico
--- ./lib/scripts/lyxpreview2bitmap.py 2005-09-21 11:22:18.0 +0200
+++ /c/Programmi/LyX-1.4.0/Resources/LyX-1.4.0pre3/scripts/lyxpreview2bitmap.py
2006-01-03 10:55:48.0 +0100
@@ -93,7 +93,7 @@
ascent = string.atof(match.group(3))
frac = 0.5
-if ascent > 0 and descent > 0:
+if ascent >= 0 and descent >= 0:
if abs(ascent + descent) > 0.1:
frac = ascent / (ascent + descent)
@@ -145,15 +145,11 @@
# This can go once dvipng becomes widespread.
dvipng = find_exe(["dvipng"], path)
if dvipng == None:
-if output_format == "ppm":
-# The data is input to legacy_conversion in as similar
-# as possible a manner to that input to the code used in
-# LyX 1.3.x.
-vec = [ argv[0], argv[2], argv[3], argv[1], argv[4], argv[5] ]
-return legacy_conversion(vec)
-else:
-error("The old 'dvi->ps->ppm' conversion requires "
- "ppm as the output format")
+ # The data is input to legacy_conversion in as similar
+ # as possible a manner to that input to the code used in
+ # LyX 1.3.x.
+ vec = [ argv[0], argv[2], argv[3], argv[1], argv[4], argv[5] ]
+ return legacy_conversion(vec)
pngtopnm = ""
if output_format == "ppm":
--- ./lib/scripts/legacy_lyxpreview2ppm.py 2005-09-21 11:22:18.0 +0200
+++
/c/Programmi/LyX-1.4.0/Resources/LyX-1.4.0pre3/scripts/legacy_lyxpreview2ppm.py
2006-01-03 11:43:58.0 +0100
@@ -95,7 +95,7 @@
descent = string.atoi(match.group(3))
frac = 0.5
-if ascent > 0 and descent > 0:
+if ascent >= 0 and descent >= 0:
ascent = float(ascent) + tp_ascent
descent = float(descent) - tp_descent
@@ -226,8 +226,14 @@
dpi = string.atoi(argv[2])
output_format = argv[3]
-if output_format != "ppm":
-error("This script will generate ppm format images only.")
+if output_format == "ppm":
+ gsdevice = "pnmraw"
+ gssuffix = "ppm"
+elif output_format == "png":
+ gsdevice = "png16m"
+ gssuffix = "png"
+else:
+error("This script will generate png or ppm format images only.")
fg_color = argv[4]
bg_color = argv[5]
@@ -272,12 +278,12 @@
alpha = 2
# Generate the bitmap images
-gs_call = '%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pnmraw ' \
- '-sOutputFile="%s%%d.ppm" ' \
+gs_call = '%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=%s ' \
+ '-sOutputFile="%s%%d.%s" ' \
'-dGraphicsAlphaBit=%d -dTextAlphaBits=%d ' \
'-r%f "%s"' \
- % (gs, latex_file_re.sub("", latex_file), \
- alpha, alpha, resolution, ps_file)
+
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote:
> Hi all!
>
> For some reason the dvipng distributed with miktex (at least the one I
> have installed) fails to generate the instant preview images:
>
> $ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00
> f0f0f0 makepk: METAFONT failed on "cmmi12".
You need to refresh the MikTeX databases. It's some obvious entry in the
package manager's menus. If you can't find it then this is a FAQ on the
MikTeX list.
(Sorry I can't be less vague :()
> So, I tried to force using the legacy_lyxpreview2ppm.py script only to
> discover that it can only generate ppm images (as its name implies ;-)).
What would be *clever* would be to use pvipng if it exists and to parse its
error stream for any "unable to handle PostScript special" type messages,
falling back on the dvips->ppm/png conversion route.
> I propose the patch at the bottom to also allow png generation in the
> legacy script. The patch also addresses the problem that when "ascent" or
> "descent" are zero, then the generated image is not correctly aligned on
> its baseline with the surrounding text.
>
> Another problem I faced is the following. When not specifying a
> \preview_scale_factor in preferences, the instant-preview inlined
> equations are perfectly aligned on the baseline, but specifying, for
> example, "\preview_scale_factor 1.02" causes the inlined images to be
> shifted down by a noticeable amount.
>
> I obviated to this by hardcoding in the conversion script "frac =
> 1.02*frac", after frac is evaluated in extract_metrics_info(), where 1.02
> matches my \preview_scale_factor. I think that this should be done in the
> LyX sources but I didn't had a look at it.
Hm. But we already pass preview_scale_factor to the script in the form
of the dpi variable. Why do we need to use it twice?
The patch looks good to me but I guess that this block in
legacy_lyxpreview2bitmap.py (renamed ;-)) will need to be specialised for
ppm files only...
# Crop the images
if pnmcrop != None:
crop_files(pnmcrop, latex_file_re.sub("", latex_file))
I guess that's there's going to be some interaction between this cropping
and the veracity of the metric info...
--
Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming <[EMAIL PROTECTED]> writes:
> You need to refresh the MikTeX databases. It's some obvious entry in the
> package manager's menus. If you can't find it then this is a FAQ on the
> MikTeX list.
>
> (Sorry I can't be less vague :()
Easy, Angus. I wasn't asking for help there ;-)
It is not that simple, I'll have a look at it. Btw, the MikTeX databases
can also be refreshed from the command line by "initexmf -u".
> > Another problem I faced is the following. When not specifying a
> > \preview_scale_factor in preferences, the instant-preview inlined
> > equations are perfectly aligned on the baseline, but specifying, for
> > example, "\preview_scale_factor 1.02" causes the inlined images to be
> > shifted down by a noticeable amount.
> >
> > I obviated to this by hardcoding in the conversion script "frac =
> > 1.02*frac", after frac is evaluated in extract_metrics_info(), where 1.02
> > matches my \preview_scale_factor. I think that this should be done in the
> > LyX sources but I didn't had a look at it.
>
> Hm. But we already pass preview_scale_factor to the script in the form
> of the dpi variable. Why do we need to use it twice?
Perhaps you mean that the dpi variable is *proportional* to
preview_scale_factor. Indeed, when not setting preview_scale_factor I
obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I
don't know the default value of preview_scale_factor (and obviously it is
not equal to 1), so I am not able to evaluate preview_scale_factor from
the knowledge of dpi.
As regards why we need to use it twice, I don't know the way the images
are imported. What I know is that if leave untouched the value of the
frac variable *and* preview_scale_factor is set to something different
than its default value, then the inlined images do not perfectly line up
with the surrounding text.
> The patch looks good to me but I guess that this block in
> legacy_lyxpreview2bitmap.py (renamed ) will need to be specialised for
> ppm files only...
>
> # Crop the images
> if pnmcrop != None:
> crop_files(pnmcrop, latex_file_re.sub("", latex_file))
You're right, I overlooked that. But it is easy to fix, isn't it ? ;-)
# Crop the images
- if pnmcrop != None:
+ if pnmcrop != None and output_format == "ppm":
crop_files(pnmcrop, latex_file_re.sub("", latex_file))
> I guess that's there's going to be some interaction between this cropping
> and the veracity of the metric info...
I don't think so. The images are cropped to the left and to the right,
so the vertical dimensions are preserved. As the only information that is
passed back through the metrics file is the percentage of the height with
respect to the sum of height and depth, there should be no interaction.
--
Enrico
Re: Instant preview in LyX/Win 1.4.0pre3
Enrico Forestieri wrote:
> Perhaps you mean that the dpi variable is *proportional* to
> preview_scale_factor. Indeed, when not setting preview_scale_factor I
> obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I
> don't know the default value of preview_scale_factor (and obviously it is
> not equal to 1), so I am not able to evaluate preview_scale_factor from
> the knowledge of dpi.
0.9
In src/graphics/PreviewLoader.C you'll find:
font_scaling_factor_ = 0.01 * lyxrc.dpi * lyxrc.zoom *
convert(lyxrc.preview_scale_factor);
...
cs << pconverter_->command << ' ' << pconverter_->to << ' '
<< support::QuoteName(latexfile) << ' '
<< int(font_scaling_factor_) << ' '
<< lyx_gui::hexname(LColor::preview) << ' '
<< lyx_gui::hexname(LColor::background);
This is the command used to launch the script. 'dpi' inside the script is
'int(font_scaling_factor_) outside it.
Thereafter, the metrics info is used in setAscentFractions() in the same
file.
> As regards why we need to use it twice, I don't know the way the images
> are imported. What I know is that if leave untouched the value of the
> frac variable *and* preview_scale_factor is set to something different
> than its default value, then the inlined images do not perfectly line up
> with the surrounding text.
Right. But you'll understand that I'm unhappy about making a change I don't
understand.
>> The patch looks good to me but I guess that this block in
>> legacy_lyxpreview2bitmap.py (renamed ) will need to be specialised for
>> ppm files only...
>>
>> # Crop the images
>> if pnmcrop != None:
>> crop_files(pnmcrop, latex_file_re.sub("", latex_file))
>
> You're right, I overlooked that. But it is easy to fix, isn't it ? ;-)
>
> # Crop the images
> - if pnmcrop != None:
> + if pnmcrop != None and output_format == "ppm":
> crop_files(pnmcrop, latex_file_re.sub("", latex_file))
>
>> I guess that's there's going to be some interaction between this
>> cropping and the veracity of the metric info...
>
> I don't think so. The images are cropped to the left and to the right,
> so the vertical dimensions are preserved. As the only information that is
> passed back through the metrics file is the percentage of the height with
> respect to the sum of height and depth, there should be no interaction.
It's been a long time since I last looked at this ;-)
--
Angus
Re: Instant preview in LyX/Win 1.4.0pre3
Angus Leeming wrote: Enrico Forestieri wrote: For some reason the dvipng distributed with miktex (at least the one I have installed) fails to generate the instant preview images: $ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0 makepk: METAFONT failed on "cmmi12". You need to refresh the MikTeX databases. It's some obvious entry in the package manager's menus. If you can't find it then this is a FAQ on the MikTeX list. (Sorry I can't be less vague :() It may be the format files rather than the package database. The MiKTeX Options app has a button on the General tab, Format files section labeled "Update Now". Enrico should give that a whirl. I ran into something similar, albeit not with preview, where METAFONT abruptly lost the ability to generate fonts. It turned out that I'd updated some core MiKTeX package(s) and the format files had not been properly updated. Cheers, /Paul
