[l2h] Another pstricks question

[Ross Moore]

Hi Mark,

On 01/12/2004, at 8:25 AM, Mark Horner wrote:

> Hi LaTeX2HTML gurus
>
> I browsed your archive and noticed a few unanswered pstricks problems 
> - perhaps everything was solved offline. I also
> have a pstricks problem which has very similar characteristics to 
> those I saw in the archive. I am working on a free
> textbook (http://www.nongnu.org/fhsst) which we want to put online - 
> we used latex and pstricks for the books but don't
> want to redo the images. When I latex2html the book the images 
> (mostly) don't work. I get the "Bad file descriptor" message.

Interesting problem.

I think the reason for your difficulties lies with the way LaTeX2HTML 
relies upon
  dvips -E   (create .eps  images of each page) to get the BoundingBox 
for the images
that it needs to create.

Since  PSTricks  uses straight PostScript code to place most of the ink 
for the image,
and the contents of the corresponding  \special commands do *not* 
contribute to
the size that is calculated by  dvips -E  , then you may get an image 
that is too small,
having cropped away most of the desired contents.

This is certainly what happened for me, when trying your example.


>
> I have tried to strip things down to a characteristic simple case (my 
> actual test file test.tex is attached):
>

Try the effect of the following:

> \begin{document}
> \begin{figure}[H]
     \framebox{%      <<<<--------------  insert this here!
>    \begin{pspicture}(0,0)(8,2)
>      \cnode[fillstyle=crosshatch](.5,1){.4}{mycircle}
>      \psline{->}(1,1)(3,1)
>      \rput(2,0.6){$p_1$, $E_1$}
>      \cnode[fillstyle=hlines](7.5,1){.4}{mycircle2}
>      \psline{->}(7,1)(5,1)
>      \rput(6, 0.6){$p_2$, $E_2$}
>    \end{pspicture}
     }%      <<<<--------------  and also this here!
> \end{figure}
> \end{document}

The \framebox is built from TeX rules, which *do* contribute to the  
dvips -E
calculation.

Now if you do not want the resulting frame, try using  \fcolorbox  
instead,
with a white frame. (If that results in a gray background, then 
explicitly
include  \pagecolor{white}   in the laTeX preamble.)


>
> After reading the manual I see no reason why it does not work - but it 
> certainly doesn't! I attempted to look into the problem but
> got out of my depth very quickly! I would really appreciate some help 
> - I have attached the output of the command:

Yes --- it's not an easy one to diagnose.

You can get a hint from this log-message:

> pstoimg: Running /usr/bin/gs  -sDEVICE=ppmraw -g47x18  -r115 
> -dTextAlphaBits=4  -sOutputFile=/tmp/l2h6872/p6887.pnm
> GS>-110 -658 translate

In the geometry switch:   -g47x18    the height of 18 is surely too 
small!

> GS>Image "/tmp/l2h6872/p6887.pnm" is PPM, 47x18
> Running "/usr/bin/pnmcrop -verbose  < /tmp/l2h6872/p6887.pnm | 
> /usr/bin/ppmquant -floyd 256 | /usr/bin/pnmtopng -interlace -trans 
> '#ffffff'  > img1.png"
> pnmcrop: Background color is white
> pnmcrop: The image is entirely background; there is nothing to crop.
> pnmcolormap: Error reading magic number from Netpbm image stream.  
> Most often, this means your input file is empty.
> pnmcolormap failed, rc=256
> pnmtopng: Error reading magic number from Netpbm image stream.  Most 
> often, this means your input file is empty.

This means that GS rendered an area of the page that missed the ink 
entirely;
hence the image appeared to contain only background, so was cropped away
on the first call to  pnmcrop .
That left nothing for the later steps, resulting in no image at all.



>
> latex2html -debug -verbosity 2 test.tex
>
> in the file testoutput.out.
>
> I have noticed a few things - when making dvi files rput commands 
> don't work but then dvips'ing them gets a ps file correctly rendered. 
> I don't know
> why this is. Also in other problems where there is text below circles 
> for example sometimes I get the text with bits of the circles in the 
> top of the picture - as though
> the cropping couldn't define the picture.

I'd guess it was all there, within the temporary .ps files, but with a 
wrong BoundingBox size.
So latter steps in the image-generation failed to capture the full 
contents,
effectively just cropping them away.

Use the \framebox  suggested above to test this theory.
Alternatively you could use:
    \colorbox{white}{.......}   or    \fcolorbox{white}{white}{.......}

The draw-back is that you will need to modify all of the source 
documents,
to place (a command which expands to) the \colorbox command.

Since all of LaTeX's color-box commands (as above) need to read their 
argument,
it is not possible to easily hack at \pspicture to make it happen 
automagically.


>
> I am open to any suggestions and would greatly appreciate any advice? 
> If I should be talking to the pstricks people please let me know.

The real fault lies with  dvips .
But that's unlikely to ever be fixed, as  dvips  is *not* a PostScript 
interpreter,
so cannot deduce what is the true bounding-box of the image.

The only way the PSTricks people could help is to write extra comments
into their \special commands, which would leave hints as to the true 
size,
so that  dvips  (or other software) could find and use such hints.
To achieve this, many things would need to be rewritten.

>
> Thanks,
>
> Mark
>
>

Hope this helps,

	Ross Moore


>
> -- 
> --
> Mark Horner                                                            
>                                              Jabber/AIM/Yahoo:   
> marknewlyn
> Co-author:
> http://www.nongnu.org/fhsst
> http://savannah.gnu.org/projects/fhsst


p.s.
The  FHSST  sounds like a great project.
I'm really happy that you have chosen to use LaTeX2HTML
to generate the website.
If there's anything that I can do to help make it suit your needs
better, just email --- I'd be glad to help.



>
> "Life is but a seg-fault away ...
>
> Life received signal SIGSEGV, Segmentation fault.
> 0x42074d40 in calloc () from /lib/i686/liblife.so.6"