forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: plugin: output.pdf: <a> not resolved in helper-commonElements.xsl, bug or feature?
Date Thu, 26 Feb 2009 21:31:11 GMT
2009/2/26 EMMEL Thomas <>:
> Ross Gardler schrieb:
> 2009/2/26 EMMEL Thomas <>:
>> Hi,
>> there is a line in
>> plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/helper-commonElements.xsl
>> which I changed locally for me:
>> @@ -368,7 +368,7 @@
>>       <xsl:apply-templates/>
>>     </fo:block>
>>   </xsl:template>
>> -  <xsl:template match="link|fork|jump">
>> +  <xsl:template match="link|fork|jump|a">
>>     <xsl:variable name="color"
>>       select="$config/colors/color[@name = 'body']/@link"/>
>>     <xsl:choose>
>> Is it a bug or feature that <a></a> is not supported here?
>> If I add it, the links will be activated, however they might be not useful
>> in all cases yet when generating the wholesite.pdf, where
>> external links need to be changed to internal links...
> In theory it is "feature".
> Internally Forrest does not have the <a> element. Under what
> circumstances do you find a document containing an <a> gets processed
> by this stylesheet?


> Confusion !!!!
> <a> is the first element documented in the document-v20.dtd and is therefore
> very valid element in forrest I think.
> I use it everywhere I need a link since <link> and <fork> and <jump>
are not
> in the DTD...
> Do I miss something?????

Forrest does not use the V2 DTD *internally*, it uses the V1.3 DTD [1].

This is because of history rather than design. Ultimately the
intention is to move to a sbset of XHTML2 on the internals. XDoc V2 is
pretty much this subset already (give or take a few bits and pieces).
However, this has been the plan for a very long time and doesn't look
like being implemented any time soon - it's a major rewrite of both
input and output stylesheets.

It is likely that there is no harm in adding the match that you
identify. However, until we understand the circumstances in which you
are managing to get that element to the output plugin it is hard to
say. I'm worried that you might be doing something that bypasses the
internal processing (which is bad) or that we have a "hole" in one of
the internal processes.

Such a hole would not show up when converting to HTML as the <a>
element is legal there and would be passed through unmodified by the
internal processing. However, given that Forrest is in use in a great
many places and this hasn't raised it's head before I want to  check
everything is in order. To that end we need an answer to my earlier
question "Under what circumstances do you find a document containing
an <a> gets processed  by this stylesheet?"



Ross Gardler

OSS Watch - awareness and understanding of open source software
development and use in education

View raw message