1

While compiling a very large document recently in xelatex and tex4ht I have observed that tex4ht doesn't handle write streams the same as xelatex. I am trying to prepare a MWE to troubleshoot my problem that started when I added another type of glossary to my document. But I am unable to reproduce the problem in smaller documents.

I don't think it is is specifically a glossaries problem because the addition of this sixth glossary doesn't break in a MWE with only 1 example term of each. My broken project has nearly 10 thousand entries in a variety of files loaded before the \begin{document}. I am unaware of any entry limit in glossaries that would force a cap on the number of entries that can be searched within but I suppose this could be possible and difficult to isolate unless known about in advance.

I make pretty full use of TeX automations as a whole:

  • cross references to document hierarchy using \ref{}
  • cross references to figures, tables, and equations using \cref{}
  • bibliography management for distinct parts, chapters, and sections using bibunits
  • table of contents and lists for all other types of objects
  • Six distinct types of glossaries, and the corresponding \makeindex, and \makeglossaries and printglossary[] calls for appearance customization
  • I am sure there are others I use that I am missing.

I have tried to force write calls by including at least one of each in a MWE but I am unable to crash my MWE.

Could anyone provide any advice regarding:

  • what other types of package calls create a new \write?
  • Or what causes distinct new \write calls to be made multiple times from the same package.
  • Or point me to documentation that describes tex4ht limitations regarding new \write?
  • Maybe all this is unnecessary if tex4ht can be forced to permit extra new \write streams...
EngBIRD
  • 3,985
  • tex4ht surely uses some extra \writes for cross referencing – michal.h21 Mar 29 '15 at 00:07
  • Why do you think it is a write problem? – cfr Mar 29 '15 at 00:24
  • @cfr Please excuse the more difficult inline formatting for the sake of presenting my error message from the console in this comment. The error that I get is ! No room for a new \write . \alloc@ ...else \errmessage {No room for a new #2} fi \fi l.73 \end{document} ? and according to numerous questions on this site, this usually is a write problem associated with glossaries – EngBIRD Mar 29 '15 at 00:32
  • Have you tried morewrites? – cfr Mar 29 '15 at 00:33
  • @cfr That was easy! Nice answer. I would be happy to accept this in answer form! I had not tried it, because I remembered reading something that discouraged this. I instead was trying to use etex and scrwfile. If I can find this question again, I will post as a comment for interests sake. – EngBIRD Mar 29 '15 at 00:38
  • @EngBIRD I wouldn't recommend loading it as a routine i.e. only load it when you need it. There are some caveats included in the package documentation. For example, spaces in filenames are bad. However, as far as I'm concerned, spaces in filenames are bad news whether I use morewrites or not, so I avoid them like the plague. It is using 'Do Not Use' functions i.e. internal stuff which it is better not to use. But, any solution is going to have to interfere with some important, low level stuff. scrwfile redirects everything to the .aux file. That's messing with stuff, too. If it works...! – cfr Mar 29 '15 at 00:51

1 Answers1

3

A while ago I ran into this issue in a different context. Searching for answers, Stephen's suggestion is the one which I ended up using. morewrites enables more new writes.

Community
  • 1
cfr
  • 198,882