References: <i7pru2hc54.fsf_-_@hilbert.math.albany.edu>
            <18385.42387.268037.81145@morse.mittelbach-online.de>
            <85wsoeto1k.fsf@lola.goethe.zz>
            <18385.42387.268037.81145@morse.mittelbach-online.de>
            <5.1.0.14.0.20080310115827.01e05a70@pop3.web.de>
            <i7pru2hc54.fsf_-_@hilbert.math.albany.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <5.1.0.14.0.20080312161539.02aed020@pop3.web.de>
Date:         Mon, 17 Mar 2008 00:46:17 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Uwe =?iso-8859-1?Q?L=FCck?= <uwe.lueck@WEB.DE>
Subject: many labels (was: A really, really bad bug.)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <85zlt66pus.fsf_-_@lola.goethe.zz>
Precedence: list
Status: R

1st: I suppose the discussion about the STRANGE GROUP in \enddocument -- 
embracing the final processing of .aux files, challenging save stack size 
in case there are thousands of (internally generated) labels -- is missing 
on the LaTeX BUG DATABASE. (Is there a Kastrup way to LaTeX bug reports?)

2nd: Bill Hammond and I supported David Kastrup's view that the problem is 
RELEVANT, pointing at large CRITICAL EDITIONS.[1] Now David Kastrup has 
told us that he has equipped his PERPAGE.STY with a patch to deal with the 
strange \enddocument.[2] This indicates
     (a) how he found the bug;
     (b) a CLASS of related mass usages of  LaTeX's label mechanism, 
applied by some MORE LaTeX USERs than authors of critical editions (David 
Kastrup, me, some others I know);
     (c) a kind of BUG in PERPAGE.sty!

As to (b): The most common use of PERPAGE.sty is (I guess) numbering 
footnotes PAGEWISE. There are other pagewise jobs to do with LaTeX. It is 
natural to implement them by using the .aux files, and it's useful to use 
the final test on label changings to warn the author when the pagewise job 
has failed due to a page break change. However, macro writers have become 
careful to keep the number of \newlabel's small, already for hash size. I 
know of the following instances:
     (i) NUMBERING LINES pagewise. This is standard in -- sorry -- critical 
editions again. I had reported here how once the footnotes generated too 
many labels in a critical edition. However, I had discovered this when the 
author reported that, after expanding his volume considerably, the PAGEWISE 
mode of NUMBERING LINES stopped working. Well, the labels from some 
thousand footnotes didn't leave the 400 control strings that numbering 
lines pagewise needed.
     -- Besides critical editions, numbering lines is used for the REVISION 
process for submissions (Elsevier recommends lineno.sty) or among 
collaborating authors -- so here are users OUTSIDE the HUMANITIES needing 
the feature, indeed; indeed scientists.
     (ii) MARGINPAR/mparhack.sty: Marginal notes usually are wanted in the 
outer margins in two-side mode, and this is what standard LaTeX sometimes 
proves to be unable to provide. mparhack.sty does better by using -- 
labels! For hash size considerations, however, the authors have managed to 
generate just one \newlabel per page.
     -- USERs: At least German LAW COMMENTARIES are typeset in the 
following style: paragraphs are numbered in their MARGINS, and 
cross-references refer to these numbers. The dangerous labels come not so 
much from the cross-references as (rather) from mparhack.sty for keeping 
the paragraph numbers on the outer margins. There are 1000-pages volumes on 
very thin paper treating an entire main branch of law like the 
"Bürgerliches Gesetzbuch" or the "Zivilprozessordnung" in detail, so here 
it would be essential not to write several \newlabel's per page.

But what if I need 10 pagewise jobs for 500 pages each of which "safely" 
generates just one \newlabel per page? -- For example:

As to (c) and (a): PERPAGE.sty can number PAGEWISE almost whatever you 
want. However, even if David Kastrup numbers FOOTNOTEs pagewise and nothing 
else, each one writes a version of \newlabel to the .aux file, perhaps many 
more than one per page.[3] This is a weakness of perpage.sty, I would say, 
reminding me of MicroSoft programmers who are too lazy to write safe 
code.[4][5] -- Is this an acceptable way of sending a bug report for 
perpage.sty? David Kastrup might become the second person understanding 
Stephan Boettcher's (lineno.sty's) method of numbering lines pagewise using 
one command string per page only.

TO CONCLUDE: Dear LaTeX Project Team, please remove the \begingroup ... 
\endgroup from \enddocument, but only after careful discussion, and please 
report it somewhere. I'd like to know about earlier versions of 
\enddocument. Maybe once there was something between \endgroup and 
\deadcycles. Or was it about TeX's final statistics? But this group means 
spoiling the save stack statistic. Or did Leslie Lamport think "When in 
doubt, a group is always the safe way", as with the \relax after 
assignments? -- David Kastrup's patch is, in my view, perfect, and should 
someone else encounter the problem, he will find somebody to help him with 
such a patch.

Good night,

     Uwe.

________________________________

[1] Cf. below:

At 01:55 11.03.08, you wrote:
>William F Hammond <hammond@CSC.ALBANY.EDU> writes:
>
> >>>5000 labels is easy to reach if you are using the label mechanism
> >>>extensively.
> >>
> >> This is real life with critical editions in the "classical" style
> >> where footnotes don't refer by footnote marks but by line numbers.
> >> ednotes.sty originally used three labels for one footnote
> >> and broke with, say, 400 pages.
> >
> > A LaTeX translation of the largest of the four religious texts
> > (English language) in Jon Bosak's 1998 XML demos might reasonably have
> > at least 24000 labels.
> > See  http://www.ibiblio.org/bosak/
> >      http://metalab.unc.edu/bosak/xml/eg/rel200.zip
>
>Here is the conditional fix that I am placing in perpage.sty.  It is not
>all too pretty, but I think it should do the trick as long as LaTeX is
>not fixed, and do nothing once this happens.

[2] See above.

[3] I have read this claim from the code and tested it on a 2-page example.

[4] Or might we think of creators of LaTeX too lazy to write safe code? 
Apart from being too lazy to "literalize" the code lines we mostly wonder 
about.

[5] I have just decided not to complete the apparatus tonight. I am 
dreaming of hyper-emails.