https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #8 from Andreas L. Delmelle <[email protected]> 2009-02-17 12:51:03 PST --- Interesting stuff! I've also read some of the Wiki, and one thought that popped in my head: Do we really need the extension 'ptr'? Could this be simplified by using the standard 'id' property perhaps? IIUC, I definitely think so, but that would mean introducing: a) auto-generated and assigned initial value for the 'id' property (mandated by the Rec, BTW: "the initial value ... is a random and unique identifier..." --XSL-FO 7.30.8 "id") b) a way for the FONodes to echo themselves back into SAX events, so they can be sent through reduceFOTree.xsl (maybe that reduction could even be hardcoded into FOP) a) would be relatively easy to implement. I've already been playing with that in the past. It may have a noticeable impact on performance for large documents, if we're not careful, since the set of ids to check becomes entirely dependent on the number of FO nodes, whereas currently, that set is limited to the ids that have been specified. b) would require more effort. Something we have never needed so far, but may be a worthwhile addition, if you think about it. The emitted FO will not correspond exactly (1-1) with the source, since shorthands will be expanded, relative specs may have been resolved and such, but still... That said, maybe to emulate that effect with the current proposal of a pre-processing stylesheet (minimal effort), we could already do something like: [in addPtr.xsl -> addId.xsl] <xsl:template name="addId"> <xsl:element name="{name()}" namespace="{namespace-uri()}"> <xsl:apply-templates select="@*"/> <xsl:if test="not(@id)"> <xsl:attribute name="id"> <xsl:value-of select="generate-id()" /> </xsl:attribute> <xsl:apply-templates /> </xsl:element> </xsl:template> May have unwanted side-effects only in case the author happens to have an explicit id that is identical to the value returned by generate-id() (but that's a bit of a stretch ;-)) [in reduceFOTree.xsl] <xsl:template match="*"> <xsl:element name="{name()}"> <xsl:copy-of select="@id" /> </xsl:element> </xsl:template> If that could make it even simpler (one less extension attribute necessary), I'm all for it... I'm not sure I'm comfortable with introducing a native extension, scattered in so many classes, while we already have the standard 'id' property conveniently available in FObj, which seems to serve the purpose nicely. Another small detail: why exactly do we need the explicit value of the xml:lang shorthand in Block.java? IIC, Block should already have the implied language and country available (via getCommonHyphenation()). Just asking, since if you look closely, you will notice that none of the shorthands are stored on the FObjs (only the expanded, native FO properties), so making this exception should have a good reason. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
