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 in directory pub/tex/documentation/nts-lEach 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.)
Related stuff which is very worth reading you can find on the CTAN archives under digests/tex-implementors.
In addition, I recommend reading the list of TeX bugs (systems/knuth/errata/tex82.bug).
At DANTE '93, held at the Technical University Chemnitz, Joachim
Lammarsch, President of
see also:
As of September 1994, there are two activities going on, the e-TeX group is working on an extension of TeX and is going to produce a first e-TeX soon. The NTS group (NTS = New Typesetting System) takes the path to reimplement TeX in Common LISP to get a deeper understanding of how the modules of TeX are cooperating which each other.
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 containing subscribe omega YOUR NAME to LISTSERV@ens.fr.
Omega was presented at March 16, 1995 at CERN (Geneva). (Can anyone give some information about the presentation?)
Optimised page breaking, avoiding ``rivers'', letterspacing (see also "Automated Kerning"), Hyphenation (Haupt- und Nebentrennstellen, see also SiSiSi), grid typesetting.
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 have 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)
\skylinehorizontallimit (a)
line 1: ------------
| |
| | ----------
------- <== (a) ==> | |
^ | |
(b) | -------
v |
----------------------
line 2:
and other parameters, but the necessary parameter set, realization,
etc. for "skylines" are subject of discussion.
Typesetting in arbitrary directions,
unicode support (16bits),
ISO/IEC
10646-1 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.
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 Peter 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.
Windows support, WYSIWYG-like features.
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 Common Lisp), 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.
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
and this number can be read by using\exit{some_integer_number}
\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...
Proposed by Jiri Zlatuska, 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.
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.
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
\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 the NTS-L
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.
\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}.)
\system (Mar 93)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, and 3. Syntax.
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.
And here's from the ``Minority Report'' (Tim Murphy and Jörg 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 program 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 e-TeX and use other
products, even if they are far less secure. (JK)
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:
and one like\system{foo}or\immediate\system{foo}
\read:
The latter one would produce the exit code into\system{foo} to \bazor\immediate\system{foo} to \baz
\baz.
Should this be done with catcode 12 characters, or should it be done
like \read, with the current catcodes?
\skylineskiplimit,
\skylinehorizontallimit\directioncode (May 1993)A \directioncode (with syntax analogous to
\uccode, \lccode, \sfcode) to
be assigned to each input character. The basic ones are
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.
\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
which are the text (hmode) equivalent of TeX's\textcode(and\textchar&\textchardef)
\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
\mathcode)
\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.]
\afterfi (August 1993)In the answer to an exercise of the
``Around the
Bend'' series (posted to the newsgroup comp.text.tex,
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.
\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)
\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
This means that <num1> is easily expressed in octal and <num2> in hexadecimal notation.
<..._atom_type> is one of the following seven types:
<..._spacing> can be specified separately for each of the four math styles (display, text, script and scriptscript) with the following values:
For more information see TeXbook, pp. 170f & Appendix G and TeX-The Program, ¶ 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 = "0033Between a large operator (= 1) and an ordinary (= 0) atom a thin space (= 1) is inserted:
\mathspacing '10 = "1111Necessary changes for the sketched proposal are very simple to implement.
The syntax of
\mathspacingis awful, but this is true for\mathcode,\delimitercode, etc.etc., too.
\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
to be compatible with TeX's standard behaviour.\inputescapechar = -1\outputescapechar = `^
\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 |}.
\outputunit (Dec 93)\outputunit
\outputunit=<unit of measure> (s. TeXbook p. 270)
\outputunit whould make TeX much more user-friendly,
since only a few people are thinking in points.
\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.
\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.
\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 ``Syntax of
\system'')
\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 Taylor 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.
\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.
\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>}.
\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
\querymode returns
With \querymode \ifmmode,
\ifhmode, \ifvmode, and
\ifinner can be emulated.
\querydefined{\cs} returns
\querycsname...\endcsname
\fancyprompt*\fancyprompt{eTeX>}eTeX>
Remarks about group efforts vs. one person creating software (Mar 93), ALGOL 68 as a warning example.
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.
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 called `e-TeX'. This implies that the enhancements are implemented as change files in WEB.
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 Common Lisp: One cannot program it. One can only configure it.
Its control constructs are simpler than in Common Lisp: Only macros, no functions. And the macros are only simple ones, one can't compute in them.
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.
`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.
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.
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.
Most of the General points in the discussion of TeX also apply to METAFONT.
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).
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).
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.
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 e-TeX should take care of this point.
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.
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.
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:
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, bm2font, ...).
Written in WEB by Peter Breitenlohner
Available from CTAN:
tex-archive/dviware/dvicopy
(and is included in the web2c package)
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).
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.
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.
Written by Eberhard Mattes
Available from CTAN:
tex-archive/fonts/utilities/qdtexvpl
Generates a virtual font from TeX macros. qdtexvpl was one
of the first available virtual font tools (`qd' = quick and dirty);
nowadays fontinst is one of the standard tools for virtual
font creation.
Written in TeX by Alan Jeffrey
Available from CTAN:
tex-archive/fonts/utilities/fontinst
Makes virtual fonts from afm files (PostScript fonts). Used by the LaTeX
team to create virtual fonts and fd files for LaTeX2e.
Written in C by Thomas Rokicki et.al.
Available from CTAN (part of dvips distribution):
tex-archive/dviware/dvips
Makes tfm files from afm files. (Out-of-date for LaTeX2e, see
fontinst)
Part of LAMSTeX (Michael Spivak)
Available from CTAN:
tex-archive/macros/lamstex
Allows to paste a dvi-file into another one.
Written in Web by John Hobby
Now freely available from CTAN:
tex-archive/graphics/metapost
A tool to build graphics to be included in TeX documents, uses a METAFONT
style language.
Written by Klaus Gunthermann
Available from CTAN:
tex-archive/web/tie
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.
Written by Thomas Rokicki et.al.
Available from CTAN:
tex-archive/dviware/dvidvi
Postprocessor for dvi files, allowing e.g. 2-up or 4-up layout of full
pages.
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 e-TeX, NTS, nor Omega.
Donald Knuth and Pierre~MacKay, Mixing right-to-left texts with left-to-right texts, TUGboat 8,1 April 1987, pp.14-25.
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.
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).
(An improved version of TeX--XeT will be part of e-TeX, version 1. Therefore the available change file for TeX 3.141 is out of date and won't be updated to newer TeX versions!)
Adds a primitive \charsubdef specifying a replacement
accent construction for non existing characters in the current font.
This 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 (see emTeX documentation).
CTAN: tex-archive/systems/unix/sisisi
CTAN: tex-archive/systems/vms/sisisi (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'). It replaces TeX's pattern oriented hyphenation algorithm by an algorithm using a tagged dictionary. This dictionary contains syllables/word parts which are used to construct the word or the words in a compound word giving the main hyphenation points (`Haupt=trenn=stellen'). Then a hardcoded algorithm for german syllable based hyphenation is applied to the word parts of the compound word giving the normal hyphenation points (`Ne-ben=trenn=stel-len') with a higher associated penalty than `Haupttrennstellen'. Contradicting hyphenation points (e.g. `Bau-mast' vs. `Baum-ast') are ignored.
Because TeX's original hyphenation algorithm is removed and replaced by the new one, SiSiSi fails the trip test, therefore not a legitimate TeX. In use at TU Wien (Austria).
[in preparation]
raichle@Informatik.Uni-Stuttgart.de wwwmaint@dante.de