[MetaTeX] libmpost status update and feature question

[Bart Vanherck]

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 ?

regards,

Bart