<refentry xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:src="http://nwalsh.com/xmlns/litprog/fragment" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="5.0" xml:id="index.links.to.section"> <refmeta> <refentrytitle>index.links.to.section</refentrytitle> <refmiscinfo class="other" otherclass="datatype">boolean</refmiscinfo> </refmeta> <refnamediv> <refname>index.links.to.section</refname> <refpurpose>HTML index entries link to container section title</refpurpose> </refnamediv> <refsynopsisdiv> <src:fragment xml:id="index.links.to.section.frag"> <xsl:param name="index.links.to.section" select="1"/> </src:fragment> </refsynopsisdiv> <refsection><info><title>Description</title></info> <para>If zero, then an index entry in an index links directly to the location of the generated <tag>anchor</tag> that is output for the indexterm. If two identical indexterm elements exist in the same section, then both entries appear in the index with the same title but link to different locations.</para> <para>If non-zero, then an index entry in an index links to the section title containing the <tag>indexterm</tag>, rather than directly to the <tag>anchor</tag> output for the indexterm. Duplicate indexterm entries in the same section are dropped. </para> <para>The default value is 1, so index entries link to section titles by default.</para> <para>In both cases, the link text in an index entry is the title of the section containing the indexterm. That is because HTML does not have numbered pages. It also provides the reader with context information for each link.</para> <para>This parameter lets you choose which style of index linking you want. </para> <itemizedlist> <listitem> <para>When set to 0, an index entry takes you to the precise location of its corresponding indexterm. However, if you have a lot of duplicate entries in sections, then you have a lot of duplicate titles in the index, which makes it more cluttered. The reader may not recognize why duplicate titles appear until they follow the links. Also, the links may land the reader in the middle of a section where the section title is not visible, which may also be confusing to the reader.</para> </listitem> <listitem> <para>When set to 1, an index entry link is less precise, but duplicate titles in the index entries are eliminated. Landing on the section title location may confirm the reader's expectation that a link that shows a section title will take them to that section title, not a location within the section. </para> </listitem> </itemizedlist> </refsection> </refentry>
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 13895 | Paul Allen | Copying using p4convert-docbook | ||
//guest/perforce_software/doc_build/main/docbook-xsl-ns-1.78.1/params/index.links.to.section.xml | |||||
#1 | 12728 | eedwards |
Upgrade ANT doc build infrastructure to assemble PDFs: - remove non-namespaced DocBook source and add namespaced DocBook source. - add Apache FOP 1.1 - copy fonts, images, XSL into _build, establishing new asset structure. The original structure remains until all guides using it can be upgraded, and several other issues can be resolved. - updated build.xml to allow for per-target build properties. - upgraded the P4SAG to use the new infrastructure. - tweaked admonition presentation in PDFs to remove admonition graphics, and resemble closely the presentation used in the new HTML layout, including the same colors. With these changes, building PDFs involves using a shell, navigating into the guide's directory (just P4SAG for now), and executing "ant pdf". Issues still to be resolved: - PDF generation encounters several warnings about missing fonts (bold versions of Symbol and ZapfDingbats), and a couple of locations where the page content exceeds the defined content area. - Due to issues within Apache FOP, PDF generation emits a substantial amount of output that is not easily suppressed without losing important warning information. - Apache FOP's interface to ANT does not expose a way to set the font base directory. The current configuration does work under Mac OSX, but further testing on Windows will need to be done to determine if the relative paths defined continue to work. The workaround is for Windows users to customize the fop-config.xml to provide absolute system paths to the required fonts. - HTML generation needs further browser testing, and exhibits broken navigation on iOS browsers within the TOC sidebar. - A number of PDF and HTML presentation tweaks still need to be made, for example: sidebars, gui* DocBook tags, whitespace, section separation, etc. |