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.
