The Communications of the TEX Users Group Volume 29 ... - TUG

More documents

Recommendations

Info

$E-m: Guidelines for Future TEX Extensions - TUG$

$TUG 2001: A TEX Odyssey PROGRAM$

$LATEX Sophisticated professional typesetting for business and ...$

$TEX and Scripting Languages - TUG$

$Geometric Diversions with TEX, METAFONT and METAPOST - TUG$

$Writing Gregg Shorthand with mEtaFoNt and LATEX - TUG$

$Generating LaTeX documents through Matlab - TUG$

MetaPost developments: MPlib project report Taco Hoekwater Elvenkind BV Dordrecht, The Netherlands http://tug.org/metapost Abstract The initial stage of the MPlib project has resulted in a library that can be embedded in external programs such as LuaTEX, and that is also the core of the mpost program. This paper presents the current state of affairs, the conversion process of the MetaPost source code, and the application interface to the library. 1 MPlib project goals The MPlib project is a logical consequence of the transfer of MetaPost development from its author John Hobby to the MetaPost development team. It originates from a desire to update MetaPost for use in the 21 st century. The first thing that needed to be done to make that happen was updating the program source code and infrastructure to be closer to today’s programming standards. These days, programs are often written in the form of shared libraries, with a small frontend application. When written in this way, a program can not only be used as a standalone program, but can also easily and efficiently be (re)used as a plugin inside other programs, or turned into a multi-user system service. With current MetaPost, such alternate uses are impossible because of the internals of the code. For example, MetaPost uses many internal global variables. This is a problem because when two users would be accessing a ‘MetaPost’ library at the same time, they would alter each other’s variables. For another example, MetaPost has static memory allocation: it requests all the computer memory it will ever use right at startup. It never bothers to free that memory, because it counts on the operating system to clean up automatically after it exits. And one file example: MetaPost not only opens files at will, but it also writes to and, even more problematically, reads from the terminal directly. A large part of updating MetaPost is therefore fixing all these issues. But while doing this, there are other weirdnesses to take care of at the same time. The present subsystem for typesetting labels (btex . ..etex) is pretty complicated, requiring an array of external programs to be installed on top of the normal mpost executable. And from a system viewpoint, the error handling of MetaPost is not very good: it often needs user interaction, and in most other cases it simply aborts. Finally, the whole process of installing the program is complicated: a fair bit of the TEX Live development tree is needed to compile the executable at all. 2 Solutions Many of the problems mentioned above are a sideeffect of the age of the source code: the source is largely based on METAFONT, and therefore written in Pascal WEB. And the bits that are not in Pascal WEB are an amalgam of C code borrowed from other projects, most notably pdfTEX. Not wanting to lose the literate programming documentation, we had only one practical way to proceed: using the CWEB system. CWEB has the same functionality that Pascal WEB has, except that it uses C as the programming language instead of Pascal, and it has some extensions so that it does not get in the way of the ‘normal’ C build system. Using CWEB, a single programming language now replaces all of the old Pascal and C code. The code has been restructured into a C library, the label generator makempx has been integrated, and compilation now depends only on the ctangle program and the normal system C compiler, so that a simple Autoconf script can be used for configuration of the build process. 3 Code restructuring Whereas converting the C code of the font inclusion and label processing subsystems to CWEB was a fairly straightforward process, converting the Pascal WEB core of MetaPost was a more elaborate undertaking. In the first stage, the Pascal code within the WEB underwent an automatic rough conversion into C code. Afterwards, the generated C code was manually cleaned up so that it compiled properly using ctangle. This part took roughly one month, and the end result was an executable that was ‘just like’ 380 TUGboat, Volume 29 (2008), No. 3 — Proceedings of the 2008 Annual Meeting
Pascal MetaPost, but using CWEB as source language instead of Pascal WEB. After that was done, the real work started: • All of the global variables were collected into a C structure that represents an ‘instance’ of MetaPost. • The Pascal string pool was stripped away so that it is now used only for run-time generated strings. Most internal functions now use normal C strings. • The PostScript backend was isolated from the core of the program so that other backends can be added much more easily. • All of the exported functions now use a C namespace. • Where it was feasible to do so, MPlib uses dynamic memory allocation. There are a few exceptions that will be mentioned later. • All input and output now uses function pointers that can be configured through the programming interface. • The MPlib library never calls exit() itself but instead returns to the calling program with a status indicator. 4 Using the library from source code Using the MPlib library from other program code is pretty straightforward: first you set up the MPlib options, then you create an MPlib instance with those options, then you run MetaPost code from a file or buffer, and finally finish up. The options that can be controlled are: • various command-line options that are familiar frommpost, such as whether MetaPost starts in INI mode, the mem_name and job_name, ‘troff’ mode, and the non-option part of the command line, • the size of the few remaining statically allocated memory arrays, • various function pointers like those for input and output, file searching, the generator function for typeset labels, and the ‘editor escape’ function, • the start value of the internal randomizer, • and finally a ‘userdata’ pointer that is never used by MPlib itself but can be retrieved by the controlling program at any time. The application programming interface at the moment is very high-level and simplistic. It supports two modes of operation: • emulation of the command-linempost program, with traditional I/O and interactive error handling, MetaPost developments: MPlib project report • an interpreter that can repeatedly execute individual string chunks, with redirected I/O and all errors treated as if nonstopmode is in effect. For the string-based interpreter, there are a few extra functions: • the runtime data can be fetched; this comprises the logging information and the internal data structure representation of any generated figures, • the instance’s error state can be queried, • the userdata pointer can be retrieved, • some statistics can be gathered, • PostScript can be generated from the image output, • and some glyph information can be retrieved; this is useful if you want to create a backend yourself. 4.1 Examples Here is a minimalistic but complete example that uses the mpost emulation method in C code: #include #include "mplib.h" int main (int argc, char **argv) { MP mp; MP_options *opt = mp_options(); opt->command_line = argv[1]; mp = mp_initialize(opt); if (mp) { int history = mp_run(mp); mp_finish(mp); exit (history); } else { exit (EXIT_FAILURE); } } Given the basic library functionality now available, it is reasonably straightforward to create bindings for other languages. We have done this for Lua, and here is a second example that uses these Lua language bindings. The Lua bindings are always based on string execution, and the option setting and instance creation are merged into a single new function: local mplib, mp, l, chunk mplib = require(’mplib’) mp = mplib.new ({ini_version = false, mem_name = ’plain’}) chunk = [[ beginfig(1); fill fullcircle scaled 20; endfig; ]] if mp then TUGboat, Volume 29 (2008), No. 3 — Proceedings of the 2008 Annual Meeting 381
Page 1 and 2: The Communications of the TEX Users
Page 3 and 4: TUG2008 Proceedings University Coll
Page 5 and 6: TUG 2008—program Monday, July 21
Page 7 and 8: At the reception. Around the front
Page 9 and 10: Taco Hoekwater, inside the Beamish
Page 11 and 12: Another, equally large, disadvantag
Page 13 and 14: This “saves” the original \text
Page 15 and 16: Figure 5: Macro result pushed back
Page 17 and 18: TEXworks: Lowering the barrier to e
Page 19 and 20: Direct and reverse synchronization
Page 21 and 22: The TEXnical terms used to describe
Page 23 and 24: 6.2 An orthogonal implementation On
Page 25 and 26: In fact, the text editors and the v
Page 27 and 28: albanian greek norwegian belarusian
Page 29 and 30: input manually, but are generated b
Page 31 and 32: 1.2 Commercially available software
Page 33: If L ATEX can fit the snippet into
Page 37 and 38: The TEX-Lua mix Hans Hagen Pragma A
Page 39 and 40: \setbox0=\hbox{x}\the\wd0 In Lua we
Page 41 and 42: start.char = uc return true end end
Page 43 and 44: stream-based approach, this time th
Page 45 and 46: example is support for OpenType fon
Page 47 and 48: typesetting system is TEX [4] creat
Page 49 and 50: 13. Image conversion from various f
Page 51 and 52: the mapping file example.paraStyleN
Page 53 and 54: The second author accepts or reject
Page 55 and 56: Languages for bibliography styles J
Page 57 and 58: @STRING{srd = {Stephen Reeder Donal
Page 59 and 60: # # standard footnote format (latex
Page 61 and 62: . , \bbled \bbleds .
Page 63 and 64: Languages for bibliography styles (
Page 65 and 66: References [1] James C. Alexander:
Page 67 and 68: Vistas for TEX: liberate the typogr
Page 69 and 70: - even direct formatting instructio
Page 71 and 72: e that quick, simple and clear rend
Page 73 and 74: see that there are slight differenc
Page 75 and 76: Creating cuneiform fonts with MetaT
Page 77 and 78: Definition of encoding (Unicode) Pl
Page 79 and 80: epresentation with proper path dire
Page 81 and 82: When it came to implementing the T1
Page 83 and 84: 4.3 OpenType math in new TEX engine
Page 85 and 86:
However, there have always been exc
Page 87 and 88:
[2] Nelson Beebe: Character set enc
Page 89 and 90:
Meta-designing parameterized Arabic
Page 91 and 92:
on the pen direction at each point
Page 93 and 94:
% Description for isolated ’alif
Page 95 and 96:
Figure 15: Tracing a word from left
Page 97 and 98:
Table 1 shows the MOS scores for in
Page 99 and 100:
P3 P3 P3 Q2 Q2 Q2 � � W3 W3 W3
Page 101 and 102:
abridged form, it looks like this:
Page 103 and 104:
with extensions is still somewhat m
Page 105 and 106:
local rx, ry = second.y_coord - ty,
Page 107 and 108:
\startreusableMPgraphic{name}... \s
Page 109 and 110:
the macro \testengine sees two argu
Page 111 and 112:
and exhyph-uk.tex, respectively. Th
Page 113 and 114:
stand for markers of semiconsonants
Page 115 and 116:
y finite state transducers (FSTs).
Page 117 and 118:
local p = hpack(copy(h.list)) lastl
Page 119 and 120:
with PDF documents. Several new tec
Page 121 and 122:
Advanced features for publishing ma
Page 123 and 124:
Page 125 and 126:
— — — — — — — — Fig
Page 127 and 128:
Page 129 and 130:
telegraph. The relatively recent di
Page 131 and 132:
1: [ type: unichar, code: 0073 ] ]
Page 133 and 134:
5 Conclusions The model introduced
Page 135 and 136:
4 Why TEX files and not other marku
Page 137 and 138:
The galley Module or: How I Learned
Page 139:
TUGboat, Volume 29 (2008), No. 3 48
Page 142 and 143:
488 TUGboat, Volume 29 (2008), No.
Page 144 and 145:
TUGBOAT Volume 29 (2008), No. 3 Tab
show all

The Communications of the TEX Users Group Volume 29 ... - TUG

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?