(not a real specialist in this area but...)

On 26.12.2004 02:13:46 Peter B. West wrote:
<snip/>
> All of which seems redundant, given that we can get to a Graphics2d 
> directly from a BufferedImage.  I assume, though, that this is the way 
> to introduce a "foreign" GraphicsEnvironment, e.g., 
> PDFGraphicsEnvironment.  Is this a fair assessment?

<fx type="serious-head-scratching"/>

IMO for BufferedImage you don't need any foreign GraphicsEnvironment.
I wouldn't care what GraphicsEnvironment class is used for a
BufferedImage.

> 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.

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.


Jeremias Maerki

Reply via email to