I wrote:
> Oh ... the TUG page now has a recipe for finding the problem less
> painfully, which I don't recall having seen before:
> http://ftp.tug.org/mail-archives/pdftex/2002-February/002216.html
> In short, you can add a "draft" option that lets PDF output get generated
> anyway, and then you can actually see exactly what link is getting
> split.
Unfortunately, that recipe seems to have little to do with current reality
:-(. Perhaps there's a \usepackage{hyperref} somewhere in the style files
JadeTeX provides, but it's sure not in the tex-pdf files we generate,
so editing it isn't a convenient solution.
What I did to locate the problem was to add some garbage text in the
para you identified, so that the A4 PDF would build again, and then look
at the output. The problem turns out to be in the *next* para, which in
A4 format breaks like this:
pg_relation_size accepts the OID or name of a table, index or toast table, and returns the on-
disk size in bytes. Specifying ’main’ or leaving out the second argument returns the size of the
main data fork of the relation. Specifying ’fsm’ returns the size of the Free Space Map (see Section
54.3) associated with the relation. Specifying ’vm’ returns the size of the Visibility Map (see Sec-
tion 54.4) associated with the relation. Note that this function shows the size of only one fork; for
most purposes it is more convenient to use the higher-level functions pg_total_relation_size or
pg_table_size.
So both the FSM and VM section-reference hyperlinks break across lines,
and one or the other is falling across a page boundary in the problematic
build. I think we'd better rearrange this para to avoid problems in
future, especially in case somebody decides to invent more forks.
I remember thinking that the possible options would look better if broken
out as an itemizedlist anyway. Let me try that ...
regards, tom lane
