[MetaTeX] libmpost status update and feature question

Taco Hoekwater taco at elvenkind.com
Mon Jul 19 12:35:02 CEST 2004


Hi,

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 
  level.

  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 
  "ofm writing".

- system memory allocation debug (temporary) code is added, and a 
  number of  bugs have been fixed.


-- 
groeten,

Taco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpost.h
Type: application/octet-stream
Size: 2162 bytes
Desc: not available
Url : http://www.ntg.nl/pipermail/metatex/attachments/20040719/1a23558b/mpost.obj


More information about the Metatex mailing list