summaryrefslogtreecommitdiff
path: root/info/digests/nts-l/9410
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/digests/nts-l/9410
Initial commit
Diffstat (limited to 'info/digests/nts-l/9410')
-rw-r--r--info/digests/nts-l/94101187
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
+