[NTG-pdftex] processing speed

Reinhard Kotucha reinhard.kotucha at web.de
Thu Jul 2 00:31:20 CEST 2009

On 1 July 2009 Jérome Laurens wrote:

 > Hahn found a bug in synctex, I fixed it and made the tests with the  
 > stable branch of pdftex

Hi Jérome,
of course, if there had been a bug in synctex, it's good that it is
fixed now.  However, I doubt that synctex was responsible for the
problem I reported.  There must still be another problem.  Isn't
synctex very new technology?  I could reproduce the problem with older
versions of TeX Live.

Please try:


I suppose that it's a better test file than the one I prepared first.

What I've found out so far is that

  1. the problem is not new,

  2. luatex has the same problem,

  3. the string pool is growing.

Because I don't know what exactly causes the problem, I can't even
provide a minimal test file.  "Unfortunately" pgfplots depends on
e-TeX and I don't have a "Knuth's TeX + e-TeX" binary.  Maybe there
exists something like this in older TL releases.

Maybe even Knuth's TeX has this problem, but I don't know to prove it.

Hans and Taco said that the string pool is the culprit.  Yes, after
adding some tiny things to the .tex file, I had to create a new format
file with an increased string pool in order to get PDF files at all.
It's definitely the string pool which causes trouble.

I don't know anything about TeX's innards but the name "string pool"
implies that it contains human readable stuff.  If this is true, isn't
it possible to convince TeX to dump the string pool to a file or to
standard output, for instance, whenever a page is shipped out?  This
probably helps to find out what's going on.

Anyway, please try 


instead of mktestfiles.gz.


Reinhard Kotucha			              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.

More information about the ntg-pdftex mailing list