1
2
3\environment luametafunstyle
4
5\startcomponent luametafuntechnology
6
7\startchapter[title={Technology}]
8
9The \METAPOST\ library that we use in \LUAMETATEX\ is a follow up on the library
10used in \LUATEX\ which itself is a follow up on the original \METAPOST\ program
11that again was a follow up on Don Knuths \METAFONT, the natural companion to
12\TEX.
13
14When we start with John Hobbies \METAPOST\ we see a graphical engine that
15provides a simple but powerful programming language meant for making graphics,
16not the freehand kind, but the more systematic ones. The output is \POSTSCRIPT\
17but a simple kind that can easily be converted to \PDF. \footnote {For that
18purpose I wrote a converter in the \TEX\ language for \PDFTEX, and even within
19the limitations of \TEX\ at that time (fonts, number of registers, memory) it
20worked out quite well.} Its output is very accurate and performance is great.
21
22As part of the \LUATEX\ development project Taco Hoekwater turned \METAPOST\ into
23\MPLIB, a downward compatible library where \METAPOST\ became a small program
24using that library. But there is more: there are (when enabled) backends that
25produce \PNG\ or \SVG, but when used these also add dependencies on moving
26targets. The library by default uses the so called scaled numbers: floats that
27internally are long integers. But it can also work in doubles, decimal and binary
28and especially the last two create a dependency on libraries. It is good to
29notice that as in the original \METAPOST\ the \POSTSCRIPT\ output handling is
30visible all over the source. Also, the way \TYPEONE\ fonts are handled has been
31extended, for instance by providing access to shapes.
32
33At some point a \LUA\ interface got added that made it possible to call out to
34the \LUA\ instance used in \LUATEX, so the three concepts: \TEX, \METAPOST\ and
35\LUA\ can combine forces. A snippet of code can be run, and a result can be piped
36back. Although there is some limited access to \METAPOST\ internals, the normal
37way to go is by serializing \METAPOST\ data to the \LUA\ end and let \METAPOST\
38scan the result using \type {scantokens}.
39
40The library in \LUAMETATEX\ is a bit different. Of course it has the same core
41graphic engine, but there is no longer a backend. In \CONTEXT\ \MKIV\ the
42\POSTSCRIPT\ (and other) backends were not used anyway because it operates on the
43exported \LUA\ representation of the result. Combined with the \type {prescript}
44and \type {postscript} features introduced in the library that provides all we
45need to make interesting extensions to the graphical engine (color, shading,
46image inclusion, text, etc). The \METAPOST\ font support features are also not
47used because we need support for \OPENTYPE\ and even in \MKII\ (for \PDFTEX\ and
48\XETEX) we used a different approach to fonts.
49
50It is for that reason that the library we use in \LUAMETATEX\ is a leaner version
51of its ancestor. As mentioned, there is no backend code, only the \LUA\ export,
52which saves a lot, and there are no traces of font support left, which also drops
53many lines of code. We forget about the binary number model because it needs a
54large library that also occasionally changes, but one can add it if needed. This
55means that there are no dependencies except for decimal but that library is
56relatively small and doesnt change at all. It also means that the resulting
57\MPLIB\ library is much smaller, but its still a substantial component in
58\LUAMETATEX. Internally I use the future version number 3. The original
59\METAPOST\ program is version 1, so the library got version 2, and that one
60basically being frozen (its in bugfix mode) means that it will stick to that.
61
62Another difference is that from the \LUA\ end one has access to several scanners
63and also has possibilities to efficiently push back results to the engine.
64Running scripts can also be done more efficient. This permits a rather efficient
65(in terms of performance and memory usage) way to extend the language and add for
66instance keyvalue based interfaces. There are some more additions, like for
67instance pre and postscripts to clip, boundary and group objects. Internals can
68be numeric, string and boolean. One can use \UTF\ input although that has also be
69added to the ancestor. Some redundant internal inputoutput remapping has been
70removed and we are more tolerant to newlines in return values from \LUA. Error
71messages have been normalized, internal documentation cleaned up a bit. A few
72anomalies have been fixed too. All in and output is now under \LUA\ control.
73Etcetera. The (now very few) source files are still \CWEB\ files but the
74conversion to \CCODE\ is done with a \LUA\ script that uses (surprise) the
75\LUAMETATEX\ engine as \LUA\ processor. This give a bit nicer \CCODE\ output for
76when we view it in e.g.\ Visual Studio too (normally the \CWEB\ output is not
77meant to be seen by humans).
78
79Keep in mind that its still \METAPOST\ with all it provided, but some has to be
80implemented in macros or in \LUA\ via callbacks. The simple fact that the
81original library is the standard and is also the core of \METAPOST\ most of these
82changes and additions cannot be backported to the original, but that is no big
83deal. The advantage is that we can experiment with new features without
84endangering users outside the \CONTEXT\ bubble. The same is true for the \LUA\
85interface, which already is upgraded in many aspects.
86
87\stopchapter
88
89\stopcomponent
90 |
