OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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

Thanks guys,


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:attribute name="id">
        <xsl:value-of select="$id"/>
      <xsl:if test="$axf.extensions != 0">
        <xsl:attribute name="axf:suppress-duplicate-page-number">true</xsl:attribute>




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)[1]"/>
    <xsl:variable name="href">
      <xsl:if test="$target">
        <xsl:value-of select="concat('ientry-', generate-id($target))"/>

      <xsl:text> (</xsl:text>
      <xsl:call-template name="gentext">
        <xsl:with-param name="key" select="'see'"/>
      <xsl:text> </xsl:text>
        <xsl:when test="$target">
            <xsl:attribute name="internal-destination">
              <xsl:value-of select="$href"/>
            <xsl:value-of select="d:see"/>
          <xsl:value-of select="d: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 <j.tosovsky@email.cz> 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

> text.

> 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

> <primary>

> element that matches (there may be many).


I am attaching my customization I use for some time (for FO/PDF). It

generates required IDs [1] and corresponding links to them.


I use it rather on simple indexes so it may not work in more complex ones.


HTH, Jan



[1] 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]