Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
On 28.12.2004 02:26:51 Peter B. West wrote: snip/ Did you find the reference to java.awt.graphicsenv in PJA? Just downloaded PJA. There's no reference in PJA other than in the javadocs for PJABufferedImage and PJAGraphicsEnvironment. Seems like the developer has to make sure that the system property is set (as could be expected). It's interesting to note that PJA subclasses SunGraphicsEnvironment and not GraphicsEnvironment. Like this they are dependent on Sun-private classes. 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 I can see nothing disturbing in here. I still think there's no need to replace the default GraphicsEnvironment because you would have to start doing the same thing PJA has to do to support BufferedImage etc. 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. Except that they built upon Sun-private classes. 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. Jeremias Maerki
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Jeremias Maerki wrote: On 28.12.2004 02:26:51 Peter B. West wrote: snip/ Did you find the reference to java.awt.graphicsenv in PJA? Just downloaded PJA. There's no reference in PJA other than in the javadocs for PJABufferedImage and PJAGraphicsEnvironment. Seems like the developer has to make sure that the system property is set (as could be expected). It's interesting to note that PJA subclasses SunGraphicsEnvironment and not GraphicsEnvironment. Like this they are dependent on Sun-private classes. So I saw. It's only for PJAGraphicsEnvironment. Where do the Sun-private classes come from? Where else have you seen a reference to java.awt.graphicsenv? Peter
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
On 28.12.2004 11:54:10 Peter B. West wrote: Jeremias Maerki wrote: On 28.12.2004 02:26:51 Peter B. West wrote: snip/ Did you find the reference to java.awt.graphicsenv in PJA? Just downloaded PJA. There's no reference in PJA other than in the javadocs for PJABufferedImage and PJAGraphicsEnvironment. Seems like the developer has to make sure that the system property is set (as could be expected). It's interesting to note that PJA subclasses SunGraphicsEnvironment and not GraphicsEnvironment. Like this they are dependent on Sun-private classes. So I saw. It's only for PJAGraphicsEnvironment. Where do the Sun-private classes come from? From the JDK/JRE (rt.jar). Where else have you seen a reference to java.awt.graphicsenv? Nowhere else in PJA. Jeremias Maerki
Tweaking the FO class hierarchy
I'm currently playing around with external-graphic and instream-foreign-object as you may have seen. It's my attempt to dive into the whole layout engine thing. I realize that there are a lot of similarities (and redundancy) between the two classes (and even their LM counterparts). I wonder if I should create a common (abstract) base class for the two. Is there anything that speaks against that other than it may be appropriate to check for additional refactoring possibilities? I'm not planning on reworking the whole thing, just to improve what I stumble upon. Jeremias Maerki
Re: Tweaking the FO class hierarchy
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I'm currently playing around with external-graphic and instream-foreign-object as you may have seen. It's my attempt to dive into the whole layout engine thing. Yes, I was very surprised and happy to see you working in layout! I realize that there are a lot of similarities (and redundancy) between the two classes (and even their LM counterparts). I wonder if I should create a common (abstract) base class for the two. They are similar enough that that would be an acceptable design. We already do the same with fo:static-content and fo:flow (more or less suggested by the spec, which IIRC declares them both flows), and the region classes. Is there anything that speaks against that other than it may be appropriate to check for additional refactoring possibilities? Yes, be careful that the decision is not just based on coincidentally common functionality. They should be closely similar objects. (Also too many classes, even if reduced LOC in each as a result, can make FOP seem larger and more complex than it actually is, which can intimidate newbies.) For a silly example, if both class Teacher and class AlpsMountain happen to have a getLocation() method, it wouldn't necessarily follow that we should have an abstract TeacherOrAlpsMountain base class. OTOH, class Teacher, class Policeman should probably extend a common abstract class Worker. The recommendation does not declare any relationship between instream-foreign-object and external-graphic, other than that they are both formatting objects. This two-tier hierarchy is already present in FOP, as we have them both extend FObj. But, again, they are close enough that an abstract base class may not be such a bad idea. Glen
