Re: PDF builds broken again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PDF builds broken again
Date: 2014-07-23 17:37:23
Message-ID: 20595.1406137043@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-07-23 18:39:17 Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Previous Message Kevin Grittner 2014-07-23 17:33:50 Re: IS NOT DISTINCT FROM + Indexing