Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Chris Bowditch
Jeremias Maerki wrote:
snip/
So here are the proposed changes:
- Package org.apache.fop.render.awt becomes org.apache.fop.render.java2d
- AWTRenderer.java becomes Java2DRenderer.java (AWT*.java -
Java2D*.java)
I think the viewer subpackage can stay as is under the renamed package.
Any objections?
None from me.
Chris


Re: another nose for the grindstone

2005-02-22 Thread Renaud Richardet
Mark, just let me know when you'll start to work on it.
Clay, sorry for not making clear that i needed the maintenance code
for reference.
Jeremias, thanks for the pointer

i'm not sure about the following. please correct me if i'm wrong:

the (currently named) AWTRenderer allows 3 different kinds of output
1) GUI-application 
2) a java Image (containing all areas represented as Graphics2D's)
3) a printed document through AWTPrintRenderer, or is it 

the commandline options to start the differents output are
1) -awt
2) 
3) -print

i started to investigate the rendering system. the AbstractRenderer is
well designed and already implementing a lot of stuff, so that should
go allright for the AWTRenderer.

thanks, renaud

On Tue, 22 Feb 2005 07:48:28 +0100, Jeremias Maerki
[EMAIL PROTECTED] wrote:
 Clay,
 
 he knows that. I told him to use the maintenance branch code as a
 reference for bringing back the AWT Renderer in CVS HEAD. Renaud and I
 met last Friday at lots.ch.
 
 So, Renaud, please use the code found under the fop-0_20_2-maintain
 branch for reference. And happy hacking!
 
 On 22.02.2005 05:38:58 The Web Maestro wrote:
  On Feb 21, 2005, at 4:55 PM, Renaud Richardet wrote:
   bonjour fop-devs
 
  Salut! Bienvenue!
 
   i would like to work on the awt renderer. Mark (or someone else) , are
   you working on it?
   i checked out the code from FOP 0.20.5. is it the latest maintenance
   version?
  
   thanks, renaud
 
  Actually, the fop-0.20.5 code is merely for reference. All FOP
  development has moved away from the fop-0.20-5 branch
  (fop-0_20-maintain OR 'maintenance' branch) in favor of  the re-design
  branch (HEAD). This was done because the 'maintenance' branch had
  significant problems that were not easily resolvable. The re-design
  branch occurred because of problems in implementing the XSL0FO 1.0
  spec--specifically with the 'keeps' I believe.
 
  In any case, if you wish to contribute to FOP development, please check
  out the HEAD branch. You may look to fop-0.20.5 for reference, but any
  work you do on that branch will probably not be integrated into FOP
  1.0.
 
 Jeremias Maerki
 
 


-- 
renaud.richardet (at) gmail (dot) com
+41 78 675 9501
www.oslutions.com


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Christian Geisert
Jeremias Maerki schrieb:
Now that we've got someone who will work on the AWT Renderer I'd like to
know if someone is against renaming the AWT Renderer to Java2D Renderer.
[..]
Any objections?
Not at all.
Christian


Re: another nose for the grindstone

2005-02-22 Thread Jeremias Maerki

On 22.02.2005 12:43:56 Renaud Richardet wrote:
 Mark, just let me know when you'll start to work on it.
 Clay, sorry for not making clear that i needed the maintenance code
 for reference.
 Jeremias, thanks for the pointer
 
 i'm not sure about the following. please correct me if i'm wrong:
 
 the (currently named) AWTRenderer allows 3 different kinds of output
 1) GUI-application 

or only a single window or just a part of a window.

 2) a java Image (containing all areas represented as Graphics2D's)

Not sure what you mean. Oleg Tkachenko wrote an extension of the AWT
Renderer that paints the area tree to a single bitmap (per page) through
the Graphics2D interface. This is something I like to see integrated
directly into the render.java2d interface.

 3) a printed document through AWTPrintRenderer, or is it 

Right. That's where the Printable interface comes into play.

 the commandline options to start the differents output are

Don't make a 1:1 association between the capabilities of the command
line and all the possible use cases of the Java2D renderer.

 1) -awt

That displays the example preview window in the render.awt.viewer
package.

 2) 

With the bitmap output support added, this will be -jpg and -tiff and
-png etc.

 3) -print

That kicks the AWTPrintRenderer.

 i started to investigate the rendering system. the AbstractRenderer is
 well designed and already implementing a lot of stuff, so that should
 go allright for the AWTRenderer.

Yes, try to use as much as possible from the AbstractRenderer to avoid
duplicate code. If you see possibilities for consolidating functionality
between the PDF and Java2D renderer, then please tell us.

If I don't get any objections by tomorrow morning (CET) I'm going to
rename the AWTRenderer to Java2DRenderer so you can work on the real
thing.

Another thing: If you plan to regularly start to contribute to FOP or
simply to be on the safe side because you're not just going to
contribute a small bugfix only, it might be good if you sent a signed
ICLA (Individual Contributor License Agreement) to the secretary of the
ASF. See here for a text and PDF version of the ICLA:
http://www.apache.org/licenses/#clas
http://www.apache.org/licenses/icla.txt
http://www.apache.org/licenses/icla.pdf

That's not the same as commit rights or committership, but we might get
to that in time. :-)

Jeremias Maerki



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread The Web Maestro
On Feb 21, 2005, at 11:03 PM, Jeremias Maerki wrote:
So here are the proposed changes:
- Package org.apache.fop.render.awt becomes 
org.apache.fop.render.java2d
- AWTRenderer.java becomes Java2DRenderer.java (AWT*.java -
Java2D*.java)

I think the viewer subpackage can stay as is under the renamed package.
Any objections?
[1] http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec.html
Jeremias Maerki
None from me! The simple and more transparent, the better.
Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote:

 Now that we've got someone who will work on the AWT
 Renderer I'd like to
 know if someone is against renaming the AWT Renderer
 to Java2D Renderer.

AWT Renderer has a rich history within FOP, it's a
popular renderer, and I have not heard of any
complaints or confusion from the user community about
its naming.  Its output is that neat-looking AWT/Swing
window, so it's not that incorrect a name.  The
internal technology we use to generate said window is
IMO less important than what the user sees.


 The API in use is actually the Java2D API [1],
 although most of the
 classes had their origin within AWT (and are still
 in there). 

Mein Freund, even the Java2D library itself (from the
link you gave below) uses .awt. in their package
names and not .java2D..  Why should we use .java2D.
in our package names when even Java2D itself
doesn't/won't?

Also, using this logic, shouldn't we rename the
(future) TIFF Renderer--which Oleg says will descend
from AWTRenderer--and current SVG Renderers to
Java2DRenderer as well?  Don't they use Java2D as
well?

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.


 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.  


 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.


 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. 
Java2DRenderer sounds like an intermediate renderer
that can be output in several different ways, not just
an AWT window.


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

Note, of course, these aren't vetoes.

Regards,
Glen



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread The Web Maestro
On Feb 22, 2005, at 8:16 AM, Glen Mazza wrote:
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Now that we've got someone who will work on the AWT
Renderer I'd like to
know if someone is against renaming the AWT Renderer
to Java2D Renderer.
AWT Renderer has a rich history within FOP, it's a
popular renderer, and I have not heard of any
complaints or confusion from the user community about
its naming.  Its output is that neat-looking AWT/Swing
window, so it's not that incorrect a name.  The
internal technology we use to generate said window is
IMO less important than what the user sees.
Well stated, Glen. In the grand scheme of things, the name of the 2 
dimensional graphics renderer (?) doesn't matter much to me.

Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Jeremias Maerki

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



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
 A veto would have been easier. :-) I would simply
 have stopped and said:
 Sigh. Again. Ok, next task.
 

Yes, but the change proposed simply doesn't rise to
the level of a veto.

 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? 

Close.  How about this:  AWTRenderer is just for our
pop-up AWT/Swing window with the document in the
middle.  It will extend an (abstract?) Java2DRenderer,
and will not really be meant to be extended or
modified by other users.  

Java2DRenderer, OTOH, is what is used for others for
embedding into AWT/Swing applications.  AWTRenderer,
in addition to being our own native renderer, will be
an excellent example of how to extend Java2DRenderer
in the user's own programs.

Simplest use case:  someone wants Java2D output but
doesn't like our AWTRenderer.  Wants to add some
buttons, remove others from the window, do 400 other
things.  They will extend the Java2DRenderer to embed
this technology into their own work.  

By way of analogy:

AWTRenderer = Squiggle
Java2DRenderer = Whatever Batik does to allow other
users to create their own Squiggle apps.  (Sorry, I
don't know Batik! ;)

WDYT?

Glen



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Jeremias Maerki
Deal. It seems like we want the same things but didn't understand each
other. I hope we do now.

I've documented all this in a Wiki page:
http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D

You said that we name our renderer on the final output the user sees.
So I also added a print and bitmap package to the proposal for
illustration.

I hope that's also what you have in mind. I'm quite happy like this
although the individual packages will be relatively thin. On the other
side, the old AWTRenderer simply did too much in one class for my taste
and at the same time had the wrong name.

The new layout also doesn't require that I prepare the ground for Renaud.
Also, I hope this Wiki page helps him see the direction what we'd like
the thing to go.

Everybody happy?

On 22.02.2005 18:29:41 Glen Mazza wrote:
 WDYT?



Jeremias Maerki



AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Renaud Richardet
bonjour fop-dev's

i've been walking through the rendering process. if i understand it
rightly, an area doesn't records it's absolute position. therefore, we
have to pass the currentIPPosition, currentBPPosition all along during
the rendering process to figure out where to position an area.
what i don't understand: this information (the absolute position of an
area) MUST somehow have been known during the building of the area
tree (otherwise we could'nt know where to break the pages). so my
question: wouldn't it be easier to record the absolute position of an
area during the page-breaking process? or am i missing something?

renaud

PS: the abstract Java2DRenderer sounds like a really good deal to me :)


Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Jeremias Maerki
Salut Renaud

I wondered about that, too:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=984481

So far, I can only say that there's so mandatory reason for that change.
It would certainly make the renderers simpler but there might be
problems in other areas. The real downside is when you have to do the
same calculations in every renderer. Some can be (and already are) put
in AbstractRenderer but for others this is not so easily possible. No
definitive answer from me. We'll see what comes out of the page-break
rewrite.


On 22.02.2005 20:28:56 Renaud Richardet wrote:
 bonjour fop-dev's
 
 i've been walking through the rendering process. if i understand it
 rightly, an area doesn't records it's absolute position. therefore, we
 have to pass the currentIPPosition, currentBPPosition all along during
 the rendering process to figure out where to position an area.
 what i don't understand: this information (the absolute position of an
 area) MUST somehow have been known during the building of the area
 tree (otherwise we could'nt know where to break the pages). so my
 question: wouldn't it be easier to record the absolute position of an
 area during the page-breaking process? or am i missing something?
 
 renaud
 
 PS: the abstract Java2DRenderer sounds like a really good deal to me :)



Jeremias Maerki



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote:

 Deal. It seems like we want the same things but
 didn't understand each
 other. I hope we do now.
 
 I've documented all this in a Wiki page:
 http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
 

Looks good!  Now whether you wish to do this before or
after Renaud moves the logic over is up to you two. 
There's advantages/disadvantages to either method.

Thanks,
Glen



Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Renaud Richardet
hello Jeremias

merci for the informations. 

 I wondered about that, too:
 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=984481

interesting!

Victor, 
in [1] you talked about dealing with the positioning of areas during
the AreaTree building. could you point me to the classes in FOray that
handle that logic?
 
 So far, I can only say that there's so mandatory reason for that change.
 It would certainly make the renderers simpler but there might be
 problems in other areas. The real downside is when you have to do the
 same calculations in every renderer.
ok, that's what i was affraid of... but i understand that the area
tree building is already enough complex.
well, i'll base the Java2DRenderer on the pdf renderer. could someone
tell me if it's stable enough (especially those tricky issues like
reference-orientation and writing-mode  that i don't completely
understand yet).

 Some can be (and already are) put
 in AbstractRenderer but for others this is not so easily possible. No
 definitive answer from me. We'll see what comes out of the page-break
 rewrite.
ok, good luck. i'm looking forward to see your rewrite.

renaud

[1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=10534


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Renaud Richardet
Glen Mazza [EMAIL PROTECTED] wrote:
 Looks good!  Now whether you wish to do this before or
 after Renaud moves the logic over is up to you two.
 There's advantages/disadvantages to either method.
yes, that looks good! 

Jeremias, if it's ok for the team, i would apreciate if you would do
the changes asap.

thanks, Renaud


Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Jeremias Maerki

On 22.02.2005 22:35:15 Renaud Richardet wrote:
snip/
  So far, I can only say that there's so mandatory reason for that change.
  It would certainly make the renderers simpler but there might be
  problems in other areas. The real downside is when you have to do the
  same calculations in every renderer.
 ok, that's what i was affraid of... but i understand that the area
 tree building is already enough complex.
 well, i'll base the Java2DRenderer on the pdf renderer. could someone
 tell me if it's stable enough (especially those tricky issues like
 reference-orientation and writing-mode  that i don't completely
 understand yet).

Well, the PDF Renderer is our reference renderer and it's the only one
that is currently actively maintained. I'll get to the PostScript
renderer later.

Just concentrate on the simple things first. No need to worry about the
writing mode already. The reference orientation is simple. It's just a
matter of getting the transformations right. Run the simple test cases
from the layout engine test suite and work from simple to more
complicated.

snip/


Jeremias Maerki



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Jeremias Maerki
Given the new layout I don't even need to prepare anything. It would
only complicate things. Just rename the AWTRenderer to Java2DRenderer,
move it to the new location, then create an empty subclass of
Java2DRenderer called AWTRenderer and move any AWT-dependant code to
that subclass.

On 22.02.2005 22:43:01 Renaud Richardet wrote:
 Glen Mazza [EMAIL PROTECTED] wrote:
  Looks good!  Now whether you wish to do this before or
  after Renaud moves the logic over is up to you two.
  There's advantages/disadvantages to either method.
 yes, that looks good! 
 
 Jeremias, if it's ok for the team, i would apreciate if you would do
 the changes asap.
 
 thanks, Renaud



Jeremias Maerki



RE: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Victor Mote
Renaud Richardet wrote:

 Victor,
 in [1] you talked about dealing with the positioning of areas 
 during the AreaTree building. could you point me to the 
 classes in FOray that handle that logic?

...

 [1] 
 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
l.apache.orgmsgNo=10534

Hi Renaud:

The main classes where you can see this logic are Area, AreaFixed, and
AreaFlexible. However some of the methods are overridden in subclasses, esp.
LineArea, since it is the pivot concept between BPD-stacking and
IPD-stacking Areas. See especially the methods that start with br (border
rectangle), pr (padding rectangle), cr (content rectangle), and rr
(render rectangle, a concept invented for dealing with adjustments to the
content rectangle for things like justification). See also the methods
setProgressionDimension, incrementProgressionDimension, setAnteriorSpace,
and incrementAnteriorSpace where the sizes of the area and its resolved
before or start space is stored.

I have to give you a bunch of caveats. There is still a bunch of the old
stuff in those classes that I haven't gotten around to removing yet. The
location computation stuff works reasonable well ATM, but a lot of the
supporting code has serious problems, so you will get NPEs, etc. with even
simple documents. This is a work in progress.

Also, I haven't implemented only some of the necessary writing-mode and
reference-orientation changes. I am kind of torn ATM between nailing this
down solidly and trying to get a usable release done.

From a speed standpoint, FOray's approach may be sub-optimal. Each Area
computes its location relative to its parent's. The philosophy behind it is
that I want to store stuff only once, not so much to save memory, but more
to reduce confusion about the proper place to go for the data, and
(importantly) to get layout to the place where it doesn't know or care about
the location, orientation, or writing-mode of an area, only its size. At
some point, we may find that it is beneficial to cache the intermediate
computations for performance. It is not important to me ATM.

The ViewCVS of the classes mentioned is here:
http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-areatree/src/java/or
g/foray/area/

Victor Mote



Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Renaud Richardet
Victor,
thanks for your explanations. i'll give a look into FOray when i'll
feel more confident about the layout process.
cheers, Renaud


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
We can do it this way.  But on second thought, I think
it would be better for Renaud to move it in as
AWTRenderer, and slowly start factoring out more and
more while things are getting settled.  BTW, this will
take some time to do anyway--it isn't easy because the
renderers are so different between 0.20.5 and 1.0.

[A note for Renaud:  I would recommend cutting down on
the chatroom English and instead start writing
properly/respectfully to us, in the same manner that
all of us have been writing to you.  Capitalize I,
the first word of each sentence, your name, our
names[1], greetings, etc.  Above all, when people
write to you in standard polite English, you shouldn't
be responding back with chatroom writing.  None of us
here do.  Thanks!]

Glen

[1]
http://marc.theaimsgroup.com/?l=fop-devm=110625230922690w=2


--- Jeremias Maerki [EMAIL PROTECTED] wrote:

 Given the new layout I don't even need to prepare
 anything. It would
 only complicate things. Just rename the AWTRenderer
 to Java2DRenderer,
 move it to the new location, then create an empty
 subclass of
 Java2DRenderer called AWTRenderer and move any
 AWT-dependant code to
 that subclass.
 
 On 22.02.2005 22:43:01 Renaud Richardet wrote:
  Glen Mazza [EMAIL PROTECTED] wrote:
   Looks good!  Now whether you wish to do this
 before or
   after Renaud moves the logic over is up to you
 two.
   There's advantages/disadvantages to either
 method.
  yes, that looks good! 
  
  Jeremias, if it's ok for the team, i would
 apreciate if you would do
  the changes asap.
  
  thanks, Renaud
 
 
 
 Jeremias Maerki