[metapost] generic TeX interface?

[Dan Luecking]

At 10:43 AM 12/10/2006, you wrote:
>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.

I don't know what this means. Neither has _any_ LaTeX setup. The use
has to do this himself, with verbatimtex..etex for the bare
btex..etex primitive, and with the macros TEXPRE and TEXPOST for the
TEX macro inteface.


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

This is almost certainly caused by the limit of
2^{12}-epsilon = 4095.99998 on numbers. One can perhaps exceed
that by setting warningcheck to 0. latexmp makes the operation
fast by writing all text labels to a file and inputting that, so
LaTeX is only run once. It requires a second pass, and it needs
to communication which label goes where, so each is labeled with
number and the value stored in a variable.

Since Metapost allows fractional indexing, one could get twice
as many pictures if it incremented by 1/2 each time. And up to
2^{28} picture if it incremented by epsilon.


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

Hence the name. A corresponding texmp would be easy to create.

>* (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".)

That is a good idea. The problem with "%&latex" is that not all
versions of TeX have that feature. Also tiny mistakes throw it off
I saw a user write
verbatimtex
%&latex;
...etex
and the semicolon caused it to fail.

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

It ought to be possible. One can certainly access the text-as-picture.
That picture ought to be (roughly) composed of a position, a font, a
string, and a color (and perhaps more attributes). It ought to be
possible to create an "istext" test on a picture and a "stringpart"
operator. But perhaps, that would require labels to be another data
type.

>* 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?

The y-coordinate of the baseline of btex..etex is 0. When a picture
is created, it has its own coordinate system. The btex..etex operation
produces a picture that has the reference point of the TeX box at
(0,0). The infont operator (operating on strings) creates a picture
with the reference point of the first character at (0,0).

The reference point of a TeX box is at the leftmost edge of the
baseline (barring TeX box manipulations).

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

It is unclear what blabel.lrt should do. If you want the same
result as label.lrt, then essentially all you are asking is
that the depth be ignored.

picture P; P:= btex testing etex;
setbounds P to
   (0,0)--(xpart urcorner P, 0)--
        --urcorner P--(0, ypart urcorner P)--cycle;
label.urt (P,z); % reference point just above and right of z
labeloffset := 0;
label.bot (P,z); % center of baseline at z

Or one could model blabel and theblabel on label and
thelabel, but replace llcorner p with (0,0) and
lrcorner p with (xpart lrcorner p, 0).

>* TeX colors should be supported.

TeX doesn't have colors. It has macros that write \special-s
to the dvi file. The \special-s used vary with the
dvi-to-whatever driver that processes the .dvi file. This would
require dvitomp to either have its own specials (and the verbatimtex
would need \usepackage[dvitomp]{graphics}) or it recognize a
restricted set of specials for some other graphics package driver,
preferably dvips. Right now that is pretty simple:
   \special{color push <the color>}
at the start of a color change and
   \special{color pop}
at the end. Then dvitomp would have to keep track of the
color stack implicit in these commands.



Daniel H. Luecking
Department of Mathematical Sciences
University of Arkansas
"I reject your reality, and substitute my own." -- Adam Savage