Yes, I mean java.awt.Graphics2D because if you have that you can generate PDF (using the PDF transcoder) and SVG (using Batik's SVGGraphics2D) from it already and you can even use it with the AWT renderer (which I prefer to call Java2D renderer). Obviously, this is not important for PS output since you can simply embed the EPS in the PS output stream.
You may remember Peter B. West (if I'm not wrong) calling for a Java2D-only rendering approach in FOP. Here you have similar considerations to make. It may not be an ideal approach in any circumstance but if you want to get quick results, going for Graphics2D first is THE choice. Well, you've just loaded me with another exciting thing to watch. I've already got too many of them. Damn. Can we vote on making a day last 26h instead of 24? On 23.09.2004 19:40:15 Victor Mote wrote: > 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. Jeremias Maerki
