[metapost] generic TeX interface?

[Stephan Hennig]

Taco Hoekwater schrieb:
> Stephan Hennig wrote:
> 
>> but scantokens refuses to process btex..etex constructs complaining
>> 
>> | ! You can only use `btex' or `verbatimtex' in a file.
>> 
>> I think that's the reason the TEX package was written.  Is there any
>> work around that?
> 
> In short: no. The only solution is to write a string to a file;
> then include the file (which is exactly what the TEX package does).

Unfortunately, btex..etex and TEX() don't share the same LaTeX setup, IIRC.


> Conceptually, btex .. etex is preprocessed much like 'pic', 'eqn' and
> 'tbl' in troff. It turns out to be really hard to change that behaviour
> while remaining backward compatible. However, I see no problem with
> inventing a completely new subsystem.

A superior subsystem is the other alternative.


> Do you have any ideas about how this should work (at the lowest
> level)?

Since I have not much insight into how low level interaction works
between MetaPost and TeX I can't say much about that.  Instead, I tried
to collect some features I'd like to see for a new TeX interface.
Here's the unsorted list:

* The macro that transforms TeX input into pictures should accept string
arguments, similar to TEX() and textext(), so that arguments can be
built dynamically.  Unlike btex..etex, that reads its argument verbatim.

* I very much like the way (La)TeX is set up for btex..etex.  That is, I
like to see my plain (La)TeX preamble in the MetaPost document.  Setting
up (La)TeX with tex.mp and latexmp.mp---in one long string or with tons
of parameters---is not half as convenient.

* Compiling several TeX pictures should be a fast operation, unlike the
TEX() approach.

* Compiling a large number of TeX pictures should be no problem.  I
remember hitting the upper limit latexmp.mp can handle somewhere above
4000 pictures.

* The interface should be able to use both, LaTeX and TeX.  Unlike
latexmp, which only supports LaTeX, AFAIK.

* (I don't remember the problem with %&latex at the moment, but maybe
the same functionality could be provided by an internal string variable
'texprocessor' that can be set to either "tex" or "latex".)

* In the resulting picture character-wise access to its textpart should
be possible in for..within loops.

* There should be an easy way to access the y coordinates of the base
line of a TeX picture.  The base line can already be accessed through
for..within, currently.  But that is cumbersome.  And who knows about that?

* Beyond the last item, it would be convenient if a macro 'blabel' could
be derived from label that doesn't refer to the cardinal points of a
picture, but to the base line of a TeX picture.  That is,
blabel(texpicture, z) puts the point on the base line at the horizontal
center of texpicture at z and, e.g., blabel.urt(texpicture, z) puts the
left most point of the base line next to z.  How to manage the base line
information internally, I don't know.

* TeX colors should be supported.

These are the things that come to my mind, currently.  If you think
implementing a new TeX interface is easier than unifying the existing
approaches, I'm just as happy with that.  However, to save from the same
trouble that is present now, btex..etex, TEX (and textext) should be
declared deprecated at the same time the new interface is available, IMHO.

Stephan Hennig