...(not a real specialist in this area but...)
On 26.12.2004 02:13:46 Peter B. West wrote: <snip/>
Did you find the reference to java.awt.graphicsenv in PJA?
What puzzles me is the circularity of requiring a BufferedImage, with its implicit dependency upon getLocalGraphicsEnvironment(), which seems to be the only way to directly discover a GraphicsEnvironment. It's as though there is no formal way to introduce your own GraphicsDevices, apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf through the reliance on BufferedImage.
Yes, I think there's no such thing, although I don't think it's necessary. The PDFGraphicsConfiguration and PDFGraphicsDevice is all that's necessary to support Graphics2D output to PDF. And PDFGraphics2D instantiates the PDFGraphicsConfiguration as necessary. If you want to replace the default GraphicsEnvironment you'd probably set the "java.awt.graphicsenv" system property accordingly. But that's most probably not something you will want to do as it has consequences on the whole AWT subsystem in normal operations.
What am I missing?
I don't know. What are you trying to do? Is this about changing font support for the PDFGraphics2D? Knowing that I might have some better ideas.
I'm just trying to understand what I'm doing when I fiddle with GEnv and GDev. When I first looked at using Java2D methods for all rendering, I concluded that the GraphicsEnvironment was "closed", because there seemed to be no independent pathway to the creation of a modified GraphicsEnvironment. That's why I was so excited when SVGGraphics2D was mentioned on fop-dev. Looking at the implementation, though, I see that the same problems exist. I don't know quite how to express my disquiet about this, but in PJA's terms, it amounts to the implicit dependency on the underlying native graphics rendering.
<q>
java.awt.Graphics methods such as drawLine (), fillOval (), drawString (),... are implemented in the default JVM with native graphical functions (except in some cases for Java2D) : That means that drawLine () finally calls a GDI system function on Windows or X11 function on a X11/UNIX machine even if the drawing is done in an off-screen image using the class java.awt.Image. This ensures the best performance for drawing graphics with Java.
</q>
Maybe it also helps to look at PJA (http://www.eteks.com/pja/en/) to get a better understanding of what is involved in the whole thing.
I just took a glance at PJA. I'll have a look at the 2D implementation code. PJA seems to have gone right back to the root of GraphicsEnvironment and built its own from scratch.
However,
<q>
Starting with release J2SETM 5.0, AWT has been re-implemented on the Solaris and Linux platforms. The new Toolkit implementation provides the following advantages:
* Removes the dependency on Motif and Xt libraries.
* Interoperates better with other GUI Toolkits.
* Provides better performance and quality.
</q>
I'll ask eTeks what the implications of this are for PJA.Peter
