[l2h] Problem with Gif generation after MiKTeX 2.4

[Peter Morling]

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>