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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
