[PATCH] AWT renderer

[Wouter Lagerweij <W....@acriter.com>]

Hi,

Before I get to the rest of this message, I'd like to apologise for the
fact that the patch is really just a replacement of the previous
versions of the files. The files in CVS all have DOS style
new-line/carriage returns at the end of each line, so a diff on our
system is not all that usefull.

Our guys working on printing (Johan and Herman) have been looking at the
AWTRenderer, and have come up with the following to fit it better with
what we want to do, which should also make it easier to use in other
scenario's.

Stephan Albers wrote:
> 
> Wouter Lagerweij schrieb:
> 
> > In using the viewer package, we wanted to use a new preview dialog
> > (one that doesn't do a System.exit(0) when finished, for instance:-).
> 
> Removing System.exit(0) is a good idea, but creating a new Dialog seems
> to be a bad idea.
> 
> Instead of creating a new class that implements similar features, why
> not
> extend the existing class, include more features, make it more
> configurable,
> subclass...?
> 
> What exactly is missing or should be improved?
> 
> Stephan

Well what we wanted to do is create our own previewer around the
rendered
page. The previewer we want uses a different command structure and
menustructure so we keep all views of our application identical.
Basically 
this means we want to be able to embed a rendered page in our own view. 

The architecture of the Previewer as it is now is a bit rigid, Suppose
we
used what's currently available and create a new DocumentPanel that can
be 
rendered upon, so we could embed a DocumentPanel in our view. 
The documentPanel though has a constructor that wants to have a specific
implementation of type PreviewDialog. Since we have our own
PreviewDialog
our first attempt was to make PreviewDialog an interface and have our
view 
implement that interface. This work fine but requires a gui-component 
(DocumentPanel) to be available in the renderer and rendering can be
done only
onscreen this way. 

Basically it was not possible to render without a DocumentPanel, which
cannot
exist without it's containing view.

Most of the collaboration (see collaboration.before.gif) was involved
with passing
the awtviewer and the documentpanel to the driver and the renderer to be
able
have something to render upon. And also with passing the renderer to the 
PreviewDialog and documentPanel so the documentPanel can call the
renderer 
to render another page. Giving some dependencies that are not absolutely 
necessary and conflicted with our goal.

The changes we made(see collaboration.after.gif) are that there are no
dependencies anymore between the documentPanel and the renderer. The 
documentPanel used to provide a graphics object for the renderer to draw
on. 
Now, the renderer has an internal image object on which it can draw the
page. 
Upon request, this image can be retrieved from the renderer to be
displayed.

Also, the AreaTree is now only needed in the renderer. We've added a 3rd
render function to the renderer which only requires a pagenumber as an
argument. The AreaTree object always gets passed to the renderer by the
Driver object. 

There are more benefits of using this architecture. For example it's now 
possible to render off-screen without a gui component. You can for
example
render a BufferedImage and display it on a webpage or in an applet.

Instead of rendering when a paintComponent event is fired, rendering 
of the image is now only triggered by a specific render method call. 
This solves the repeatedly rendering of the documentPanel when scrolling
in the old version, which makes scrolling a lot faster. 


Some additional notes about the collaborations:

Both collaborations are drawn from the viewpoint of AWTCommandline.
Only the collaborations that changed or show dependencies between
classes
are shown. Internal processes of the classes are not shown, they have
not 
been changed.

collaboration.before.gif:

1. the awtCommandLine creates the AWTRenderer
2. the awtRenderer is passed to the previewer.
3. the awtRenderer is passed to the documentPanel.
4. the awtCommandLine creates a driver.
5. the awtRenderer is passed to the driver.
6-8 the driver is asked to parse, format and render.
9  the driver passes the resulting areaTree to 
   the renderer, with a null PrintWriter.
10 the renderer sets the AreaTree in the documentPanel.
11-13 the renderer updates the size, pagenumber and pagecount
   of the documentPanel.
14 the paintComponent event is triggered, here we get a graphics
   component upon which the renderer will paint.
15 pass the graphics component we got from the triggered 
   paintComponent to the renderer, the renderer repaints the document..


collaboration.after.gif:
1. the awtCommandLine creates the driver.
2. the awtCommandLine creates the renderer.
3. the awtCommandLine passes the renderer to the driver.
4-6 the driver is asked to parse, format and render.
7 the driver calls the renderer to render with the parsed and formatted
  areaTree.
8. the renderer renders on its internal image a new first page. 
9 the awtCommandLine asks the renderer to get it's lastRendered page.
10.. (not on image) the awtCommandLine asks the renderer to
renderPage(x).


regards, 
the Acriter Printing Team

PS:
  we think the AWTRenderer is by far the best way of doing printing
  in 100% java at this moment.


-- 
Wouter Lagerweij
wlagerweij@acriter.com
Acriter Software
The Netherlands