[metapost] Can't get write/scantokens to work.

[Dan Luecking]

At 05:24 AM 9/18/2007, you wrote:

>It has been proposed
>(http://tex.loria.fr/prod-graph/zoonekynd/metapost/macros.mp) to use the
>following macro :
>
>vardef TEX primary s =
>   write "verbatimtex"                    to "mptextmp.mp";
>   write "\documentclass[12pt]{article}"  to "mptextmp.mp";
>   write "\usepackage[T1]{fontenc}"       to "mptextmp.mp";
>   write "\usepackage{amsmath,amssymb}"   to "mptextmp.mp";
>   write "\begin{document}"               to "mptextmp.mp";
>   write "etex"                           to "mptextmp.mp";
>   write "btex "&s&" etex"                to "mptextmp.mp";
>   write EOF                              to "mptextmp.mp";
>   scantokens "input mptextmp"
>enddef;
>
>Then use TEX(...) to get a picture of a TeX command.
>
>Well, I don't really understand why all the prologue is required (maybe
>because I don't understand the way the input is processed by
>scantokens), still, this looks like an ugly hack.

1. Metapost's does btex/etex scanning at a different level than
other scanning. When the first such item in a file is encountered,
it searches the whole input file for them and runs (la)tex
once. It runs a separate tex process for each separate input file.

2. Since the argument to the TEX macro is not recognized as a
btex/etex until the macro is expanded, this macro is typically
encountered after the rest of that file has alererady been scanned.
Therefore it writes the required structure to a temporary file and
inputs it to force metapost to process it.

3. Since a separate tex process is started for each TEX macro call,
each such call requires a new verbatimtex prologue.

4. Metapost rules disallow the special token "input" in the
replacement text of a macro. Thus this macro hides it in a
string that is passed to scantokens.

The reason for point 4 is that macro text is tokenized during
the definition process. This can cause valid filenames to become
corrupted. For example, the valid filenames x01 and x1.0 would both
be converted into the same tokens even though they represent different
files. Therefore input has to be at the outer level, so Metapost will
know not to tokenize the filename. (This is a consequence of Knuth's
decision not to represent filenames as strings. A reasonable decision
at the time, given that Metafont did not have the "write" and "read"
commands.)

If you have metapost version 1.000 you can use the TEXPRE macro to
establish the verbatimtex that will be passed to each TEX call. With
that, you don't have to define your own TEX macro, but can use the
one defined in the distributed file TEX.mp.


>verbatimtex
>%&latex
>\documentclass{article}
>\usepackage[T1]{fontenc}
>\usepackage[nice]{nicefrac}
>\begin{document}
>etex;
>
>vardef TEX primary s =
>   write "verbatimtex"                    to "mptextmp.mp";
>   write "%&latex"                       to "mptextmp.mp";
>   write "\documentclass{article}"       to "mptextmp.mp";
>   write "\usepackage[T1]{fontenc}"       to "mptextmp.mp";
>   write "\usepackage[nice]{nicefrac}"   to "mptextmp.mp";
>   write "\begin{document}"               to "mptextmp.mp";
>   write "etex"                           to "mptextmp.mp";
>   write "btex "&s&" etex"                to "mptextmp.mp";
>   write EOF                              to "mptextmp.mp";
>   scantokens "input mptextmp"
>enddef;
>
>prologues := 2;
>beginfig(1)
>   label (TEX("abc"), (0,0));
>   label (btex b etex, (2cm, 2cm));
>   label (TEX("def$\nicefrac{1}{2}$"), (4cm, 4cm));
>endfig;
>end.
>
>
>mptopdf(1) just says there's an error (thanks buddy), but mpost(1) seems
>just fine about it.  If I run mptopdf(1) after mpost(1), the `b'
>disappears and only `1/2' is shown on both upper-right and lower-left
>corners.  The point is that I must use mptopdf(1) to get some
>transparency effects.

Perhaps ther are some fonts missing in your setup. The T1 font
encoding (without other changes) selects the EC fonts to replace
CM in LaTeX. Not every system has these in the type1 format that
works best in PDF. It is possible that mptopdf has trouble with
this. Your file works fine on my system, with the cm-super files
SFRM1000.pfb partially embedded in try.1 and mptopdf having no
problems.


>So, question is, am I searching for a feature beyond MP capacities?

No. The proof is that it works for me. Of course, I have Metapost 1.000
which is much better than previous at handling fonts.

Dan


Daniel H. Luecking
Department of Mathematical Sciences
University of Arkansas
"Dubito ergo cogito, cogito ergo sum" --Descarte