Objectives

Modularity

εχT_EX's object-oriented design (see figure) includes some main modules that act without knowledge about the functioning of the other modules (encapsulation). Thus the frontend with tokenisation and the expansion of tokens, up to the creation of nodes are exchangeable, independently from the typesetter. The same applies to the backend that generates the output. A special role plays the font module that provides font information to the typesetter as well as to the output module.

Inside the main modules other subdivisons are established, making subtitution or enhancement of single aspects of a function possible. So the font module may be extended to new formats by adding or replacing a font reader, without directly affecting other parts of the program. Likewise new algorithms may be integrated into the typesetter that is responsible for line breaking and the structure of the page.

Compatibility

εχT_EX will provide all of T_EX's primitives. Since syntax and function of some primitives (e.g. \input) leads to undesirable constraints on modern systems, supplemental primitives will be designed and implemented in these cases. The old variants will clearly be marked obsolete. In some cases this has been done already. Hardly understandable peculiarities of T_EX can be abandoned in favour of a clean implementation. Moreover the behaviour in case of an error will not be emulated completely equally. Eventually εχT_EX shall be able to typeset existing documents visually identically to T_EX.

εχT_EX will not be compatible regarding the strict separation of iniT_EX and virT_EX. So far, loading of hyphenation patterns and creation of format files is possible only for iniT_EX. εχT_EX on the other hand shall be able to load hyphenation patterns globally at any time, i.e. it shall not be limited to hyphenation tables that are stored in the format files. Therefore it will be possible to load only those hyphenation tables at runtime that are actually needed. εχT_EX also has the ablility to create a format under particular conditions, namely outside of any group.

From ε-T_EX mainly those facilities will be adopted whose main effect is not limited to the logging messages. The additional tracing primitives are not adopted to the vocabulary of εχT_EX because εχT_EX will provide its own progressive facilities for debugging purposes. The facilities of ε-T_EX to toggle the direction of writing will be omitted, too. These can be realised with the help of Ω-compatible primitives on macro level. Thus compatibility to real existing ε-T_EX documents should be obtained.

From Ω the extensions regarding the fonts will be taken, as well as the feature of setting the direction of writing. However εχT_EX will not adopt the encoding functions of Ω, but instead realise 16-bit capability with its own easily comprehensible methodes. Here established basic facilities of Java will be used.

There are two kinds of pdfT_EX features: those controlling PDF output, and those providing additional typographic features. The latter shall be widely adopted. Here the problem arises that in pdfT_EX these primitives are prefixed with »pdf«, too. Hence new names and partially other primitives will replace them in εχT_EX. As above, macros may be used as the connective link. In most cases, e.g. with L^AT_EX packages like graphics or hyperref, a change to a new driver is recommended. This all the more, as the way to implement capabilities that are strongly depenent on the backend is different inεχT_EX.

New Features

Although εχT_EX is designed so that new facilities can easily be added to every main module – actually on the level of primitives – εχT_EX will right from start be equipped with some innovations. One of these is the handling of different encodings of input files. At this εχT_EX uses Java's built-in facilities to transfer read characters into an internal 32-bit coding.

As several of T_EX's primitives are limited to 8-bit, and Ω to 16-bit, new appropriate equivalents will be defined, e.g. for \mathcode. On the other hand, \char will be able to handle values greater than 255 directly. Actually this is an incompatibility to T_EX, but since T_EX would report an error in this case, this behaviour is compatible to existing error-free documents.

Expansions that do not depend on a specific output format, but are – even in various ways – supported by different output formats, will have their own primitives. Examples for this are the begin and end of links as well as their targets./

T_EX knows elements that do not deal with typography of the page, but they must be processed when it is written out (\shipout). Examples for this whatsits are \openout, \closeout and \write, always without being prefixed with \immediate. Especially these should not have any effect on page breaking, which can't be guaranteed by T_EX as is. This deficency shall be improved in εχT_EX, despite arising incompatibilities.

Among the whatsits, the \special primitive plays a special role. Depending on its meaning, it may have effects on line or page breaking (e.g. if a graphic is inserted), or not (e.g. if colour is changed). Apart from the fact that εχT_EX will support colours directly, εχT_EX will have a new primitive for extensions that depend on the output format. When encountering this primitive, the typesetter will demand the decision whether the element affects line or page breaking from the backend (see IObject and Boxsize in the figure). For example, a PDF backend may return the size of an image that was inserted by this primitive.

Medium-term εχT_EX shall provide graphical elements like lines of arbitrary gradient, ellipses, bezier curves etc. Also graphical transformations like rotation, reflexion, or scaling shall be implemented.