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. Смотрите информацию ключар здесь.
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.
The εχTEX instance ties together the core funtionality. It abstracts from any user interaction. This central component is fully functional.
The input subsystem is responsible for reading from an input stream and tokenizes it.
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.
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.
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.
The document writer defines the translation of nodes into a native output format. Several implementations are provided.
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.
The first draft of a translation into PDF is present.
A translation into PostScript format is present. The embedding of fonts is missing.
A translation into encapsulated PostScript format is present. The embedding of fonts is missing.
The SVG writer produces SVG files.
The node pipe processes the nodes before they are translated to a native format.
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.
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.
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.
The paragraph builder splits paragraphs into lines and aligns them properly. Several implementations are provided. One of them is a TEX-compatible reimplementation.
The ligature builder inserts ligatures into the paragraph at hand.
HypenationThe 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.
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 can be read. A massive refactoring towards full support of Unicode fonts is under way.
Virtal fonts can be read and used.
PFB files can be read. A massive refactoring towards full support of Unicode fonts is under way.
Work on OpenType fonts has been started.
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.
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.
The configuration support can be used to configure an application. Currently an implementation based on an XML configuration is provided. This is fully functional.
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.