[tex-live] No room for a new \write

[Philipp Fäh]

--- As I said above, the limit of 32 files which can be open at the same
--- time sounds ridiculously nowadays.  On the other hand, operating
--- systems limit the number of files which can be open at the same 
time.

o.k., I agree
Mac OS X: http://developer.apple.com/qa/qa2001/qa1005.html or ulimit -a



--- I don't think I have ever seen an example where there was a serious
--- need for more than 16 read or write allocators. I would like to see 
an
--- actual example of a document with no programming errors and with no
--- excessively sloppy handling of resources that still needs more than
--- 16 distinct read or write handles (simultaneously or sequentially).

LaTeX (4)
toc, lot, lof (3)
...				--> ....
minitoc  			--> titletoc   (one .ptc-file) (1)
makeidx 			--> for more  (in one file) splitidx (1)
natbib, multibib 	--> foreach \newcites{}{}  .aux  (x)
other packages 	--> (i.e. comment (1), m-pictex, m-ch-en (1), Hyperref 
outlinefile (1) + (x + 1 .brf), etc.) (y)

7 + 2 + x + y < 16
with a secondary bibliography x=1
with need of chemistry (ppchtex) and Hyperref
  7 + 2 + 1 +       4 < 16
14 < 16
comments is very useful, to uncomment some/a lot of  text without the 
percent sign
15 < 16
so we are just at the limit

o.k. I could optimize a lot of stuff in my file and restrict some of my 
means. Although there are still a lot of packages to use.



--- The number of write streams don't depend on the number of chapters.
--- More write streams are possible: He was using just one index,
--- more indexes are possible with multind, there could be a
--- list of listings and so on.

That would imply a new (\write-file) structure?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1740 bytes
Desc: not available
Url : http://tug.org/pipermail/tex-live/attachments/20070318/5c3143a8/attachment.bin