Re: PDF build issue with 9.0 Alpha5 - Mailing list pgsql-docs
From | Tom Lane |
---|---|
Subject | Re: PDF build issue with 9.0 Alpha5 |
Date | |
Msg-id | 482.1272511442@sss.pgh.pa.us Whole thread Raw |
In response to | Re: PDF build issue with 9.0 Alpha5 (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-docs |
I wrote: > Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.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
pgsql-docs by date: