Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by AndreasDelmelle: http://wiki.apache.org/xmlgraphics-fop/PropertyHandling/PropertyCache The comment on the change is: To be continued... New page: = PropertyCache = == Introduction == As FOP processes the input it receives from the {{{javax.xml.transform.Transformer}}}, each {{{startElement()}}} event it receives comes with a parameter attribute-list. Those XML attributes are converted into FO properties, passing through a {{{PropertyList}}}, and subsequently bound to the generated {{{FObj}}} as member variables (see also: PropertyHandling). Even though the {{{StaticPropertyList}}}, a Java object having two backing arrays whose length is equal to the total number of properties (= roughly two times {{{Property[250]}}}), only has a life-span between {{{startElement()}}} and {{{endElement()}}}, the total number of {{{FObj}}} instances generated by a document with significantly large {{{fo:table}}}s will be very high. Those objects and their members will basically all remain referenced until FOP's {{{AreaTreeHandler}}} receives an {{{endPageSequence()}}} event. As a very rough example, for layout of an {{{fo:table}}} with 15 explicit {{{fo:table-column}}}s, and 4000 explicit {{{fo:table-row}}}s FOP instantiates: * 1 {{{Table}}} * 15 {{{TableColumn}}}s * 1 {{{TableBody}}} * 4.000 {{{TableRow}}}s * 60.000 {{{TableCell}}}s * 60.000 {{{Block}}}s (a table-cell cannot be empty, when specified) So, 124.017 objects will live in the Java heap, until the table is fully rendered, and this still excludes any further content or any layout-related classes. Before the introduction of the {{{PropertyCache}}}, if the author were to specify an explicit font-size of "10pt" on all the {{{fo:table-cell}}}s, this would lead to an equal amount of distinct {{{FixedLength}}} instances. This could be avoided by making use of property inheritance: specify the property on the ancestor {{{fo:table}}}, and through inheritance, only one {{{FixedLength}}} instance was needed for the entire table, as the same instance would be picked up by the {{{PropertyList}}}s responsible for resolving the cells' properties. Ultimately, this could be brought down to one instance for the whole document, by specifying the global font-size on the {{{fo:root}}}. Note: a fact overlooked by many is that, according to the XSL-FO Recommendation, '''any''' property may be specified on '''any''' formatting object. The fact that the font-size property does not apply to {{{fo:root}}} still does not mean that the property will be entirely lost. Due to regular inheritance, '''all''' {{{PropertyList}}}s will ultimately use the value of the root {{{PropertyList}}} unless an override is provided on a deeper level. Still, sometimes this type of streamlining of the stylesheet is not always possible. In contexts where the stylesheet is generated by a third-party tool, there are likely to be many XML attribute specifications that, from the point of view of the formatter would be redundant. On another note, there are also many {{{<enum>}}} properties that share the same possible values, but are not inherited. The initial idea for further optimization in that are was given to FOP by Richard Wheeldon in a Bugzilla patch (see: https://issues.apache.org/bugzilla/show_bug.cgi?id=41044). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
