[l2h] solutions to cropping problems, with netpbm v9.x

[Ross Moore]

Hi LaTeX2HTML users,

Concerning the  pnmcrop  utility from the  Netpbm  utilities (v 9.x)
available at  sourceforge.org , and the problems that this causes
to image-generation with LaTeX2HTML ...

   ... here's my understanding of what is going wrong,
and suggested stategies to get it fixed.

 pnmcrop  first tries to determine a "background-color"
and crops-off only rows or columns which are all of this color.

In 1994p1 the strategy to determine this background was
 1. see if 3 corners are the same color; if so, then use this;
 2. if not, see if 2 corners are the same and use this;
 3. if not, then construct an average using all 4 corners.

The subroutine called for this is:  pnm_backgroundxel  from  libpnm3.c .
The commandline switches -black and -white override this.


In v9.6 and later (up to 9.11, and perhaps as early as 8.x) this was
changed to call instead   pnm_backgroundxelrow   also from  libpnm3.c .
However this only uses a single row of the image to determine the
 background-color, so far as I can tell.

I think it is the top row that is used, as there seems to be
just one call to:  pnm_readpnmrow  in the  compute_background
routine of  pnmcrop.c .

Thus there is no way of determining the color of the cropping-bars
from just looking at the top row of a typical image as currently
produced for use with LaTeX2HTML.
This means that the cropping-bars do not get cropped-off.


What to do about it ?

Either:

 1. fix pnmcrop to return to the strategy of  1994p1

 This is my preference, but I don't know what effect this will have
on other uses of  pnmcrop .
Also, there is the time-factor, and there are a lot of `bad' versions
out there, which will probably never be updated.

 1a.  add an extra switch to  pnmcrop  that allows the user to choose
      which background strategy to use.

      pstoimg  would be adjusted to use this switch, when available.

OR

 2.  adjust LaTeX2HTML to put the lower cropping-bar at the top instead.

 This in itself is not a full solution, as it only works for those
images where there is currently a lower cropping-bar.

e.g. for displayed-math and other "vertical" environments,
there is only a left-side cropping-bar.
For these, the width is determined by the width of the material typeset.
The purpose of the cropping bar is only to add white-space above and below
the main content of the image.

Adding a cropping-bar at the top is fraught with danger, for TeXnical reasons,
related to vertical/horizontal modes, and overflowing the \textwidth .



Would someone please verify my assesment of the problem and proposed
solutions. 


As a temporary fix, that works for black cropping-bars on light-colored backgrounds,
the  pstoimg  file can be edited in 2 places:

1.  add the  -verbose  switch to all calls to pnmcrop; e.g.

    my $PNMCROP = '/share/netpbm/bin/pnmcrop -verbose ';
                                             ^^^^^^^^^

2. edit  pstoimg  according to the following diff: 

diff -r1.11 pstoimg.pin
1251,1253c1251,1257
<       $croparg = '-bot ';
<     } elsif($edge =~ /[tlr]/i) {
<       $croparg = "-$edge ";
---
>       $croparg = '-bot -black ';
>     } elsif($edge =~ /t/i) {
>       $croparg = '-top ';
>     } elsif($edge =~ /l/i) {
>       $croparg = '-left -black ';
>     } elsif($edge =~ /r/i) {
>       $croparg = '-right ';

This should result in the relevant portion of  pstoimg  looking like:

  while ($EXTRA_CROP =~ /([atblrs])/gi) {
    my $edge = $1;
    my $croparg = '';
    if($edge =~ /b/i) {
	$croparg = '-bot -black ';
    } elsif($edge =~ /t/i) {
	$croparg = '-top ';
    } elsif($edge =~ /l/i) {
	$croparg = '-left -black ';
    } elsif($edge =~ /r/i) {
	$croparg = '-right ';
    } elsif($edge =~ /s/i) {
#RRM: shave at most 1-2 rows of white from the bottom


Be aware that using -black in this way may not work with colored text;
it certainly will fail for light text on a black background.


I hope this helps overcome some difficulties.


All the best,

	Ross Moore