--- Finn Bock <[EMAIL PROTECTED]> wrote:
> The patch does not unnest the Property.Maker class.
> It doesn't matter 
> all that much to me, but if it is considered a good
> idea it is easy to do.

Ooops...I think I had misread the code there. 
Actually, hold off on this then.

> Should the values of the constants still be globally
> unique, or just 
> unique within each inner-interface? I would say
> globally unique since it 
> would be easier to add a int->string method
> somewhere for debugging.

Absolutely--still globally unique, and I have no
intention of changing the interfaces' internal value
definitions--they will still be equal to
Constants.this and Constants.that.  If the interfaces
still prove later to not be that helpful, we can get
rid of them and just switch to the same-named

I look into doing making the changes on this issue

> I think you have mentioned this a couple of times
> before, but I didn't 
> understand it back then either. Perhaps I just
> doesn't understand what 
> part of our code you consider Renderer and Area
> Tree. Because I can't 
> find any references to properties or propertyList in
> the area package or 
> in the pdf and ps renderer.

Maybe nothing in fo.Area needs conversion; very little
with the renderers (except RTFRenderer, because it
doesn't use an area tree.  I remember needing to
convert a few of the properties there from
Strings->ints.)  I thought we had made some property
requests in PDFRenderer and AWTRenderer, but I may be
wrong there.  But this is a minor issue, after we
tackle this patch.


Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

Reply via email to