https://issues.apache.org/bugzilla/show_bug.cgi?id=46705





--- Comment #8 from Andreas L. Delmelle <adelme...@apache.org>  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.

Reply via email to