[MetaTeX] libmpost status update and feature question
taco at elvenkind.com
Mon Jul 19 12:35:02 CEST 2004
libmpost (and it's accompanying program "metamp") is slowly
becoming a bit more than just a collection of random CPU instructions.
The current version is 0.10. It can dump and re-read mem files,
and it correctly executes some (the simplest) MP commands.
There are still loads of bugs to sort out before an alpha release
makes sense, though.
Something to talk about: For the first public (beta) release, it would be neat
if there is an initial extension in place that we can announce. The obvious
choice would be a different shipout backend like PDF (not in the least because
that would be comparatively easy to code) but there are other options, like
unlimited memory or metafont-like windowing support or cmyk color or ......
I basically want to hear feature requests: what would make *you* want to
use metamp instead of mpost?
That said, here's the list of things I've done since last week's update
announcement (with some other remarks and questions embedded):
- The headers have been cleaned up considerably
(a few hunderd #defines are expanded in the source)
- The copyright has been clarified, the original AT&T statement
added as an informative file, and all C and header files now
have GPL statements. Assessing the legal status of this is
beyond me, but I hope that at least I've made my intentions
clear (see attached mpost.h).
- mpx file reading and xord/xchr/is_printable processing have
been removed. These should be taken care of at the application
There is the question of how to handle btex..etex.
My current plan is to parse all of the 'TeX stuff' into a C string,
then place a call the enclosing program to ask for the replacement
text for that string. Advantage of this: application programs can
stay a bit smaller than for the next approach.
A different approach would be to remove btex ... etex from
the core language completely, and let the pre-processing be
done before libmpost even looks at the code. Advantage of
this: makes the library smaller and it would be easier to extend
for a different plug-in language.
What do you guys think?
- The printing code is cleaned up considerably. Specifically,
terminal and log line offset handling are moved to metamp.
This introduces a small incompatibility with mpost (line
breaks will not all be identical), but I believe the extra generality
and clarity in the library is worth it. Anyway, I want to eventually
move towards "streams" instead of "selector settings", like the
"information stream", "warning stream", "error stream" etc. Then
we can let the application decide what to do with the stuff.
- most of the not-dumped static arrays are now removed from
struct METAPOST, to be allocated at runtime. This saves
space in the mem files.
- font read handling (for "infont") is changed so that it now uses an
array of struct FONT, instead of the old 'font_info' font memory
with it's separate support arrays. The struct is not finished yet,
because it should contain all of the font info, not just the
part used by libmpost (mposts TFM reader skips large sections
because they are not needed).
- font write handling (tfm commands) overflow checks have gone away
in favor of dynamic re-allocation. This needs more work to split the
current stuff into the abstraction "metric information" and "tfm writing",
so that there can eventually be extensions for "afm writing" or
- system memory allocation debug (temporary) code is added, and a
number of bugs have been fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2162 bytes
Desc: not available
Url : http://www.ntg.nl/pipermail/metatex/attachments/20040719/1a23558b/mpost.obj
More information about the Metatex