Jeremias Maerki wrote:

> PDF Reference Fourth Edition Version 1.5:
> Chapter 4.7.1, page 296:
> "Note: Since PDF 1.4 encompasses all of the Adobe imaging 
> model features of the PostScript language, there is no longer 
> any reason to use PostScript XObjects. This feature is likely 
> to be removed from PDF in a future version."
> Apparently it already is in reality, because Acrobat Reader 
> 6.0.2 no longer passes EPS images to a PostScript printer, 
> while Acrobat Reader 5.x does. 

OK, I see what you mean, and I am intimately familiar with the citation.
Embedding EPS as an XObject is deprecated. However, using EPS as input for a
PDF document would not be deprecated by the above statement. Instead they
are suggesting that because there is a one-to-one relationship between the
capabilities, that any PostScript code (EPS or otherwise) should be
converted to the PDF equivalent. So, EPS input is not deprecated per se,
just embedding it as an XObject.

> > Reason: I am in the middle of writing a very rudimentary PS 
> > Interpreter for FOray, for purposes of "properly" parsing 
> the contents of Type1 font files.
> > There are easier ways to accomplish the immediate purpose, but one 
> > reason I went to this level of trouble is that I *think* it 
> may help 
> > us in embedding EPS files in PDF. If EPS graphics are being 
> deprecated 
> > within the PDF standard itself, that is of great interest.
> Interesting. You probably know from my various comments on 
> this list that I'm longing for such a beast under BSD-style 
> license. Having an interpreter is one thing, but making it 
> paint EPS files to a Graphics2D will be another challenge 
> altogether. But even if it only supported some basic Level 1 
> elements this would already be extremely helpful.

This is *very* much in a state of flux right now (I just started the
interpreter 2 days ago), but here is the plan: I have a PSSystemDict class
right now that houses the various PostScript operators (I have 4 of about
500 working ATM). I *think* that it ought be possible to make a subclass
that hijacks (overrides) the native meaning of the operators to transform
them into PDF operators instead. We'll see how it goes. You are right that
it is non-trivial.

By Graphics2D, do you mean java.awt.Graphics2D? I don't really intend to
build anything that will be using that directly, although subclasses could
do that if it were useful. (Also, I suppose that it might be useful as a
common intermediate format, but I haven't thought that far ahead). IOW, I
guess I am building something pretty abstract, not intended to actually
drive any hardware. (It is abstract in the PostScript sense, but not the
java sense). So a subclass would need to handle Path Construction and
Painting Operators and similar items. So, for example, the PostScript
operator curveto pops 6 items off of the stack and appends a Bézier cubic
section. My interpreter (I guess its really an emulator) will only pop the 6
items off of the stack (i.e. it merely pretends to do the actual drawing).
But one subclass could use java.awt tools to draw something on the screen,
and another subclass could write a PDF "c" operator instead (I think -- they
look similar at first glance anyway). I think that should be a pretty good
way to proceed, but am interested in any comments.

Victor Mote

Reply via email to