and...@anarazel.de (Andres Freund) writes:
>> In some cases, it is possible for pdfjadetex to error out even with
>> expanded texmf.cnf settings. The sign of this is that jadetex is able
>> to process the file, but pdfjadetex isn't. The upstream maintainer,
>> Sebastian Rahtz, had this to say:
>>
>> | pdfjadetex _can_ go over a string limit in TeX
>> | which *isn't* changeable in texmf.cnf. The workaround is to write a
>> | file called jadetex.cfg, containing just the line
>> |
>> | \LabelElementsfalse
Interesting. That seems to be a slightly more aggressive version of my
9.0-era hack: it effectively turns FlowObjectSetup into a no-op that won't
generate page labels at all, saving *both* of the strings it would create
not only one. However, I'm afraid that's not gonna do: it looks like it
turns a large fraction of the index entries from page numbers into "??".
And some of the table-of-contents entries as well. (It looks like maybe
only things with explicit id= entries get correct page number data with
this setting. We could maybe live with that if the tool threw an error
about missing ids; but it doesn't, it just emits "??" ...)
Curiously though, that gets us down to this:
30615 strings out of 245828
397721 string characters out of 1810780
which implies that indeed FlowObjectSetup *is* the cause of most of
the strings being entered. I'm not sure how that squares with the
observation that there are less than 5000 \pagelabel entries in the
postgres-US.aux file. Time for more digging.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
