DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41044>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41044


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From [EMAIL PROTECTED]  2007-06-29 11:19 -------

More info:
Reverting the change in the usage of the PropertyCache by PropertyList solves 
11 of the 70 errors I 
initially encountered. The others are related to the Common* property bundles 
that include properties 
that can be percentages (padding, margin...)

The idea is right, but the implementation is slightly in error. Most likely due 
to the inherent complexity 
of the properties package...(?)
Once you get it, it's really simple actually:
Every Property class has its own particular Maker that deals with converting an 
attribute value to the 
correct type of Property instance. FOPropertyMapping initializes a cache of 
those makers, one for each 
property defined in the XSL-FO Rec. (still limited to 1.0)
The PropertyList deals with the entire attribute list for a single FO. Given an 
Attributes instance, it 
extracts a few properties first --font-size, column-number-- because of 
possible dependencies in 
other properties --em-lengths, from-table-column(). All the others are looped 
over: fetch Maker and 
call Maker.make(), basically, which triggers the PropertyParser to parse the 
expression and return a 
generic Property instance, possibly a compound or a list of Property 
instances...

Thinking some more about the general approach, the pseudo-singleton pattern by 
itself is not enough 
here (private constructors and a getInstance()).
I'm thinking of also weaving some of it into the Maker-logic. Have the Makers 
bear the responsibility 
that no necessary duplicates are missing (as is the case for the LengthBase of 
"50%" for instance, after 
applying the patch)
Also, I'm going to set aside the idea about creating canonical Common* bundles 
FTM, apart from the 
quite common "no border, no padding, no background" scenario. The padding 
length-conditionals and 
BorderInfos are already difficult enough to handle. If the border, padding and 
background properties by 
themselves are guaranteed to be canonical, then a lot of the 'duplicate' 
bundles will be nothing but 
wrappers around a bunch of references to the very same BorderInfos, absolute 
padding-widths, etc. 
That's already bound to save a lot.

There seems to be an inherent error, not only WRT percentages, but more 
generally any relative value. If 
I get the drift of the patch correctly, it creates a canonical Property 
instance for the attribute:
width="2em"

Meaning: for a LengthProperty with an explicitly specified value of "2em"...? 
What if we then later on 
encounter that same attribute value on another, very likely unrelated node?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to