diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/digests/nts-l |
Initial commit
Diffstat (limited to 'info/digests/nts-l')
23 files changed, 3814 insertions, 0 deletions
diff --git a/info/digests/nts-l/9205.gz b/info/digests/nts-l/9205.gz Binary files differnew file mode 100644 index 0000000000..f447faef5a --- /dev/null +++ b/info/digests/nts-l/9205.gz diff --git a/info/digests/nts-l/9206.gz b/info/digests/nts-l/9206.gz Binary files differnew file mode 100644 index 0000000000..74f9636f0c --- /dev/null +++ b/info/digests/nts-l/9206.gz diff --git a/info/digests/nts-l/9207.gz b/info/digests/nts-l/9207.gz Binary files differnew file mode 100644 index 0000000000..3d737378a8 --- /dev/null +++ b/info/digests/nts-l/9207.gz diff --git a/info/digests/nts-l/9208.gz b/info/digests/nts-l/9208.gz Binary files differnew file mode 100644 index 0000000000..6c91510aa3 --- /dev/null +++ b/info/digests/nts-l/9208.gz diff --git a/info/digests/nts-l/9210.gz b/info/digests/nts-l/9210.gz Binary files differnew file mode 100644 index 0000000000..51de1e2faf --- /dev/null +++ b/info/digests/nts-l/9210.gz diff --git a/info/digests/nts-l/9211.gz b/info/digests/nts-l/9211.gz Binary files differnew file mode 100644 index 0000000000..7e80ef5107 --- /dev/null +++ b/info/digests/nts-l/9211.gz diff --git a/info/digests/nts-l/9302.gz b/info/digests/nts-l/9302.gz Binary files differnew file mode 100644 index 0000000000..7ae5eb0717 --- /dev/null +++ b/info/digests/nts-l/9302.gz diff --git a/info/digests/nts-l/9303.gz b/info/digests/nts-l/9303.gz Binary files differnew file mode 100644 index 0000000000..c3668043df --- /dev/null +++ b/info/digests/nts-l/9303.gz diff --git a/info/digests/nts-l/9304.gz b/info/digests/nts-l/9304.gz Binary files differnew file mode 100644 index 0000000000..1a9c8bf41b --- /dev/null +++ b/info/digests/nts-l/9304.gz diff --git a/info/digests/nts-l/9305.gz b/info/digests/nts-l/9305.gz Binary files differnew file mode 100644 index 0000000000..463603cc79 --- /dev/null +++ b/info/digests/nts-l/9305.gz diff --git a/info/digests/nts-l/9306.gz b/info/digests/nts-l/9306.gz Binary files differnew file mode 100644 index 0000000000..23c1ac58b0 --- /dev/null +++ b/info/digests/nts-l/9306.gz diff --git a/info/digests/nts-l/9308.gz b/info/digests/nts-l/9308.gz Binary files differnew file mode 100644 index 0000000000..f73974ec75 --- /dev/null +++ b/info/digests/nts-l/9308.gz diff --git a/info/digests/nts-l/9309.gz b/info/digests/nts-l/9309.gz Binary files differnew file mode 100644 index 0000000000..ae2661c036 --- /dev/null +++ b/info/digests/nts-l/9309.gz diff --git a/info/digests/nts-l/9310.gz b/info/digests/nts-l/9310.gz Binary files differnew file mode 100644 index 0000000000..b5f6a19a41 --- /dev/null +++ b/info/digests/nts-l/9310.gz diff --git a/info/digests/nts-l/9311.gz b/info/digests/nts-l/9311.gz Binary files differnew file mode 100644 index 0000000000..31e1dfbe09 --- /dev/null +++ b/info/digests/nts-l/9311.gz diff --git a/info/digests/nts-l/9312.gz b/info/digests/nts-l/9312.gz Binary files differnew file mode 100644 index 0000000000..cb21650623 --- /dev/null +++ b/info/digests/nts-l/9312.gz diff --git a/info/digests/nts-l/9401.gz b/info/digests/nts-l/9401.gz Binary files differnew file mode 100644 index 0000000000..5171735a89 --- /dev/null +++ b/info/digests/nts-l/9401.gz 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. + |