[pstricks] Is pst-pdf meant to work with arbitrary postscript

Gene Selkov selkovjr at gmail.com
Wed Sep 16 20:23:42 CEST 2009


Wow! What an explosion of opportunities! 

(I am still trying to assess whether ps2pdf will do the job, and I have
just found that ochem can in theory render all figures on separate
pages, which if true will mean that the problem of processing them with
pdf*tex can be solved)

> try it with the attached two files ochem.sty and ochem.pro
> 
> It works for me without an error

Works for me too, although the graphics and text have fallen apart and
are scattered across the page. But both graphics and text are correct,
though (in terms of the number of things and their size). The lines seem
to be "more correct" than text; I noticed that when things do work, the
entire construct is rendered in the bottom left corner of the page,
(although I don't know whether its relative location matters at all,
given that cropping must be done at a later stage).

The attached file shows how things are supposed to look when rendered
correctly -- it too is made with jadetex and dvips, but with pst-pdf
disabled.

I am trying to understand what happened. The part where pspicture
environment gets parsed by pst-pdf seems to be straightforward. But it
apperas to depend on something else that pst-pdf misses (or that I am
neglecting to direct it to). Where does that come from normally, along
the jadetex-dvi route? Would it be helpful to think about grabbing a
larger chunk of the tex code, in the same manner as ps4pdf did with the
\PSforPDF macro?

Where did you get those macros now in ochem.sty?

I see them in the working version of the dvi file, but their origin
eludes me. 

Thanks,

--Gene
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page5.ps
Type: application/postscript
Size: 77283 bytes
Desc: not available
URL: <http://tug.org/pipermail/pstricks/attachments/20090916/e9e60461/attachment-0001.ps>


More information about the PSTricks mailing list