17

On MiKTex webpage, it is written:

MiKTeX (pronounced mick-tech) is an up-to-date implementation of TeX/LaTeX and related programs for Windows (all current variants).

Also on this page Installing TeX, LaTeX, and REVTeX on your own computer :

TeX is the same everywhere, but the software that implements TeX is different for different systems, and the elements described above are packaged differently for different platforms.

And by google, one can find more, such as TeX++: An Object Oriented TeX Implementation .

Github rep for TeX++ as suggested by Bruno Le Floch in comments

I would like to know what is "an implementation of TEX".

I know that PDF is a format (or a language) and PDF reader is an implementation in order to parse PDF files. Is "an implementation of TEX" similar to PDF and PDF readers?

So nowadays, each distribution, such as MikTeX, TeXlive and MacTeX (and ...etc.), has its own "TeX engine"? Or I am wrong and they all use the same source code of TeX and just compile with different compiler and target to different platform?

texenthusiast
  • 6,057
user565739
  • 5,482

2 Answers2

13

The verb "to implement" means, according to my dictionary,

put (a decision, plan, agreement, etc.) into effect

and it's from Latin implēre (to fulfill), from which also "employ" derived through French.

So "an implementation of TeX" is something that makes TeX (and connected software) usable on a particular machine.

"TeX, the program" is publicly available free of charge and everybody is entitled to use the source for producing derived works. A restriction is that the final product cannot be called "TeX" if it doesn't pass the so-called "trip test".

A program in source code does nothing, what's needed is to adapt it to a processor architecture and to an operating system, so that it can be compiled and made into an executable program. Let's go simple, first, and consider only TeX in the original Knuth form.

One needs to prepare a "change file" where some machine dependent parts must be filled in (I/O and access to time data, for instance). Then TeX can be compiled (often after first translating the Pascal source into C) and run.

However, TeX (the executable) by itself is almost useless. One has to teach it how to access vital parts, such as the font metric data and input files. This is usually done by linking it to a library called kpathsea (by Karl Berry) during the preparation of the change file or in the compilation process. This library facilitates file system access by TeX and also running auxiliary programs when needed (for instance calling METAFONT when font metric data is not available). It's not the only way: the KerTeX project uses a different library.

Having TeX in good shape is still not sufficient. One needs a DVI previewer, a way to produce the needed bitmaps for the fonts, a printer driver, METAFONT. On modern systems, the DVI previewer and the printer driver would be linked to a library for using Type1 fonts.

And that's not the whole picture: nowadays a TeX system should provide pdfTeX, XeTeX and LuaTeX, whose compilation and packing are not easy tasks, considering also what's needed in order to make the complete bundle usable on a machine.

Some "standard packagings" emerged already in the first years of TeX. In the olden days one could get a tape containing prepackaged distributions of TeX for some mainstream architectures: Unix (in some of its variants), Vax/VMS, IBM mainframes. When PC's appeared, some distributions became available on diskettes, free of charge or commercial: emTeX for DOS or OS/2, OzTeX for Mac OS, AtariTeX, AmigaTeX were on the "free" or "shareware" side; PCTeX, Textures and others on the commercial side.

Nowadays the most used implementations of TeX and friends (that is a bundle of connected software for using TeX or variants thereof) are, on the "free" side, TeX Live (Unix based architectures, but also Windows) and MiKTeX (Windows only; a GNU/Linux version had been announced, but never really implemented, as far as I know).

egreg
  • 1,121,712
  • Somewhat tangential, so feel free not to answer (or to say it should be asked as a separate question): to what extent do pdfTeX/XeTeX/LuaTeX assume kpathsea or specific details of web2c, say? For example, if one got a Pascal compiler with all the features of the compiler Knuth originally used (AFAICT no such compiler exists today), and tried to run tangle on pdftex.web or xetex.web, would it stand a chance of being usable (with possibly minor modifications)? AFAICT both pdfTeX and XeTeX have always been built only with web2c, i.e. they wrote Pascal code with goal of producing C code. – ShreevatsaR Jul 05 '17 at 06:24
  • 1
    @ShreevatsaR Not only they depend on kpathsea, but also on other libraries such as libpng or HarfBuzz. Maybe one could dispense with kpathsea, but the other libraries most likely need a C compiler. – egreg Jul 05 '17 at 08:03
7

Well, the code for "engines": tex, pdftex, luatex, xetex is nowadays more or less the same across the distributions. However, other programs, packages etc. may depend on the choice of the distribution authors.

A distribution is "TeX and friends", so the choice of "friends" may be different for different distros :)

Boris
  • 38,129
  • 1
    Is there any TUGboat article expanding TeX and friends and its implementation in for eg: TeXLive MikTeX ? – texenthusiast May 23 '13 at 04:08
  • i had a strong impression that xetex and luatex were implemented from the ground up, taking no more than hints from knuth's stuff (as seen in tex -- pdftex also has lots of stuff that's not knuthian). – wasteofspace May 23 '13 at 11:20
  • @wasteofspace I do not mean that xetex or luatex use tex codebase (they actually do :); rather I mean that xetex or luatex code is the same in MikTeX and TeXLive - up to some details like handling writing to parent directories etc, which correspond to design decisions of the distro authors. – Boris May 23 '13 at 15:57