Date: Tue, 31 Jan 1995 21:15:16 +0100
Sender: NTS-L Distribution list <NTS-L@DHDURZ1.EARN>
From: "J%org Knappen, Mainz" <KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE>
Subject: Frequently asked questions of NTS-L, 5th edition
X-To: nts-l <nts-l@dhdurz1.bitnet>
To: Multiple recipients of list NTS-L <NTS-L@DHDURZ1.EARN>
Frequently Asked Questions of NTS-L
Fifth edition
Date: 31-JAN-1995
Archive name: nts-l-faq
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
1.5. Writing more than one dvi-file
1.6. Anchors
1.7. dump/restore mechanism
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
2.12. \protected
2.13. \scantokens
2.14. \deferred
2.15. \everyeof
2.16. \readline
2.17. \evaluate
2.18. \ifevaluate
2.19. \everyeof
2.20. \fancyprompt
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
3.5. Extensions and Enhancements
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
7.1. Horizontal and Vertical Mirroring
7.2. Rotation of a glphy by 180 degrees
8. Additions to the TeX kit
8.1. dvicopy
8.2. dv2dp and dp2dv
8.3. gftotxt
8.4. qdtexvpl
8.5. fontinst
8.6. afmtotfm
8.7. dvipaste
8.8. METAPOST
8.9. Tie
8.10. dvi2dvi
9. Existing extensions to TeX
9.1. TeX-XeT
9.2. TeX--XeT
9.3. MLTeX
9.4. SiSiSi
9.5. Japanese TeX
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.
Omega is now announced to be presented at March 16, 1995 at CERN (Geneva).
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)
Remark: UTF-8 (UNICODE) can be handled with `TeX classic', LaTeX2e
support is provided by the CJK package written by Werner Lemberg.
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.
1.5. Writing more than one dvi-file (Nov 94)
I want to have TeX ready in the memory and avoid loading it anew and anew
for each run again which costs lots of startup time, if you have to load
every file via NFSS.
The idea I am toying with is to have something like
\level
which clones the current state of TeX and allows to start a new dvi-file.
Then you do anything you want (start even another \level) and at last you say
\exit
which performes like \end, except that it restores exactly the state before
the last cloning.
To communicate some information to the waiting lion, there may be one
exeption. You say
\exit{some_integer_number}
and this number can be read by using
\exitstatus.
Applications are many. If you have a format which usually requires several
runs, you can do all the runs within one job, and automatically decide,
whether a further run is necessary. Of course, you should device your format
to have a counter maxruns to avoid endless looping...
1.6. Anchors (Nov 94)
Proposed by Jiri, an ``anchor point'' would be in some senses
be analogous to a mark, but rather than recording textual information it
would instead record the co-ordinates of itself, relative to the reference
point of the smallest surrounding box. Additional new primitives would
be required to return the co-ordinates of a specified anchor point.
1.7. dump/restore mechanism
I'd suggest something much simpler, but also more general: Include \dump in
all versions of TeX. The initex/virtex distinction is simply not worth the
bother of retaining any more - the memory differences are trivial in modern
terms. \dump should ideally also be extended to allow dumping from inside of
a group.
Once you do this, it becomes possible to write programs to analyze format
files. Since the analysis programs would not be part of TeX proper, they can
be as elaborate as anyone might want to make them. Sorting would be no
problem, for example.
None of this would cost anything in TeX itself, and except for the ability
to \dump inside a group, if added, would not even have an effect on whether
the resulting E-TeX is properly "TeX", since it would be invisible to any
possible trip test.
2. Proposed additions to TeX (concrete new primitives)
2.0. General (Jun 92, Jul 92, Aug 93, Nov 94)
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...
A list of new primitives, enhancements and extensions has been prepared
on the NTS meeting at Lindau in October 1994. It was posted to this list in
November 1994 and provoked plenty of discussions and additional suggestions.
Under the discussed primitves were \bind, \contents<box#>, \futuredef,
\ifdefined, \ifcsname ... \endcsname, \unless, \OSname, \defaultextension.
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)
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
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.
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.
2.12. \protected (new prefix for macro definitions) (Nov 94)
Analogous to \long, \outer, etc., causes the associated macro to be
non-expanding in contexts where such behaviour is likely to be undesirable
(in particular in \writes and \edefs); an explicit \expandafter \empty
may be used to force expansion in these circumstances.
2.13. \scantokens (Nov 94)
Allows an existing token-list to be re-input under a different catcode regime
from that under which it was created; as it uses all of TeX's present \input
mechanism, even %%ff notation will be interpreted as if \input. Causes an
`empty filename' to be input, resulting in `( )' appearing in the log file
if \tracingscantokens (q.v.) is strictly greater than zero. If the token
list represents more than one line of input, and if an error occurs, then
\inputlinenumber will reflect the logical input line from the token list
rather than the current input line number from the current file.
2.14. \deferred (Nov 94)
At the moment, only \writes are deferred; there are cases when it would
be desirable for other things, too, to be expanded only during \shipout,
and \specials are one of these. (See also 2.2.3)
2.15. \everyeof {<balanced text>}
Provides a hook whereby the contents of a token list register may be
inserted into TeX's reading orifice when end-of-file is encountered
during file reading. Would not be invoked of the file indicated
logical e-o-f through the medium of \endinput. Proposed by Phil
to allow clean processing of file-handling code which requires
a (sequence of characters yielding) \else or fi to be found in a
file, where no such sequence can be guaranteed.
2.16. \readline <integer> to <cs> (Nov 94)
Allows a single line to be read from an input file as if each character
therein had catcode 12. Intended to be used for verbatim copying
operations, in conjunction with \scantokens, or to allow error-free parsing
of `foreign' (non-TeX) files.
2.17. \evaluate {<arithmetic expression>} (Nov 94)
Intended for use on the r-h-s of \count, \dimen and \skip assignments,
it would allow the use of infix arithmetic operators such as +, -, * and /;
the type of the result would, in general, be the type of the simplest operand
forming a part of the expression, and the normal semantics of TeX would allow
this to be further coerced where necessary. Parenthesised sub-expressions
would be allowed.
Additional operations were proposed: trigonometric functions, square
root, pythagorean addition (METAFONT's `++'), angle{<delta_x, delta_y>}.
2.18. \ifevaluate{<boolean expression>}....\else....\fi (Nov 94)
The boolean expression should allow for the usual operators like
.not., .and., .or., .xor., =, >, <, <=, etc., if feasable it should also
allow the evaluation of arithmetic expressions. Some functions are needed
to get information old TeX \if's know now, I propose the name
\query<whatever> to these functions.
At the moment I see need for the following \query<whatever> functions:
\queryeof returns `1' if eof, `0' else
\querymode returns `0' in the infamous `no mode' (do we need to
differentiate finer here?
`1' in vertical mode
`2' in restricted vertical mode
`3' in horizontal mode
`4' in restricted horizontal mode
`5' in math mode
`6' in restricted math mode
With \querymode \ifmmode, \ifhmode, \ifvmode, and \ifinner can be emulated.
\querydefined{\cs} `1' if defined, `0' else
\querycsname...\endcsname (ditto)
2.19. \everyeof {<balanced text>}
Provides a hook whereby the contents of a token list register may be
inserted into TeX's reading orifice when end-of-file is encountered
during file reading. Would not be invoked of the file indicated
logical e-o-f through the medium of \endinput. Proposed by Phil
to allow clean processing of file-handling code which requires
a (sequence of characters yielding) \else or fi to be found in a
file, where no such sequence can be guaranteed.
2.20. \fancyprompt
allow configuration of the TeX prompt (default `*'), e.g.
*\fancyprompt{eTeX>}
eTeX>
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, the latter seem to be quite unregular and
baroque.
3.5. Extensions and Enhancements (Nov 94)
`Extensions' are basically new primitives which have no effect on the
semantics of existing TeX documents, except insofaras any document which
tests whether such a primitive is, in fact, undefined, will clearly obtain
opposite results under TeX and e-TeX; `enhancements' are more fundamental
changes to the TeX kernel which may affect the semantics of existing TeX
documents even if no new primitive is used or even tested. Such changes
may be, for example, differences in the construction of TeX's internal
lists, or perhaps different hyphenation or ligaturing behaviour.
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.
On comp.text.tex I saw a remark, that specials may occur on places in the
dvi-file, where TeX can't put them. Maybe eTeX should take care of this
point.
7.1. Horizontal and Vertical Mirroring (Nov 94)
Allow a glyph to be mirrored in a vertical axis, placed centrally;
mirrored in a horizontal axis, placed at half the x(?)-height.
It was noted, that the specification of the axes might cause problems.
It was also noted, that several drivers understand specials for the
requested action.
7.2. Rotation of a glphy by 180 degrees (Nov 94)
This would greatly increase the power of vpl files (e.g. define schwa by
rotating e), and I hope that it would be possible for drivers to implement.
It was noted, that this is fine, but rotation by 90 degrees cannot be
device independent, because there are printers with rectangular (non-square)
pixels.
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, gftype, (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.
Another group includes drawing programmes (TeXCAD, xfig, gnuplot, ...) to
create graphics to be imported to TeX documents and graphics converters
(ghostscript, xv, bmt2font, ...).
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. dv2dp and dp2dv
Written in C by Geoffrey Tobin
Available on request from the author
dv2dp makes a human readable file from a dvi file. The companion
programme dp2dv 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
Available from the CTAN archives
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.
8.7. dvipaste
Part of LAMSTeX (Michael Spivak)
Allows to paste a dvi-file into another one.
8.8. METAPOST
Written in Web by John Hobby
Now freely available from the CTAN
A tool to build graphics to be included in TeX documents, uses a METAFONT
style language.
8.9. Tie
Written by Klaus Gunthermann
Available from CTAN
Allows to process multiple change files to a given Web source. A tool
of this kind is needed to build any eTeX distribution, since one has
tex.web, etex.ch, tex.ch-system, and etex.ch-system files to deal with.
8.10. dvi2dvi
Available from CTAN
Postprocessor for dvi files, allowing e.g. 2-up or 4-up layout of full
pages.
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).
9.5. Japanese TeX
[in preparation]
The End.
Generated by dwww version 1.15 on Thu May 23 05:50:41 CEST 2024.