Re: Uh-oh: documentation PDF output no longer builds in HEAD
От | Tom Lane |
---|---|
Тема | Re: Uh-oh: documentation PDF output no longer builds in HEAD |
Дата | |
Msg-id | 7290.1447018196@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Uh-oh: documentation PDF output no longer builds in HEAD (andres@anarazel.de (Andres Freund)) |
Ответы |
Re: Uh-oh: documentation PDF output no longer builds in
HEAD
|
Список | pgsql-hackers |
andres@anarazel.de (Andres Freund) writes: > While taking pretty short of forever, postgres-US.pdf seems to build on > my debian unstable as of 8d7396e509 + some additional docs. Is this > dependant of what version of text you're using (plain tex, pdftex, > xetex, whatnot)? > postgres-US.log contains: > 360764 strings out of 481710 Interesting. They must have boosted the strings limit from 2^18 to 2^19. According to what I've read, this is doable when compiling TeX from source, but we can hardly expect users (or packagers) to do that if their distribution hasn't built it that way. (The 2^18 limit I'm seeing is with RHEL6's tex package. I'm currently downloading the Fedora rawhide package to see if it's any better, but man that is one large package...) BTW, I realized after poking around that the hack I put in back in 9.0 probably only eliminates about 5000 strings from the pool, because it should save one string per \pagelabel entry added to the .aux file, and there are less than 5000 such entries after a successful build. So that was a good quick-n-dirty fix but it's really only scratching the surface of the problem: there are ~240000 other strings getting made somewhere. I wonder if a better answer is possible. regards, tom lane
В списке pgsql-hackers по дате отправления: