Re: Building PDFs error: \pdfendlink ended up in different nesting level than \pd

On Thu, Jan 27, 2011 at 6:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Kupershmidt <schmiddy(at)gmail(dot)com> writes:
>> How did you figure out that the problem was coming from that spot in
>> installation.sgml? I'd be interested to see whether another hack would
>> work in lieu of an actual fix in pdftex.
>
> If you look at the mentioned line number in the tex-pdf file, you can
> figure out where you are in the document, assuming your eyes don't glaze
> over from the incredibly verbose TeX macros first.
>
> (Note: if you just do "make postgres-A4.pdf", make will unhelpfully
> throw away the tex-pdf intermediate file upon error.  What I have done
> when I needed to look is to explicitly "make postgres-A4.tex-pdf" and
> then "make postgres-A4.pdf", which keeps make from discarding the
> tex-pdf file when the second step fails.  I wonder though if we could
> tweak the makefile to make this less inconvenient.)

Thanks for looking into this further. Both the -US and -A4 PDFs are
still failing for me on a recent git checkout including your change to
catalog.sgml.

I tried the two-step make process you suggested. The second step of
building postgres-US.pdf failed like so:

Overfull \hbox (1.19998pt too wide) in alignment at lines 1390237--1390679
[] []

Package longtable Warning: Column widths have changed
(longtable) in table 287 on input line 1390679.

[3987.0.6
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
fstartlink.

I looked around line 1390679 of postgres-US.tex-pdf, where I saw this
snippet from seg.sgml:

(spaces around the range operator are ignored)

so I'm guessing some link around that spot is to blame. Perhaps trying
to hack up all these problem spots in the SGML source is a lost cause,
at least for my build environment. I might try pestering folks on the
pdftex mailing list next.

Josh