[l2h] Problem with Gif generation after MiKTeX 2.4
Julius Smith
julius.smith at gmail.com
Thu Jun 23 06:24:31 CEST 2005
I just ran into this problem upon upgrading from Fedora Core 2 to Fedora Core 4.
In debugging this, I verified that Ross's analysis is correct: the
vrule/hrule rounding in ghostscript's ps-to-pnm conversion sometimes
leaves a row of white pixels along the bottom to the right the vrule
on the left. (In other words, the vrule on the left extends one pixel
deeper than the hrule along the bottom, which throws off the pnmcrop
sequence.) Unfortunately, for me, changing MATH_SCALE_FACTOR just
changed the subset of images having the problem. (I have a large
number of images.)
I seem to have tracked the problem down to a new "QV" postscript
routine emitted in all the image postscript headers by dvips:
% Patch by TVZ
% Makes dvips files draw rules with stroke rather than fill.
% Makes narrow rules more predictable at low resolutions
% after distilling to PDF.
% May have unknown consequences for very thick rules.
% Tested only with dvips 5.85(k).
TeXDict begin
/QV {
gsave newpath /ruleY X /ruleX X
Rx Ry gt
{ ruleX ruleY Ry 2 div sub moveto Rx 0 rlineto Ry }
{ ruleX Rx 2 div add ruleY moveto 0 Ry neg rlineto Rx }
ifelse
setlinewidth 0 setlinecap stroke grestore
} bind def
end
I found this patch in
/usr/share/texmf/dvips/misc/alt-rule.pro
and renamed it to "QV_Hide" (to get the default definition for QV),
and now the problem seems to be gone for me once again. I also tried
debugging the patch by adding the same rounding that was in the
previous QV definition:
/QV {
gsave newpath
transform round exch round exch itransform
/ruleY X /ruleX X
Rx Ry gt
{ ruleX ruleY Ry 2 div sub moveto Rx 0 rlineto Ry }
{ ruleX Rx 2 div add ruleY moveto 0 Ry neg rlineto Rx }
ifelse
setlinewidth 0 setlinecap stroke grestore
} bind def
So far this seems to fix the problem as well, while preserving the use
of strokes instead of fills for rules. However, rounding to device
coordinates may negate the intended benefit of using strokes, since I
can't see why there should be any difference in the rounded case. In
the unrounded case, I can imagine anti-aliased strokes spanning
non-integer runs of pixels. However, we clearly do not want anything
but solid black rules here on the left and bottom.
If the v/h-rules could be calculated to be an integer number of pixels
in length and width at the latex level (in the code emitted to
images.tex), then it shouldn't matter whether rounding is performed by
the QV routine. At the moment, that seems like the Right Fix to me.
Julius
On 11/1/04, Peter Morling <pmorling at nat.sdu.dk> wrote:
> Hi Ross,
>
> Thanks. I did try to vary the $IMAGE_SCALE. Setting the MATH_SCALE_FACTOR a
> little higher e.g. 1.85 will help the problem a little. But, then math is
> larger than text and this is not a good solution. However i just found that
> setting:
>
> $PK_GENERATION = 1;
> $METAFONT_DPI = 72;
>
> solves the problem and everythings is back to normal, it works! But what is
> the problem then? My guess is that MiKTeX release 2.4. either uses new
> dimensions on their fonts or they use a new colormap. I will try and find
> out. What do you think? How should LateX2HTML react on this in the future?
>
> Best,
> Peter
>
> ----- Original Message -----
> From: "Ross Moore" <ross at maths.mq.edu.au>
> To: "Peter Morling" <pmorling at nat.sdu.dk>
> Cc: <latex2html at tug.org>
> Sent: Saturday, October 30, 2004 1:50 PM
> Subject: Re: [l2h] Problem with Gif generation after MiKTeX 2.4
>
>
> > Hi Peter,
> >
> > On 30/10/2004, at 1:31 AM, Peter Morling wrote:
> >
> > >
> > > *** processing 1 images ***
> >
> >
> > The script that is being run now is pstoimg :
> >
> > > Debug (syswait): Running "C:\Perl\bin\perl.exe
> > > C:\usr\local\l2h\bin\pstoimg.bat
> > > -type gif -debug -tmp C:\Temp\l2h2116 -discard -scale 1.6 -geometry
> > > 26x16 -margi
> > > ns 126,72 -crop abls -transparent -out img1.gif
> > > C:\Temp\l2h2116\image001.ps"
> > > at C:\usr\local\l2h\bin/latex2html.bat line 4249
> >
> > This is a Perl script that comes with LaTeX2HTML.
> > You can read it and follow its logic, to correlate
> > the messages with the program-flow.
> >
> >
> > > Running "C:\usr\local\bin\pnmcrop.exe -verbose <
> > > C:\Temp\l2h2116\p1408.pnm > C:\Temp\l2h2116\p1408.t01"
> >
> >
> > >> C:\usr\local\bin\pnmcrop.exe: Background color is #0000b3
> > >> C:\usr\local\bin\pnmcrop.exe: cropping 2 rows off the top
> > >> C:\usr\local\bin\pnmcrop.exe: cropping 2 rows off the bottom
> > >> C:\usr\local\bin\pnmcrop.exe: cropping 1 col off the left
> > >> C:\usr\local\bin\pnmcrop.exe: cropping 3 cols off the right
> > >> C:\usr\local\bin\pnmcrop.exe: Background color is #000000
> >
> > At this point, the image should have been cropped to just
> > snugly include the "cropping-bars" (or justification bars).
> >
> > This step means that LaTeX2HTML doesn't need to know
> > "exactly" where the ink is on the page, omly that it indeed
> > is within the rectangular graphic produced by dvips and
> > Ghostscript. That way we don't need to worry about variability
> > with software versions, or that different fonts may be being
> > used on different platforms.
> >
> >
> > Next the cropping-bars are removed:
> >
> > > Running "C:\usr\local\bin\pnmcrop.exe -verbose -bot -sides <
> > > C:\Temp\l2h2116\p1408.pnm > C:\Temp\l2h2116\p1408.t02"
> >
> > >> C:\usr\local\bin\pnmcrop.exe: Not cropping. No border found.
> > >> C:\usr\local\bin\pnmcrop.exe: Background color is #000000
> > >>
> > Hmm; failure to remove the bottom bar should mean that the
> > bottom row of pixels is not all of the same colour (usually black).
> >
> > That happens when the font-metrics are not such as to correctly
> > include all of the "ink" within the rectangle described by the metric
> > information.
> >
> > This sometimes happens at the right-hand end, with math symbols
> > that are "curvy", such as script letters. Adding an extra \, in the
> > LaTeX
> > is generally enough to fix it.
> >
> > Alternatively, it could be that the cropping-bars themselves do not meet
> > exactly at the left-hand end.
> >
> >
> > > Running "C:\usr\local\bin\pnmcrop.exe -verbose -l -sides <
> > > C:\Temp\l2h2116\p1408.pnm > C:\Temp\l2h2116\p1408.t03"
> >
> > >> Image "C:\Temp\l2h2116\p1408.pnm" is PGM, 46x35
> > >> C:\usr\local\bin\pnmcrop.exe: cropping 2 cols off the left
> > >> C:\usr\local\bin\pnmcrop.exe: Background color is #0000b3
> >
> > Having used the -debug switch, you should be able to look at the
> > temporary bitmap images: p1408.t01 p1408.t02 p1408.t03 etc.
> > to see what went wrong.
> >
> > (The process number, 1408 here, will be different each time.)
> >
> >
> > One final "shaving" crop is done along the bottom edge:
> >
> > > Running "C:\usr\local\bin\pnmcrop.exe -verbose -sides -bot <
> > > C:\Temp\l2h2116\p1408.pnm > C:\Temp\l2h2116\p1408.t04"
> > > Image "C:\Temp\l2h2116\p1408.t04" is PGM, 46x34
> >
> > >> C:\usr\local\bin\pnmcrop.exe: cropping 1 row off the bottom
> >
> > ... just in case there are 1 or 2 rows of all-white pixels there.
> > This is to ensure that text without descenders sit snugly on
> > the baseline, rather than a little above it.
> >
> > If this "shave" removes too much, then it's assumed that
> > all that white space is required --- the unshaved image
> > is used instead.
> >
> >
> > > Image "C:\Temp\l2h2116\p1408.pnm" is PGM, 46x34
> > > Running "C:\usr\local\bin\ppmquant.exe 256 < C:\Temp\l2h2116\p1408.pnm
> > > >
> > > C:\Temp\l2h2116\p1408.t05"
> > >
> > >> C:\usr\local\bin\ppmquant.exe: making histogram...
> > >> C:\usr\local\bin\ppmquant.exe: 2 colors found
> > >> C:\usr\local\bin\ppmquant.exe: choosing 256 colors...
> > >> C:\usr\local\bin\ppmquant.exe: mapping image to new colors...
> >
> >
> > > Running "C:\usr\local\bin\ppmtogif.exe -trans #ffffff <
> > > C:\Temp\l2h2116\p1408.pnm > img1.gif"
> > > pstoimg.bat: Written img1.gif
> > >
> > >> C:\usr\local\bin\ppmtogif.exe: computing colormap...
> > >> C:\usr\local\bin\ppmtogif.exe: 2 colors found
> > >
> >
> >
> > > (img1.gif is attached)
> >
> >
> > > Why is the gif created from p1408.pnm ? And not one of the .pnm files
> > > that
> > > are cropped?
> >
> > There is a renaming of the final temporary file back to the standard
> > .pnm name.
> >
> > In the pstoimg script, you'll see that the various graphics utilities
> > are
> > called via:
> > &do_cmd($in,$tmp,$cmd) || return 0;
> >
> > The coding in sub do_cmd includes a Rename call,
> > so that the input and output files have the standard .pnm name.
> >
> > This is done to make it easy to call the various utilities for special
> > effects:
> > flip, rotate, padding, etc.
> >
> >
> >
> > >
> > > If I manually executes:
> > >
> > > C:\testtex>C:\usr\local\bin\pnmcrop.exe -black -verbose -bot <
> > > C:\Temp\l2h2116\p1408.pnm > C:\Temp\l2h2116\p1408.tmp
> > > C:\usr\local\bin\pnmcrop.exe: Background color is #000000
> > > C:\usr\local\bin\pnmcrop.exe: cropping 2 rows off the bottom
> > >
> >
> > > I will get the correct image, attached: img1a.gif.
> > >
> >
> > OK; but you aren't working with the same input file that
> > LaTeX2HTML used.
> >
> > Try it with p1408.t01 or p1408.t02 and you should find
> > that a bottom-crop doesn't work.
> >
> >
> > I think the cropping-bars are not meeting properly ---
> > just missing by a single pixel; viz
> >
> >
> > XX
> > XX
> > XX XXXX (bottom of a letter 'O' say)
> > XX XXXX XXXX
> > XX XXXX XXXX
> > XX XXXXXXX
> > XX
> > XX
> > XXXXXXXXXXXXXXXXXXXXXXXXXXX
> > XXXXXXXXXXXXXXXXXXXXXXXXXXX
> > XXXXXXXXXXXXXXXXXXXXXXXXXXX
> > XX
> >
> >
> > Here the 1st bottom-crop will fail.
> > The left-crop removes the 2 columns on the left;
> > and now the shaving-crop removes the white row at the bottom.
> > (If the bottom bar had been correctly removed, the shave would
> > have removed the 2 white rows above it!)
> >
> > > I hope this information is detailed enough.
> > >
> >
> > Does this explanation make sense to you.
> >
> > If there is indeed just 1 pixel causing problems with some images,
> > then it's probably due to a rounding effect, as Ghostscript creates
> > an image at fixed resolution. The bottom edges of the \hrule s for
> > the bars may be just sufficiently different to be on different sides
> > of a pixel boundary.
> >
> > Try varying the $IMAGE_SCALE factor by small amounts, and force
> > the images to be remade.
> > You should be able to find a suitable value that works well without
> > oversizing the images.
> >
> >
> > >
> > > Best,
> >
> > Hope this helps,
> >
> > Ross
> >
> >
> > > Peter
> > > <img1.gif><img1a.gif>
>
> _______________________________________________
> latex2html mailing list
> latex2html at tug.org
> http://tug.org/mailman/listinfo/latex2html
>
More information about the latex2html
mailing list