summaryrefslogtreecommitdiff
path: root/info/digests/nts-l
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/digests/nts-l
Initial commit
Diffstat (limited to 'info/digests/nts-l')
-rw-r--r--info/digests/nts-l/9205.gzbin0 -> 59937 bytes
-rw-r--r--info/digests/nts-l/9206.gzbin0 -> 66119 bytes
-rw-r--r--info/digests/nts-l/9207.gzbin0 -> 27013 bytes
-rw-r--r--info/digests/nts-l/9208.gzbin0 -> 2249 bytes
-rw-r--r--info/digests/nts-l/9210.gzbin0 -> 18716 bytes
-rw-r--r--info/digests/nts-l/9211.gzbin0 -> 870 bytes
-rw-r--r--info/digests/nts-l/9302.gzbin0 -> 876 bytes
-rw-r--r--info/digests/nts-l/9303.gzbin0 -> 49029 bytes
-rw-r--r--info/digests/nts-l/9304.gzbin0 -> 7611 bytes
-rw-r--r--info/digests/nts-l/9305.gzbin0 -> 1341 bytes
-rw-r--r--info/digests/nts-l/9306.gzbin0 -> 12291 bytes
-rw-r--r--info/digests/nts-l/9308.gzbin0 -> 1385 bytes
-rw-r--r--info/digests/nts-l/9309.gzbin0 -> 2431 bytes
-rw-r--r--info/digests/nts-l/9310.gzbin0 -> 7285 bytes
-rw-r--r--info/digests/nts-l/9311.gzbin0 -> 71881 bytes
-rw-r--r--info/digests/nts-l/9312.gzbin0 -> 3235 bytes
-rw-r--r--info/digests/nts-l/9401.gzbin0 -> 26997 bytes
-rw-r--r--info/digests/nts-l/9402385
-rw-r--r--info/digests/nts-l/9405200
-rw-r--r--info/digests/nts-l/94101187
-rw-r--r--info/digests/nts-l/94111897
-rw-r--r--info/digests/nts-l/9412113
-rw-r--r--info/digests/nts-l/950132
23 files changed, 3814 insertions, 0 deletions
diff --git a/info/digests/nts-l/9205.gz b/info/digests/nts-l/9205.gz
new file mode 100644
index 0000000000..f447faef5a
--- /dev/null
+++ b/info/digests/nts-l/9205.gz
Binary files differ
diff --git a/info/digests/nts-l/9206.gz b/info/digests/nts-l/9206.gz
new file mode 100644
index 0000000000..74f9636f0c
--- /dev/null
+++ b/info/digests/nts-l/9206.gz
Binary files differ
diff --git a/info/digests/nts-l/9207.gz b/info/digests/nts-l/9207.gz
new file mode 100644
index 0000000000..3d737378a8
--- /dev/null
+++ b/info/digests/nts-l/9207.gz
Binary files differ
diff --git a/info/digests/nts-l/9208.gz b/info/digests/nts-l/9208.gz
new file mode 100644
index 0000000000..6c91510aa3
--- /dev/null
+++ b/info/digests/nts-l/9208.gz
Binary files differ
diff --git a/info/digests/nts-l/9210.gz b/info/digests/nts-l/9210.gz
new file mode 100644
index 0000000000..51de1e2faf
--- /dev/null
+++ b/info/digests/nts-l/9210.gz
Binary files differ
diff --git a/info/digests/nts-l/9211.gz b/info/digests/nts-l/9211.gz
new file mode 100644
index 0000000000..7e80ef5107
--- /dev/null
+++ b/info/digests/nts-l/9211.gz
Binary files differ
diff --git a/info/digests/nts-l/9302.gz b/info/digests/nts-l/9302.gz
new file mode 100644
index 0000000000..7ae5eb0717
--- /dev/null
+++ b/info/digests/nts-l/9302.gz
Binary files differ
diff --git a/info/digests/nts-l/9303.gz b/info/digests/nts-l/9303.gz
new file mode 100644
index 0000000000..c3668043df
--- /dev/null
+++ b/info/digests/nts-l/9303.gz
Binary files differ
diff --git a/info/digests/nts-l/9304.gz b/info/digests/nts-l/9304.gz
new file mode 100644
index 0000000000..1a9c8bf41b
--- /dev/null
+++ b/info/digests/nts-l/9304.gz
Binary files differ
diff --git a/info/digests/nts-l/9305.gz b/info/digests/nts-l/9305.gz
new file mode 100644
index 0000000000..463603cc79
--- /dev/null
+++ b/info/digests/nts-l/9305.gz
Binary files differ
diff --git a/info/digests/nts-l/9306.gz b/info/digests/nts-l/9306.gz
new file mode 100644
index 0000000000..23c1ac58b0
--- /dev/null
+++ b/info/digests/nts-l/9306.gz
Binary files differ
diff --git a/info/digests/nts-l/9308.gz b/info/digests/nts-l/9308.gz
new file mode 100644
index 0000000000..f73974ec75
--- /dev/null
+++ b/info/digests/nts-l/9308.gz
Binary files differ
diff --git a/info/digests/nts-l/9309.gz b/info/digests/nts-l/9309.gz
new file mode 100644
index 0000000000..ae2661c036
--- /dev/null
+++ b/info/digests/nts-l/9309.gz
Binary files differ
diff --git a/info/digests/nts-l/9310.gz b/info/digests/nts-l/9310.gz
new file mode 100644
index 0000000000..b5f6a19a41
--- /dev/null
+++ b/info/digests/nts-l/9310.gz
Binary files differ
diff --git a/info/digests/nts-l/9311.gz b/info/digests/nts-l/9311.gz
new file mode 100644
index 0000000000..31e1dfbe09
--- /dev/null
+++ b/info/digests/nts-l/9311.gz
Binary files differ
diff --git a/info/digests/nts-l/9312.gz b/info/digests/nts-l/9312.gz
new file mode 100644
index 0000000000..cb21650623
--- /dev/null
+++ b/info/digests/nts-l/9312.gz
Binary files differ
diff --git a/info/digests/nts-l/9401.gz b/info/digests/nts-l/9401.gz
new file mode 100644
index 0000000000..5171735a89
--- /dev/null
+++ b/info/digests/nts-l/9401.gz
Binary files differ
diff --git a/info/digests/nts-l/9402 b/info/digests/nts-l/9402
new file mode 100644
index 0000000000..4cc6b51a63
--- /dev/null
+++ b/info/digests/nts-l/9402
@@ -0,0 +1,385 @@
+========================================================================
+Date: Sat, 29 Jan 1994 02:12:06 -0500
+Reply-To: NTS-L Distribution list <NTS-L@DHDURZ1.BITNET>
+From: Laurent Siebenmann <laurent@MATH.TORONTO.EDU>
+Subject: extended features of Textures
+
+extended features of Textures
+
+
+ > Initex can load patterns (cumulative with TeX3)
+ > only if
+ > 1. no .fmt is loaded
+ > 2. no paragraph has been typeset
+
+Consulting five TeX implementations as to whether
+restrictions 1. and 2. hold as stated, I find:
+
+ Textures | OzTeX | Direct-TeX | mlTeX | C-TeX
+1. no yes yes yes yes
+2. no no no no no
+
+I conclude that Bernd's correction to 2 is sustained
+for standard TeX; and that my "correction" to 1.
+is not --- as Peter Breitenlohner predicted.
+I am very happy to be wrong here rather than in TUGboat.
+
+ I was accurately describing *extended TeX* behavior
+of Textures --- a subject certainly of interest here.
+
+ I am surprised. Hitherto I had not found any qualitative
+deviation of Textures behavior from that of an enormous initex
+with which one communicates mostly via Macintosh interface
+tools.
+
+ Has anyone else noticed further "extended" TeX features
+of Textures? The obvious answer is that Textures has merged
+initex into virtex. But has it not just dropped
+virtex?
+
+ Extended TeXs aught to provide a complete catalog of their
+deviations from the performance of standard TeX. (That
+includes e-TeX.) Particularly so where ".tex" file
+acceptabilityis involved. Has Textures not done so?
+
+ Laurent S
+
+ *** "[Do not] put too much confidence in experimental results until
+ *** they have been confirmed by theory."
+ *** ---Arthur Stanley Eddington
+
+========================================================================
+Date: Sat, 29 Jan 1994 02:15:15 -0500
+Reply-To: NTS-L Distribution list <NTS-L@DHDURZ1.BITNET>
+From: Laurent Siebenmann <laurent@MATH.TORONTO.EDU>
+Subject: e- for economy
+
+e- for economy
+
+ > IMHO if only a very, very small group of TeX users can not
+ > switch to e-TeX because of very restricted hardware/software
+ > limitations, we should tell them to get a better machine/a
+ > better OS (and ignore them)...
+
+If you want e-TeX users to be numerous, tell them that they
+will be able to use as many modules of e-TeX as their
+power and capacity and os permit. And that, in TeX
+compatibility mode, power and RAM requirements will be
+comparable to that of TeX.
+
+ Laurent S
+
+========================================================================
+Date: Sat, 29 Jan 1994 02:14:51 -0500
+Reply-To: NTS-L Distribution list <NTS-L@DHDURZ1.BITNET>
+From: Laurent Siebenmann <laurent@MATH.TORONTO.EDU>
+Subject: Lessons from the past
+
+Lessons from the past
+
+
+1) Textures has already erased the distinction between initex and
+virtex. I hope e-TeX will do as much.
+
+2) Textures has already allowed pattern assimilation by
+any format of TeX that does not contain a compacted hyphenation trie.
+I hope e-TeX will do as much. This allows one to quickly
+(inter)nationalize precompiled formats.
+
+3) (ini)TeX 2 allowed one to erase the existing trie at any
+time and input new patterns. I hope e-teX will do as much.
+Even if it cannot be done on a language-by-language basis.
+No new command is needed; TeX could simply report that it
+has been obliged to erase patterns. Textures does not
+currently have this feature.
+
+ With (3), e-TeX could never be completely stopped
+when a heavily multilingual job comes along --- say a
+tourist brochure in seven languages. At worst it would be
+slowed.
+
+ I see no reason why (1) and (2) would require one to
+
+ > -- to remove the trie compaction in IniTeX,
+ > -- change the code behind \pattern to build an already usable
+trie
+
+So this proposal not what Bernd is suggesting. Are (1)(2)(3)
+inadequate in practice?
+
+
+ Laurent S
+
+========================================================================
+Date: Mon, 31 Jan 1994 11:08:53 +0100
+Reply-To: NTS-L Distribution list <NTS-L@DHDURZ1.BITNET>
+From: Mariusz Olko <mariusz@THETA1.IFPAN.EDU.PL>
+Subject: Re: eTeX: Proposal for hyphenation patterns on demand
+In-Reply-To: <9401281933.AA03784@sigma.ifpan.edu.pl>
+
+Tim Bradshaw writes:
+
+ > More interestingly: just how big is the overhead of using initex rather
+ > than virtex? How will it compare with the overhead from using, say
+ > LaTeX3 rather than 2.09, which presumably people will be encouraged to
+ > do.
+
+For preprocessing patterns TeX needs a number of arrays size of which
+can be astimated as
+( 3*sizeof(int) + sizeof(char) +sizeof(boolean) ) * trie_size + 256*sizeof(int)
+
+This gives about 120k for trie size of 30000.
+
+
+Mariusz
+
+========================================================================
+Date: Mon, 31 Jan 1994 11:51:18 +0100
+Reply-To: NTS-L Distribution list <NTS-L@DHDURZ1.BITNET>
+From: Mariusz Olko <mariusz@THETA1.IFPAN.EDU.PL>
+Subject: Re: eTeX: Proposal for hyphenation patterns on demand
+In-Reply-To: <9401282017.AA03813@sigma.ifpan.edu.pl>
+
+Bernd Raichle writes:
+
+ > When I wrote my reply to the proposal I thought about the possibility
+ > -- to remove the trie compaction in IniTeX,
+ > -- change the code behind \pattern to build an already usable trie and
+ > -- include the same code in VirTeX.
+ >
+ > This means that the trie data structures and routines have to be
+ > changed and we can't compress the trie by identifying common subtries,
+ > because a subtries will be propably changed...
+
+We don't have to give up with compaction. We can end up with partial
+compaction ie. when dumping format eTeX can compact whatever it has
+ready and then each set can be compacted before use. In current TeX a
+flag is checked whether the table has already been compacted befor
+typesetting is started. It can be arranged that there is a separate
+flag for each language. It can be checked separately before
+hyphenating word in current language and if this part of table is not
+ready it can be compacted.
+
+I have made test to see what is the overlap between the subtries of
+Polish and English patterns. Here are the results.
+English patterns 6075 trie size as reported by iniTeX
+Polish patterns 5505
+ ------------------
+ total 11580
+
+When loading two sets together i get trie size 11344. That means the
+gain from compacting patterns together is 236 at the level of 2% !!!.
+(Can anybody check this for other sets of paterns ?)
+
+At the same time Ziri Zlatuska's experiments show that compacted
+patterns are nearly 30% smaller than non compacted.
+
+
+regards
+ Mariusz
+
+========================================================================
+Date: Tue, 1 Feb 1994 13:40:24 +0100
+Reply-To: Chris Rowley <C.A.Rowley@open.ac.uk>
+From: "Johannes L. Braams" <J.L.Braams@RESEARCH.PTT.NL>
+Subject: LaTeX2e conference announcement
+
+ *******************************
+ * LaTeX2e: The Conference *
+ *******************************
+ ************
+ Announcing the New Standard version of LaTeX
+ ********************************************
+
+You've read the hype, you've ordered the book---
+ --- haven't you? ---
+ ---now here's the chance to discover the real thing!
+
+For authors, publishers, support persons, ..., everyone---
+ ---two days to discover what LaTeX2e can do for you
+
+All the New Features of LaTeX2e---
+ The New Standard Version of LaTeX
+ ---Incorporating SliTeX and AMSLaTeX
+ ************
+
+ *** how to install it
+
+ *** how to integrate your local styles
+
+ *** how to use scalable fonts
+
+ *** how to integrate graphics
+
+ *** how to process existing documents
+
+ *** how to use the new features
+
+ *** how to write extension packages
+
+ Presentations by members of the LaTeX3 project team
+ Featuring Frank Mittelbach, Johannes Braams, David Carlisle,
+ Chris Rowley, Alan Jeffrey, Michel Goosens (at least)
+
+***************************************************************
+Booking Form
+
+I wish to attend the UKTUG's LaTeX2e conference on March 21st--22nd:
+
+Name:
+Organisation:
+Address:
+
+
+Telephone:
+Email:
+Please specify any special dietary requirements:
+Specify any changes to standard 1-night accommodation[2]:
+Indicate whether you require a copy of `The \LaTeX\ Companion'[3]:
+
+ Payment enclosed[1,4,9]
+or purchase order number[5]
+ Signed:
+ Date:
+
+Notes
+[1] Payment for the conference, all meals (including a conference dinner),
+ refreshments and accommodation for the night of Monday, March 21st,
+ will be \pounds89 for members of UKTUG (or other \TeX\ user groups)
+ and \pounds120 for non-members.
+[2] Additional nights' accommodation (bed and breakfast) can
+ be included at a cost of \pounds20 per night.
+ Indicate which additional nights you require
+ (if any). If you do not require accommodation for the night
+ of Monday, March 21st, deduct \pounds20 and note this.
+[3] `The \LaTeX\ Companion', by Goossens, Mittelbach and Samarin,
+ has recently been published by Addison Wesley. It is the main source of
+ documentation about \LaTeX2e. We hope to have this book
+ available to delegates at a discount from its normal price of
+ \pounds26.95. Please indicate whether you wish to take advantage of
+ this offer, which is available only to those attending
+ the conference.
+[4] Sterling cheques should be made payable to `Warwick University'.
+[5] A Purchase Order, with an order number, is an acceptable alternative
+ method of payment, but will attract a \pounds15 surcharge on the
+ amount due.
+[6] If your cost is outside the range \pounds69--175, recalculate.
+[7] Return the completed form to arrive by Tuesday March 1st, 1994.
+ We cannot guarantee enrollment after that date. If you are unable to
+ return the form by then, but are definitely coming, contact
+ the local organiser by email, telephone, fax or mail to secure a place.
+ For contact details, see below.
+[8] If your requirements are not met by the options offered,
+ contact the local organizer.
+[9] Note that VAT is not chargeable.
+[10] A proper LaTeX-able version of the booking form is available from
+ the local organizer.
+
+Meeting duration
+Conference registration will commence at 1000 on Monday 21st;
+coffee will be available from 1030; the sessions will start at 1115.
+The sessions will end at 1700 on Tuesday 22nd.
+
+Travel to Warwick University
+There is an Inter-City rail service to Coventry, but from some
+locations it may be easier to travel to Birmingham initially.
+
+Journey depart arrive
+Euston to Coventry 0810 0920
+ 0840 0950
+ 0910 1025
+Manchester to Coventry 0718 0929
+ 0818 1027
+Bristol (TM) to B'ham 0714 0854 Trains from Birmingham to Coventry
+ 0830 0954 are frequent and fast (journey time
+Newcastle to B'ham 0640 0951 of 20--30 minutes, departing
+York to B'ham 0742 0951 every 10 or 15 minutes).
+
+There will be a shuttle bus service running between 1000 and 1030 for delegates
+arriving at Coventry Railway Station. The shuttle bus will also be available
+on the 22nd to take delegates back to the station.
+
+A taxi from the station to the University costs about \pounds4.
+Alternatively, buses (notably the X10, X12, 12 and 12A) run from
+just outside the station to the University, taking about 15 minutes.
+It is a de-regulated service and as such impossible to guess the
+fare from day to day. It is usually about 50p. The 12 and 12A services
+are `correct fare only', but no-one (except the driver) knows what
+the correct fare is.
+
+The University is easily accessible by car, and
+may be reached from the M1, M40, M42, M45, M6 and M69.
+There is ample parking for private vehicles on campus.
+
+Birmingham airport is about 12 minutes from Coventry by
+rail and is connected by a frequent and fast service.
+
+Payment Address
+Please return the completed booking form, together
+with your payment, to arrive before Tuesday March 1st, 1994, to:
+
+Malcolm Clark (lxii)
+Computing Services Tel: 0203 523365
+University of Warwick Fax: 0203 523267
+Coventry CV4 7AL Email: m.clark@uk.ac.warwick (Janet)
+UK m.clark@warwick.ac.uk (Internet)
+
+ Enrol by March 1st, 1994
+
+========================================================================
+Date: Wed, 2 Feb 1994 13:46:51 +0100
+Reply-To: NTS-L Distribution list <NTS-L@DHDURZ1.BITNET>
+From: Peter Deussen <dem@CS.TU-BERLIN.DE>
+
+unsubscibe
+
+========================================================================
+Date: Fri, 4 Feb 1994 12:44:49 EST
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "MARSOLAIS,SYLVAIN,MR" <BBFO@MUSICB.MCGILL.CA>
+
+LIST GLOBAL
+
+========================================================================
+Date: Thu, 17 Feb 1994 11:53:04 -0500
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Michael Downes <MJD@MATH.AMS.ORG>
+Subject: Another debugging proposal
+
+Proposed debugging extension:
+
+---Improve the reporting of conditionals when \tracingmacros > 1 to make
+it easier to locate the source of an error such as "File ended when \ifx
+on line 1371 was incomplete". Since TeX already maintains the
+information about the begin-conditional command and the line number, I
+hope that it would not be too hard to write this into the log file at
+the appropriate point, together with the current conditional nesting
+level:
+
+ {\ifx: 2 l.300}
+ {false}
+ {\fi: \ifx 2 l.300}
+
+where "2" indicates the nesting level inside the conditional.
+
+Motivation: There is currently no easy way to properly match up all the
+\if's and \fi's in a tracing log, for reasons that are a little
+complicated to explain. Anyone who has tried to debug this sort of error
+in a complicated macro package will know what I'm talking about, I
+think. The proposed extension would help in this way: If you want to
+find the \ifx that matches a given \fi, you would merely have to search
+backward for the pattern
+
+ {\ifx: 2
+
+The nesting level number guarantees that the first occurrence in the
+reverse direction will be the proper match, provided that tracing was
+turned on throughout the intervening material. The line number will help
+track down a match when there is a large amount of intervening material
+so that tracing through all of it would be inconvenient (for example, by
+producing a log file that uses up all 7 megs of your remaining disk
+space :-).
+
+Michael Downes
+mjd@math.ams.org
+
diff --git a/info/digests/nts-l/9405 b/info/digests/nts-l/9405
new file mode 100644
index 0000000000..490e376bcc
--- /dev/null
+++ b/info/digests/nts-l/9405
@@ -0,0 +1,200 @@
+========================================================================
+Date: Mon, 2 May 1994 13:54:20 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "Miguel SANTOS, DCC/USD (Tel (33-1) 45 24 19 40 )" <Miguel.M.D.SANTOS@DCC-USD.OECD.FR>
+Subject: SUBSCRIPTION
+
+I would like to know who to join MICROSOFT NT discussion list.
+
+Thanks
+
+Dos Santos Miguel @ OECD.fr
+2 rue Andre Pascal
+75775 PARIS CEDEX FRANCE
+
+========================================================================
+Date: Mon, 2 May 1994 13:54:44 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "Adolfo ALADRO, DCC/COD (Tel (33-1) 45 24 18 88 )" <Adolfo.A.A.ALADRO@DCC-COD.OECD.FR>
+Subject: Subscription
+
+I would like to know how to join Microsoft NT discussion list.
+Thanks.
+
+Aladro Adolfo@OECD.Fr
+2, Rue Andre Pascal
+75016 Paris
+
+Tel (33-1) 45 24 18 88
+Fax (33-1) 45 24 19 51
+
+========================================================================
+Date: Mon, 2 May 1994 18:55:12 MEZ
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Werner Lemberg <A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT>
+Subject: Re: SUBSCRIPTION
+In-Reply-To: Message of Mon,
+ 2 May 1994 13:54:20 GMT from <Miguel.M.D.SANTOS@DCC-USD.OECD.FR>
+
+On Mon, 2 May 1994 13:54:20 GMT Miguel SANTOS, DCC/USD (Tel (33-1) 45 24 19 40 )
+>I would like to know who to join MICROSOFT NT discussion list.
+>
+>Thanks
+>
+
+This is the joke of the month !
+
+ Werner
+
+========================================================================
+Date: Thu, 5 May 1994 01:15:05 +0200
+Reply-To: Krzysztof_Leszczynski@camk.edu.pl
+From: Chris Leszczynski <Krzysztof_Leszczynski@CAMK.EDU.PL>
+Subject: Re: SUBSCRIPTION
+In-Reply-To: <9405021657.AA05866@alfa.camk.edu.pl> from "Werner Lemberg" at
+ May 2, 94 06:55:12 pm
+
+>
+> On Mon, 2 May 1994 13:54:20 GMT Miguel SANTOS, DCC/USD (Tel (33-1) 45 24 19 40
+ )
+> >I would like to know who to join MICROSOFT NT discussion list.
+> >
+> >Thanks
+> >
+>
+> This is the joke of the month !
+>
+> Werner
+>
+Maybe we should change the subject of out list, after all S in NTS
+stands for ``System'' and N for ``New''. All we need is a small change
+of T abbreviation to ``Technology'' ;-)
+
+ Chris (chris@camk.edu.pl)
+
+PS. I'm really happy to get ANY letter from NTS-l, even that one :-)
+
+========================================================================
+Date: Fri, 13 May 1994 21:34:30 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: Survey: Existing extensions to TeX
+
+What extensions to TeX does already exist ? I am aware of TeX-XeT,
+TeX--XeT, MLTeX and Sisisi, but there may be more. Specially I have heard
+that some commercial implementations provide additional primitives or
+extensions.
+
+Do extended MF's exist (I'm aware of none) ?
+
+What additions to the standard TeX kit exist (Roughly the following
+programmes: weave, tangle, TeX, MF, gftopk, gftype, pktype, tftopl, pltotf,
+dvitype, mft, vptovf, vftovp ... did I miss any? ) ?
+
+Yours, J"org Knappen.
+
+========================================================================
+Date: Fri, 13 May 1994 21:10:00 LCL
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Timothy Murphy <tim@MATHS.TCD.IE>
+Subject: Re: Survey: Existing extensions to TeX
+In-Reply-To: <01HCAVUSIIPQ00CPDO@mailgate.ucd.ie> from "J%org Knappen,
+ Mainz" at May 13, 94 09:34:30 pm
+
+>
+> What additions to the standard TeX kit exist (Roughly the following
+> programmes: weave, tangle, TeX, MF, gftopk, gftype, pktype, tftopl, pltotf,
+> dvitype, mft, vptovf, vftovp ... did I miss any? ) ?
+>
+dvicopy seems to be "in" now.
+
+========================================================================
+Date: Sat, 14 May 1994 14:50:13 +0100
+Reply-To: phfrom@nyx.uni-konstanz.de
+Comments: Warning -- original Sender: tag was phfrom@[134.34.3.4]
+From: Hartmut Frommert <phfrom@NYX.UNI-KONSTANZ.DE>
+Subject: Re: Survey: Existing extensions to TeX
+
+In message Fri, 13 May 1994 21:34:30 +0100,
+ "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE> writes:
+
+> What extensions to TeX does already exist ? I am aware of TeX-XeT,
+> TeX--XeT, MLTeX and Sisisi, but there may be more [..]
+
+J%org: Please post (or mail me) a summary of eventual e-mail replies.
+
+Btw, I think you are also aware of the macro packages and utilities
+LaTeX, BibTeX, Ams-Stuff[Fonts, TeX, LaTeX] and more, but what you consider
+seems to be slightly different ..
+
+ Hartmut Frommert | Russia HAS a space station !
+ <phfrom@nyx.uni-konstanz.de> | Mars Observer 2 would have survived.
+
+========================================================================
+Date: Sat, 14 May 1994 19:12:58 -0400
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: bbeeton <BNB@MATH.AMS.ORG>
+Subject: Re: Survey: Existing extensions to TeX
+In-Reply-To: <01HCANIAFOS29GW2XX@MATH.AMS.ORG>
+
+j"org knappen asks:
+ What extensions to TeX does already exist ? I am aware of TeX-XeT,
+ TeX--XeT, MLTeX and Sisisi, but there may be more. Specially I have heard
+ that some commercial implementations provide additional primitives or
+ extensions.
+
+vtex, by micropress, inc., forest hills, ny, has added a number of
+primitives. it reportedly has a "compatibility" switch that enables
+it to pass the trip test, but i've never had the opportunity to
+examine the evidence. the author, michael vulis, has said that
+vtex is *not* tex -- files using the extensions are not backward
+compatible. (see reference below.)
+
+among the new primitives are the following:
+ \aliasfont -- for substituting a scalable font for standard cm
+ \exec -- for adding new "commands" (primitives?) to vtex
+ additional keywords on the \font command:
+ slant, aspect, smallcaps, outline, shadow, gray, fillpattern
+probably more are described in the book by michael vulis, but i can't
+find my copy at the moment. the information given here appears in
+the tugboat article by vulis, "vtex enhancements of the tex language",
+11 #3 (sept. 1990), pp.429-434.
+
+ Do extended MF's exist (I'm aware of none) ?
+
+the vtex people have also created an implementation of mf that is
+advertised as being able to create "either bitmapped or scalable
+fonts".
+
+ What additions to the standard TeX kit exist (Roughly the following
+ programmes: weave, tangle, TeX, MF, gftopk, gftype, pktype, tftopl, pltotf,
+ dvitype, mft, vptovf, vftovp ... did I miss any? ) ?
+
+gftodvi is part of metafontware; a printed woven output of the four
+mfware programs (gftype, gftopk, gftodvi and mft) can be obtained
+from the tex users group as the publication texniques #13.
+
+along with the adaptation of type-1 (postscript) fonts to be used
+with tex, the pfa/pfb manipulation programs might be considered to
+be part of the font kit.
+ -- bb
+
+========================================================================
+Date: Tue, 17 May 1994 08:52:33 +0200
+Reply-To: NTS-L Distribution list <NTS-L@DHDURZ1.BITNET>
+From: Reino de Boer <sysrb@cs.few.eur.nl>
+Subject: Re: Survey: Existing extensions to TeX
+
+Hallo J"org,
+
+I think that patgen could be considered an addition to the standard TeX kit.
+
+Perhaps MetaPost can be considered an `extension' to MF.
+
+Regards -- Reino
+--
+Reino R. A. de Boer
+CS Dept, Faculty of Economics, Erasmus University Rotterdam
+email: sysrb@cs.few.eur.nl
+There exists a way to compile TeX (Knuth 1985).
+
diff --git a/info/digests/nts-l/9410 b/info/digests/nts-l/9410
new file mode 100644
index 0000000000..8ad407d1a8
--- /dev/null
+++ b/info/digests/nts-l/9410
@@ -0,0 +1,1187 @@
+========================================================================
+Date: Mon, 10 Oct 1994 18:05:48 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: FAQ: Differences to the last edition
+
+************
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;18
+ 3 Fourth edition
+ 4 Date: 10-OCT-1994
+ 5 Currently maintained by: knappen@vkpmzd.kph.uni-mainz.de (J%org Knappen)
+******
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+ 3 Third edition
+ 4 Date: 26-JAN-1994
+ 5 Currently maintained by: knappen@vkpmzd.kph.uni-mainz.de (J%org Knappen)
+************
+************
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;18
+ 24 under tex/info/tex-implementors. In addition, I recommend reading the
+ list
+ 25 of TeX bugs (tex-archive/systems/knuth/errata/tex82.bug).
+ 26
+******
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+ 24 under tex/info/tex-implementors.
+ 25
+************
+************
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;18
+ 61 8. Additions to the TeX kit
+ 62 8.1. dvicopy
+ 63 8.2. dvitodpl and dpltodvi
+ 64 8.3. gftotxt
+ 65 8.4. qdtexvpl
+ 66 8.5. fontinst
+ 67 8.6. afmtotfm
+ 68 9. Existing extensions to TeX
+ 69 9.1. TeX-XeT
+ 70 9.2. TeX--XeT
+ 71 9.3. MLTeX
+ 72 9.4. SiSiSi
+ 73
+******
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+ 60
+************
+************
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;18
+ 90 As of September 1994, there are two activities going on, the ETeX
+ group
+ 91 is working on a extension of TeX and is going to produce a first ETeX
+ soon.
+ 92 The NTS group takes the path to reimplement TeX in common LISP to get
+ 93 a deeper understanding of how the modules of TeX are cooperating which
+ 94 eachother.
+ 95
+ 96 Independently, the Omega project was launched to produce a typesetting
+ system
+ 97 which uses unicode as internal code and can handle arbitrarily encoded
+ input
+ 98 via filters.
+ 99
+ 100 The beforementioned projects were presented at the 1994 TUG meeting at
+ Santa
+ 101 Barbara and at the EuroTeX'94 conference at Gdansk. For more
+ information,
+ 102 consult the respective proceedings. For the Omega project exists a
+ mailing
+ 103 list, omega@ens.fr. To subscribe, send an e-mail to LISTSERV@ens.fr.
+ 104
+ 105 1. Proposed features of a New Typesetting system
+******
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+ 77 1. Proposed features of a New Typesetting system
+************
+************
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;18
+ 166 (one hyphen only). Allthough TeX will be frozen at version $\pi$,
+ 167 this is not true for TeX--XeT. (see also 9.2)
+ 168
+******
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+ 138 (one hyphen only).
+ 139 Allthough TeX will be frozen at version $\pi$, this is not true for
+ TeX--XeT.
+ 140
+************
+************
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;18
+ 390 \afterfi should be expandable, because \if...\fi is expandable.
+ 391
+******
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+ 362 (IMHO the \afterfi should be expandable, because \if...\fi is
+ expandable.)
+ 363
+************
+************
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;18
+ 734 8. Additions to the TeX kit
+ 735
+ 736 8.0. General
+ 737 The TeX kit, meaning the bundle of programmes building up a complete
+ TeX
+ 738 installation, contains besides the major programmes TeX and METAFONT
+ 739 additional programmes, traditionally divided into several groups:
+ 740
+ 741 a) TeXware: dvitype, tftopl, pltotf, pooltype, pktype, patgen, vftovp,
+ 742 vptovf, (outdated: pxtopk, pktopx)
+ 743 b) MFware: mft, gftodvi, gftopk, (outdated: gftopxl)
+ 744 c) webware: weave, tangle
+ 745
+ 746 And, of course, drivers for the screens and printers.
+ 747
+ 748 Other utility programmes more loosely associated with TeX are indexers
+ 749 (makeindex, idxtex, glotex, ...) and bibliography tools (bibtex,
+ 750 bibclean, ...). Makeindex and Bibtex are standard tools, because they
+ 751 are described in the LaTeX manuals.
+ 752
+ 753 8.1. dvicopy
+ 754 Written in WEB by Peter Breitenlohner
+ 755 Available from CTAN
+ 756 Resolves all references to virtual fonts in a dvi file. Can be used to
+ 757 create a dvi file without virtual fonts (e.g. for drivers which cannot
+ 758 handle vf's).
+ 759
+ 760 8.2. dvitodpl and dpltodvi
+ 761 Written in C by Geoffrey Tobin
+ 762 Available ?
+ 763 dvitodpl makes a human readable file from a dvi file. The companion
+ 764 programme dpltodvi makes a dvi file frome a dvi property list file.
+ 765 It allows you to change dvi files with a text editor.
+ 766
+ 767 8.3. gftotxt
+ 768 Written in C by Yannis Haralambous
+ 769 Available ?
+ 770 Extracts a certain kind of specials from the gf file into a text file.
+ 771 Workaround for the famous non-ability of METAFONT to write auxiliary
+ 772 files.
+ 773
+ 774 8.4. qdtexvpl
+ 775 Written by Eberhard Mattes
+ 776 Part of the emtex distribution (CTAN)
+ 777 Generates a virtual font from TeX macros. qd = quick and dirty.
+ 778
+ 779 8.5. fontinst
+ 780 Written in TeX by Alan Jeffrey
+ 781 Available form CTAN
+ 782 Makes virtual fonts from afm files (PostScript fonts). Used by the
+ LaTeX
+ 783 team to create virtual fonts and fd files for LaTeX2e.
+ 784
+ 785 8.6. afmtotfm
+ 786 Written in C by Thomas Rokicki
+ 787 Available from CTAN (part of dvips distribution)
+ 788 Makes tfm files from afm files.
+ 789
+ 790
+ 791 9. Existing extensions to TeX
+ 792
+ 793 9.0 General
+ 794 Here I include short description of existing extensions to TeX. This
+ section
+ 795 does not include commercial TeX implementations because of lack of
+ solid
+ 796 enough information on them. It also does not yet include ETeX, NTS,
+ nor
+ 797 Omega.
+ 798
+ 799 9.1. TeX-XeT (Don Knuth and Pierre MacKay)
+ 800 CTAN: tex-archive/systems/knuth
+ 801 Adds new primitives \beginR, \endR, \beginL, and \endL for right to
+ left
+ 802 typesetting. Despite their names, the new primitives are insensitive
+ to
+ 803 TeX's grouping mechanism. Outputs a special file in dvi-ivd format,
+ which
+ 804 need be resolved by another programme or requires special drivers.
+ 805
+ 806 9.2. TeX--XeT (Peter Breitenlohner)
+ 807 Available from CTAN tex-archive/systems/knuth/tex--xet
+ 808 Implements the same primitives as TeX-XeT, but outputs a normal dvi
+ file.
+ 809 Passes the trip test (as far as I know).
+ 810
+ 811 9.3. MLTeX (Michael Ferguson)
+ 812 Available from aldebaran.ee.mcgill.ca in pub/mltex
+ 813 Adds a primitive \charsubdef, which allows the following: input of
+ 8-bit
+ 814 characters, participation of accented characters not present in the
+ output
+ 815 encoding in hyphenation, ligatures and kerning with accented letters.
+ 816 Especially popular in francophone countries.
+ 817 emTeX supports MLTeX via the /ml option.
+ 818
+ 819 9.4. SiSiSi (Wilhelm Barth, Heinrich Nirschl, Heini Hofstaedter und
+ Harald
+ 820 Mueller)
+ 821 Available from CTAN: tex-archive/systems/vms (sic!)
+ 822 Implements another hyphenation algorithm (the name means SIchere
+ 823 SInnentsprechende SIlbentrennung, which is translated `secure
+ sensitive
+ 824 hyphenation') specific to the german language (with Haupt- und
+ 825 Nebentrennstellen). Fails the trip test, therefore not a legitimate
+ TeX.
+ 826 In use at TU Wien (Austria).
+ 827
+ 828 The End.
+******
+File $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+ 706 The End.
+************
+
+Number of difference sections found: 7
+Number of difference records found: 128
+
+DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=$DISK2:[KNAPPEN.NTS]FAQ.DIFF;1-
+ $DISK2:[KNAPPEN.NTS]FAQ.TXT;18-
+ $DISK2:[KNAPPEN.NTS]FAQ.TXT;16
+
+========================================================================
+Date: Mon, 10 Oct 1994 18:03:48 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: Frequently asked questions -- 4th edition
+
+ Frequently Asked Questions of NTS-L
+
+Fourth edition
+Date: 10-OCT-1994
+Currently maintained by: knappen@vkpmzd.kph.uni-mainz.de (J%org Knappen)
+
+Remark about the format:
+
+This faq is divided into several sections and subsections. Each section
+contains a subsection general with some ideas which have not yet been
+discussed. I added a date to some subsections to allow you to retrieve
+fuller discussions from the archives. The transactions of this group are
+archived on
+
+ ftp.th-darmstadt.de [130.83.55.75] *)
+ directory pub/tex/documentation/nts-l
+
+Each file in this directory is named yymm, where (guess :-) yy is the
+year and mm is the month when the mail arrived. (I.e., all postings
+of one month are bundled in one file.)
+*) Avoid using the number above ... it is subject to changes.
+
+Related stuff which is very worth reading you can find on the CTAN archives
+under tex/info/tex-implementors. In addition, I recommend reading the list
+of TeX bugs (tex-archive/systems/knuth/errata/tex82.bug).
+
+-1. Contents
+
+0. About NTS
+1. Proposed features of a New Typesetting system
+1.1. Improvement of Quality
+1.2. Internationality
+1.3. New Look and Feel
+1.4. Changing the ligaturing algorithm
+2. Proposed additions to TeX (concrete new primitives)
+2.1. \lastmark etc.
+2.2. \system
+2.3. \skylineskiplimit, \skylinehorizontallimit
+2.4. \directioncode
+2.5. \textcode
+2.6. \afterfi
+2.7. \interactionmode
+2.8. \mathspacing
+2.9. \inputescapechar
+2.10. \middle
+2.11. \outputunit
+3. Metaremarks
+3.1. TeX is not perfect
+3.2. In which language shall NTS be written
+3.3. The TeX language
+3.4. The TeX engine
+4. Deviations
+4.1. Automated Kerning
+4.2. About Lout
+5. Proposed changes to METAFONT
+5.1. Writing to auxiliary files
+6. Proposed changes to the tfm file format
+6.1. Vertical kerning
+6.2. Cross-font ligatures
+7. Proposed changes to the dvi file format
+8. Additions to the TeX kit
+8.1. dvicopy
+8.2. dvitodpl and dpltodvi
+8.3. gftotxt
+8.4. qdtexvpl
+8.5. fontinst
+8.6. afmtotfm
+9. Existing extensions to TeX
+9.1. TeX-XeT
+9.2. TeX--XeT
+9.3. MLTeX
+9.4. SiSiSi
+
+0. About NTS (Mar 93, see also Jul 92)
+
+ At DANTE '93, held at the Technical University Chemnitz last week, Joachim
+ Lammarsch, President of Dante, announced that the NTS project which had been
+ started under the aegis of DANTE, was to be re-formed under a new
+ co-ordinator, Philip Taylor. The old core group, announced at the previous
+ annual DANTE meeting, was to be dissolved, and a new core group established.
+ Membership of the new core group will not be restricted to DANTE members,
+ but will instead be offered to various well-known names (and some
+ lesser-known!) in the international TeX community.
+
+ see also:
+ F. Mittelbach: E-TeX Guidelines for future TeX, TUGboat v11n3 (1990)
+ P. Taylor: The future of TeX, EuroTeX'92 Prag (Proceedings); reprinted
+ in TUGboat v13n4, 433 (1992)
+
+ As of September 1994, there are two activities going on, the ETeX group
+ is working on a extension of TeX and is going to produce a first ETeX soon.
+ The NTS group takes the path to reimplement TeX in common LISP to get
+ a deeper understanding of how the modules of TeX are cooperating which
+ eachother.
+
+ Independently, the Omega project was launched to produce a typesetting system
+ which uses unicode as internal code and can handle arbitrarily encoded input
+ via filters.
+
+ The beforementioned projects were presented at the 1994 TUG meeting at Santa
+ Barbara and at the EuroTeX'94 conference at Gdansk. For more information,
+ consult the respective proceedings. For the Omega project exists a mailing
+ list, omega@ens.fr. To subscribe, send an e-mail to LISTSERV@ens.fr.
+
+1. Proposed features of a New Typesetting system
+
+1.1. Improvement of Quality
+
+1.1.0 General:
+ Optimised page breaking, avoiding ``rivers'', letterspacing (see also 4.1),
+ Hyphenation (Haupt- und Nebentrennstellen), grid typesetting
+
+1.1.1 Skyline approach to line breaking (Mar 93)
+
+You can break paragraphs as usual with the current model, where all
+lines are simple rectangular boxes. If there's no necessity to insert
+\lineskip, then you don't have to look at the skyline. Only if two
+lines are too near (e.g. distance<\lineskiplimit), you have to look
+into the two rectangular boxes and to check if the boxes inside
+overlap at one or more places.
+For the worst case (i.e., you have to look at the skyline for all
+pairs of lines) processing the skyline model consumes a lot of process
+time, but this shouldn't hinder us to test this idea and look at the
+results.
+
+Btw, the skyline model seems to be easy to implement in the current
+TeX, because we need only some changes when the finally broken lines
+of the paragraph are put on the vertical list. There are more changes
+needed in the code, if the line break should be changed for the cases
+where it is possible to avoid an overlap with other break points, but
+IMHO it's nonetheless a relatively small change.
+
+Additionally you have to introduce some new parameters. I think of
+something like:
+ \skylineskiplimit (b)
+ minimum vertical distance between two boxes
+ \skylinehorizontallimit (a)
+ minimum horizontal distance
+
+
+line 1: ------------
+ : :
+ : : ----------
+ ------- <== (a) ==> : :
+ ^ : :
+ (b) : -------
+ v :
+ ----------------------
+line 2:
+
+and other parameters, but the necessary parameter set, realization,
+etc. for "skylines" are subject of discussion.
+
+
+1.2. Internationality
+
+1.2.0 General:
+ Typesetting in arbitrary directions, unicode support (16bits), ISO10646
+ support (32bits), ligatures pointing to other fonts, vertical kerning,
+ better accent handling (\topaccent and \botaccent)
+
+1.2.1 Supporting TeX--XeT primitives for right to left typesetting
+ TeX--XeT is an existing extension to TeX supporting right-to-left
+ typesetting an producing a usual dvi-file. TeX--XeT is written by
+ P. Breitenlohner and freely available. It is different from TeX-XeT
+ (one hyphen only). Allthough TeX will be frozen at version $\pi$,
+ this is not true for TeX--XeT. (see also 9.2)
+
+1.3. New Look and Feel
+
+1.3.0 General
+ Windows support, wysiwyg-like features
+
+1.3.1 Interaction with the operating system and other programmes
+ see 2.2. \system
+
+1.4. Changing the ligaturing algorithm
+ Replace the (IMHO over-)optimized ligature builder/kerning routines in
+ TeX by routines which separate between the building of ligatures and
+ the insertion of kerns between the characters/ligatures.
+
+ This can be realized in a simple way by using two passes: in the
+ first pass the ligatures are built and in the second pass the
+ resulting ligatures and remaining single characters are used to
+ determine the necessary kerns.
+
+ To ensure compatibility between e-TeX and TeX, it will be possible to
+ switch between the new and the current behaviour.
+
+ Additionally a flag in the TFM file of each font can be used to
+ specify which behaviour is to be used for the font. This ensures that
+ "old" fonts with some tricky ligature/kerning programs depending on
+ the old behaviour can still be used with e-TeX. (I don't know if this
+ font dependent switching is really necessary. Comments, please!!)
+
+ Example:
+
+ A font contains the following ligatures and kerns:
+
+ o " => ligature (o") (= \"{o})
+ V o => kern(-smallkern)
+ V lig(o") => nothing
+
+ Input: V o "
+ Output of current TeX: V kern(-smallkern) ligature(o")
+ Output with change: V ligature(o")
+
+ Status:
+
+ Bernd Raichle has written a simple, but running reimplementation of TeX's
+ ligature/kerning routine (in CommonLisp), which still waits to be
+ rewritten as a TeX.web change file.
+ The ligature builder/kerning routine is realized in one pass; kerns
+ are introduced in a delayed manner, i.e., after we are sure that
+ there's no possibility for a ligature.
+ Additionally there's a switch between the current TeX and the new
+ behaviour. (The TRIP test fails with the new behaviour.)
+
+PS: IMHO the ligature/kerning routines should be further changed to
+ remove the `shelf{}ful' anomaly (see TeXbook, exercise 5.1), i.e.,
+ reinserting ligatures when words are hyphenated.
+ The change should allow ligatures for inputs like `f{}f' or
+ `f\relax f', which will simplify the macros in `german.sty',
+ Babel and changed macros for \", \', ... which are used to select
+ characters from DC fonts or other fonts with national characters.
+
+2. Proposed additions to TeX (concrete new primitives)
+
+2.0. General (Jun 92, Jul 92, Aug 93)
+ A rather long list of proposed primitives (more or less worked out) was
+ posted by Karl Berry on 10-Jun-1992. It contains suggestions like:
+ \elseif (selfexplaining), \format{foo} (allow the author to select a format),
+ \host{name} \host{os} \host{type} \getenv to extract host information
+ \TeXversion, \usertime, \everyeof, and others.
+
+ It is currently not possible to get some information about the current
+ mode of TeX and make conditionals dependent on it and/or restore it after
+ some action (see 2.7. \interactionmode)
+
+ More of this kind are a conditional or primitive to signal, when TeX is
+ in "expand only" mode (\edef, \mark, \write, ...), when TeX is
+ scanning numbers (here I'm thinking---and hating---german.sty's active
+ doublequote, which can also be used as a marker for hexadecimal
+ numbers), when TeX is peeking for some special tokens (first column in
+ an \halign), etc...
+
+2.1. \lastmark etc. (Jun 92, Jul 92)
+ Currently you cannot remove a \write or \mark or
+ \insert or rule from any list at all. If we allow them to removed, how
+ will the commands appear to the user? If we have \lastmark like
+ \lastbox, then perhaps we need a mark data type so that we can say something
+ like \setmark0=\lastmark. It will probably be difficult
+ in the case of \insert's to think of a good command syntax.
+
+ Perhaps \lastpenalty, \lastkern, \lastskip should
+ remove the penalty, kern, skip, ... so that they are consistent with
+ \lastbox. Then \unpenalty, \unkern, and \unskip would be unnecessary.
+ (Of course most macro packages would probably want to reimplement them,
+ as macros: \def\unpenalty{\count@\lastpenalty},
+ \def\unkern{\dimen@\lastkern}, \def\unskip{\skip@\lastskip}.)
+
+2.2. \system (Mar 93)
+
+2.2.0 General
+ Oops, this got rather longish, but this topic has caused plenty of traffic.
+ I decided to quote directly the positions of both sides. The subpoints are
+ 1. Pro 2. Contra 3. Syntax
+
+2.2.1 Pro
+ First comes the proposal as formulated by Phil Taylor:
+
+ There has been much discussion on how a \system primitive might interact
+ with different operating systems, each with different functionality and a
+ different syntax. My idea was to extend the concept of a `TeX
+ implementation', which at the moment implies the creation and application
+ of a change-file to the master TeX source, to include an implementation-
+ specific macro library. Thus each implementor, as well as creating and
+ applying a change file, would also be responsible for mapping a well-defined
+ set of macros, through the \system primitive, to the syntax and
+ functionality of the operating system for which he or she has assumed
+ responsibility. To cite a specific example:
+
+ Assume that in e-Lib (a hypothetical macro library to accompany e-TeX),
+ a macro \sys$delete_file {<parameters>} is partially defined; then each
+ implementor would be responsible for mapping \sys$delete_file {<parameters}>
+ to his or her own implementation of \system. e-Lib would define the effect
+ and the result(s), \system would provide the interface, and the implementor
+ would be responsible for providing the mapping.
+
+ The question has been asked: ``Why via \system and macros? Why not via
+ explicit primitives to carry out the various functions that are envisaged?''
+
+ To which I would suggest that the answer is ``Because `the various functions
+ which are envisaged' is both enormous (requiring many new primitives), and
+ yet not large enough (because no matter what functionality we posit, someone
+ will come up with an idea that has not been considered).'' By implementing
+ just one \system primitive, and an extensible e-Lib macro library, one can
+ create a robust and well-tested e-TeX whilst allowing new system interactions
+ to be added at the simplest points: through the implementation-independent
+ and implementation-specific components of e-Lib.
+
+2.2.2 Contra
+ And here's from the ``Minority Report'' (Tim Murphy and J"org Knappen)
+
+ May I recall the immortal words of Ken Thompson,
+ "A program should do one thing, and do it well." (TM)
+
+ I don't like the hackers to decide, making eTeX yet another programme from
+ which I can send e-mail and read news :-) Maybe people will tell me eTeX is
+ a fine operating system, but TeX version $\pi$ is the better typesetter :-)
+
+ But there is another side of \system, I want to call it the monstrosity
+ side. Many people are thinking now, that TeX is a monster and difficult to
+ tame. \system will add to this monstrosity. It will create a new paradise
+ for hackers creating system hacks. And it will make people turn away from
+ eTeX and use other products, even if they are far less secure. (JK)
+
+2.2.3 Syntax
+ If a \system command is required, should it not have a similar syntax
+ and semantics to the a similar TeX command. I can't think of anything
+ else in TeX (prepares to be shown wrong) that expands in the mouth and
+ has side-effects. Should it not be like \read, \write etc. that is it
+ generates a whatsit that is obeyed at shipout, unless preceded by an
+ \immediate, in which case it is done immediately by the stomach.
+ There seem to be two obvious syntaxes, one like \write:
+ \system{foo} or \immediate\system{foo}
+ and one like \read:
+ \system{foo} to \baz or \immediate\system{foo} to \baz
+ The latter one would produce the exit code into \baz. Should this be
+ done with catcode 12 characters, or should it be done like \read, with
+ the current catcodes?
+
+2.3. \skylineskiplimit, \skylinehorizontallimit
+ see section 1.1.1
+
+2.4. \directioncode (May 1993)
+ A \directioncode (with syntax analogous to \uccode, \lccode, sfcode) to be
+ assigned to each input character. The basic ones are
+ 0 -- transparent (space, full stop...)
+ 1 -- left-to-right (latin letters, digits...)
+ 2 -- right-to-left (hebrew letters, arab letters...),
+ a truly international NTS will also have codes for vertical typesetting
+ and some special cases.
+
+ The question is how to use this idea consistently. One could extend the
+ notion of TeX's modes. Horizontal mode is in fact left-to-right mode, a
+ right-to-left mode is missing. To be complete, this mode will be equipped
+ with boxen and all the stuff TeX's left-to-right (aka horizontal) mode has.
+
+ At the beginning of a paragraph NTS decides which mode to choose by the
+ \directioncode of the first input character. Sometimes the first character
+ will have the wrong code, in this case the insertion of an explicit
+ control sequence (like \lrbox{}) is necessary. If a character with another
+ directioncode occurs, NTS starts a \rlbox and finishes it as soon as a
+ character with the original \directioncode appears or at the end of the
+ paragraph.
+
+ For the building of right-to-left tables a \rlalign is needed.
+
+2.5. \textcode (Sep 93, Nov 93)
+ Some of the character coding discussions in the Technical Working
+ Group on Multiple Language Coordination and some experiences I've made
+ with `german.sty' (specially the problems with an active doublequote
+ and hex integer constants!) lead to this _incomplete_ proposal/idea
+ for the following addition:
+ Introduce something like
+ \textcode (and \textchar & \textchardef)
+ which are the text (hmode) equivalent of TeX's \mathcode (and
+ \mathchar/\mathchardef) primitives.
+
+ With an equivalent and appropriate implemented \textcode primitive
+ (with the choice to define a character as "pseudo-active"), it would
+ be possible to
+ * relate characters to different fonts
+ (using a generalized `fam' of \mathcode)
+
+ * suppress expansion of active characters (it will only be
+ expanded, if it is read to form the hlist)
+ (using an equivalent \mathcode="8000 value)
+ [This point allows the use of e.g. a pseudo-active "
+ which expands to non-expandable tokens and it removes
+ the special construct \relax\ifmmode... for active
+ characters, too.]
+
+2.6. \afterfi (August 1993)
+ In the answer to an exercise of the ``Around the Bend'' series, Michael Downes
+ realised the non-existence of an \afterfi primitive (Note: He did not
+ demand it nor really miss it). Perhaps an \afterfi can
+ simplify some obscure mouth-only macros with nested conditionals???
+ \afterfi should be expandable, because \if...\fi is expandable.
+
+2.7. \interactionmode (Nov 93, was: \currentinteractionmode)
+ Add a new count register \interactionmode, which reflects the user
+ interaction level with the following values:
+ <= 0 batch_mode
+ = 1 nonstop_mode
+ = 2 scroll_mode
+ >= 3 error_stop_mode
+
+ The commands \batchmode...\errorstopmode, the "options" 'Q', 'R', 'S'
+ in the interactive error routine and all other TeX internal
+ interaction level changes (e.g. after an interruption) access this new
+ register. The level changes in the interactive error routine and the
+ old commands should always work, even if the symbol \interactionmode is
+ redefined (this means that the user can redefine \interactionmode, but the
+ commands \batchmode...\errorstopmode still work).
+
+ Examples:
+
+ \ifnum\interactionmode<1 \AskUser \else \UseDefault \fi
+
+ {\interactionmode=0 % switch to \batchmode
+ \global\font\test=xyz10 % try to load font
+ }% % restore former interaction level
+ % ... now test if font has been loaded
+ % without error (i.e. != nullfont)
+
+ Status:
+
+ Bernd Raichle has made and implemented the necessary changes in his local
+ TeX version. They have to be tested and checked for forgotten things.
+
+2.8. \mathspacing (Nov 93)
+ Add a new count register array \mathspacing with 64 entries (we really
+ need only 64-8=56 entries, because some of them are never used, but to
+ simplify things 64 are used) with the following syntax:
+
+ \mathspacing <num1>=<num2> % 0 <= <num1> <= 63
+
+ The spacing specified in number <num2> is inserted between the two
+ math atom types specified in number <num1>. The two numbers are coded
+ as
+
+ <num1> = <left_atom_type> * 8 + <right_atom_type>
+ <num2> = ( (<display_spacing> * 256 + <text_spacing>) * 256
+ + <script_spacing> ) * 256 + <scriptscript_spacing>
+
+ This means that <num1> is easily expressed in octal and <num2> in
+ hexadecimal notation.
+
+ <..._atom_type> is one of the following seven types:
+
+ 0 ordinary 1 large operator
+ 2 binary operation 3 relation
+ 4 opening 5 closing
+ 6 punctuation 7 delimited subformula
+
+ <..._spacing> can be specified separately for each of the four math
+ styles (display, text, script and scriptscript) with the following
+ values:
+
+ 0 no space
+ 1 thin space (specified by \thinmuskip)
+ 2 medium space ( -- " -- \medmuskip)
+ 3 thick space ( -- " -- \thickmuskip)
+
+ 4-255 reserved for other things
+ (e.g. other spacings and/or additional penalties,
+ like \relpenalty, \binoppenalty, ...)
+
+ For more information see TeXbook, pp. 170f & Appendix G and TeX--The
+ Program, \S 764ff.
+
+ Examples: (using TeX's standard spacing)
+
+ Between an `ordinary' (= 0) and a `relation' (= 3) atom a thick
+ space (= 3) is inserted, but not in script or scriptscript style.
+
+ \mathspacing '03 = "0033
+
+ Between a large operator (= 1) and an ordinary (= 0) atom a thin
+ space (= 1) is inserted:
+
+ \mathspacing '10 = "1111
+
+ Status:
+
+ Necessary changes for the sketched proposal are very simple to
+ implement.
+ The syntax of \mathspacing is awful, but this is true for \mathcode,
+ \delimitercode, etc.etc., too.
+
+2.9. \inputescapechar (Nov 93, alternative names were proposed during
+ discussion)
+ Use two new internal count registers \inputescapechar and
+ \outputescapechar to specify the "escape" character to be used for
+ unprintable characters.
+ If \inputescapechar is not in [0..255], TeX's behaviour is used,
+ i.e., two equal characters with category 7 are used as a prefix for a
+ ^^x notated character, otherwise two characters with code
+ \inputescapechar are used for this prefix.
+ If \outputescapechar is not in [0..255], the character `^' is used
+ when an unprintable character has to be written.
+
+ The default values of these two registers are
+ \inputescapechar = -1
+ \outputescapechar = `^
+ to be compatible with TeX's standard behaviour.
+
+ Problems:
+
+ What's the behaviour of e-TeX when the \outputescapechar is
+ unprintable for this TeX implementation (remember that it is only
+ necessary that a subset of ASCII is printable; more in TeXbook, end of
+ Appendix C), e.g.,
+ \outputescapechar=`^^M
+ Do we really want to make this possible? How to prevent such
+ situations (e.g. by restricting the values of \outputescapechar to a
+ subset of ASCII, which is printable for all TeX implementations)?
+
+ Relation between \newlinechar and \outputescapechar?
+ IMO \outputescapechar (and all other characters in the ^^x notation
+ for an unprintable character) should never result in a written
+ newline, which is TeX's behaviour for versions >= 3.141.
+
+ Status:
+
+ The necessary changes are simple (for TeX version >= 3.141). I have
+ made changes for \outputescapechar in my local TeX version to allow
+ the specification of all printable characters in a "TeX code page"
+ definition (the \outputescapechar register changes are the only thing
+ needed to complete the change).
+ The problems mentioned above have to be discussed before e-TeX can
+ contain this extension.
+
+2.10. \middle (Jan 94)
+ Generalize the syntax of \left<delimiter> <formula> \right<delimiter>
+ to allow one or more optional \middle delimiters,
+ \left<delimiter> <formula> \middle<delimiter> <formula> \right<delimiter>.
+
+ The middle delimiter grows to the same height as the left and right ones.
+ Constructions of this kind are used throughout quantum mechanics (Dirac
+ notation), e.g.
+ $$
+ \left\langle A \middle: \hat{O} \middle: B \right\rangle
+ $$
+ By default, the \middle element is \mathrel, you can make it
+ \mathord by embracing it {\middle :}.
+
+
+2.11. \outputunit (Dec 93)
+ \outputunit unit to be used when e-TeX shows some dimen or glue
+ value
+ Usage: \outputunit=<unit of measure> (s. TeXbook p. 270)
+ Rationale:
+
+ Currently TeX forces the user to think in points when it outputs any
+ dimen or glue value (e.g. when issueing an overfull hbox warning).
+ But a program should adapt to the conventions of the user instead the
+ other way round. The addition of \outputunit whould make TeX much
+ more user-friendly, since only a few people are thinking in points.
+
+3. Metaremarks
+
+3.0. General
+ Remarks about group efforts vs. one person creating software (Mar 93),
+ ALGOL 68 as a warning example
+
+3.1. TeX is not perfect (Jun 92, Jul 92)
+ The discussion has taken place in June and July 1992. Several details were
+ worked out, where TeX could be improved. Another point of criticism was
+ the programming language of TeX in general, several participants prefer a
+ procedural language over a macro language.
+
+3.2. In which language shall NTS be written (Mar 93)
+ In 1992, there was much discussion, in which language an NTS should be
+ implemented (candidates were LISP, C, and WEB). This has settled in March
+ 1993 (to PASCAL-WEB), because of the acceptance of the
+ idea that rather than wait for an ``all-singing, all dancing'' NTS, the
+ group should develop, in a stepwise manner, small but significant
+ enhancements to TeX. This implies that the enhancements are implemented as
+ change files in WEB.
+
+3.3. The TeX language (Oct/Nov 93)
+ The TeX language is a simple language in the sense, that it contains only
+ few concepts. It belongs to the Lisp family. In particular, it's a
+ list-based macro language with late binding. Actually, that's all one
+ needs to say to characterize it.
+ Its data constructs are simpler than in Common Lisp: `token list' is the
+ only first order type. Glue, boxes, numbers, etc., are engine
+ concepts; instances of them are described by token lists.
+ Its lexical analzsis is simpler than CL: One cannot program
+ it. One can only configure it.
+ Its control constructs are simpler than in CL: Only macros, no
+ functions. And the macros are only simple ones, one can't compute
+ in them.
+
+3.4. The TeX engine (Oct/Nov 93)
+ The TeX engine lies below the TeX language. Glue, boxes, numbers, etc.
+ belong to the TeX engine. The registers of the engine can be changed
+ by TeX's primitives. However, those seem to be quite unregular and
+ baroque.
+
+4. Deviations
+
+4.0. General
+ (empty)
+
+4.1. Automated Kerning (Oct 92)
+ Kindersley's "optical kerning": for the purposes of
+ kerning, each character is replaced by a circle centred on the centre of
+ gravity of that character; the radius of the circle is determined by the
+ fourth moment of the character (that is, the fourth root of the sum over
+ all black pixels of the fourth power of their distance from the centre). On
+ the UKTUG trip to Kindersley's studio, I tried to extract the reason why
+ the fourth, as opposed to third or fifth or whatever, moment is used; the
+ reason is apparently that it "looks right".
+
+ We can construct elaborate schemes for kerning (Kindersley's fourth
+ moments, FontStudio's (convex?) envelopes, Calamus' eight widths, etc), but
+ the proof of the typographical pudding is in the eating of the resulting
+ words, so to speak.
+
+4.2 About Lout (June 1993)
+ In June 1993, the new system Basser Lout caused several questions and
+ suggestions on this list. The following is taken from a short review
+ of Lout by Bernd Raichle:
+
+ `Lout' is a (yet another) document formatting system, released under
+ the terms of the GNU General Public License and available on some ftp
+ servers.
+
+ IMHO it's more like a `troff' (with a better input language and some
+ newer concepts) than a `TeX'.
+
+ A few citations from the documentation of lout:
+
+ Lout is a high-level language for document formatting, designed and
+ implemented by the author. The implementation, known as Basser
+ Lout, is a fully operational production version written in C for the
+ Unix operating system, which translates Lout source code into
+ PostScript, a device-independent graphics rendering language
+ accepted by many high-resolution output devices, including most
+ laser printers.
+ [...]
+ When expert users can implement such applications quickly,
+ non-experts benefit. Although Lout itself provides only a small
+ kernel of carefully chosen primitives,
+
+ Lout has 23 primitive operators... missing, for example, the simplest
+ arithmetical operators (there is only the operator "@Next" which
+ increases a number by one).
+
+ packages written in Lout and distributed with Basser Lout provide an
+ unprecedented array of advanced features in a form accessible to
+ non-expert users. The features include rotation and scaling, fonts,
+
+ These features are mostly based on the output language... Postscript
+ (if you are looking inside a Lout package, you find large portions of
+ embedded Postscript code).
+
+ paragraph and page breaking,
+
+ TeX does a better job for these two items, because Lout is missing
+ most of TeX's paragraph/page breaking parameters. (Note: Lout uses
+ TeX's hyphenation algorithm and the hyphenation patterns.)
+
+ displays and lists, floating figures and tables, footnotes, chapters
+ and sections (automatically numbered), running page headers and
+ footers, odd-even page layouts, automatically generated tables of
+ contents, sorted indexes and reference lists, bibliographic and
+ other databases (including databases of formats for printing
+ references), equations, tables, diagrams, formatting of Pascal
+ programs, and automatically maintained cross references.
+
+ TeX's math setting abilities are better. Lout uses a package named
+ `eq' derived from the `eqn' preprocessor used with `troff'. And there
+ are other packages named `tab' (for tabulars) and `fig' (drawing
+ figures).
+
+ [...]
+ Lout is organized around four key concepts -- objects, definitions,
+ galleys, and cross references -- [...]
+
+ The concept of `galleys' and the "expansion" of recursive defintions
+ are IMHO the only new concept in Lout:
+
+ `galleys' are a way to describe a page, dividing it in certain regions
+ which can be filled from different sources (e.g. a footnote galley is
+ filled with footnote text, etc.).
+
+ Recursive definitions are very simple, e.g.
+ def @Leaders { .. @Leaders }
+ defines the command (Lout calls it `object') to "expand" to a `..' and
+ if there is place for another "expansion" it is called again.
+
+ For example
+ \hbox to 4in{Chapter 7 \dotfill 53}
+ is in Lout
+ 4i @Wide { Chapter 7 @Leaders 53 }
+
+ With this recursive definitions, a whole document is defined as a
+ @PageList consisting of a @Page and a @PageList with an incremented
+ @PageNum. A @Page is defined as a set of `galleys' (header, text
+ body, footnotes, footer), which are also defined as a list of
+ text/footnotes/... and so on.
+
+ Perhaps others can add more impressions, mine are based on the
+ documentation coming with the Lout package and some tests done in
+ 1-2 hours.
+
+5. Proposed changes to METAFONT
+
+5.O. General
+ Most of the General points in the discussion of TeX also apply to METAFONT.
+
+5.1. Writing to auxiliary files
+ METAFONT should be able to write to auxiliary files. Desparately needed
+ for packages which allow to draw figures in METAFONT and label them in TeX
+ (BoF session at EuroTeX '92, Prague).
+
+
+6. Proposed changes to the tfm file format
+
+6.1. Vertical kerning (Jun 92)
+ This may sound exotic to you, but the AFM format can do
+ it. And I desperately need it for non-Latin alphabets (everytime I need
+ a character in a ligature raised or lowered, I have to reserve a position
+ in the font for it).
+
+6.2. Cross-font ligatures (Jun 92)
+ Ligatures pointing to other fonts!! Yes, imagine for example that your
+ 256 chars are full, you could still access characters by ligatures...but
+ they have to be in the same font.
+
+7. Proposed changes to the dvi file format
+
+7.0. General
+ A longer discussion about colour inclusion into the dvi-file occured in
+ Oct/Nov 93. The outcome was, that high-quality colour handling is a difficult
+ and device dependent task, better left to the printer driver. Colour can be
+ handled by the \special command which is sent directly to the driver.
+
+8. Additions to the TeX kit
+
+8.0. General
+ The TeX kit, meaning the bundle of programmes building up a complete TeX
+ installation, contains besides the major programmes TeX and METAFONT
+ additional programmes, traditionally divided into several groups:
+
+ a) TeXware: dvitype, tftopl, pltotf, pooltype, pktype, patgen, vftovp,
+ vptovf, (outdated: pxtopk, pktopx)
+ b) MFware: mft, gftodvi, gftopk, (outdated: gftopxl)
+ c) webware: weave, tangle
+
+ And, of course, drivers for the screens and printers.
+
+ Other utility programmes more loosely associated with TeX are indexers
+ (makeindex, idxtex, glotex, ...) and bibliography tools (bibtex,
+ bibclean, ...). Makeindex and Bibtex are standard tools, because they
+ are described in the LaTeX manuals.
+
+8.1. dvicopy
+ Written in WEB by Peter Breitenlohner
+ Available from CTAN
+ Resolves all references to virtual fonts in a dvi file. Can be used to
+ create a dvi file without virtual fonts (e.g. for drivers which cannot
+ handle vf's).
+
+8.2. dvitodpl and dpltodvi
+ Written in C by Geoffrey Tobin
+ Available ?
+ dvitodpl makes a human readable file from a dvi file. The companion
+ programme dpltodvi makes a dvi file frome a dvi property list file.
+ It allows you to change dvi files with a text editor.
+
+8.3. gftotxt
+ Written in C by Yannis Haralambous
+ Available ?
+ Extracts a certain kind of specials from the gf file into a text file.
+ Workaround for the famous non-ability of METAFONT to write auxiliary
+ files.
+
+8.4. qdtexvpl
+ Written by Eberhard Mattes
+ Part of the emtex distribution (CTAN)
+ Generates a virtual font from TeX macros. qd = quick and dirty.
+
+8.5. fontinst
+ Written in TeX by Alan Jeffrey
+ Available form CTAN
+ Makes virtual fonts from afm files (PostScript fonts). Used by the LaTeX
+ team to create virtual fonts and fd files for LaTeX2e.
+
+8.6. afmtotfm
+ Written in C by Thomas Rokicki
+ Available from CTAN (part of dvips distribution)
+ Makes tfm files from afm files.
+
+
+9. Existing extensions to TeX
+
+9.0 General
+ Here I include short description of existing extensions to TeX. This section
+ does not include commercial TeX implementations because of lack of solid
+ enough information on them. It also does not yet include ETeX, NTS, nor
+ Omega.
+
+9.1. TeX-XeT (Don Knuth and Pierre MacKay)
+ CTAN: tex-archive/systems/knuth
+ Adds new primitives \beginR, \endR, \beginL, and \endL for right to left
+ typesetting. Despite their names, the new primitives are insensitive to
+ TeX's grouping mechanism. Outputs a special file in dvi-ivd format, which
+ need be resolved by another programme or requires special drivers.
+
+9.2. TeX--XeT (Peter Breitenlohner)
+ Available from CTAN tex-archive/systems/knuth/tex--xet
+ Implements the same primitives as TeX-XeT, but outputs a normal dvi file.
+ Passes the trip test (as far as I know).
+
+9.3. MLTeX (Michael Ferguson)
+ Available from aldebaran.ee.mcgill.ca in pub/mltex
+ Adds a primitive \charsubdef, which allows the following: input of 8-bit
+ characters, participation of accented characters not present in the output
+ encoding in hyphenation, ligatures and kerning with accented letters.
+ Especially popular in francophone countries.
+ emTeX supports MLTeX via the /ml option.
+
+9.4. SiSiSi (Wilhelm Barth, Heinrich Nirschl, Heini Hofstaedter und Harald
+ Mueller)
+ Available from CTAN: tex-archive/systems/vms (sic!)
+ Implements another hyphenation algorithm (the name means SIchere
+ SInnentsprechende SIlbentrennung, which is translated `secure sensitive
+ hyphenation') specific to the german language (with Haupt- und
+ Nebentrennstellen). Fails the trip test, therefore not a legitimate TeX.
+ In use at TU Wien (Austria).
+
+The End.
+
+========================================================================
+Date: Tue, 11 Oct 1994 09:25:23 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Robin Fairbairns <Robin.Fairbairns@CL.CAM.AC.UK>
+Subject: Re: Frequently asked questions -- 4th edition
+In-Reply-To: J%org Knappen's message of "Mon,
+ 10 Oct 1994 18:03:48 BST."
+ <"swan.cl.cam.:181900:941011054028"@cl.cam.ac.uk>
+
+J%org gives an ftp address for the FAQ; I would propose that it ought
+also to be available via CTAN.
+
+What do others think? An appropriate place would seem to me to be
+info/NTS-FAQ, not (since it's not a current product) help/NTS-FAQ
+where the TeX-FAQ is.
+
+Robin Fairbairns
+
+Robin (Campaign for the Third Programme) Fairbairns rf@cl.cam.ac.uk
+U of Cambridge Computer Lab, Pembroke St, Cambridge CB2 3QG, UK
+Private page: http://www.cl.cam.ac.uk/users/rf/robin.html
+
+========================================================================
+Date: Tue, 11 Oct 1994 08:34:27 CDT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "George D. Greenwade" <bed_gdg@SHSU.EDU>
+Subject: Re: Frequently asked questions -- 4th edition
+
+On Tue, 11 Oct 1994 09:25:23 +0100, Robin Fairbairns
+<Robin.Fairbairns@cl.cam.ac.uk> posted:
+> J%org gives an ftp address for the FAQ; I would propose that it ought also
+> to be available via CTAN.
+>
+> What do others think? An appropriate place would seem to me to be
+> info/NTS-FAQ, not (since it's not a current product) help/NTS-FAQ where the
+> TeX-FAQ is.
+
+I honestly don't know what the NTS-FAQ document is, but my suspicion is
+that it answers questions about NTS and not the CTAN. If so, it belongs in
+info/ (originally named documentation/) and not help/. The purpose of
+help/ is for documentation and assistance about the CTAN itself. Looking
+through the TWG-TAG discussions some time back, the TeX-FAQ was placed in
+help/ instead of info/(documentation/) as most of the issues discussed in
+it as far as software and "how/where do I get..." questions were answered
+in it and the grand intent way back when was to reduce those questions to
+"CTAN".
+
+--George
+
+========================================================================
+Date: Tue, 11 Oct 1994 19:06:58 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: Re: Frequently asked questions -- 4th edition
+
+Robin,
+
+placing the faq also on CTAN is fine with me.
+
+--J"org Knappen.
+
+========================================================================
+Date: Thu, 13 Oct 1994 18:59:42 +1000
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Geoffrey TOBIN <ecsgrt@LUXOR.LATROBE.EDU.AU>
+Subject: dvitodpl and dpltodvi (see FAQ)
+
+Regarding dvitodpl and dpltodvi. Those programs, which I have lazily
+named dv2dp and dp2dv, have been quietly :-) available on request
+since 1992.
+
+I wanted to refine them, but other tasks have taken precedence. If
+people don't mind a tentative, poorly documented, pair of programs,
+then I'll upload them.
+
+REMARK:
+The first version of dv2dp took an afternoon to write from scratch,
+using the (now-disbanded) TUG DVI Drivers committee's DVI description.
+It is a continual puzzle to me that a two-way translation for dvi
+format similar to tfm <-> pl, vf <-> vpl and gf <-> chr, seems not to
+have been previously distributed, even if only for completeness' sake.
+
+The DPL format is presently fairly compact, expanding DVI files by an
+average of threefold. However, having recently read Joachim Schrod's
+description of the Virtual Font commands, I'm wondering whether DPL
+should be totally remodeled to resemble VPL, because VF is very
+similar to DVI, and VPL is in the Knuthian Property List style.
+
+Perhaps dv2dp and dp2dv should see the light of day, to promote
+discussion?
+
+Best wishes!
+Geoffrey Tobin
+
+========================================================================
+Date: Thu, 13 Oct 1994 10:19:42 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Anselm Lingnau <lingnau@TM.INFORMATIK.UNI-FRANKFURT.DE>
+Subject: Re: dvitodpl and dpltodvi (see FAQ)
+In-Reply-To: (Geoffrey TOBIN <ecsgrt@LUXOR.LATROBE.EDU.AU> 's message of Thu,
+ 13 Oct 1994 18:59:42 +1000.)
+ <9410130900.AA31283@gauss.math.uni-frankfurt.de>
+
+Geoffrey TOBIN <ecsgrt@LUXOR.LATROBE.EDU.AU> writes:
+
+> I'm wondering whether DPL
+> should be totally remodeled to resemble VPL, because VF is very
+> similar to DVI, [...]
+
+It would be nice to be able to convert a DVI file to a virtual font, if only
+to ease including complex PicTeX output into documents without causing TeX
+to burst because of insufficient main memory.
+
+Anselm
+--
+Anselm Lingnau ......................... lingnau@tm.informatik.uni-frankfurt.de
+The reward of a thing well done is to have done it. --- Ralph Waldo Emerson
+
+========================================================================
+Date: Thu, 13 Oct 1994 10:45:12 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: drucbert <drucbert@RESEAU.ONECERT.FR>
+Subject: Re: dvitodpl and dpltodvi (see FAQ)
+
+If you have memory oveflows when using PiCTeX, perhaps
+the ``dvipaste'' program may help you. It is very handful
+and rather easy to use.
+
+Jean-Pierre Drucbert
+drucbert@reseau.onecert.fr
+
diff --git a/info/digests/nts-l/9411 b/info/digests/nts-l/9411
new file mode 100644
index 0000000000..4fbdbe8a5d
--- /dev/null
+++ b/info/digests/nts-l/9411
@@ -0,0 +1,1897 @@
+========================================================================
+Date: Tue, 8 Nov 1994 20:35:13 BST
+Reply-To: Philip Taylor <P.Taylor@Vax.Rhbnc.Ac.Uk>
+From: Philip TAYLOR <CHAA006@VAX.RHBNC.AC.UK>
+Subject: e-TeX: some specific proposals!
+
+Dear Colleagues -- The NTS group have been very quiet of late, and there has
+been little discussion of NTS and/or e-TeX on this list. But although we
+have been quiet, we have not been idle, and we now have a definite list of
+proposals which we are considering for incorporation in e-TeX. Please read
+the ideas below, and make any comments which you feel appropriate.
+
+ Philip Taylor,
+ Technical Director, NTS project.
+--------
+
+Minutes of the NTS meeting held at Lindau on October 11/12th 1994
+=================================================================
+
+Present: Philip Taylor, Jiri Zlatuska, Bernd Raichle, Friedhelm Sowa,
+ Peter Breitenlohner, Joachim Lammarsch.
+
+It was AGREED that no progress had apparently been made on the `canonical
+TeX kit' project, and that no progress was likely to be made unless and until
+an active proponent of the project emerged within, or was recruited to, the
+group; accordingly the project was officially placed on ice.
+
+It was AGREED that in the absence of adequate funding for the NTS project
+proper, no serious work could be carried out; several possible sources of
+funding remained to be explored, and the group were hopeful that this project
+would see the light of day before too long. [ACTION: JZ, JL]
+
+It was AGREED that the e-TeX project was both feasible and very worthwhile, and
+that all efforts should initially be concentrated on achiving progress in this
+area. With the benefit of hindsight it was AGREED that the original proposal
+to issue new releases at six-monthly intervals had been over-optimistic, and
+that a more realistic timescale would involve new releases once per year. It
+was also AGREED that the first release should be accomplished as soon as
+possible, consistent with the need to ensure that the code released was both
+bug-free and unlikely to require more than a minimum of re-thinking in the
+light of experience.
+
+The group attempted to identify as many ideas as possible which either has
+already been proposed for incorporation in e-TeX, or which were natural
+consequences of (or alternatives to) ideas already proposed. The remainder
+of this document lists the various ideas mooted, and discusses their intention
+and implementation.
+
+--------
+
+\horigin, \vorigin (dimen registers, default = 1 in).
+These two registers, requested by Phil, will serve to make explicit for the
+first time the canonical (1", 1") origin decreed by DEK in the definition of
+the DVI format, and on which all formats are currently predicated. Phil
+explained that his college, amongst others, had eschewed this convention right
+from the outset, and has instead adopted the more logical (0", 0") origin,
+requiring all drivers to be configured in a non-standard manner. Providing
+the origin registers within e-TeX would allow all drivers to be reconfigured
+to the standard, whilst existing practices could be maintained simply by local
+initialisation of the registers to (0", 0"). As e-TeX might eventually require
+the adoption of a new version of the DVI format (to encompass, for example,
+colour), that might also be the appropriate time at which to propose universal
+adoption of a (0", 0") origin.
+
+\<enhancement>state (internal integer registers, one for each enhancement).
+A unified mechanism is proposed for all enhancements [1] whereby an internal
+integer register is associated with each, the name of the register being derived
+from the concatentation of the name of the enhancement and the word `state';
+such registers are read/write, and if their value is zero or negative the
+associated enhancement is disabled [2]. If a positive non-zero value is
+assigned to anu such register, then the associated enhancement shall be
+enabled, and if the register is interrogated then a positive non-zero value
+shall indicate that the associated enhancement is enabled. It is possible
+that in a future release differing values assigned to or returned by such
+registers may indicate the revision-level of enhancements, and therefore it
+is initially recommended that only the values zero or one be used.
+
+\TeXXeTstate, \MLTeXstate (internal integer registers).
+These are the only two enhancements currently under consideration, although
+Bernd Raichle also has a proposal for an alternative ligaturing mechanism
+which would probably of necessity form an enhancement if adopted. MLTeX
+is not proposed for incorporation in the first release, but may be incorporated
+in the second. The group acknowledges the generosity of Michael Ferguson in
+allowing the incorporation of his work on MLTeX.
+
+\interactionmode (internal integer register).
+Allows read/write access to the present \scrollmode, \nonstopmode, etc.,
+family of primitives; the values will be a monotic sequence of period one,
+and descriptive names will be associated through the e-plain (and e-LaTeX?)
+formats. [3]
+
+<additional \tracing... detail>
+Peter has implemented augmented semantics for some of the \tracing commands
+whereby increasingly positive values given increasingly detailed output.
+
+\protected (new prefix for macro definitions).
+Analogous to \long, \outer, etc., causes the associated macro to be
+non-expanding in contexts where such behaviour is likely to be undesirable
+(in particular in \writes and \edefs); an explicit \expandafter \empty
+may be used to force expansion in these circumstances.
+
+\bind (new prefix for macro definitions).
+Proposed by Phil, this was intended to allow macros to be bound to the
+current _meaning_ of embedded control sequences rather than to their names,
+in a manner analogous to PostScript's `bind def'. However the group were
+unconvinced of the merits of this proposal, and it was classified as
+`more work needed' (MWN).
+
+\evaluate {<arithmetic expression>}.
+Intended for use on the r-h-s of \count, \dimen and \skip assignments,
+it would allow the use of infix arithmetic operators such as +, -, * and /;
+the type of the result would, in general, be the type of the simplest operand
+forming a part of the expression, and the normal semantics of TeX would allow
+this to be further coerced where necessary. Parenthesised sub-expressions
+would be allowed. [4]
+
+\contents <box #>.
+Proposed by Jiri, this is intended to allow the TeX programmer access to the
+sort of information normally only available via the log file as a result of
+a \show; in principle it would generate the simplest list of TeX tokens which
+would generate the box specified, assuming that each token generated still
+had its canonical meaning. MWN.
+
+<anchors>: Proposed by Jiri, an ``anchor point'' would be in some senses
+be analogous to a mark, but rather than recording textual information it
+would instead record the co-ordinates of itself, relative to the reference
+point of the smallest surrounding box. Additional new primitives would
+be required to return the co-ordinates of a specified anchor point. MWN.
+
+\scantokens {<balanced text>}.
+Allows an existing token-list to be re-input under a different catcode regime
+from that under which it was created; as it uses all of TeX's present \input
+mechanism, even %%ff notation will be interpreted as if \input. Causes an
+`empty filename' to be input, resulting in `( )' appearing in the log file
+if \tracingscantokens (q.v.) is strictly greater than zero. If the token list
+represents more than one line of input, and if an error occurs, then
+\inputlinenumber will reflect the logical input line from the token list rather
+than the current input line number from the current file.
+
+\unexpanded {<balanced text>}.
+An alternative to \protected, for use when a whole brace-delimited token
+list (`balanced text') is to be protected from expansion. Intended to be
+use in \writes and \edefs.
+
+\every<whatever>.
+The group discussed many possibilities of implementing additional \every
+primitives in e-TeX; most were classified as MWN, but one (\everyeof) is
+being considered for e-TeX version 1.
+
+\futuredef <cs> <tok> <tok>.
+Analogous to \futurelet, but the <cs> will be expandable, and expand to the
+next token encountered (or to the next balanced text if the next token is
+of catcode 1). MWN.
+
+\futurechardef <cs> <tok> <char-or-tok>.
+A combination of \futurelet and \chardef, will allow the next character to
+be inspected and its character code returned iff it has not yet been tokenised.
+If tokenisation has already taken place, will return -1. Intended to allow
+the catcode of the next character to be changed based on its value.
+
+\ifdefined <cs>.
+Allows direct testing of whether or not a given <cs> is defined.
+
+\ifcsname ... \endcsname.
+Ditto, but for a sequence of <tokens-expanding-to-characters>; this also
+avoids wasting of hash table space.
+
+\unless <boolean-if>.
+Inverts the sense of the following boolean-if; particularly useful in
+conjunction with \ifeof in \loop ... \ifeof ... \repeat constructs,
+but also of use with (say) \ifdefined and \ifcsname.
+
+\TeX<whatever>state.
+More work needed! A mechanism whereby a TeX document can ask TeX some
+questions about the current state of its digestive tract. For example it
+would be nice to know if TeX was currently involved in an assignment, and
+if so which part of the assignment was currently being elaborated.
+
+\marks <integer>
+Allows, for the first time, a whole family of marks rather than just the one
+provided by TeX; will also require analogous \topmarks <integer>, etc. The
+group propose to provide 16 such marks, but are interested to know if the
+(La)TeX community consider this sufficient. A related \markdef primitive
+may be provided to simplify mark allocation, in a manner analogous to the
+existing \...def primitives.
+
+\deferred \special (or perhaps \deferredspecial).
+At the moment, only \writes are deferred; there are cases when it would
+be desirable for other things, too, to be expanded only during \shipout,
+and \specials are one of these.
+
+\textcode <integer>.
+Could provide a text-mode analogy to TeX's \mathcode. MWN.
+
+\middle <delimiter>.
+Analogous to \left and \right, allows delimiters to be classed as \middle,
+and their spacing thereby adjusted.
+
+\filename.
+Would allow access to the name of the file currently being \input.
+Lots of discussion on just how much or how little should be returned.
+MWN.
+
+\OSname.
+Very contentious. Would provide the name of the operating system, and
+thereby allow documents to behave differently on different systems.
+Deprecated on that basis, and will not be provided unless/until a \system
+primitive is also provided.
+
+\system {<balanced text>}.
+Definitely not proposed for e-TeX version 1. Would allow operating system
+calls to be made, and their status and result(s) returned in some way.
+A lot MWN.
+
+\tracingscantokens (internal integer register).
+See \scantokens.
+
+<smarter discretionaries, e.g. \discretionarylefthyphenmin>.
+Hyphenation after an implicit hyphen is sometimes highly desirable, and
+the group are investigating mechanisms whereby this could be both provided
+and parameterised. MWN.
+
+\everyhyphen (token list register).
+Would allow TeX's present hard-wired behaviour of placing an empty
+discretionary after every explicit hyphen to be modified. However, there
+are potentially problems of recursion, and perhaps even a need to remove
+the hyphen. MWN.
+
+\clubpenalties, \widowpenalties.
+A start at improving TeX's penalty system by making it more flexible. These
+two penalty `arrays' would allow a different penalty to be associated with
+one-line widows, two-line-widows, etc. [5]
+
+\ifenhanced.
+A boolean-if which would return -true- iff any enhancement is enabled.
+Would allow a e-TeX document to check if it is being processed in `extended'
+more or `enhanced' mode. Phil argues for this one but the group are
+unconvinced: the advice of the TeX community is to be sought.
+
+\lastnodetype.
+Would allow, for the first time, the unambiguous identification of the type
+of the last node of one of TeX's internal lists, removing (for example) the
+ambiguity when \lastpenalty returns 0 (which can indicate no penalty node,
+or a penalty node with value 0). Would return one of a monotonic series of
+integers of period one. Meaningful names would be assigned to these through
+the e- series formats [3].
+
+\unnode.
+Would allow the removal of _any_ node from the end of one of TeX's internal
+lists.
+
+\lastnode.
+Perhaps analogous to \contents (q.v.), or perhaps quite different, would allow
+access to the value of the last node of one of TeX's internal lists.
+Generalises TeX's present mechanism whereby only a subset of nodes can be
+accessed. MWN.
+
+\readline <integer> to <cs>.
+Allows a single line to be read from an input file as if each character
+therein had catcode 12 [6]. Intended to be used for verbatim copying
+operations, in conjunction with \scantokens, or to allow error-free parsing
+of `foreign' (non-TeX) files.
+
+\everyeof {<balanced text>}
+Provides a hook whereby the contents of a token list register may be
+inserted into TeX's reading orifice when end-of-file is encountered
+during file reading. Would not be invoked of the file indicated
+logical e-o-f through the medium of \endinput. Proposed by Phil
+to allow clean processing of file-handling code which requires
+a (sequence of characters yielding) \else or fi to be found in a
+file, where no such sequence can be guaranteed.
+
+\listing (internal integer register).
+Would allow the generation of a listing containing (for example) TeX's analysis
+of current brace depth, macro nesting, etc. Different positive values would
+allow different amounts of information to be generated. Would the TeX
+community like such a feature?
+
+\defaultextension.
+Would allow TeX' present hard-wired behaviour of appending .TeX to a filename
+not possessing an explicit extension to be modified, allowing an alternative
+extension to be specified. Would this be of use to the L2e/L3 team, and/or
+to the TEX world in general?
+
+<fixed point arithmetic>.
+Several of the above ideas cannot be implemented at the moment, as they
+would allow access to the `forbidden area' of machine-dependent arithmetic.
+If TeX's present floating point calculations were replaced by Knuth's
+fixed-poing arithmetic proposals, then there would no longer be a forbidden
+area and all such ideas could, in principle, be implemented.
+
+Notes:
+
+[1] `Extensions' are basically new primitives which have no effect on the
+ semantics of existing TeX documents, except insofaras any document which
+ tests whether such a primitive is, in fact, undefined, will clearly obtain
+ opposite results under TeX and e-TeX; `enhancements' are more fundamental
+ changes to the TeX kernel which may affect the semantics of existing TeX
+ documents even if no new primitive is used or even tested. Such changes
+ may be, for example, differences in the construction of TeX's internal
+ lists, or perhaps different hyphenation or ligaturing behaviour.
+
+[2] It is currently proposed that all enhancements be disabled by e-IniTeX
+ immediately prior to the execution of \dump. This decision was taken
+ based on the advice of Frank Mittelbach.
+
+[3] Question: should there, in fact, be an e-plain (or e-LaTeX) format,
+ or should there simply be an e-plain.tex file which can be loaded by
+ a user document? Peter votes for an e-plain.tex file that will \input
+ plain.tex but no hyphenation patterns.
+
+[4] Should e-TeX allow access to more powerful operators than just
+ +, -, * and /?
+
+[5] `Arrays' are not very obvious in TeX at the moment, although there are,
+ for example, \fontdimens and such-like. But should these have fixed
+ bounds (as in 256 count registers, for example), or arbitrary upper
+ bounds (as in font dimens, if the `extra' elements are assigned as
+ soon as the font is loaded). Or should they be finite-but-unbounded,
+ as in \parshape, wherein the first element indicates the number of
+ elements which follow? These questions are applicable to marks as
+ well as to penalties...
+
+[6] Should spaces have catcode 10 for this operation? Peter thinks so,
+ but based on existing simulations of this operation, I [PT] am more
+ inclined to think they should have catcode 13.
+
+========================================================================
+Date: Tue, 8 Nov 1994 22:20:56 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "Denis B. Roegel" <Denis.Roegel@LORIA.FR>
+Subject: suggestion for NTS
+
+I just read the minutes of the October meeting and find
+it very interesting. If I were millionaire, I would
+immediately help e-TeX, but alas...
+
+Anyway, a few days ago, I noticed something which is quite
+difficult to do in TeX and which might be improved. It is the
+fact that when a paragraph is cut in lines and these lines
+are added to previous accumulated pages in order to form
+a page, several lines are left back for the next pages.
+These lines are set in boxes and unfortunately some
+informations are lost. Sometimes, you wish to unset these
+set lines and since information is lost, it would be
+interesting to have these lines as tokens in a special
+token list. The problem I think is to find a correspondance
+between where the page ends between the lines, and where
+the page ends in this token list. I feel there are cases
+where this is simple.
+
+So, if this were possible, you could easily add a command
+in the output routine which would unset the lines already set,
+insert a \parshape and cut some shape out of each page.
+Wouldn't that be neat ?
+
+Well just a suggestion...and if not for e-TeX, please consider
+it for NTS.
+
+Regards,
+
+Denis.
+
+========================================================================
+Date: Tue, 8 Nov 1994 17:15:00 -0500
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: bbeeton <BNB@MATH.AMS.ORG>
+Subject: Re: e-TeX: some specific proposals!
+In-Reply-To: <01HJ8PR36T2QEBODFE@MATH.AMS.ORG>
+
+having just undergone some rather painful experiences with poorly
+checked input, i'd really like to be able to inquire about the
+current nesting level. this perhaps falls in the category of
+"\listing", about which feedback was requested. i'm not sure i
+want a great deal of detail though -- just a register whose value
+i could test from time to time to make sure that things haven't
+gotten out of hand. this would make it possible, for instance,
+to trigger an error message reasonably near the source of a
+problem rather than waiting for the end of a job.
+ -- bb
+
+========================================================================
+Date: Wed, 9 Nov 1994 10:10:17 +0100
+Reply-To: flexus!RfSchtkt@maze.ruca.ua.ac.be
+From: Raf Schietekat <flexus!rfschtkt@MAZE.RUCA.UA.AC.BE>
+Subject: TeX grammar
+
+LS,
+
+Can TeX be parsed by something like lex/yacc, and if so, where can I find the
+sources, if available for free? Maybe only subsets of TeX can be handled this
+way? Or maybe it's hopeless altogether? I've tried to compile (traditional
+meaning) a grammar from the information in `The TeXbook', but I've encountered
+all sorts of problems when trying to compile it (computer science meaning).
+
+Thanks,
+
+Raf Schietekat, RfSchtkt@maze.ruca.ua.ac.be, Flanders, Belgium
+(real, i.e., with triangle in the Deliver button) NeXTmail preferred
+Addressing limitations: no !, % or .uucp, I think
+
+PS: Please reply to my address, because my system/situation throws away all
+messages from this list (I have to lie in ambush to pick incoming messages out
+of the uucp queue). If you're a uucp guru...
+
+========================================================================
+Date: Wed, 9 Nov 1994 18:44:38 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
+Subject: Re: TeX grammar
+In-Reply-To: <199411091736.SAA19623@rs3.hrz.th-darmstadt.de> from "Raf
+ Schietekat" at Nov 9, 94 10:10:17 am
+
+Raf Schietekat wrote:
+>
+> Can TeX be parsed by something like lex/yacc
+
+No. As a macro language TeX has an extensible grammar. That cannot be
+modelled with parser generators like the one above. One has to use
+modifiable grammars.
+
+What makes such tools even more unsuitable, is the point that the
+lexical analysis can be configured.
+
+It's not a problem per se to parse TeX; Common Lisp's macro language
+and its configurability is by far more complex (and more powerful)
+than TeX; it simply isn't your classic Aho-Hopcraft-Ullman-textbook
+type of language.
+
+ Joachim
+
+--
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
+Computer Science Department
+Technical University of Darmstadt, Germany
+
+========================================================================
+Date: Wed, 9 Nov 1994 18:57:38 BST
+Reply-To: Philip Taylor <P.Taylor@Vax.Rhbnc.Ac.Uk>
+From: Philip TAYLOR <CHAA006@VAX.RHBNC.AC.UK>
+Subject: Re: suggestion for NTS
+
+Denis --
+
+>> I just read the minutes of the October meeting and find
+>> it very interesting. If I were millionaire, I would
+>> immediately help e-TeX, but alas...
+
+We shall all pray for you to win a lottery!
+
+>> Anyway, a few days ago, I noticed something which is quite
+>> difficult to do in TeX and which might be improved. It is the
+>> fact that when a paragraph is cut in lines and these lines
+>> are added to previous accumulated pages in order to form
+>> a page, several lines are left back for the next pages.
+>> These lines are set in boxes and unfortunately some
+>> informations are lost. Sometimes, you wish to unset these
+>> set lines and since information is lost, it would be
+>> interesting to have these lines as tokens in a special
+>> token list. The problem I think is to find a correspondance
+>> between where the page ends between the lines, and where
+>> the page ends in this token list. I feel there are cases
+>> where this is simple.
+
+This is a very interesting proposal, and one which I believe
+Frank Mittlebach has already proved possible: thank you very
+much for reminding us of it -- I will add it to the list of
+ideas which must be considered.
+
+ ** Phil.
+
+========================================================================
+Date: Thu, 10 Nov 1994 19:45:00 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Jonathan Fine <J.Fine@PMMS.CAM.AC.UK>
+Subject: Turning a set paragraph into tokens
+
+Dear NTS Reader
+In a recent posting Denis Roegel asks for a command which would
+> unset lines already set
+so that the output routine could
+> cut some shape out of each page.
+
+The purpose for which Roegel requests the new command can be
+accomplished with TeX as it is, by writing some admittedly tricky
+macros. For example, see articles by Alan Hoenig in TUGBoat.
+
+best regards
+Jonathan Fine
+
+========================================================================
+Date: Thu, 10 Nov 1994 22:02:28 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
+Subject: Re: Turning a set paragraph into tokens
+In-Reply-To: <199411101948.UAA35319@rs3.hrz.th-darmstadt.de> from "Jonathan
+ Fine" at Nov 10, 94 07:45:00 pm
+
+On another point concerning that subject: It was announced that e-TeX
+shall really be able to `rescan' a token list, to be able to process
+an input with different catcodes.
+
+I would like to know how the rescan of \tok, as defined in
+
+ \let\u=\uppercase % contains `s'
+
+ \newtoks\tok
+
+ \catcode`\s=10
+ \tok\expandafter{\u{asb}}
+ \catcode`\s=11
+
+is handled. To make my point clear, for those who do not know TeX by
+heart: The `s' is lost and cannot be recovered in TeX.
+
+ Joachim
+
+--
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
+Computer Science Department
+Technical University of Darmstadt, Germany
+
+========================================================================
+Date: Thu, 10 Nov 1994 23:00:52 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: \oddhoffset, \evenhoffset, etc.
+
+\oddhoffset, \evenhoffset, \oddvoffset, \evenvoffset
+
+If you have a printer capable of real twosideprinting, it may happen, that
+the front page and the back page have different offsets and you want to
+correct for it separately. I remember that this problem was once mentioned
+on de.comp.tex.
+
+--J"org Knappen.
+
+========================================================================
+Date: Thu, 10 Nov 1994 23:02:23 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: \horigin
+
+\horigin, \vorigin
+
+I don't see the gain of these two commands. In fact, there is no
+``natural'' origin of the coordinate system at all. The upper left corner
+looks very unnatural as well, why shouldn't it be the lower left corner
+with the usual orintation of axes? However, shifting around the coordinate
+system does not give you anything you don't have in the old one, therefore
+the standard is better left untouched.
+
+--J"org Knappen.
+
+========================================================================
+Date: Thu, 10 Nov 1994 15:51:28 -0500
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Michael Downes <MJD@MATH.AMS.ORG>
+Subject: Re: Turning a set paragraph into tokens
+In-Reply-To: <01HJBGMLEC6QEBOQQC@MATH.AMS.ORG>
+
+(Denis Roegel:)
+> fact that when a paragraph is cut in lines and these lines
+> are added to previous accumulated pages in order to form
+> a page, several lines are left back for the next pages.
+> These lines are set in boxes and unfortunately some
+> informations are lost. Sometimes, you wish to unset these
+> set lines and since information is lost, it would be
+> interesting to have these lines as tokens in a special
+> token list. The problem I think is to find a correspondance
+> between where the page ends between the lines, and where
+> the page ends in this token list. I feel there are cases
+> where this is simple.
+
+(Jonathan Fine:)
+> The purpose for which Roegel requests the new command can be
+> accomplished with TeX as it is, by writing some admittedly tricky
+> macros. For example, see articles by Alan Hoenig in TUGBoat.
+
+Yes, and I don't think it would be wise to attempt to keep track of a
+correspondence between tokens and the lines of a paragraph; that would
+be an attempt to find synchronization between two very different, very
+*asynchronous* data types (token stream versus horizontal list). The
+most natural thing to do, within the current framework of TeX, would be
+to save the trailing part of the paragraph in a box register as a single
+unbroken line and make that accessible in the output routine. And even
+then I think you have difficult complications because linebreaking and
+the movement of material from `recent contributions' to `current page'
+are separate steps. Consider also that the desired behavior cuts
+unnaturally across TeX's optimization of line breaks over an entire
+paragraph: the line breaks that TeX finds if the tail of the paragraph
+is left as a single unbroken line might differ from the line breaks that
+TeX finds if the tail of the paragraph is fully broken. This in turn can
+affect the height/depth of the lines that fall at the page boundary,
+which would seem to imply a fundamental instability in the decision
+about where the tail of the paragraph is to be broken off!
+
+Michael Downes
+mjd@math.ams.org
+
+========================================================================
+Date: Thu, 10 Nov 1994 23:01:33 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: \evaluate
+
+\evaluate
+
+I think, that the following three functions are a must: sin, cos, sqrt.
+Pythagorean addition (like METAFONT's `++') is also worth considering.
+
+The other arithmetic features of METAFONT are also fine, but I don't want
+to go over the top (OTT). It would be difficult enough to implement
+\evaluate anyhow.
+
+--J"org Knappen.
+
+========================================================================
+Date: Thu, 10 Nov 1994 23:06:58 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: \fancyprompt
+
+\fancyprompt
+
+allow configuration of the TeX prompt (default `*').
+
+*\fancyprompt{eTeX>}
+eTeX>
+
+--J"org Knappen.
+
+========================================================================
+Date: Thu, 10 Nov 1994 23:03:54 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: Make eTeX less batch orientated
+
+The following is something new and rather different from the current
+proposals. The idae behind is having TeX ready in the memory and avoid
+loading it anew for each run again and again which costs lots of startup
+time, if you have to load everything via NFSS.
+
+The idea I am toying with is to have something like
+ \level
+which clones the current state of TeX and allows to start a new dvi-file.
+Then you do what you want (start even another \level, if you want, and at
+last you say
+ \exit
+which performes like \end, except that it restores exactly the state before
+the last cloning.
+
+Wait a minute, you want to may communicate some information to the waiting
+lion. So there may be one exeption. You say
+ \exit{some_integer_number}
+and this number can be read by using
+ \exitstatus.
+
+Applications are many. If you have a format which usually requires several runs,
+ you
+can do all the runs within one job, and automatically decide, wether a
+further run is necessary. Of course, you should device your format to have
+a counter maxruns to avoid endless looping...
+
+--J"org Knappen.
+
+========================================================================
+Date: Thu, 10 Nov 1994 22:46:01 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "Denis B. Roegel" <Denis.Roegel@LORIA.FR>
+Subject: Re: Turning a set paragraph into tokens
+In-Reply-To: <199411101947.UAA29243@lorraine.loria.fr> from "Jonathan Fine" at
+ Nov 10, 94 07:45:00 pm
+
+'Jonathan Fine'
+>
+> Dear NTS Reader
+> In a recent posting Denis Roegel asks for a command which would
+> > unset lines already set
+> so that the output routine could
+> > cut some shape out of each page.
+>
+> The purpose for which Roegel requests the new command can be
+> accomplished with TeX as it is, by writing some admittedly tricky
+> macros. For example, see articles by Alan Hoenig in TUGBoat.
+>
+
+I don't doubt this is possible in TeX, since everything is possible
+within TeX. But it is difficult. And also unefficient.
+Here is an excerpt of an exchange with Donald Arseneau:
+
+DA> ... I must say that you can't unbox paragraphs and
+DA> re-set them: choice of discretionary (hyphenation) and discarding are
+DA> permanent; they cannot be restored. To have a chance at reshaping a
+DA> paragraph, you must keep either the original text of the paragraph, or
+DA> set it on a single line (\hsize=\maxdimen) and keep that box. See
+DA> shapepar.sty. It would be much better to use non-TeX.
+
+I had understood that one purpose of e-TeX was to ease things
+that were otherwise difficult, or am I wrong ?
+
+Denis.
+
+========================================================================
+Date: Fri, 11 Nov 1994 11:29:11 BST
+Reply-To: Philip Taylor <P.Taylor@Vax.Rhbnc.Ac.Uk>
+From: Philip TAYLOR <CHAA006@VAX.RHBNC.AC.UK>
+Subject: Quick response to recent proposals
+
+My thanks to those who responded to the recent list of proposals for e-TeX:
+here are my immediate reactions to the new suggestions; other members of the
+team will probably want to respond individually:
+
+ ** Phil.
+--------
+>> On another point concerning that subject: It was announced that e-TeX
+>> shall really be able to `rescan' a token list, to be able to process
+>> an input with different catcodes.
+
+>> I would like to know how the rescan of \tok, as defined in
+
+>> \let\u=\uppercase % contains `s'
+
+>> \newtoks\tok
+
+>> \catcode`\s=10
+>> \tok\expandafter{\u{asb}}
+>> \catcode`\s=11
+
+>> is handled. To make my point clear, for those who do not know TeX by
+>> heart: The `s' is lost and cannot be recovered in TeX.
+
+If e-TeX sees \scantokens {\tok}, it will simply process the
+characters "\tok" under the current catcode regime; if it
+sees \scantokens \expandafter {\tok}, then I would expect it
+to scan "\u{a b}", but Peter (who proposed and implemented this
+feature) is better placed than I to explain exactly what he intends
+it to do. I'm sure he will respond shortly.
+--------
+>> \oddhoffset, \evenhoffset, \oddvoffset, \evenvoffset
+
+>> If you have a printer capable of real twosideprinting, it may happen, that
+>> the front page and the back page have different offsets and you want to
+>> correct for it separately. I remember that this problem was once mentioned
+>> on de.comp.tex.
+
+I really cannot see a genuine need for this: \hoffset & \voffset are
+honoured _only_ during shipout; it is a very simple matter for the
+output routine to tweak them just prior to threading \shipout.
+Or have I missed something?
+--------
+>> \evaluate
+
+>> I think, that the following three functions are a must: sin, cos, sqrt.
+>> Pythagorean addition (like METAFONT's `++') is also worth considering.
+
+If we allow trig functions we must implement them using integer arithemetic,
+otherwise portability issues will become a problem. It is _very_ hard
+to know where to stop once you go beyond the basic four (plus, perhaps,
+mod and div). But ++ is a nice idea.
+
+>> The other arithmetic features of METAFONT are also fine, but I don't want
+>> to go over the top (OTT). It would be difficult enough to implement
+>> \evaluate anyhow.
+--------
+>> \horigin, \vorigin
+
+>> I don't see the gain of these two commands. In fact, there is no
+>> ``natural'' origin of the coordinate system at all. The upper left corner
+>> looks very unnatural as well, why shouldn't it be the lower left corner
+>> with the usual orintation of axes? However, shifting around the coordinate
+>> system does not give you anything you don't have in the old one, therefore
+>> the standard is better left untouched.
+
+There are several reasons for eschewing the (1", 1") convention.
+
+(1) It's irrational: what on earth is special about 1" down, 1" in?
+(2) It's nonsensical if you trying to set 35mm slides at natural size;
+(3) Today's undergradutes don't know what an inch is...
+(4) For pedagogical reasons, I always teach that \horigin reprsents
+ the left margin, and \vorigin represents the top margin: I'd hate
+ to have to qualify this by ``provided that you first subtract one inch''.
+--------
+>> The following is something new and rather different from the current
+>> proposals. The idae behind is having TeX ready in the memory and avoid
+>> loading it anew for each run again and again which costs lots of startup
+>> time, if you have to load everything via NFSS.
+
+>> The idea I am toying with is to have something like
+>> \level
+>> which clones the current state of TeX and allows to start a new dvi-file.
+>> Then you do what you want (start even another \level, if you want, and at
+>> last you say
+>> \exit
+>> which performes like \end, except that it restores exactly the state before
+>> the last cloning.
+
+>> Wait a minute, you want to may communicate some information to the waiting
+>> lion. So there may be one exeption. You say
+>> \exit{some_integer_number}
+>> and this number can be read by using
+>> \exitstatus.
+
+>> Applications are many. If you have a format which usually requires several
+ runs,
+>> you
+>> can do all the runs within one job, and automatically decide, wether a
+>> further run is necessary. Of course, you should device your format to have
+>> a counter maxruns to avoid endless looping...
+
+Very interesting: there are other calls for allowing more than one DVI file;
+certainly worthy of further consideration.
+--------
+>> \fancyprompt
+
+>> allow configuration of the TeX prompt (default `*').
+
+>> *\fancyprompt{eTeX>}
+>> eTeX>
+
+Seems pretty cosmetic to me: is this a serious proposal?
+--------
+>> Yes, and I don't think it would be wise to attempt to keep track of a
+>> correspondence between tokens and the lines of a paragraph; that would
+>> be an attempt to find synchronization between two very different, very
+>> *asynchronous* data types (token stream versus horizontal list). The
+>> most natural thing to do, within the current framework of TeX, would be
+>> to save the trailing part of the paragraph in a box register as a single
+>> unbroken line and make that accessible in the output routine. And even
+>> then I think you have difficult complications because linebreaking and
+>> the movement of material from `recent contributions' to `current page'
+>> are separate steps. Consider also that the desired behavior cuts
+>> unnaturally across TeX's optimization of line breaks over an entire
+>> paragraph: the line breaks that TeX finds if the tail of the paragraph
+>> is left as a single unbroken line might differ from the line breaks that
+>> TeX finds if the tail of the paragraph is fully broken. This in turn can
+>> affect the height/depth of the lines that fall at the page boundary,
+>> which would seem to imply a fundamental instability in the decision
+>> about where the tail of the paragraph is to be broken off!
+
+But Frank has shewn that it _can_ _be_ _done_. The output routine is
+an irrelevancy in this: what is needed is \reconsiderparagraphs, which
+allows all material carried over from the current paragraph at a page
+break to be re-subjected to (e-)TeX's paragraphing algorithm.
+
+>> I don't doubt this is possible in TeX, since everything is possible
+>> within TeX. But it is difficult. And also unefficient.
+>> Here is an excerpt of an exchange with Donald Arseneau:
+
+>> DA> ... I must say that you can't unbox paragraphs and
+>> DA> re-set them: choice of discretionary (hyphenation) and discarding are
+>> DA> permanent; they cannot be restored. To have a chance at reshaping a
+>> DA> paragraph, you must keep either the original text of the paragraph, or
+>> DA> set it on a single line (\hsize=\maxdimen) and keep that box. See
+>> DA> shapepar.sty. It would be much better to use non-TeX.
+
+>> I had understood that one purpose of e-TeX was to ease things
+>> that were otherwise difficult, or am I wrong ?
+
+No, that's _exactly_ the point. As I said in my earlier reply, this
+is a very important proposal which I am extremely glad you reminded
+us about.
+
+ ** Phil.
+
+========================================================================
+Date: Fri, 11 Nov 1994 11:48:00 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Jonathan Fine <J.Fine@PMMS.CAM.AC.UK>
+Subject: Re: Turning a set paragraph into tokens
+
+Denis Roegel wrote
+> I had understood that one purpose of e-TeX was to ease things
+> that were otherwise difficult
+and he may be right.
+
+Knuth provided macros so that things could be done without writing
+a whole new program. To my mind it is very important to know of any
+required facility, whether it is
+a) possible and not hard
+b) possible and hard
+c) not possible
+by writing macros or by improving the .dvi driver.
+
+For example, the \vorigin, \horigin feature can be provided by writing macros.
+(It's a question of intercepting the \shipout command, and this can be done
+by using the \afterbox macros that Sonja Maus published in TUGboat a while ago.)
+
+Now for the facility Roegel requested. This is, he agrees, possible but hard.
+I'm in favour of making things easier, but for the life of me, I cannot see how
+turning s set box into tokens will help.
+
+I am in broad agreement with the contribution of Michael Downes on this matter.
+
+with best regards
+Jonathan Fine
+
+========================================================================
+Date: Mon, 14 Nov 1994 15:05:01 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: David Carlisle <carlisle@CS.MAN.AC.UK>
+Subject: Re: e-TeX: some specific proposals!
+In-Reply-To: <9411082043.AA13490@m1.cs.man.ac.uk> (message from Philip TAYLOR
+ on Tue, 8 Nov 1994 20:35:13 BST)
+
+The following is a (very slightly) modified version of some comments I
+sent to Phil after he spoke about these proposals at UKTUG. I have
+modified the comments slightly in the light of other comments made
+since then on this list
+
+David
+=============================================================
+General point first:
+
+Some of these new primitives take up some nice names
+that users may want to use (or have used) in documents, I realise that
+the commands only become activated if the extensions are enabled, but
+these names may cause problems in converting documents to use etex
+features, and mean that it becomes hard to use those command names in
+future.
+
+As almost all the extra commands are aimed at the macro programmer
+rather than the document author, had your group ever considered giving
+the commands more `internal' names, eg with a unique prefix
+
+\etexevaluate
+\etexfilename
+
+etc
+
+I suggest etex as the prefix here as it is all letters, actually I
+would go further and use @ or _ in the names, macro files easily
+arrange to have the right catcode, and this leaves the `letters' name
+space free for user commands.
+\future_def ?
+
+
+
+> \horigin, \vorigin & <dimen registers>, default = 1 in & logical page origin
+
+Not sure that this gives you anything (and takes up a nice name)
+
+\horigin=???
+appears to be
+\hoffset=-1in \advance\hoffset by ???
+
+
+Others have commented on this too. It seems that the desired semantics
+can easily be gained without this extension.
+
+
+
+> \interactionmode & <count register> & read/write access to \scrollmode, etc.
+
+Also versions of \scrollmode and friends that obeyed TeX's normal scoping
+rules would be useful.
+
+> \protected <macro definition> & <primitive> & prefix analogous to
+> \long, \outer, ...
+
+Need to think whether your suggested semantics (never expand in edef-y
+things) is enough, or whether one really would need some kind of
+\protectionlevel
+parameter
+(0= normal usage, 1= protected macros dont expand)
+or something.
+
+> \evaluate {<arithmetic expression>} & <skip primitive> & evaluates
+> and returns arithmetic expression
+
+Would this add to the list of characters that have special
+significance in the etex bnf expression descriptions. eg ( * / )
+as well as + - . ??
+
+
+> \ifdefined <cs> & <if-primitive> & tests if <cs> is defined without
+> wasting hash-table space
+
+I thought that \ifx\foo\undefined did not waste hash space either ?
+
+> \ifcsname ... \endcsname & <if-primitive> & tests if constructed
+> <cs> is defined without wasting hash-table space
+
+I think this is atacking the wrong problem.
+It is not the
+\expandafter\ifx\csname foo \endcsname\undefined
+construct that is broken. It is the \csname primitive.
+
+What is desparately needed is a primitive like csname, but generates
+the standard TeX undefined command error if \foo is undefined.
+
+Then
+
+\expandafter\ifx\csnamedoneright foo \endcsnamedoneright\undefined
+
+ought to work as well as
+
+\ifx\foo\undefined
+
+but more importantly could stop doing the current mess of having to
+check whether foo is defined, and raise an error `by hand' if not,
+before executing \csname foo \endcsname
+
+> \markdef <cs> <integer> & <mark allocater> & allows multiple (16) marks
+
+Fixed, especially fixed low, upper limits are a bad thing in general,
+and in particular here. 16 will not be enough.
+
+ideally just
+\marktoken <cs> to allow an arbitrary number of marks. If that is not
+in the TeX style please let <cs> be an arbitrary <count> value.
+
+Presumably this comes with matching typed versions of \mark \firstmark
+etc to actually use the typed marks?
+
+
+> \filename & <primitive> & analogous to \jobname
+As I mentioned, I would like all these commands to get internal names,
+but \filename would be a particularly nice name for users to lose.
+
+
+> \defaultextension & <?string register?> & specifies alternative to `.tex'
+
+Doesn't buy you much within the document, where the macro level can do
+this quite easily. (LaTeX does a lot of this sort of thing) however
+being able to change the default extension on the command line
+implicit input would be useful.
+
+Actually this made me think, it would be useful to be able to
+change that default behaviour of adding \input, if some suitable syntax
+could be found, perhaps a token register, defaulting to {\input}.
+
+Currently for any files input with \input{foo} LaTeX avoids TeX's
+unfriendly missing file error, with its own error loop. It can not do
+this with files on the command line as it can not grab the filename
+very easily/
+
+> <fixed point arithmetic>
+
+Yes please, then give me \last-everything \un-everything :-)
+
+
+
+
+========
+
+One other feature would be nice. This is not a change to the language
+of TeX itself, but rather to its `standard implementation'.
+
+Currently
+
+\global\let\foo\undefined
+
+makes \foo act in all (I think?) respects as if \foo had never been
+defined, however \foo still sits in the hash table taking up a
+valuable slot that can never be used for any other command. Would it
+be possible for this to be de-allocated?
+
+David
+
+========================================================================
+Date: Mon, 14 Nov 1994 11:02:41 -0500
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: bbeeton <BNB@MATH.AMS.ORG>
+Subject: Re: e-TeX: some specific proposals!
+In-Reply-To: <01HJGS6A3I76EBOZKF@MATH.AMS.ORG>
+
+among other requests for e-tex, david carlisle has proposed the
+following:
+
+ One other feature would be nice. This is not a change to the language
+ of TeX itself, but rather to its `standard implementation'.
+
+ Currently
+
+ \global\let\foo\undefined
+
+ makes \foo act in all (I think?) respects as if \foo had never been
+ defined, however \foo still sits in the hash table taking up a
+ valuable slot that can never be used for any other command. Would it
+ be possible for this to be de-allocated?
+
+when knuth was asked about this, a long time ago, his response was
+that he was unable to tell whether in fact a \cs was defined elesewhere,
+locally, and to continually be defining and undefining the same thing
+would be wasteful and time-consuming. i think there was also some
+consideration of clearing things out of the middle of the hash table
+(the same reason given for not being able to remove a file name from
+the string pool unless it is the very last thing put onto the list).
+i will try to look up the reference if that is considered useful.
+also, peter may have a different opinion ...
+ -- bb
+
+========================================================================
+Date: Mon, 14 Nov 1994 17:13:01 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "Denis B. Roegel" <Denis.Roegel@LORIA.FR>
+Subject: Re: e-TeX: some specific proposals!
+In-Reply-To: <199411141606.RAA15561@lorraine.loria.fr> from "bbeeton" at Nov
+ 14, 94 11:02:41 am
+
+'bbeeton'
+>
+> among other requests for e-tex, david carlisle has proposed the
+> following:
+>
+> One other feature would be nice. This is not a change to the language
+> of TeX itself, but rather to its `standard implementation'.
+>
+> Currently
+>
+> \global\let\foo\undefined
+>
+> makes \foo act in all (I think?) respects as if \foo had never been
+> defined, however \foo still sits in the hash table taking up a
+> valuable slot that can never be used for any other command. Would it
+> be possible for this to be de-allocated?
+>
+> when knuth was asked about this, a long time ago, his response was
+> that he was unable to tell whether in fact a \cs was defined elesewhere,
+> locally, and to continually be defining and undefining the same thing
+> would be wasteful and time-consuming. i think there was also some
+> consideration of clearing things out of the middle of the hash table
+> (the same reason given for not being able to remove a file name from
+> the string pool unless it is the very last thing put onto the list).
+> i will try to look up the reference if that is considered useful.
+
+In TeX's errorlog, I found the following which might shed some light
+on the topic.
+
+Denis.
+
+* 28 Aug 1979
+ ...
+S422\>403. Correct a serious |\gdef| bug:
+ Control sequences don't obey a last-in-first-out
+ discipline, so \TeX\ loses things from the hash table when deleting a
+ control sequence. @259
+# To fix this, I either need to restrict \TeX\ (so that
+ |\gdef| can be used inside a group only for control sequences already
+ defined on the outer level) or need to change the hash table algorithm.
+ Although all applications of \TeX\ known to me will agree to the
+ former restriction, I've chosen the latter alternative,
+ because it gives me
+ a chance to improve the language: Control sequences
+ of arbitrary length will now be recognized.
+
+========================================================================
+Date: Fri, 18 Nov 1994 20:31:34 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: "Denis B. Roegel" <Denis.Roegel@LORIA.FR>
+Subject: an other suggestion
+
+This might be interesting and quite easy to implement (I think):
+
+\showdefinedcommands : show all the commands that have been defined
+by \def, \edef, \let, etc.
+
+It can be useful for debugging.
+
+Denis.
+
+========================================================================
+Date: Fri, 18 Nov 1994 19:58:07 BST
+Reply-To: Philip Taylor <P.Taylor@Vax.Rhbnc.Ac.Uk>
+From: Philip TAYLOR <CHAA006@VAX.RHBNC.AC.UK>
+Subject: Re: an other suggestion
+
+>> This might be interesting and quite easy to implement (I think):
+>> \showdefinedcommands : show all the commands that have been defined
+>> by \def, \edef, \let, etc.
+>> It can be useful for debugging.
+
+Or perhaps even \showallknowncontrolsequences? It could tag each
+with its type: primitive, macro, chardef'd, etc? If you walked
+through the hash table they'd come out in a strange order, but I'm
+not sure you'd want the overhead of sorting them...
+
+I can't say I'm enthusiastic at the thought of these, but is there
+a general demand for either the simple or the full-blown version?
+
+ ** Phil.
+
+========================================================================
+Date: Fri, 18 Nov 1994 16:39:52 EDT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Jerry Leichter <leichter@LRW.COM>
+Subject: Re: an other suggestion
+
+ >> This might be interesting and quite easy to implement (I think):
+ >> \showdefinedcommands : show all the commands that have been defined
+ >> by \def, \edef, \let, etc.
+ >> It can be useful for debugging.
+
+ Or perhaps even \showallknowncontrolsequences? It could tag each
+ with its type: primitive, macro, chardef'd, etc? If you walked
+ through the hash table they'd come out in a strange order, but I'm
+ not sure you'd want the overhead of sorting them...
+
+ I can't say I'm enthusiastic at the thought of these, but is there
+ a general demand for either the simple or the full-blown version?
+
+I'd suggest something much simpler, but also more general: Include \dump in
+all versions of TeX. The initex/virtex distinction is simply not worth the
+bother of retaining any more - the memory differences are trivial in modern
+terms. \dump should ideally also be extended to allow dumping from inside of
+a group.
+
+Once you do this, it becomes possible to write programs to analyze format
+files. Since the analysis programs would not be part of TeX proper, they can
+be as elaborate as anyone might want to make them. Sorting would be no
+problem, for example.
+
+How about a control sequence cross-referencer? If dumping inside of groups is
+allowed, how about fancy stack tracebacks? I could see this being used as the
+basis of a general TeX debugging environment - the analogue of a Unix core
+file.
+
+None of this would cost anything in TeX itself, and except for the ability to
+\dump inside a group, if added, would not even have an effect on whether the
+resulting E-TeX is properly "TeX", since it would be invisible to any possible
+trip test.
+ -- Jerry
+
+========================================================================
+Date: Sat, 19 Nov 1994 13:12:45 MEZ
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Werner Lemberg <A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT>
+Subject: Re: an other suggestion
+In-Reply-To: Message of Fri, 18 Nov 1994 19:58:07 BST from
+ <CHAA006@VAX.RHBNC.AC.UK>
+
+I think it would be quite nice to have a dump facility:
+
+if you say \TeXdump, you get a complete description of the registers,
+defined commands etc. comparable to a core file. TeX should exit then.
+
+
+ Werner
+
+========================================================================
+Date: Mon, 21 Nov 1994 14:40:02 BST
+Reply-To: Philip Taylor <P.Taylor@Vax.Rhbnc.Ac.Uk>
+From: Philip TAYLOR <CHAA006@VAX.RHBNC.AC.UK>
+Subject: Re: an other suggestion
+
+[Jerry Leichter wrote: ]
+
+>> I'd suggest something much simpler, but also more general: Include \dump in
+>> all versions of TeX. The initex/virtex distinction is simply not worth the
+>> bother of retaining any more - the memory differences are trivial in modern
+>> terms. \dump should ideally also be extended to allow dumping from inside of
+>> a group.
+
+It is interesting that Nelson Beebe has also proposed that \dump/\restore
+should be more generally accessible as well. Clearly we must look into this.
+
+ ** Phil.
+
+========================================================================
+Date: Mon, 21 Nov 1994 16:26:09 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: David Carlisle <carlisle@CS.MAN.AC.UK>
+Subject: another creaping feature
+
+One really useful feature (almost a bug fix, really) would be
+a new primitive, say \something, which had the same effect as \relax
+except that <optional \something's> was added to the end of the bnf
+descriptions for count and skip etc.
+
+Then if you wanted to return the maximum of two numbers you could go
+
+\def\maxnum#1#2{\ifnum#1\something>#2\something#1\else#2\fi\something}
+
+This is currently terribly difficult to do in TeX. in fact I am not
+sure it is possible in full generality.
+
+You can not terminate #1 or #2 with \relax as that leaves a token
+which gets in the way, you can not use <space> as that will only be
+eaten up if the arguments are literal digit strings, not internal
+registers.
+
+An alternative would be to use \relax instead of a new csname, but
+that would probably break too much existing code unfortunately.
+
+David
+
+========================================================================
+Date: Mon, 21 Nov 1994 17:52:56 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Piet van Oostrum <piet@CS.RUU.NL>
+Subject: Re: another creaping feature
+In-Reply-To: <199411211638.AA27566@relay.cs.ruu.nl>
+
+>>>>> David Carlisle <carlisle@cs.man.ac.uk> (DC) writes:
+
+DC> One really useful feature (almost a bug fix, really) would be
+DC> a new primitive, say \something, which had the same effect as \relax
+DC> except that <optional \something's> was added to the end of the bnf
+DC> descriptions for count and skip etc.
+
+DC> Then if you wanted to return the maximum of two numbers you could go
+
+DC> \def\maxnum#1#2{\ifnum#1\something>#2\something#1\else#2\fi\something}
+
+DC> This is currently terribly difficult to do in TeX. in fact I am not
+DC> sure it is possible in full generality.
+
+DC> You can not terminate #1 or #2 with \relax as that leaves a token
+DC> which gets in the way, you can not use <space> as that will only be
+DC> eaten up if the arguments are literal digit strings, not internal
+DC> registers.
+
+Can't this be solved by using \number?
+
+I think in your example the first \something is unnecessary, as the number
+is terminated by ">".
+
+\def\maxnum#1#2{\ifnum#1>\number#2 \number#1\else\number#2\fi }
+
+Except that this would give a decimal number rather than a \count or
+internal integer in some cases.
+--
+Piet van Oostrum <piet@cs.ruu.nl>
+
+========================================================================
+Date: Mon, 21 Nov 1994 17:38:08 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: David Carlisle <carlisle@CS.MAN.AC.UK>
+Subject: Re: another creaping feature
+In-Reply-To: <9411211728.AA24616@m1.cs.man.ac.uk> (message from Piet van
+ Oostrum on Mon, 21 Nov 1994 17:52:56 +0100)
+
+> Can't this be solved by using \number?
+Not in full generality, no. If provoked I could dig out my test cases
+of what goes wrong with various definitions of \maxnumber...
+
+
+One might want to insist that it actually returns #1 or #2, not just
+an equal value (thus discounting your code)
+
+eg you might want this to work
+
+\maxnum{\count0}{\count2}=0
+
+ie set either \count0 or \count2 to 0...
+
+Also what do you do about \skip assignments, there you can only
+currently stop the lookahead using \relax, which often is one token
+too many in further processing.
+
+David
+
+========================================================================
+Date: Mon, 21 Nov 1994 21:54:07 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: \showcsname...\endcsname
+
+\showcsname ... \endcsname
+
+In an increasingly popular macro package the authors make intense use of
+untypeable (and sometimes almost unreadable) control sequences with
+spaces, backslashes and other strange tokens in. For analysis I like to
+have
+
+\showcsname....\endcsname, which acts like \show.
+
+Maybe it should be accompagnied by a
+
+\meaningcsname....\endcsname
+
+for use in programmes.
+
+--J"org Knappen.
+
+========================================================================
+Date: Mon, 21 Nov 1994 21:17:37 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: An alternative to the creaping features
+
+What about something like:
+\ifevaluate{<boolean expression>}....\else....\fi ?
+
+This would give a general and flexible \if whith much more comfort then you
+have now. Of course some dirty tricks aren't possible with this one, like
+pushing tokens from the condition to the {true} branch.
+
+The boolean expression should allow for the usual operators like
+.not., .and., .or., .xor., =, >, <, <=, etc., if feasable it should also
+allow the evaluation of arithmetic expressions. Some functions are needed
+to get information old TeX \if's know now, I propose the name
+\query<whatever> to these functions.
+
+At the moment I see need for the following \query<whatever> functions:
+
+\queryeof returns `1' if eof, `0' else
+\querymode returns `0' in the infamous `no mode' (do we need to
+ differentiate finer here?
+ `1' in vertical mode
+ `2' in restricted vertial mode
+ `3' in horizontal mode
+ `4' in restricted horizontal mode
+ `5' in math mode
+ `6' in restricted math mode
+ With \querymode \ifmmode, \ifhmode, \ifvmode, and \ifinner can be emulated.
+\querydefined{\cs} `1' if defined, `0' else
+\querycsname...\endcsname " "
+
+--J"org Knappen.
+
+========================================================================
+Date: Mon, 21 Nov 1994 23:17:55 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: "Denis B. Roegel" <Denis.Roegel@LORIA.FR>
+Subject: show space tokens in \tracingmacros
+
+When you have to debug some weird encoding issue in LaTeX2e,
+you soon realize that there are internal command names
+containing a trailing white space. The problem arises when you
+want to follow some trace given by \tracingmacros.
+
+For instance, let's imagine two control sequences \cs-one and \cs-one ,
+the second having a white space (see it ?) at the end.
+When you trace expansions, you get something like:
+
+\cs-one -> ...
+
+and
+
+\cs-one -> ...
+
+I mean, the only difference is the slightly visible shift of the arrow.
+
+It would be nice if there was some way to show more explicitely these
+space tokens.
+
+Denis.
+
+========================================================================
+Date: Tue, 22 Nov 1994 10:17:03 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Piet van Oostrum <piet@CS.RUU.NL>
+Subject: Re: show space tokens in \tracingmacros
+In-Reply-To: <199411212220.AA03823@relay.cs.ruu.nl>
+
+>>>>> "Denis B. Roegel" <Denis.Roegel@loria.fr> (DBR) writes:
+
+DBR> When you have to debug some weird encoding issue in LaTeX2e,
+DBR> you soon realize that there are internal command names
+DBR> containing a trailing white space. The problem arises when you
+DBR> want to follow some trace given by \tracingmacros.
+
+DBR> For instance, let's imagine two control sequences \cs-one and \cs-one ,
+DBR> the second having a white space (see it ?) at the end.
+DBR> When you trace expansions, you get something like:
+
+DBR> \cs-one -> ...
+
+DBR> and
+
+DBR> \cs-one -> ...
+
+DBR> I mean, the only difference is the slightly visible shift of the arrow.
+
+DBR> It would be nice if there was some way to show more explicitely these
+DBR> space tokens.
+
+Actually, I think the tracing mechanism is defective in more serious ways.
+It is very difficult to track where you are in a deeply nested macro
+expansion sequence. So selective tracing of macros should be possible and
+the run-time nesting structure should be visible. Also assignments should
+be tracable (i.e. the value assigned should be printed).
+
+The tracing system may have been sufficient for plain TeX, but it is in no
+way up to modern software engineering standards in cases like latex2e.
+--
+Piet van Oostrum <piet@cs.ruu.nl>
+
+========================================================================
+Date: Tue, 22 Nov 1994 10:21:12 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Piet van Oostrum <piet@CS.RUU.NL>
+Subject: Re: \showcsname...\endcsname
+In-Reply-To: <199411212205.AA03674@relay.cs.ruu.nl>
+
+>>>>> "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE> (JKM) writes:
+
+JKM> \showcsname ... \endcsname
+JKM> In an increasingly popular macro package the authors make intense use of
+JKM> untypeable (and sometimes almost unreadable) control sequences with
+JKM> spaces, backslashes and other strange tokens in. For analysis I like to
+JKM> have
+
+JKM> \showcsname....\endcsname, which acts like \show.
+
+JKM> Maybe it should be accompagnied by a
+
+JKM> \meaningcsname....\endcsname
+
+How would this differ from \expandafter\show\csname ....\endcsname
+\expandafter\meaning\csname ....\endcsname?
+--
+Piet van Oostrum <piet@cs.ruu.nl>
+
+========================================================================
+Date: Tue, 22 Nov 1994 22:17:34 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
+Subject: Re: \showcsname...\endcsname
+
+Piet's suggestion:
+
+ How would this differ from \expandafter\show\csname ....\endcsname
+ \expandafter\meaning\csname ....\endcsname?
+
+just works fine for me, so I can withdraw this proposal.
+
+--J"org Knappen.
+
+P.S. Thanks for that, it really helps in studying LaTeX2e code.
+
+========================================================================
+Date: Wed, 23 Nov 1994 15:01:12 BST
+Reply-To: Philip Taylor <P.Taylor@Vax.Rhbnc.Ac.Uk>
+From: Philip TAYLOR <CHAA006@VAX.RHBNC.AC.UK>
+Subject: Another idea for e-TeX: \traceingfileio
+
+Having put up the so-called `patch level 4' of LaTeX-2e, I found it expedient
+to allow full sub-directory searching... This was a mistake, since LaTeX-2e
+proceeded to find LTHyphen.Cfg in some arcane unsupported Cyrillic
+sub-directory, but that is by the by...
+
+Rather more importantly, TeX can now appear to take a finite-but-unbounded time
+to find a file that it used to find almost instantaneously. So what I propose,
+specifically bearing in mind the possible requirements of TWG-TDS, is a new
+primitive \tracingfileio: differing positive values would cause greater or
+lesser verbosity, but basically it would shew each attempt to open a file,
+including the particular path which it is currently traversing. I would
+suggest that one use of the granularity would be to differentiate between
+\input, \openin and \font (have I missed any?).
+
+ ** Phil.
+
+========================================================================
+Date: Wed, 23 Nov 1994 16:45:21 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Bernd Raichle <Raichle@INFORMATIK.UNI-STUTTGART.DE>
+Subject: Re: Another idea for e-TeX: \traceingfileio
+In-Reply-To: Philip TAYLOR's message of Wed, 23 Nov 1994 15:01:12 BST
+ <9411231503.AA28121@ifi.informatik.uni-stuttgart.de>
+
+on Wed, 23 Nov 1994 15:01:12 BST, Philip TAYLOR <CHAA006@VAX.RHBNC.AC.UK> said:
+[...]
+Phil> Rather more importantly, TeX can now appear to take a finite-but-unbounded
+ time
+Phil> to find a file that it used to find almost instantaneously. So what I
+ propose,
+Phil> specifically bearing in mind the possible requirements of TWG-TDS, is a
+ new
+Phil> primitive \tracingfileio: differing positive values would cause greater or
+Phil> lesser verbosity, but basically it would shew each attempt to open a file,
+Phil> including the particular path which it is currently traversing. I would
+Phil> suggest that one use of the granularity would be to differentiate between
+Phil> \input, \openin and \font (have I missed any?).
+
+The file name and searching part of TeX is highly _implementation
+dependent_ and in the moment the code to search files in a list of
+directories---probably extended by recursive subdirectory searching---
+is included through the TeX.web change file of the implementation or
+some separate routines (e.g. Karl Berry's kpathsea(rch) routines used
+in web2c).
+
+What we can do is to give the TeX implementors some "hooks" in TeX to
+enable some additional debug output in their routines... if the file
+search routines provide it.
+These "hooks" are comparable with the |fix_date_and_time| procedure,
+providing the initial settings for the \time, \day, \month, \year
+registers, whose default code in TeX.web (returning 12am 07/04/1776)
+has to be replaced by some implementation dependent code.
+
+
+Questions to be answered:
+
+ - Should we try to enable/disable additional implementation dependent
+ debugging output using some TeX registers/primitive commands?
+ - Standardized form of the output or some conventions?
+ Which ones?
+ - Hooks for implementors:
+ registers as flags, like \tracing..., or primitive commands?
+
+Bernd
+
+========================================================================
+Date: Wed, 23 Nov 1994 11:33:03 -0500
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: bbeeton <BNB@MATH.AMS.ORG>
+Subject: Re: Another idea for e-TeX: \traceingfileio
+In-Reply-To: <01HJTEODUK3MEBP7TJ@MATH.AMS.ORG>
+
+bernd raichle points out that there are some features of tex
+that are (legitimately) implementation dependent, including
+the treatment of \openin vs. \input. he proposes that some
+"hooks" be provided in nts to regularize some such features,
+and asks some questions:
+
+ - Should we try to enable/disable additional implementation dependent
+ debugging output using some TeX registers/primitive commands?
+ - Standardized form of the output or some conventions?
+ Which ones?
+ - Hooks for implementors:
+ registers as flags, like \tracing..., or primitive commands?
+
+i can't answer these questions directly, but would like to
+encourage agreement among implementors to present such features
+in a form as similar as possible to the macro writer. it's
+really no fun trying to debug problems that arise because of
+system dependencies on systems *other* than the one(s) one is
+used to using. with tugboat, i've gotten used to the differences
+in end-of-line markers (and routinely convert all files from
+certain authors before trying to process them) and similar,
+but there are still surprises, and they waste a lot of time.
+a uniform presentation -- when possible -- would mean that i
+might really be able to get help from other people who don't
+have exactly the same setup as i do, a luxury that i don't
+now enjoy.
+ -- bb
+p.s. i will still claim publicly that "from tex, you get the
+same output from the same input", but it ain't true, guys!
+not with the inventive minds and highly-tuned personal systems
+that tugboat authors revel in.
+
+========================================================================
+Date: Thu, 24 Nov 1994 00:13:09 +0000
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Timothy Murphy <tim@MATHS.TCD.IE>
+Subject: Re: Another idea for e-TeX: \traceingfileio
+In-Reply-To: <01HJTRI6R1PE00EB6T@mailgate.ucd.ie> from "Bernd Raichle" at Nov
+ 23, 94 04:45:21 pm
+
+> What we can do is to give the TeX implementors some "hooks" in TeX to
+> enable some additional debug output in their routines... if the file
+> search routines provide it.
+
+In my view this request is completely misconceived.
+The sought-for debug facilities are already present in unixTeX
+(in kpathsea-2.4).
+
+I have yet to see a suggestion made by the NTS people
+which I both understand and agree with.
+
+========================================================================
+Date: Thu, 24 Nov 1994 13:26:00 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: "Ciar\\'an \\'O Duibh\\'in" <Csg0070@QUEENS-BELFAST.AC.UK>
+Subject: Transforming glyphs in dvi and vpl files
+
+I've already sent this suggestion to one or two members of NTS, but I've
+just discovered NTS-L, where I should have sent it in the first place!
+Apologies if something like this has already been discussed here.
+
+I'd like to proposed an enhancement to dvi file format:
+
+At present, a dvi file can contain instructions to shift a glyph (but
+I don't think any other operations on a glyph are allowed). I'd like
+to propose three (two really, each is the product of the other two):
+
+Allow a glyph to be:
+1. mirrored in a vertical axis, placed centrally;
+2. mirrored in a horizontal axis, placed at half the x(?)-height;
+3. rotated by 180 degrees about the point of intersection of those axes.
+
+This would greatly increase the power of vpl files (e.g. define schwa by
+rotating e), and I hope that it would be possible for drivers to implement.
+
+Ciar\'an \'O Duibh\'in.
+
+========================================================================
+Date: Thu, 24 Nov 1994 13:54:16 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Angus Duggan <angus@HARLEQUIN.CO.UK>
+Subject: Transforming glyphs in dvi and vpl files
+In-Reply-To: <14173.199411241340@holly.cam.harlequin.co.uk>
+
+"Ciar\\'an \\'O Duibh\\'in" writes:
+>I've already sent this suggestion to one or two members of NTS, but I've
+>just discovered NTS-L, where I should have sent it in the first place!
+>Apologies if something like this has already been discussed here.
+>
+>I'd like to proposed an enhancement to dvi file format:
+>
+>At present, a dvi file can contain instructions to shift a glyph (but
+>I don't think any other operations on a glyph are allowed). I'd like
+>to propose three (two really, each is the product of the other two):
+
+I don't know what you mean by "shift a glyph". The DVI format has instructions
+to put a character at the current position without altering the position, and
+to put a character at the current position, adjusting the current horizontal
+position by the width of the character, taken from the TFM file.
+
+>Allow a glyph to be:
+>1. mirrored in a vertical axis, placed centrally;
+
+What is centrally? The TFM file has the height, width and depth of the
+character, but there need not be any relationship between these dimensions and
+the bounding box of the area marked by the glyph.
+
+>2. mirrored in a horizontal axis, placed at half the x(?)-height;
+
+The x-height is only stored as a fontdimen, by convention. Non-text fonts are
+at liberty to use the fondimen for anything they want.
+
+>3. rotated by 180 degrees about the point of intersection of those axes.
+>
+>This would greatly increase the power of vpl files (e.g. define schwa by
+>rotating e), and I hope that it would be possible for drivers to implement.
+
+I very much doubt that it would be easy to agree on any proposal like this. I
+doubt whether any extensions to the DVI format apart from already existing
+ones (TeX-XeT, and \special conventions) will get significant support from
+driver writers.
+
+>Ciar\'an \'O Duibh\'in.
+
+a.
+--
+Angus Duggan, Harlequin Ltd., Barrington Hall, | INET: angus@harlequin.co.uk
+Barrington, Cambridge CB2 5RG, U.K. | PHONE: +44(0)1223 873838
+
+========================================================================
+Date: Thu, 24 Nov 1994 13:56:03 +0000
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Sebastian Rahtz <Sebastian.Rahtz@CL.CAM.AC.UK>
+Subject: Re: Transforming glyphs in dvi and vpl files
+In-Reply-To: Your message of "Thu, 24 Nov 1994 13:26:00 GMT."
+ <"swan.cl.cam.:161610:941124134520"@cl.cam.ac.uk>
+
+i see why there is the desire to play with glyphs in the dvi file, but
+is it really worth the effort? we know we can do this easily in
+virtual fonts whose only drawback is that they are tied to a driver
+that can implement the \special commands. so why not just work on
+standardizing \specila commands for rotation and mirroring, and you
+can leave the dvi format alone.
+
+sebastian
+
+========================================================================
+Date: Thu, 24 Nov 1994 17:06:50 +0100
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
+Subject: Re: Transforming glyphs in dvi and vpl files
+In-Reply-To: <199411241342.OAA41041@rs3.hrz.th-darmstadt.de> from "Ciar\\'an
+ \\'O Duibh\\'in" at Nov 24, 94 01:26:00 pm
+
+Ciar\'an \'O Duibh\'in wrote:
+>
+> Allow a glyph to be:
+> 1. mirrored in a vertical axis, placed centrally;
+> 2. mirrored in a horizontal axis, placed at half the x(?)-height;
+> 3. rotated by 180 degrees about the point of intersection of those axes.
+
+Others commented already of the problems of the terms `centrally' and
+`x-height' in DVI files. I want to add
+
+ -- DVI drivers are not required (and should not!) to read TFM files,
+ so they don't have access to fontdimens.
+
+Btw, if we adopt your proposal; the next thing that'll be wanted is
+rotating by 90 degrees. (I bet because that was brought up a few
+dozen times before...) Before anybody adds this proposal keep in mind
+that we have devices with non-square ratios where simple matrix
+transformation does not work.
+
+Cheers,
+ Joachim
+ [ex-secretary of ex-committee on DVI Driver Standards]
+
+--
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
+Computer Science Department
+Technical University of Darmstadt, Germany
+
+========================================================================
+Date: Mon, 28 Nov 1994 13:50:00 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: "Ciar\\'an \\'O Duibh\\'in" <Csg0070@QUEENS-BELFAST.AC.UK>
+Subject: Re: Transforming glyphs in dvi and vpl files
+
+Despite the generally unfavourable comment, I'm not dissuaded. I am not being
+flippant in asking for characters to be turned upside-down, as I typeset
+quite a lot of phonetics (and I know there are phonetic fonts). But be
+reassured that I can't think of any useful character made by rotating a
+common character through 90 degrees!
+
+I should also have said that I am looking at this from the viewpoint of
+virtual font construction. Perhaps it was misleading to say "dvi format",
+when I really meant "vpl format". (I did so because there's already a section
+on "dvi format" in the NTS-L FAQ, and Knuth stated in his "Virtual Fonts"
+article that "it's easy for dvi drivers to read vf files, because vf format
+is similar to the pk and dvi formats they already deal with". And I think I
+read that what you are allowed to do in vpl files is limited by what you
+can do in dvi files.)
+
+What I meant by "shifting a glyph" is that the dvi file can contain
+instructions to move anywhere before setting it, and then move back again.
+Turning to vpl files, here's how ptmrq.vpl defines A-acute - note the
+MOVERIGHT and MOVEDOWN:
+
+(CHARACTER O 301
+ (CHARWD R 0.721997)
+ (CHARHT R 0.900989)
+ (MAP
+ (PUSH)
+ (SETCHAR C A)
+ (POP)
+ (PUSH)
+ (MOVERIGHT R 0.1939945)
+ (MOVEDOWN R -0.21399)
+ (SETCHAR O 302)
+ (POP)
+ (MOVERIGHT R 0.721997)
+ )
+ )
+
+What I would like to be able to do, in making a vpl file for phonetics
+from a normal alphabetic font, and needing turned m (i.e. rotated through
+180 degrees), turned h, vertically-flipped (or mirrored) y, horizontally-
+flipped e, etc. would be something like this - any suitable syntax will do:
+ (SETCHAR (TURN C m)) or
+ (SETCHAR (VFLIP C y)) or
+ (SETCHAR (HFLIP C e))
+A nice point is to compare these transformations with what can be done
+with metal type. A turn is no problem there, which is presumably why so
+many new symbols are made that way. But flipping is not possible with
+physical type, though it should be with computers.
+
+The question most people raised was the one I hoped they might answer for
+me: about what point should the glyph be turned, or in what axes should it
+be flipped? I've come to the conclusion that neither general fontdimens
+(quadwidth, xheight) nor individual widths/heights/depths are adequate,
+even if available. The vf designer will have to say, in each individual
+case, where the axes are. And this is ok. Let's say I want to turn the
+"m" of 10pt Adobe Times Roman. This has a width of 0.77799 design units
+(tens of points) and a height of 0.453498 design units. So I might wish
+to say in my vpl file
+ (SETCHAR (TURN 0.388995 0.226749 C m))
+If the result of those values didn't look right (e.g. if the character
+extended outside its nominal width or height), I could adjust the values,
+or apply an additional MOVERIGHT or MOVEDOWN. In fact, we could make all
+flips and turns relative to the reference point, and then the last example
+would be equivalent to:
+ (MOVERIGHT 0.77799) (MOVEDOWN -0.453498) (SETCHAR (TURN C m))
+Or maybe turns and flips should be relative to the centre of the glyph's
+width and height, so that the outline of the box stays where it is. In that
+case this example becomes once again simply
+ (SETCHAR (TURN C m))
+and an additional MOVERIGHT and MOVEDOWN will always achieve the required
+effect if further adjustment is necessary (a MOVEDOWN would certainly be
+needed for turned h, for example).
+
+I didn't fully understand the comment:
+> why not just work on standardizing \special commands for rotation and
+> mirroring, and you can leave the dvi format alone.
+If possible, that would be fine. But aren't specials used for device-specific
+features? The drivers I use are dviscr and dvips. Dviscr has no specials
+for rotation and mirroring, and I don't see how adding them would be any
+easier than dealing with the proposed extension to dvi (recte vpl) format.
+I'm thinking of bitmap fonts just as much as outline fonts, by the way.
+
+Ciar\an \'O Duibh\'in.
+
+========================================================================
+Date: Mon, 28 Nov 1994 14:58:59 MEZ
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@dearnpc.gmd.de>
+From: Werner Lemberg <A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT>
+Subject: Re: Transforming glyphs in dvi and vpl files
+In-Reply-To: Message of Mon, 28 Nov 1994 13:50:00 GMT from
+ <Csg0070@QUEENS-BELFAST.AC.UK>
+
+On Mon, 28 Nov 1994 13:50:00 GMT Ciar\\'an \\'O Duibh\\'in said:
+>Despite the generally unfavourable comment, I'm not dissuaded. I am not being
+>flippant in asking for characters to be turned upside-down, as I typeset
+>quite a lot of phonetics (and I know there are phonetic fonts). But be
+>reassured that I can't think of any useful character made by rotating a
+>common character through 90 degrees!
+>
+
+What about Chinese/Japanese?
+
+ Werner
+
+PS: I know, I know, TeX is not really used to these languages :-)
+
diff --git a/info/digests/nts-l/9412 b/info/digests/nts-l/9412
new file mode 100644
index 0000000000..60b7af051b
--- /dev/null
+++ b/info/digests/nts-l/9412
@@ -0,0 +1,113 @@
+========================================================================
+Date: Tue, 13 Dec 1994 01:28:21 -0800
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: LIONEL GOLDBERG <actuary@IX.NETCOM.COM>
+Subject: Court Ordered Liquidation - Computer Memory - CPU's & Hdsk Drives
+
+Choice Trading Company, Court Appointed Liquidators, have
+been assigned to liquidate the following Multi-Million Dollar
+inventory of computer Memory Chips, CPU's and Hard Disk Drives.
+All items are new and come with applicable manufactures warranty.
+Prices quoted include all state and local taxes plus shipping and
+handling.
+
+Order Cost
+Number Mfg. Description (EACH)
+
+Memory
+
+1524 Toshiba 30 Pin Simms 1x3 70ns 1 meg $ 25.00
+1525 Toshiba 30 Pin Simms 1x9 70ns 1 meg 25.00
+1526 Toshiba 30 Pin Simms 4x9 70ns 4 meg 100.00
+
+1527 Toshiba 30 Pin Simms 1x3 60ns 1 meg 26.00
+1528 Toshiba 30 Pin Simms 1x9 60ns 1 meg 26.00
+1529 Toshiba 30 Pin Simms 4x9 60ns 4 meg 106.00
+
+1624 Toshiba 72 Pin Simms 512x36 70ns 2 meg 50.00
+1625 Toshiba 72 Pin Simms 1x36 70ns 4 meg 100.00
+1626 Toshiba 72 Pin Simms 2x36 70ns 8 meg 200.00
+1627 Toshiba 72 Pin Simms 4x36 70ns 16 meg 400.00
+1628 Toshiba 72 Pin Simms 8x36 70ns 32 meg 800.00
+
+1624 Toshiba 72 Pin Simms 512x36 60ns 2 meg 52.00
+1625 Toshiba 72 Pin Simms 1x36 60ns 4 meg 104.00
+1626 Toshiba 72 Pin Simms 2x36 60ns 8 meg 208.00
+1627 Toshiba 72 Pin Simms 4x36 60ns 16 meg 416.00
+1628 Toshiba 72 Pin Simms 8x36 60ns 32 meg 832.00
+
+Memory for the Macintosh
+
+1122 Toshiba 1 meg x 8 Simm Module 70ns 1 meg 31.00
+1123 Toshiba 2 meg x 8 Simm Module 70ns 2 meg 62.00
+1124 Toshiba 4 meg x 8 Simm Module 70ns 4 meg 109.00
+
+CPU's
+
+1276 Intel 80486 DX/33 115.00
+1277 Intel 80486 DX/50 188.00
+1278 Intel 80486 DX-2/66 156.00
+1279 Intel 80486 DX-4/75 358.00
+1280 Intel 80486 DX-4/100 498.00
+1281 Intel Pentium 80501-60 366.00
+1282 Intel Pentium 80501-66 453.00
+1283 Intel Pentium 80502-90 558.00
+
+Hard Disk Drives
+
+Seagate Barracuda Drives
+1351 Seagate ST11950N 8ms 3.5" 1.69 GB SCSI 658.00
+1352 Seagate ST12550N 8ms 3.5" 2.1 GB SCSI 899.00
+1353 Seagate ST15150N 8ms 3.5" 4.2 GB SCSI 1,526.00
+1354 Seagate ST31200N 11ms 3.5" 1.05 GB SCSI 538.00
+1355 Seagate ST11900N 9ms 3.5" 1.7 GB SCSI 628.00
+1366 Seagate ST2400A 9ms 3.5" 2.1 GB SCSI 856.00
+1367 Seagate ST15230N 9ms 3.5" 4.29 GB SCSI 1,454.00
+1368 Seagate ST41080N 11ms 5.5" 9.08 GB SCSI 2,848.00
+
+Western Digital
+1366 Western AC2340 12ms 3.5" 340 MB IDE 122.00
+1367 Western AC2420 12ms 3.5" 420 MB IDE 136.00
+1368 Western AC2540 12ms 3.5" 540 MB IDE 160.00
+1369 Western AC2700 12ms 3.5" 731 MB IDE 230.00
+
+Conner
+1372 Connor CFS420A 14ms 3.5" 420 MB IDE 138.00
+1373 Connor CFA540A 10ms 3.5" 540 MB IDE 168.00
+1374 Connor CFA1080A 10ms 3.5" 1080 MB IDE 408.00
+
+ORDERING INFORMATION
+
+To order please use a company order form/letterhead or if for
+personal use, use a plain white sheet of paper with your return
+address. List the items desired by order number, the quantity
+and total cost. Send your order with check or money order
+payable to Choice Trading Company to:
+
+Choice Trading Company
+Order Processing Lot #1776
+86228 Terminal Annex
+Los Angeles, Ca. 90086-0228
+
+Orders are processed on a first come basis. Adjustments and
+refunds will be made immediately for items that have sold out.
+Please allow 2 to 3 Weeks for shipping. Due to court ordered
+restrictions we are unable to accept COD, phone or credit card
+orders.
+
+This public offering is valid through December 30, 1994. Any
+unsold inventories will be auctioned. For auction information
+please send a self addressed stamped enveloped to:
+
+Choice Trading Company
+Lot #1776
+202 So. Broadway
+Los Angeles, Ca. 90012
+(213) 856 6172
+
+If you are unable to use this information, please pass it on to
+someone who may.
+
+Lionel M. Goldberg
+Actuary
+
diff --git a/info/digests/nts-l/9501 b/info/digests/nts-l/9501
new file mode 100644
index 0000000000..331f8bd6b5
--- /dev/null
+++ b/info/digests/nts-l/9501
@@ -0,0 +1,32 @@
+========================================================================
+Date: Fri, 13 Jan 1995 11:03:08 -0500
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Michael Downes <MJD@MATH.AMS.ORG>
+Subject: \eqno, \leqno should not be math mode
+
+A suggestion for e-TeX:
+
+The contents of \eqno, \leqno should be typeset in text mode, not math
+mode. In particular, they should not call \everymath. Equation numbers
+are inherently textual in nature, like all the other structural
+numbering in a document, even though we sometimes embellish them with
+bits of math or want to use centered math * instead of raised text *.
+
+Michael Downes
+mjd@math.ams.org
+
+========================================================================
+Date: Fri, 13 Jan 1995 16:25:15 GMT
+Reply-To: NTS-L Distribution list <NTS-L%DHDURZ1.BITNET@vm.gmd.de>
+From: Philip Taylor <CHAA006@VMS.RHBNC.AC.UK>
+Subject: Re: \eqno, \leqno should not be math mode
+
+>> The contents of \eqno, \leqno should be typeset in text mode, not math
+>> mode. In particular, they should not call \everymath. Equation numbers
+>> are inherently textual in nature, like all the other structural
+>> numbering in a document, even though we sometimes embellish them with
+>> bits of math or want to use centered math * instead of raised text *.
+
+Many thanks for your suggestion, Michael: I will ensure that it
+is discussed. ** Phil.
+