[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Odp: RE: [docbook-apps] Re: [docbook] Indexterms - see and seealso linked to another indexterm
I've tried Bob's solution and it worked. As I don't use "sortas", I just ignored it for now. For FO/PDF, I've come up with something like this:
<xsl:template match="d:indexterm" mode="index-primary">
..<xsl:variable name="id" select="concat('ientry-', generate-id())"/>
<xsl:if test="$axf.extensions != 0">
Then, for mode="index-see"
<xsl:template match="d:indexterm" mode="index-see">
<xsl:param name="scope" select="."/>
<xsl:param name="role" select="''"/>
<xsl:param name="type" select="''"/>
<xsl:variable name="see" select="normalize-space(d:see)"/>
<xsl:variable name="target" select="key('primary', $see)"/>
<xsl:value-of select="concat('ientry-', generate-id($target))"/>
<xsl:with-param name="key" select="'see'"/>
And the same for mode="see-also". I don't know if it's absolutely correct, but it seems to be working.
Jan, I've looked at your solution as well, but got a little bit lost. As I'm new to XSLT, I have some problems with following the code. Is the difference mainly in a way IDs are generated or somewhere else?
As the next step,I'm thinking about the way to extend the solution also for secondary entries. I guess that for the <see> element it might not make that much sense to link a primary entry to a secondary one - and not the other way round - but for <seealso> it seems sensible. What do you think?
It's a bit more tricky, of course, as there might be more than one secondary entries for a given phrase, for which the primary entries might be different, e.g.:
So, one needs to search only for secondary entries with a given primary entry. I'm trying to work this out. I may let you know, if I get anywhere.
Thanks once again,
On 2013-10-09 honyk <firstname.lastname@example.org> wrote:
On 2013-10-08 Bob Stayton wrote:
> The basic problem is that the entries in the index are generated from
> indexterm elements that reside in the document. You cannot directly use
> the id of an indexterm, because that is used to link back into the
> So an index entry needs to generate its own unique id. Then the
> stylesheet needs to match the text from the <see> to the first
> element that matches (there may be many).
I am attaching my customization I use for some time (for FO/PDF). It
generates required IDs  and corresponding links to them.
I use it rather on simple indexes so it may not work in more complex ones.
 IDs are composed from normalized primary/secondary entries (spaces are
translated into dashes). Bob's approach to use the generate-id() function
seems to be better here.