[metapost] Does MetaPost catch on?

[laurent at math.toronto.edu]

Stephan Hennig writes (passim):

 > I like separating text and graphics....

I do too.

I adore TeX and I adore metapost.  And in isolation I find
each unified and efficient.  I cannot say simple alas, but
each is of manageable complexity when each is used with no
reference to the other.

In contrast, I find the complexities generated by
integration of TeX into metapost rather daunting. The mere
matter of  maintaining and updating a metafont-with-TeX
distribution is bad news. For example, the requirement (in
practice) that TeX be the up-to-date TeX-Live distribution
is a discourtesy to other TeX distributions and their
users. Also, the apparent requirement that the user follow
the considerable traffic here concerning details and bugs
of the integration of TeX into metapost is frighening.

A feature request that I consider reasonable and valuable
would be this:

 | The distribution of metapost should include an option
 | for "no typesetting engine". In practice this could
 | amount to offering a new option at launch:
 |
 | mpost -no_typesetting_engine
 |
 | in addition to
 |
 | mpost -troff
 | mpost -tex=latex
 | mpost -tex=plain

If I understand correctly, many TeX distributions (MicTeX,
OzTeX, ...) do not include an up-to-date metapost
compilation. A decent implemenattion of this
'no_typesetting_engine' feature would permit all TeX
distributions to almost immediately include an up-to-date
metapost usable for pure graphics. It would also permit an
autonomous distribution of metapost good for pure graphics
that I or anyone could use to to follow the most current
progress of metapost --- say on any remote linux machine.
There are other science oriented systems that would benefit
from the inclusion of metapost for pure graphics; "maple"
is perhaps one since its syntax is close to that of
metapost.

I hope someone will assure me (and demonstrate!) that this
seemingly trivial 'no_typesetting_engine' option with the above
features is already present or trivial to implement.

Unfortunately it is a truism that retrofitting simplicity
into a complex system is harder than elaborating complex
features.

Thanks Stephan for your vision and courage.

Laurent S.