[l2h] Another pstricks question

Mark Horner marknewlyn at yahoo.co.uk
Wed Dec 1 02:38:46 CET 2004


Hi Ross

Thanks very much for the explanation and solution. I have tried a few of 
them and things look fine.

I really appreciate the help as you've saved me a tremendous amount of 
work :-D

Thanks again,

Mark

Ross Moore wrote:

> 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"
>
>
>


-- 
--
Mark Horner                                                                                                         
Jabber/AIM/Yahoo:   marknewlyn                                                               

Co-author:
http://www.nongnu.org/fhsst
http://savannah.gnu.org/projects/fhsst

"Life is but a seg-fault away ...

Life received signal SIGSEGV, Segmentation fault.
0x42074d40 in calloc () from /lib/i686/liblife.so.6"




More information about the latex2html mailing list