[l2h] black lines at the left and bottom of the generated images

Ross Moore ross@ics.mq.edu.au
Sat, 13 Oct 2001 09:57:25 +1000 (EST)


> I've seen this problem in the list but i haven't seen the answer so i
> create my own pstoimg script that uses convert of ImageMagic instead of
> netpbm to see if it was the problem but NO! the images are still bad!!!.

Your script makes a simple conversion from .eps to another format
 (using Ghostscript, since ImageMagick links to the GS libraries).

There is no attempt to do the crop that allows the image to be sized
to exactly the correct size and shape needed for proper alignment
in the HTML page.

Those L-shaped "cropping-bars" are deliberately part of the image,
for they allow the correct amount of space to be captured as part
of the image, within the rectangle defined by the interior of the
cropping-bars. Hence they are an important part of the image.
Of course they need to be removed, once the image has been cut
down to the correct size, and that is where  pnmcrop  is used.


> Please, someone tell me how to fix this problem!!!

A.
The *normal* fix would be to compile and install netpbm
 --- or at least sufficient part of it to use the  pstoimg
script that comes with LaTeX2HTML.


B.
An alternative fix might be to use a (hairline thin) rectangle
around the image contents, rather than wide cropping-bars.
Then if dvips can be trusted to get the bounding-box of the .eps
exactly right, there may be no need for further adjustments to
the size of the image.

Some type of delimiting object is needed, else dvips will just
calculate the BoundingBox to be the minimal area containing the
contents, leaving nothing for the extra space that is usually needed.
It has to be hairline thin, else it will need to be cropped-off too.


Unfortunately this doesn't work when TeX typesets characters that
place ink outside the metric-size of the character glyph;
e.g. at the bottom of script capitals with rounded base (S O C Q)
and in some fancy fonts (accented characters, Indic scripts).


C.
The *best* alternative to using netpbm would be to have a cropping
utility available with ImageMagic, that works in a similar way to
how  pnmcrop  determines what needs to be cropped.

Most cropping utilities need to be told now much to crop, and/or
which rows/columns of pixels should be removed.
 pnmcrop  is much smarter, in that when told to crop from one
side, it will only do so if *all* the pixels along that edge are
of the same color; it then crops as many complete rows/columns as
are of this same color, along that edge.


So if you can provide a utility that emulates pnmcrop, then we
will be glad to write a version of pstoimg that uses ImageMagic
and not  netpbm .



BTW, I looked at the innards of ImageMagic last weekend,
and successfully managed to compile it for my Digital Unix box
(for which there is no pre-compiled binary).
It uses much the same libraries that netpbm uses, for the vital
image conversion routines. In particular, it uses Ghostscript
for handling .eps and .ps files. 
(The difficulty in achieving a smooth compilation was similar to
getting a smooth compilation of all the utilities in  netpbm .)

Thus, in principle, it offers nothing extra over what  netpbm
can do. It just wraps up the coding into a big black box with
buttons to push (i.e. command-line options). On the other hand,
netpbm uses separate utilities for different tasks; so is *much*
more easily scriptable to perform a particular specialised task.

On the down-side, there is little scope for debugging when an
ImageMagic conversion goes wrong; whereas with a scripted set
of calls to  netpbm  utilities, you can isolate the particular
utility that has failed in a sequence of conversion steps.



Hope this helps,

	Ross Moore


> 
> ---
> Jaime Alberto Silva Colorado
> Administrador servidores Linux
> grupo DESOFMAT
> Universidad Tecnológica de Pereira
> ICQ# 75722794
> AOL Messenger screen name: el mono jaime
> 

[Attachment, skipping...]

[Attachment, skipping...]