[MetaTeX] libmpost status update and feature question
herckb at pandora.be
Thu Aug 5 18:58:20 CEST 2004
On Mon, 2004-07-19 at 12:35, Taco Hoekwater wrote:
> 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 ......
It is not clear to me what you mean by this.
> 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?
I like the second approach, let a completely different plugin handle the
preprocessing. A lot of tools work with this approach. For example
http://cvs.gnome.org/viewcvs/gcm/ has a plugin to convert text from rtf
into html. The plugin is in a different library.
Of course this means that there must be written some kind of interface.
What input does the plugin wants and what output generates it ?
More information about the Metatex