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 JeremiasMaerki: http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign The comment on the change is: Proposal on border painting ------------------------------------------------------------------------------ * Currently, the IF is implemented over our area tree which contains a generic structure for traits. Maps present a certain amount over overhead by themselves which this approach avoids. Furthermore, the !AreaTreeParser has to inspect various trait sets per area tree object which causes too many Map operations. * The conversion from !ContentHandler to IFPainter only requires one lookup (see !AttributesImpl.getValue()) per parameter. The number of parameters is very small. Some parameters are complex Strings which need to be parsed themselves (for example startBox()'s transform parameter). The overhead here should be relatively low since these are not extremely frequent operations. setFont()'s parameters could be changed from String to an enumeration class which would cause a Map lookup, but again setFont() is not a very frequent operation and not every parameter will be set and therefore parsed on every call. + == Border Painting == + + For border painting at least two approaches are possible. Either, the IF is extended by commands to do complex clipping and path painting operations, or we abstract border painting to the same level as in the area tree. The former is problematic since it increases the size of the IF files (and therefore parsing time) and not all output formats have the same capabilities as PDF or PostScript (ex. PCL needs to use bitmaps to paint nicely looking borders). That leaves the latter approach. It probably makes sense to reuse the !BorderProps class to encapsulate the properties/traits of the individual borders of a box. So the proposed approach looks like this: + + {{{ + <border-rect x="1233" y="1200" width="20000" height="20000" + border-start="(solid,#800080,8000,collapse-inner)" + border-end="(solid,#ffff00,6000,collapse-outer)" + border-before="(solid,#808080,4000,collapse-outer)" + border-after="(solid,#000080,8000,collapse-outer)"/> + + void drawBorderRect(Rectangle rect, BorderProps start, BorderPropds end, BorderProps before, BorderProps after) throws IFException; + }}} + + As a consequence there won't be an way to combine multiple border segments easily to reduce output file size and painting artifacts (usually not a problem). If that is something desirable, it should probably be done in IFRenderer. But since at the moment there's not enough time to pursue that and we don't really have a problem, this is ignored for now. + + Text decoration painting which currently goes through the {{{drawBorderLine()}}} method in most renderers will have to be done differently, probably through {{{drawRect()}}}. + == Extensions == The new intermediate format will need to make extensive use of extensions, mostly output format specific extensions like media selection for PCL or PostScript, or overlay functionality in AFP. The extensions will be produced in a namespace outside the normal intermediate format namespace. Features that are only implemented/supported by a small subset of output formats, ex. bookmarks and named destinations, shall be implemented as an extension in order to avoid cluttering the intermediate format itself for minimal cases. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
