# [metapost] generic TeX interface?

Dan Luecking luecking at uark.edu
Mon Dec 11 19:03:29 CET 2006

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

>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