[l2h] Problem with Gif generation after MiKTeX 2.4

[Ross Moore]

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>