Are we sure it should return 0? Shouldn't there be a difference between "no value" given, and a value of "0" given, esp. in cases when you need to calculate inheritance? I think so...
I think we moved from int-->Integer for properties just recently (Victor did, I believe, in prodding from Peter Herweg?) because we precisely need NULLs to be returned sometime. (0 won't always be correct.) OTOH, if you notice in the Area.RegionViewport class I recently put some helper classes in such as getPaddingAndSpacingBefore(), for finding the values of *specific* properties, where we can make such "return a 0 if it's NULL"-type determinations. These helper functions (1) simplify the renderer code (esp. as the business logic would otherwise be duplicated in each renderer class), (2) allows code sharing between the renderers and layout (which also sometimes needs to calculate these values), and (3) provides a central point to store property-specific business logic (e.g., how do we handle a NULL for this *specific* property system-wide? Raise exception or a warning, return 0, return 2 as the default?, etc., etc.) This may be a more accurate route for us--note for memory concerns, though, I just provided methods in the RegionViewport to calculate the values, and did not duplicate the values themselves in RegionViewport. Glen --- Chris Bowditch <[EMAIL PROTECTED]> wrote: > Fop Devs, > > one thing I did notice was a small deficiency in > Area.getTraitAsInteger(). > If the Trait hasnt been set, i.e. the call to > getTrait returns null, then an > exception gets thrown. When Padding is present it is > perfectly valid as an > Integer, so the method should NOT throw an exception > saying it isnt an > integer, when in fact it just isnt present (for that > block) Instead it > should return 0. I have submitted a patch for this. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24705 > > Chris > __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
