Hi all;
Just when I thought I'd seen the last of those registration marks leaking
through the image creation process --- after all, I've got the latest
everything:
(dvipsk 5.58f, Aladdin Ghostscript 5.10, netpbm 1 March 1994 (p1 !!)
But, then I tried a larger math scale factor & they're back!
It seems that when gs produces the ppm images it's _occasionally_ breaking
contact between the left registration mark and the bottom one.
Using gs (or showps) to view the ps files doesn't reveal any break, but
it appears in the ppm file. As it's (always?) a single pixel off, it's
apparently a rounding error in gs.
But, I'll offer a workaround:
Normally, the cropping code "bl" produces the sequence
pnmcrop | pnmcrop -bottom | pnmcrop -left
to crop all the white, then the bottom bar (which it recognizes as black,
because of the black in the upper left?) and finally the left bar. Cropping
the
bottom fails when there's a gap.
Consider this alternative:
pnmcrop | pnmcrop -left | pnmcrop -left | pnmcrop -black
the first -left crops the black, the second -left crops the white gap if there
is one (if the bottom bar extends all the way to the left it wont crop
anything). The last crops any borders containing only black: the bottom.
This will work fine IFF 1) the real image doesn't extend into the gap, in
which case it will fail as before (but this shouldn't happen?) and 2) if the
real image doesn't consist of an all black border along any of the 4 sides.
To implement this, I changed the various cropping codes in latex2html
where there was a "bl" to "ll0"
and I added 2 new codes to pstoimg 0 and 1 which yield "| $pnmcrop -black" and
"| $pnmcrop -white" respectively.
I'll gladly supply more details if anyone thinks this is a sane approach :>
[A more expensive sequence that solves the second condition would be:
pnmcrop | pnmcrop -left | pnmcrop -left | pnmpad -black -l1 | pnmcrop -bottom
| pnmcrop -left
ugh]
--
--
[EMAIL PROTECTED]
http://math.nist.gov/~BMiller/
