Ned Konz ned@squeakland.org wrote:

I'm trying to get the Postscript export working for my Connectors documentation. I have fixed a couple of problems with the Bezier drawing (like using eofill rather than fill), and am now attacking the polygon drawing and filling.

Go Ned!! If you can clean this up that would be really awesome.

Has anyone done any work with the Postscript output recently?

Everyone seems to have the same experience I have had and that you seem to be having: it looks *really* nice when it works, but there are also a lot of places where the output looks funny. I would be interested, too, if someone has been really using this code lately, but my guess is that they don't because you have to be so careful of the structure of your morphs.

-Lex

I haven't done ps programming recently and I'd have to drag out the books to answer some of your questions, but here's some answers.

I'm trying to get the Postscript export working for my Connectors documentation. I have fixed a couple of problems with the Bezier drawing (like using eofill rather than fill), and am now attacking the polygon drawing and filling.

However, I'm a bit puzzled about a few things (note that I really am NOT a Postscript programmer):

• The bounding box in the EPS output is too small by the 10x10 offset that is

added, so the right edge of the printed Morph is clipped, and the morph is not centered in the resultant bbox.

• For some reason,

PostscriptCanvas>>frameAndFillRectangle:fillColor:borderWidth:topLeftColor:bott omRightColor:

draws an "inset border" on all filled, bordered rectangles -- even if the border style isn't inset! Is this *really* what we want? Wouldn't it make more sense to try to reproduce the *actual* style of the border?

• When exporting a Morph as Postscript, we use an extension of '.eps' even

when not writing a valid EPS file (however, the file is much closer to a valid EPS file if you set the postscriptStoredAsEPS preference). Perhaps we should use a '.ps' extension when not writing an EPS.

• EPS files aren't supposed to do 'showpage', but we put one at the end of

the file. Should we?

And we go to some lengths to redefine showpage so it's bracketed with a gsave/ grestore. Why?

/_showpageSqueak /showpage load def /showpage { gsave _showpageSqueak grestore } bind def

you want to save the current graphics state before you work on the section of the page that you are describing so that you can set it back to the base settings with the grestore

• EPS files aren't supposed to mess with global drawing state settings.

However, we do this:

[ currenttransfer /exec cvx 1.2 /exp cvx ] cvx bind settransfer

again this only affects the current graphics state so that you'd have to put it in each .EPS file you'd want is to be effect for

which appears (to me) to be changing the gamma.

But what happens if you have several of these .EPS files in a single document? Won't the transfer function then be changed by each one of these?

And anyway, isn't the gamma *really* device-dependent? How would we know how much gamma correction to use if we don't know what devices they're viewing the original and the Postscript on? It's not like we can assume they're viewing the original on a Mac and printing on a LaserWriter, after all...

• We don't provide a preview image for the EPS, which makes it harder to

actually *use* the EPS files in something like a word processor.

the preview's usually just a bitmap image. lots of times there's no preview, though it does make them more interesting to use...

Has anyone done any work with the Postscript output recently?

Thanks, Ned