% This file is part of MetaPost. The MetaPost program is in the public domain. @* Nota bene. This is not the official reference library but a version meant for \LUAMETATEX\ in combination with \METAFUN, which is integrated in \CONTEXT. When the original gets improved I will diff the progression of the original \CWEB\ files and merge improvements. I'm pretty sure that the \TEX part of this file doesn't process but I'll look into that later. The comments are kept as they were but there are occasional remakts because we changes some bits and pieces. The references to properties, variables, constants etc, are mostly kept. I due time I'll fix it and see if I can render the file, but for not it's okay to just read the comments. I admit that I check things in Visual Studio anyway, which is why there are now |enum| used. This split is needed because the original library is the one used for \METAPOST\ the program which is used by DEK, and I don't want to mess up his workflow. At some point I might emulate \METAPOST\ but I might as well decide to remove the interaction completely from this variant. It al depends on the outcome of experiments that Alan and I conduct, and as it's done in free time, it will take while. Don't push us, don't nag, don't complain. The original library is where the support is concentrated and you can always use that with the \MKIV\ macros. Todo: check typecasts, the halfword and quarterwords are now integers. Todo: Move more variables into the scope that they're used. Todo: Remove some (int) cast that are left overs from quarterword. Todo: Remove unused variables ... postpone more padding till that is done. Todo: Support color in group objects Because we don't want macros to clash with fields in record, setters and getters are prefixed by |mp_|. In order not clash with typedefs and accessors, in some cases |mp_get_| and |mp_set_| are used (eventually that might be true for all these cases). The |mp_free_| functions are complemented by |mp_new_| functions. In \MPLIB\ 2 |mp_get_| is used instead so keep that in mind when comparing the sources. I might also pass |mp| to all macros, just for consistency. To be considered: use the same record for rgb and cmyk (less code eventually). In order to make extensions a bit easier (and also because of consistency in enumerations, some _token and _sym and similar specifiers have been made _command (it was already somewhat inconsistent anyway). When something gets compared to cur_cmd it makes sense to use _command anyway. % some (int) can go (Hans Hagen, 2019+) @* Comment. At some point Taco Hoekwater brilliantly converted \MP\ into a library. Since then usage and integration of \METAPOST\ in \CONTEXT\ went even further than before. There were some backends added for \SVG\ and \PNG, and several number systems could be used. This was quite an effort! The \MP\ program became a wrapper around this library. The library is also used in \LUATEX\ but there we don't need the backend code at all. Also, having the traditional \TFM\ generating code (inherited from \MF) makes not much sense because we now live in an \OPENTYPE\ universum and the hard coded 256 limitations were even for \TYPEONE\ not okay. The GUST font team use their own tools around \MP\ anyway. This variant (below) is therefore a stripped down library. Everything related to loading fonts is gone, and if a \PS\ backend is needed the functionality has to go into its own module (as with \SVG\ and \PNG). This means that code removed here has to go there. One problen then is that the output primitives have to be brought in too, but in good \CWEB\ practices, that then can be done via change files (basically extending the data structures and such). However, a more modern variant could be to just use the library with \LUA, produce \PDF\ and convert that to any format needed. This is what we do in \CONTEXT. After a decade of usage I like to change a few interface aspects so here this happens. So: this variant is {\em not} the official \MP\ library but one meant for usage in \LUAMETATEX\ and experiments by Alan Braslau and Hans Hagen for more advanced graphics, produced by cooperation between \LUA\ and \MP. This strategy permits experiments without interference with the full blown version. Of course we can retrofit interesting extensions into its larger version at some point. It's all a work of love, done in our own time, so don't push our agenda in this. Stripping is easier than adding and the things I added were not at the level of the language or processing but the interface to \LUA\ as well as some details of text processing. Some more of that might happen. For instance, all file \IO\ now goes via \LUA\ so we assume the callbacks being set. On my agenda are to delegate printing of messages and errors to the plugin. Also filenames might be done differently. Messages are already normalized. As a start the psout.w file was stripped and turned into a mpcommon.w file. This means that the old \PS\ output code is no longer there. Because that file got small it eventually got merged in here which (1) permits some reshuffling and (2) gives room for optimizing the interface to \LUA\ (do we need the indirectness?). Quite some code has been stripped because we assume that \LUA\ can provide these features: file io, logging, management, error handling, etc. This saves quite a bit of code and also detangles a bit the mixed program vs. library code. For now the \quote {terminal} approach is kept. In the process I reformatted the source a bit. Sorry. It is no big deal because it looks like \METAPOST\ is not evolving, but what does evolve is the code here: scanners and more access, to mention a few. I've added braces so that comments can go with single statements and there can be no doubt when \WEB\ macros are used (some braces could go there. More variables will become local (to branches for instance). Messages are done more directly, etc. etc. One of the reasons for doing that is that it looks nicer in Visual Studio. There it helps to move some variables to a more local scope. Of course a side effect is that backporting is now no longer an option. In some cases redundant braces were removed (when it's clear in the w file) and some else statements have been added where confusion takes place because that one doesn't return (so compilers can for instance warn about uninitialized pointers). I made sure that the resulting code is readable in visual studio. Work in progress: prefix with mp_ so that macros don't clash with fields and we can get rid of _ hackery. Maybe some day: zpair zpath zdraw ztransform: just add an extra z dimension to the existing data types which makes it compatible too. Todo: consider double only Todo: use documented c Todo: rework some (more) helpers Todo: center Todo: centerofmass Todo: ceiling x Todo: x div y Todo: x mod y Todo: dir x Todo: unitvector (Hans Hagen, 2019+) @* Introduction. This is \MP\ by John Hobby, a graphics-language processor based on D. E. Knuth's \MF. Much of the original Pascal version of this program was copied with permission from MF.web Version 1.9. It interprets a language very similar to D.E. Knuth's METAFONT, but with changes designed to make it more suitable for PostScript output. The main purpose of the following program is to explain the algorithms of \MP\ as clearly as possible. However, the program has been written so that it can be tuned to run efficiently in a wide variety of operating environments by making comparatively few changes. Such flexibility is possible because the documentation that follows is written in the |WEB| language, which is at a higher level than C. A large piece of software like \MP\ has inherent complexity that cannot be reduced below a certain level of difficulty, although each individual part is fairly simple by itself. The |WEB| language is intended to make the algorithms as readable as possible, by reflecting the way the individual program pieces fit together and by providing the cross-references that connect different parts. Detailed comments about what is going on, and about why things were done in certain ways, have been liberally sprinkled throughout the program. These comments explain features of the implementation, but they rarely attempt to explain the \MP\ language itself, since the reader is supposed to be familiar with {\em The \METAFONT\ book} as well as the manual @.WEB@> @:METAFONTbook}{\sl The {\logos METAFONT}book@> {\em A User's Manual for \METAPOST}, Computing Science Technical Report 162, AT\AM T Bell Laboratories. @ The present implementation is a preliminary version, but the possibilities for new features are limited by the desire to remain as nearly compatible with \MF\ as possible. On the other hand, the |WEB| description can be extended without changing the core of the program, and it has been designed so that such extensions are not extremely difficult to make. The |banner| string defined here should be changed whenever \MP\ undergoes any modifications, so that it will be clear which version of \MP\ might be the guilty party when a problem arises. @^extensions to \MP@> @^system dependencies@> At some point I started adding features to the library (think of stacking) but the more interesting additions came when Mikael Sundqvist and we side tracked from extending math at the \TEX\ end to more \METAFUN: intersection lists, arctime lists, path iteration, a few more helpers, some fixes, a bit more control, access to previously hidden functionality, appended paths, etc. And there is undoubtly more to come. As with all \LUATEX\ and \LUAMETATEX\ development, most gets explained in the history documents in the \CONTEXT\ distribution and articles. It was around version 3.14 (end May 2022). @d default_banner "This is MPLIB for LuaMetaTeX, version 3.14" @= # define metapost_version "3.14" @ We used to have three header files: common, mpmp and mplib, but there ws some (growing) dependency on the one hand and we decided to target just \LUAMETATEX\ on the other. After all, this is a special version. So, we now have one header file only. The variables from |MP_options| are included inside the |MP_instance| wholesale. This also permits some further stripping. Actually we can probably get rid of the intermediate \POSTSCRIPT\ representation or add a little more abstraction. @(mp.h@>= # ifndef MP_H # define MP_H 1 # include "avl.h" # include "auxmemory.h" # include # include @ typedef struct MP_instance *MP; @ typedef struct MP_options { @