[metapost] generic TeX interface?

[Stephan Hennig]

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

Of course, the user has to set up a LaTeX preamble.  What I meant was
that you can set up different preambles for btex..etex and TEX().  The
net effect is that you can't silently replace btex..etex by TEX(), e.g.,
in the y_tex package posted earlier.  (Users would notice a performance
breakdown, of course.)


>>* 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 suggest latextext() as the user macro name for that package. :)


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

Does that mean %&latex is only interpreted by TeX?  Until now I thought
MetaPost notices that line and calls LaTeX instead of TeX in case.


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

So simple.  Do you know some documentation to read about that, i.e., the
structure of a picture variable and the positioning of TeX labels?

If you've accidentally wrapped a TeX generated picture in a thelabel
statement the baseline seems lost, as long as you don't know the depth
of the original picture (and labeloffset).  However, inspecting the
picture in a for..within loop reveals the old baseline when asking for
the ypart of a textual component, i.e,

labeloffset := 0bp;
pic := btex testing etex;
pic := thelabel.urt(pic);
for item within pic:
  if textual item:
    show ypart item;
  fi
endfor

should show a positive value in case the text contained descenders.

I've found this by trial and error and don't know how reliable the
information is.  As I see it know ypart returns just the shifting of the
coordinate system that you spoke about before.  I never knew 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.
> 
> It is unclear what blabel.lrt should do. If you want the same
> result as label.lrt, 

Originally, not really.  But now I don't know. :)


> 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

Isn't the last comment true for label.top, actually?


>>* TeX colors should be supported.
> 
> TeX doesn't have colors.

Well, I know I should have been more precise.

Dan, thanks for your clear and detailed comments.  I would like to
invite others to comment to or add features to this list.  And Taco to
strike out items that have only little chance becoming implemented.
(I'm just not sure if I really want to _invite_ him to. :)

Best regards,
Stephan Hennig