Thread: broken index references
If you search through recent 9.2 or 9.3dev PDFs for the string "??" you should find ten occurrences. Other than the first instance in Chapter 9, the other nine are all in the index, and indicate an unknown reference to some index entry. For example, you can see in the current 9.2-A4 PDF: """ deadlock, 349 timeout during, ?? ... fsync configuration parameter, ?? ... full_page_writes configuration parameter, ?? """ AFAICT tex is getting confused by <indexterm> entries appearing before <term>. Or at least, switching the order seems to fix the problem. Patch attached. Josh
Attachment
Josh Kupershmidt <schmiddy@gmail.com> writes:
> If you search through recent 9.2 or 9.3dev PDFs for the string "??"
> you should find ten occurrences. Other than the first instance in
> Chapter 9, the other nine are all in the index, and indicate an
> unknown reference to some index entry. ...
> AFAICT tex is getting confused by <indexterm> entries appearing before
> <term>. Or at least, switching the order seems to fix the problem.
> Patch attached.
Great catch, patch applied.
A different PDF-output problem that I've been noticing for awhile is that
certain intra-page links don't work. The only clue I've found about it
is the warnings in the TeX log, for instance:
pdfTeX warning (dest): name{SQL-CREATETABLE-COMPATIBILITY-TITLE} has been refer
enced but does not exist, replaced by a fixed one
pdfTeX warning (dest): name{SQL-CREATEINDEX-STORAGE-PARAMETERS-TITLE} has been
referenced but does not exist, replaced by a fixed one
pdfTeX warning (dest): name{SQL-CREATETABLE-STORAGE-PARAMETERS-TITLE} has been
referenced but does not exist, replaced by a fixed one
pdfTeX warning (dest): name{SQL-CREATEINDEX-CONCURRENTLY-TITLE} has been refere
nced but does not exist, replaced by a fixed one
pdfTeX warning (dest): name{SQL-GROUPBY-TITLE} has been referenced but does not
exist, replaced by a fixed one
pdfTeX warning (dest): name{SQL-WHERE-TITLE} has been referenced but does not e
xist, replaced by a fixed one
pdfTeX warning (dest): name{SQL-FROM-TITLE} has been referenced but does not ex
ist, replaced by a fixed one
If you look at the relevant intrapage links on these reference pages,
you find that they look right (the text does correspond to the
referenced title item), but the link actually goes to page 1 of the PDF.
(This is with the Fedora 16 PDF toolchain.) Any idea what's causing that?
regards, tom lane
On Sat, Mar 23, 2013 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > A different PDF-output problem that I've been noticing for awhile is that > certain intra-page links don't work. The only clue I've found about it > is the warnings in the TeX log, for instance: I could have overlooked a working example.. but as far as I've seen, every link of the form: <xref linkend="..." endterm="..."> just goes to Page 1 in the PDFs. I checked against a recent 9.2-A4.pdf from the website and my own 9.3-A4.pdf built on Debian; the psql page (psql-ref.sgml) has a number of such links. The links seem to work OK in the HTML version, though. Josh
On Fri, Mar 29, 2013 at 04:25:17PM -0700, Josh Kupershmidt wrote:
> On Sat, Mar 23, 2013 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > A different PDF-output problem that I've been noticing for awhile is that
> > certain intra-page links don't work. The only clue I've found about it
> > is the warnings in the TeX log, for instance:
>
> I could have overlooked a working example.. but as far as I've seen,
> every link of the form:
>
> <xref linkend="..." endterm="...">
>
> just goes to Page 1 in the PDFs. I checked against a recent 9.2-A4.pdf
> from the website and my own 9.3-A4.pdf built on Debian; the psql page
> (psql-ref.sgml) has a number of such links. The links seem to work OK
> in the HTML version, though.
Sorry to be looking at this late, but I just tested the 9.3.1 PDF at:
http://www.postgresql.org/files/documentation/pdf/9.3/postgresql-9.3-US.pdf
and the link on page 1748 that links to section 31.14 worked fine:
For additional environment variables, see Section 31.14.)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
On Sat, Nov 30, 2013 at 2:53 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, Mar 29, 2013 at 04:25:17PM -0700, Josh Kupershmidt wrote: >> On Sat, Mar 23, 2013 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > A different PDF-output problem that I've been noticing for awhile is that >> > certain intra-page links don't work. The only clue I've found about it >> > is the warnings in the TeX log, for instance: >> >> I could have overlooked a working example.. but as far as I've seen, >> every link of the form: >> >> <xref linkend="..." endterm="..."> >> >> just goes to Page 1 in the PDFs. I checked against a recent 9.2-A4.pdf >> from the website and my own 9.3-A4.pdf built on Debian; the psql page >> (psql-ref.sgml) has a number of such links. The links seem to work OK >> in the HTML version, though. > > Sorry to be looking at this late, but I just tested the 9.3.1 PDF at: > > http://www.postgresql.org/files/documentation/pdf/9.3/postgresql-9.3-US.pdf > > and the link on page 1748 that links to section 31.14 worked fine: > > For additional environment variables, see Section 31.14.) [... jogging my memory ... ] I think the problem was specifically with links of the form: <xref linkend="..." endterm="..."> having the "endterm" attribute specified -- your example didn't have an "endterm". For an example, see the next page (p. 1749 according to our page numbering, under the "Meta-Commands" sub-heading), for the link to "SQL Interpolation" at the end of this paragraph: <para> If an unquoted colon (<literal>:</literal>) followed by a <application>psql</> variable name appears within an argument, it is replaced by the variable's value, as described in <xref linkend="APP-PSQL-interpolation" endterm="APP-PSQL-interpolation-title">. </para> which at least in my PDF reader just sends one back to Page 1. Josh
On Sat, Nov 30, 2013 at 05:23:14PM -0500, Josh Kupershmidt wrote: > > Sorry to be looking at this late, but I just tested the 9.3.1 PDF at: > > > > http://www.postgresql.org/files/documentation/pdf/9.3/postgresql-9.3-US.pdf > > > > and the link on page 1748 that links to section 31.14 worked fine: > > > > For additional environment variables, see Section 31.14.) > > [... jogging my memory ... ] I think the problem was specifically with > links of the form: > > <xref linkend="..." endterm="..."> > > having the "endterm" attribute specified -- your example didn't have > an "endterm". For an example, see the next page (p. 1749 according to > our page numbering, under the "Meta-Commands" sub-heading), for the > link to "SQL Interpolation" at the end of this paragraph: > > <para> > If an unquoted colon (<literal>:</literal>) followed by a > <application>psql</> variable name appears within an argument, it is > replaced by the variable's value, as described in <xref > linkend="APP-PSQL-interpolation" endterm="APP-PSQL-interpolation-title">. > </para> > > which at least in my PDF reader just sends one back to Page 1. Yes, I confirm that failure on Debian. Thank you. Anyone want to suggest a cause? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On 11/30/13, 8:34 PM, Bruce Momjian wrote: >> <para> >> > If an unquoted colon (<literal>:</literal>) followed by a >> > <application>psql</> variable name appears within an argument, it is >> > replaced by the variable's value, as described in <xref >> > linkend="APP-PSQL-interpolation" endterm="APP-PSQL-interpolation-title">. >> > </para> >> > >> > which at least in my PDF reader just sends one back to Page 1. > Yes, I confirm that failure on Debian. Thank you. Anyone want to > suggest a cause? Apparently a bug in the tool chain. The link works correctly when built with FOP, so I think the markup is correct.