Development     Documentation     Download    

State of Implementation

The state of development is associated to the following component diagram of εχTEX. You can click on the diagram to navigate to the corresponding information.

ExTeX Component Diagram Main Control ExTeX Instance Interpreter Context Input Filter Input Subsystem Interpreter Interpreter Subsystem DVI Writer PDF Writer PS Writer EPS Writer SVG Writer Output Filter Node Pipe Document Writer Backend Scanner Typesetter Page Builder Paragraph Builder Ligature Builder Hypenation Typesetting Subsystem Localizer Generic Factory Configuration Support Resource Finder Framework Font ExTeX Font Metrics TeX Font Metrics Adobe Font Metrics TrueType Fonts Virtual Fonts PFB OpenType Fonts Font Family Font Subsystem

Main Control

The components of εχTEX are tied together by a main program. Currently a TEX-compatible command line main program is provided with εχTEX. This main program is pretty complete. Other main programs can be envisaged in the future.

ExTeX Instance

The εχTEX instance ties together the core funtionality. It abstracts from any user interaction. This central component is fully functional.

Input Subsystem

The input subsystem is responsible for reading from an input stream and tokenizes it.

Input Filter

Input filters can be used to preprocess the input stream before it is seen by the scanner. Currently no input filters are provided.


Two implementations for the scanner are fully functional. They provide a TeX-compatible and an extended functionality.

Interpreter Subsystem

The interpreter subsystem provides a TEX-compatible macro processor. This is based on a context which contains the state of the whole engine – like the eqtable of TEX.


The interpreter is nearly complete. Registers, conditionals, macros, file IO – including a configurable \write18 – are in place. Some functionality is not complete – like the outer flag for macros.

Interpreter Context

There are two implementation of the context. One with the TEX-compatible set of registers and one with additional registers – like real numbers. Those contexts are pretty stable. Only the observability   for tracing and debugging   needs to be completed.

All primitives of TEX are present but not fully functional. Especially the primitives related to math typesetting and table typesetting need further attention. Some extensions from ε-TEX, pdfTEX, and Ω have already been implemented.


The backend contains all components which process the page after the typesetting is complete. Usually this processing involves the translation of the nodes into some external format. Optionally some processing can be performed on the nodes before they are translated and on the byte stream after the translation.

Document Writer

The document writer defines the translation of nodes into a native output format. Several implementations are provided.

DVI Writer

The DVI format is the original output format of TEX. εχTEX comes with two implementations to produce DVI. One is just for plain DVI and one includes support for dvips specials. Both are pretty complete.

PDF Writer

The first draft of a translation into PDF is present.

PS Writer

A translation into PostScript format is present. The embedding of fonts is missing.

EPS Writer

A translation into encapsulated PostScript format is present. The embedding of fonts is missing.

SVG Writer

The SVG writer produces SVG files.

Node Pipe

The node pipe processes the nodes before they are translated to a native format.

Output Filter

The concept of an ouput filter completes the chain of processing by manipulation on the level of the output format. This component is not implemented at all.

Typesetting Subsystem

The typesetting subsystem is responsible of taking a stream of nodes and producing pages. In the course of this action several tasks have to be performed: hyphenation, ligature insertion, paragraph breaking, and page breaking.

The interfaces for the componets are defined. The implementation of several components has to be completed.


The typesetter ties togeter the sub-components. It is fully functional.

Page Builder

The page builder splits material off the main vertical list and ships it out as pages. A basic implementation id present. Further implementations have to be provided.

Paragraph Builder

The paragraph builder splits paragraphs into lines and aligns them properly. Several implementations are provided. One of them is a TEX-compatible reimplementation.

Ligature Builder

The ligature builder inserts ligatures into the paragraph at hand.


The hyphenation component encapsulates language specific processing of the paragraph at hand. The insertion of soft hyphenations and splitting off words are the major tasks. One TEX-compatible implementation is present; Other implementations with enhanced functionality can be envisioned.

Font Subsystem

The task of the font subsystem is to provide the information about the glyphs in a font. Various types of fonts should be supported. Type-1 fonts and tfm fonts can already be processed. Other types like vf fonts have to be completed or completely implemented.


Font is the generic interface to handle different kinds of fonts in εχTEX. A first implementation is present. A massive refactoring towards full support of Unicode fonts is under way.

ExTeX Font Metrics

EFM provides a means to store the internal representation of a font for fast loading. This feaure is functional for the first generation of fonts.

TeX Font Metrics

TFM files as defined by TEX can be read and used.

Adobe Font Metrics

AFM files can be read. A massive refactoring towards full support of Unicode fonts is under way.

TrueType Fonts

Truetype fonts can be read. A massive refactoring towards full support of Unicode fonts is under way.

Virtual Fonts

Virtal fonts can be read and used.


PFB files can be read. A massive refactoring towards full support of Unicode fonts is under way.

OpenType Fonts

Work on OpenType fonts has been started.

Font Family

The concept of font families is known from macro packages like LATEX on the other side target output formats like RTF use font families as well. Thus εχTEX will be extended to support font families in addition to solitary fonts.


The implementation of εχTEX is based on a component framework. This component framework provides means for managing the lifecycle of a component – especially the creation in factories. This includes services like configuration and logging. The framework is inspired by the Apache Avalon framework.

The framework is pretty stable. The functionality needed is provided. This part can be considered complete.


The localizer can be used to access resource bundles. It provides some convenience functionality for localizing, i.e. the translation of messages into other languages. The default language is English. This is fully functional. Some experiments with German have shown that the concept is vlaid and complete.

Generic Factory

The generic facory provides support for all kinds of factories. It automaticaly takes care of several cross cutting concerns like logging and configuration. The generic factory is completed.

Configuration Support

The configuration support can be used to configure an application. Currently an implementation based on an XML configuration is provided. This is fully functional.

Resource Finder

The start of processing consists of the finding of an input file. This applies to TeX documents, formats, fonts, etc. The task of finding files of different kinds is accomplished by file finders. The interface and infrastructure is in place. Several implementations of file finders are present. They can be selected and combined in the configuration.

Contact Address
Sponsored by
Hosted by
© 2013 The εχTEX Group