On 22.02.2005 17:16:56 Glen Mazza wrote:
<snip/>
> Now, if you want to create a Java2DRenderer as a
> abstract base class for Renderers utilizing
> it--AWTRenderer, AWTPrintRenderer, SVGRenderer,
> TIFFRenderer, etc., that would appear to make a lot
> more sense.  Consider that before you tie
> "Java2DRenderer" specifically with our AWTRenderer.

Actually, that was what I had in mind but obviously haven't explained
well enough.

> 
> > AWT is
> > actually the windowing toolkit which is something
> > that's not used inside
> > the renderer. 
> 
> True, but PDF is not used within the PDF Renderer. 
> Text codes "/0 /0 /a /c" etc. etc. are instead.  To a
> degree, using this logic here would then call for us
> renaming PDF Renderer to BinaryOutputCodesRenderer.  

Huh? Lots of dependencies on the PDF package in the PDF renderer.

> 
> > Only when the Java2D renderer is
> > embedded inside a GUI
> > application AWT (or rather Swing or SWT) are coming
> > into use. 
> 
> Yes, so far we have been naming our renderers on the
> final output that the user sees (here, an AWT/Swing
> window), not the internal technology used in
> generating that output.

Not only an AWT/Swing window. We're also printing, creating bitmap
images and we can (via JPS) create PDF and PS files. That's why AWT
doesn't really fit what it does.

> > And the
> > preview window actually uses Swing, not AWT.
> > 
> 
> But Swing sits on top of AWT, no?  Also, I suspect
> there are AWT-specific packages within the AWTRenderer
> anyway (such as the EventHandlers and EventListeners
> like java.awt.event.ActionEvent).  AWTRenderer appears
> more accurate overall then SwingRenderer, and has the
> added benefit of not sounding as silly.  ;)

:-)


> > So here are the proposed changes:
> > 
> > - Package org.apache.fop.render.awt becomes
> > org.apache.fop.render.java2d
> >
> 
> -0.5, because java2d itself uses "awt" in its package
> name, and we use (or will use) java2d for more than
> the AWTRenderer.  It's more consistent as-is.
> 
> Also, "AWTRenderer" gives the user a better mental
> model of what the output of this type is -- and
> AWT/Swing Window with a document in the middle. 

That's only one use case.

> "Java2DRenderer" sounds like an intermediate renderer
> that can be output in several different ways, not just
> an AWT window.

EXACTLY!!!! That's exactly what is my intention with this proposal.

> > - AWTRenderer.java becomes Java2DRenderer.java
> > (AWT*.java ->
> > Java2D*.java)
> > 
> 
> -0.5, because, again, other renderers use or may use
> Java2D.  And we can't all be renaming our renderers
> BinaryOutputCodesRenderer.java and
> Java2DRenderer.java.

I don't buy that.

> Note, of course, these aren't vetoes.

A veto would have been easier. :-) I would simply have stopped and said:
"Sigh. Again. Ok, next task."

Would it be more interesting/agreeable if we would leave the render.awt
package and create an AWTRenderer that is optimized for embedding into
AWT/Swing applications? The AWTRenderer would subclass the
Java2DRenderer in the render.java2d package. Improving embeddability of
the AWTRenderer was something I also had in mind. We've had several
instances where people had trouble embedding the AWTRenderer in their
application or simply use the preview form.


Jeremias Maerki

Reply via email to