Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Jul 23, 2014 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> A more robust fix would be to identify the para where the problem actually
>> is and re-word it so that the link doesn't cross a *line* boundary (in
>> either US or A4). That makes it safe as long as that particular para
>> doesn't get reworded in future; whereas with what you did, addition or
>> subtraction of a line anywhere in a pretty broad range could resurrect
>> the issue.
> Hmm. Good point. OTOH it only showed up in the backbranch (and only in
> one of them), so I figured we might get away with it.
> Have you figured out any way to actually track down which para has the
> problem itself, or is it all manual work?
My recollection is it takes a bit of detective work but you can generally
figure it out by eyeballing the TeX input file around the complained-of
line number. The first trick is that our makefiles think the TeX input
file is temp and delete it on failure, so you need to ask for it to be
built not the PDF file. The second trick is that the line number is not
spot-on; the error seems to come out only when TeX decides where it's
going to break the page, which it won't do until it has absorbed a few
more lines than actually end up on the page.
I think I've posted more details in some past thread on the issue ...
oh, here:
http://www.postgresql.org/message-id/9473.1296172647@sss.pgh.pa.us
>> Of course, it would be a lot better if the toolchain didn't have this
>> limitation (or at least managed to report it more usefully). I'm not
>> holding my breath for that to happen though.
> Yeah, they would probably have done it years ago if they were going to at all...
IIRC there actually was a patch that purported to fix this a year or so
ago, but it didn't help :-(
regards, tom lane
