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/9410 | |
Initial commit
Diffstat (limited to 'info/digests/nts-l/9410')
| -rw-r--r-- | info/digests/nts-l/9410 | 1187 |
1 files changed, 1187 insertions, 0 deletions
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 + |