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
