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"