Re: PDF build issue with 9.0 Alpha5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>, pgsql-docs <pgsql-docs(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: PDF build issue with 9.0 Alpha5
Date: 2010-04-29 03:24:02
Message-ID: 482.1272511442@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

I wrote:
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim(at)gunduz(dot)org> writes:
>> I was trying to build PDF docs for 9.0 Alpha5, and I got this message:
>> ! TeX capacity exceeded, sorry [number of strings=245830].

> I've found a possible solution for this. The bulk of the strings are
> being created by jadetex.dtx: it makes two control sequences for each
> flow object in the document. One of these is a page number and the
> other seems to have no purpose except to prevent creating duplicate
> hyperref anchors. However, diking out the latter doesn't create any
> obvious ill effects --- either we have no occurrences in our docs of a
> pattern that would result in a duplicate, or there isn't any real
> adverse consequence of having a dup.

It occurred to me that I could investigate the consequences of this hack
more closely by building the 8.4 docs with and without the jadetex.cfg
hack. I find that:

* The text content of the PDF is the same either way: the output of
pdftotext is bit-for-bit the same, and the output of pdf2ps seems to
be about the same (there are some differences that don't seem
consequential).

* I can't immediately find any particular problems in the PDF itself.
There are some broken intrapage links, but those are broken in the
un-hacked output as well.

* The TeX log shows a fair number of warnings like this:
TeX warning (ext4): destination with the same identifier (name{351})
has been already used, duplicate ignored
However, there are some of these even without the hack, so apparently
this isn't critical. Other than these warnings the .log files are
identical.

So I'm pretty well convinced that this is a usable workaround. It
certainly beats the heck out of not being able to build PDFs at all.

I also looked into the question of whether this would affect any other
output paths. The only other output type that jadetex is used for is
plain PostScript. I find that .ps output still builds on my machine
without using the hack. The output .ps file is different with the
hack in place, but not in significant ways as far as I can see
(it's a bit hard to tell though, since the output is pretty darn
unreadable). What is particularly interesting is that the un-hacked
.ps run is not anywhere near overflowing TeX's string capacity:

Here is how much of TeX's memory you used:
161458 strings out of 245673
1244334 string characters out of 1808311
832500 words of memory out of 1500000
175113 multiletter control sequences out of 10000+200000
69272 words of font info for 109 fonts, out of 1200000 for 2000
645 hyphenation exceptions out of 8191
29i,13n,44p,650b,3983s stack positions out of 5000i,500n,6000p,200000b,15000s

This surprised the heck out of me, because I thought that jadetex.dtx
was upstream of the specific output file format. It suggests that we
might look for an alternative solution by investigating just what's
different between the .ps and .pdf configurations. However, I don't
have time for that right now, and we need some usable fix so that
people can build docs for the beta.

Barring anybody having a better solution, I'll commit the
FlowObjectSetup hack tomorrow.

regards, tom lane

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2010-04-29 14:53:56 Why the separate jade calls for pdf and ps output?
Previous Message Heikki Linnakangas 2010-04-28 07:34:33 Re: recovery configuration parameters