Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jan 2004 09:43:28 +0100 Received: by mail.proteosys.com (8.12.10/8.12.2) with ESMTP id i0V8hM81025484 for ; Sat, 31 Jan 2004 09:43:24 +0100 MIME-Version: 1.0 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i0V8XViv028717; Sat, 31 Jan 2004 09:33:32 +0100 (MET) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E7D6.4BF6F800" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i0UN022c017104; Sat, 31 Jan 2004 09:23:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 16937 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 31 Jan 2004 09:23:19 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i0V8DJwM021402 for ; Sat, 31 Jan 2004 09:13:19 +0100 Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i0V8Meiv026912 for ; Sat, 31 Jan 2004 09:22:40 +0100 (MET) Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1AmqNl-0003jM-Ts for latex-l@listserv.uni-heidelberg.de; Sat, 31 Jan 2004 03:21:38 -0500 Lines: 25 Return-Path: X-OriginalArrivalTime: 31 Jan 2004 08:43:28.0075 (UTC) FILETIME=[4C0269B0:01C3E7D6] X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0 () Content-class: urn:content-classes:message Subject: A job for eTeX. Date: Sat, 31 Jan 2004 08:48:59 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A job for eTeX. Thread-Index: AcPn1kweApYjWC7zQWm3seb5Kjbd+Q== From: "David Kastrup" Sender: "Mailing list for the LaTeX3 project" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4747 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E7D6.4BF6F800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, currently involved with programming a footnote package, I was trying to get a clue about just when to insert \color@begingroup and \color@endgroup and reached the conclusion: forget it. If a footnote is broken across several pages, we will get all hell break loose, anyhow. The current implementation works basically by protecting headlines and stuff within a closed color stack from the bleeding of any main material text into them, but this is all rather shaky. So either we need separate color stacks in the output drivers which we can switch between (probably not the worst idea: technically a rather clean solution), or we need to use a marks mechanism for keeping track of the color stack state whenever things get split. Is there any intention of getting either solution into the main LaTeX, or should I rather shoot for an island solution within bigfoot.sty eventually? After all, there are probably not so many entities that actually cross page boundaries. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ------_=_NextPart_001_01C3E7D6.4BF6F800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A job for eTeX.

Hi folks,

currently involved with programming a footnote = package, I was trying
to get a clue about just when to insert = \color@begingroup and
\color@endgroup and reached the conclusion: forget = it.  If a footnote
is broken across several pages, we will get all hell = break loose,
anyhow.

The current implementation works basically by = protecting headlines
and stuff within a closed color stack from the = bleeding of any main
material text into them, but this is all rather = shaky.

So either we need separate color stacks in the output = drivers which
we can switch between (probably not the worst idea: = technically
a rather clean solution), or we need to use a marks = mechanism for
keeping track of the color stack state whenever = things get split.

Is there any intention of getting either solution into = the main
LaTeX, or should I rather shoot for an island = solution within
bigfoot.sty eventually?  After all, there are = probably not so many
entities that actually cross page boundaries.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

------_=_NextPart_001_01C3E7D6.4BF6F800--