blob: 13c48eee5fdb4d1b88244c6b2d69e3de74fa1922 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
<head>
<title>UK TeX FAQ -- question label semanticnest</title>
</head><body>
<h3>Capacity exceeded [semantic nest ...]</h3>
<p/>
<pre>
! TeX capacity exceeded, sorry [semantic nest size=100].
...
If you really absolutely need more capacity,
you can ask a wizard to enlarge me.
</pre>
Even though TeX suggests (as always) that enlargement by a wizard
may help, this message usually results from a broken macro or bad
parameters to an otherwise working macro.
<p/>The “semantic nest” TeX talks about is the nesting
of boxes within boxes. A stupid macro can provoke the error pretty
easily:
<blockquote>
<pre>
\def\silly{\hbox{here's \silly being executed}}
\silly
</pre>
</blockquote><p>
The extended traceback
(see <a href="FAQ-erroradvice.html"><em>general advice</em> on errors</a>)
<em>does</em> help, though it does rather run on. In the case above,
the traceback consists of
<pre>
\silly ->\hbox {
here's \silly being executed}
</pre>
followed by 100 instances of
<pre>
\silly ->\hbox {here's \silly
being executed}
</pre>
The repeated lines are broken at exactly the offending macro; of
course the loop need not be as simple as this — if <code>\</code><code>silly</code> calls
<code>\</code><code>dopy</code> which boxes <code>\</code><code>silly</code>, the effect is just the same and
alternate lines in the traceback are broken at alternate positions.
<p/>There are in fact two items being consumed when you nest boxes: the
other is the grouping level. Whether you exhaust your
<em>semantic nest</em> or your permitted <em>grouping levels</em> first is
controlled entirely by the relative size of the two different sets of
buffers in your (La)TeX executable.
<p/><p>This question on the Web: <a href="http://www.tex.ac.uk/cgi-bin/texfaq2html?label=semanticnest">http://www.tex.ac.uk/cgi-bin/texfaq2html?label=semanticnest</a>
</body>
|
