\sometxt in staticMPfigure

\sometxt in staticMPfigure

[Sanjoy Mahajan]

Another small metafun test file.  It displays no text in the middle of
the ellipse.  Using \textext instead of \sometxt works.

\starttext
\startstaticMPfigure{fig}
  draw \sometxt{hello};
  draw fullcircle scaled 1cm xscaled 2;
\stopstaticMPfigure

\usestaticMPfigure[fig]

xyz
\stoptext

Re: \sometxt in staticMPfigure

[Hans Hagen]

Sanjoy Mahajan wrote:
> Another small metafun test file.  It displays no text in the middle of
> the ellipse.  Using \textext instead of \sometxt works.
>
> \starttext
> \startstaticMPfigure{fig}
>   draw \sometxt{hello};
>   draw fullcircle scaled 1cm xscaled 2;
> \stopstaticMPfigure
>
> \usestaticMPfigure[fig]
>
> xyz
> \stoptext
>   
demanding guy ... 

a static is just an mp graphic and mp does not know a thing about \macros

you can try the bet ai just uploaded 

Hans 


-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

Hans Hagen wrote:
> demanding guy ...  a static is just an mp graphic and mp does not know
> a thing about \macros

Thanks, I understand now; and sorry, I hadn't meant it as a feature
request!  I was trying only to learn the differences between all the
ways of doing *TeX labels in figures, and was trying experiments.  I
should have added that the difference was probably from a confusion on
my part (my conceptual model derailed when sometxt failed but textext
worked).

> you can try the bet ai just uploaded 

Thanks!  I'm using the new beta (2006.09.25) to test sometxt in
staticMPfigure but got derailed at this staticMPgraphic:

============= 4.tex =====================================
\starttext
\startstaticMPfigure{fig}
  draw fullcircle scaled 1cm xscaled 2;
\stopstaticMPfigure

\usestaticMPfigure[fig]

xyz
\stoptext
==================================================

The texexec run says "figure 4-fig.pdf can not be found" and 4.pdf shows
a dummy figure in place of the figure.  4-fig.mp contains just

=========================================
;

draw fullcircle scaled 1cm xscaled 2;
=========================================

which looks a lot simpler than it did in previous versions.  4.log says
that write18 ran

   texmfstart --ifchanged=4-fig.mp texexec --mpstatic 4-fig.mp

I ran it by hand omitting the --ifchanged:

  $ texmfstart texexec --mpstatic 4-fig.mp
  /home/sanjoy/texmf/scripts/context/ruby/texexec.rb:101:in `mpstatic'TeXExec | option 'randomseed' is set to '1131'
  TeXExec | option 'filename' is set to '4-fig.mp'
  TeXExec | option 'mainlanguage' is set to 'standard'
  TeXExec | option 'bodyfont' is set to 'standard'
  TeXExec | option 'language' is set to 'standard'
  TeXExec | option 'engine' is set to 'standard'
  TeXExec | option 'distribution' is set to 'web2c'
  TeXExec | option 'texformats' is set to 'ennlmptopdf'
  TeXExec | option 'mpsformats' is set to 'metafun'
  TeXExec | option 'progname' is set to 'context'
  TeXExec | option 'interface' is set to 'standard'
  TeXExec | option 'runs' is set to '8'
  TeXExec | option 'backend' is set to 'standard'
  : undefined method `processmpstatic' for #<TEX:0xb7bbe91c> (NoMethodError)
	  from /home/sanjoy/texmf/scripts/context/ruby/texexec.rb:749

I guess because there's no processmpstatic procedure, whereas texexec.rb
calls job.processmpstatic.  But the analogous procedure,
processmpgraphic, is a bit daunting so I haven't tried to write
processmpstatic.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   -- Bertrand de Jouvenal

Re: \sometxt in staticMPfigure

[Hans Hagen]

Sanjoy Mahajan wrote:
>
> I guess because there's no processmpstatic procedure, whereas texexec.rb
> calls job.processmpstatic.  But the analogous procedure,
> processmpgraphic, is a bit daunting so I haven't tried to write
> processmpstatic.
>   
    def processmpstatic
        if filename = getvariable('filename') then

in tex.rb 

looks like a messed up update 


-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

>    def processmpstatic
>        if filename = getvariable('filename') then

> in tex.rb 
>
> looks like a messed up update 

Ah, you're right and I just realized what happened.  

'ctxtools --updatecontext' calls unzip with -uo:

       -u  update existing files and create new ones if needed.  This
           option performs the same function as the -f option,
           extracting (with query) files that are newer than those
           with the same name on disk, and in addition it extracts
           those files that do not already exist on disk.  See -f
           above for information on setting the timezone properly.

I'd been hacking with tex.rb (debugging the --dvi switch) so my tex.rb
was more recent than the one in cont-tmf.zip, so it wasn't updated.

Is it important to have -u?  I'd take the -u switch out of my own
ctxtools.rb but then it'll eventually get overwritten with the next
update, and the -u switch will be back!

I'll update by hand for now and retest.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: \sometxt in staticMPfigure

[Hans Hagen]

Sanjoy Mahajan wrote:
> Ah, you're right and I just realized what happened.  
>
> 'ctxtools --updatecontext' calls unzip with -uo:
>
>        -u  update existing files and create new ones if needed.  This
>            option performs the same function as the -f option,
>            extracting (with query) files that are newer than those
>            with the same name on disk, and in addition it extracts
>            those files that do not already exist on disk.  See -f
>            above for information on setting the timezone properly.
>
> I'd been hacking with tex.rb (debugging the --dvi switch) so my tex.rb
> was more recent than the one in cont-tmf.zip, so it wasn't updated.
>
> Is it important to have -u?  I'd take the -u switch out of my own
> ctxtools.rb but then it'll eventually get overwritten with the next
> update, and the -u switch will be back!
>   
dunno, probably only for speed reasons, so maybe we should use just -o 

Hans 


-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

>> Is it important to have -u?
> dunno, probably only for speed reasons, so maybe we should use just -o 

I agree.  Correctness over speed, I think.  -u makes testing reports
less reliable and can cause subtle bugs when all the files don't share
the same version (I noticed it soon in this case only because it had
happened to me before when it took a while to find).

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: \sometxt in staticMPfigure

[Aditya Mahajan]

On Tue, 26 Sep 2006, Hans Hagen wrote:

> Sanjoy Mahajan wrote:
>> Ah, you're right and I just realized what happened.
>>
>> 'ctxtools --updatecontext' calls unzip with -uo:
>>
>>        -u  update existing files and create new ones if needed.  This
>>            option performs the same function as the -f option,
>>            extracting (with query) files that are newer than those
>>            with the same name on disk, and in addition it extracts
>>            those files that do not already exist on disk.  See -f
>>            above for information on setting the timezone properly.
>>
>> I'd been hacking with tex.rb (debugging the --dvi switch) so my tex.rb
>> was more recent than the one in cont-tmf.zip, so it wasn't updated.
>>
>> Is it important to have -u?  I'd take the -u switch out of my own
>> ctxtools.rb but then it'll eventually get overwritten with the next
>> update, and the -u switch will be back!
>>
> dunno, probably only for speed reasons, so maybe we should use just -o

How about adding a --force switch to --updatecontext. So that

ctxtools --updatecontext calls unzip -uo (for the normal user)

and

ctxtools --updatecontext --force calls unzip -o (for those who play 
around with source files)

Aditya

Re: \sometxt in staticMPfigure

[Hans Hagen]

Aditya Mahajan wrote:
> On Tue, 26 Sep 2006, Hans Hagen wrote:
>
>   
>> Sanjoy Mahajan wrote:
>>     
>>> Ah, you're right and I just realized what happened.
>>>
>>> 'ctxtools --updatecontext' calls unzip with -uo:
>>>
>>>        -u  update existing files and create new ones if needed.  This
>>>            option performs the same function as the -f option,
>>>            extracting (with query) files that are newer than those
>>>            with the same name on disk, and in addition it extracts
>>>            those files that do not already exist on disk.  See -f
>>>            above for information on setting the timezone properly.
>>>
>>> I'd been hacking with tex.rb (debugging the --dvi switch) so my tex.rb
>>> was more recent than the one in cont-tmf.zip, so it wasn't updated.
>>>
>>> Is it important to have -u?  I'd take the -u switch out of my own
>>> ctxtools.rb but then it'll eventually get overwritten with the next
>>> update, and the -u switch will be back!
>>>
>>>       
>> dunno, probably only for speed reasons, so maybe we should use just -o
>>     
>
> How about adding a --force switch to --updatecontext. So that
>
> ctxtools --updatecontext calls unzip -uo (for the normal user)
>
> and
>
> ctxtools --updatecontext --force calls unzip -o (for those who play 
> around with source files)
>
>   
i already patched ctxtool to unzip everything 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

> i already patched ctxtool to unzip everything 

I think this is the right solution (or using -o to unzip).  The unzip
time is low compared with the time to download cont-tmf.zip (disks are
faster than almost all network connections), so optimizing unzip time
is not worth the chance of inconsistent source files.  

>From Knuth, I think: "Premature optimization is the root of all evil."

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

With the new beta, this stress test for \sometxt works fine:

====================================================
\setupcolors[state=start]
\starttext
\startstaticMPfigure{fig}
  label(\sometxt{he\color[blue]{ab}lo}, origin) withcolor red;
  draw fullcircle scaled 1cm xscaled 2;
\stopstaticMPfigure

\usestaticMPfigure[fig]

xyz
\stoptext
====================================================

Well, it comes out in red, then blue, but the last two letters ('lo')
are in black, I guess because pdftex doesn't have a color stack.  But
that's not what I was meaning to test.  I just wanted to test \sometxt
and it looks good.

But, the following now doesn't work (I'm pretty sure it would have
worked with 2006.08.08 because I've been using the boxes macros alot):

================= dc2.tex [my crazy naming scheme] ===================
\starttext

\startMPinclusions
  input boxes
\stopMPinclusions

\startstaticMPfigure{fig}
  boxit.h(btex h etex);
  drawboxed(h);
\stopstaticMPfigure

\usestaticMPfigure[fig]

xyz

\stoptext
====================================================

It produces

  This is MetaPost, Version 0.901 (Web2C 7.5.3)
  (/home/sanjoy/texmf/web2c/natural.tcx)
  (texexec-mpgraph.mp
  >> boxit.h
  ! Isolated expression.
  <to be read again> 
		     (
  l.150 boxit.h(
		btex  h etex
  ? 

That's from making:

============== dc2-fig.mp ======================================
;

boxit.h(btex h etex);
drawboxed(h);
====================================================

and then ruby running:

  system(texmfstart --ifchanged=dc2-fig.mp texexec --mpstatic dc2-fig.mp),

which eventually makes the larger file texexec-mpgraph.mp and then does:

  mpost -mem=metafun -translate-file=natural.tcx texexec-mpgraph.mp

which produces the same error.

Hmm, looking at texexec-mpgraph.mp, there's no 'input boxes' line, so
the MPinclusions are not being included?

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   -- Bertrand de Jouvenal

Re: \sometxt in staticMPfigure

[Hans Hagen]

Sanjoy Mahajan wrote:
> With the new beta, this stress test for \sometxt works fine:
>
> ====================================================
> \setupcolors[state=start]
> \starttext
> \startstaticMPfigure{fig}
>   label(\sometxt{he\color[blue]{ab}lo}, origin) withcolor red;
>   draw fullcircle scaled 1cm xscaled 2;
> \stopstaticMPfigure
>
> \usestaticMPfigure[fig]
>
> xyz
> \stoptext
> ====================================================
>
> Well, it comes out in red, then blue, but the last two letters ('lo')
> are in black, I guess because pdftex doesn't have a color stack.  But
> that's not what I was meaning to test.  I just wanted to test \sometxt
> and it looks good.
>   
this is tricky; context has a color stack, but the text  and mp stuff 
work independently (in mp there is no symmetry in color handling); i can 
imagine a different handling of mp colors, but this will slow down 
things (comes down to pushing and popping colors on the context color 
stack and such)

in this situation, i think that the best we can do is to revert to the 
current color, so i patched things a bit:

test case:

\setupcolors[state=start,textcolor=red]
\starttext
    red
        \color[green]{green
            \startMPcode
                label(\sometxt{green\color[blue]{blue}green}, origin) 
withcolor red;
                draw fullcircle scaled 1cm xscaled 2;
            \stopMPcode
        green}
    red
\stoptext

> But, the following now doesn't work (I'm pretty sure it would have
> worked with 2006.08.08 because I've been using the boxes macros alot):
>
> ================= dc2.tex [my crazy naming scheme] ===================
> \starttext
>
> \startMPinclusions
>   input boxes
> \stopMPinclusions
>
> \startstaticMPfigure{fig}
>   boxit.h(btex h etex);
>   drawboxed(h);
> \stopstaticMPfigure
>
> \usestaticMPfigure[fig]
>
> xyz
>
> \stoptext
> ====================================================
>
> It produces
>
>   This is MetaPost, Version 0.901 (Web2C 7.5.3)
>   (/home/sanjoy/texmf/web2c/natural.tcx)
>   (texexec-mpgraph.mp
>   >> boxit.h
>   ! Isolated expression.
>   <to be read again> 
> 		     (
>   l.150 boxit.h(
> 		btex  h etex
>   ? 
>
> That's from making:
>   
hm, i'll add the inclusions
(here it fails anyway doe to some

clearboxes->clearboxes
                      .clearb_(h);
clearboxes->clearboxes
                      .clearb_(h);
clearboxes->clearboxes
                      .clearb_(h);
clearboxes->clearboxes
                      .clearb_(h);
clearboxes->clearboxes

no time to look into that now (i never use boxes)

i'll make a new beta

Hans

 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

> > \starttext
> >
> > \startMPinclusions
> >   input boxes
> > \stopMPinclusions
> >
> > \startstaticMPfigure{fig}
> >   boxit.h(btex h etex);
> >   drawboxed(h);
> > \stopstaticMPfigure
> >
> > \usestaticMPfigure[fig]
> >
> > xyz
> >
> > \stoptext

> hm, i'll add the inclusions
> (here it fails anyway doe to some
> 
> clearboxes->clearboxes
>                       .clearb_(h);

I'd seen those errors in one of my tests.  Oh, that's what it was: I'd
tried the input boxes line in the figure itself.  Had you tried the
same thing either by hand or with the inclusions or verbatimtex..etex
material going inside the figure?  Here's the test file:

\starttext
\startstaticMPfigure{fig}
  input boxes
  boxit.h(btex h etex);
  drawboxed(h);
\stopstaticMPfigure
\usestaticMPfigure[fig]
\stoptext

Regular metapost gives the same clearboxes error (not sure if it's a
MP bug or something tricky the boxes package did that doesn't work
inside a figure?).  Feed this file to mpost to test:

beginfig(1)
  input boxes
  boxit.h(btex h etex);
  drawboxed(h);
endfig;
end

> i'll make a new beta

Thanks.

-Sanjoy

Re: \sometxt in staticMPfigure

[Hans Hagen]

you can test the beta

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

> you can test the beta

This gives the clearboxes error:

=================== box.tex ===================
\startMPinclusions
  input boxes
\stopMPinclusions

\starttext
\startstaticMPfigure{fig}
  boxit.h(btex h etex);
  drawboxed(h);
\stopstaticMPfigure
\usestaticMPfigure[fig]
\stoptext
=====================================

The cause is that it produces this intermediate mp file:

========= box-fig.mp ===============
input boxes
boxit.h(btex h etex);
drawboxed(h);
===================================

This fails because all three lines go into a beginfig..endfig and
metapost fails.  That may be a metapost bug in this case, but for
robustness I think it should become:

input boxes
beginfig(1)
boxit.h(btex h etex);
drawboxed(h);
endfig;
end

In order to do that transformation, box-fig.mp would need separate
sections for the inclusions and for the main figure code.

Am I using inclusions incorrectly?  i.e. Should I instead use
MPextensions to get material placed at the top of the metapost file
for use by all figures?  Like this:

=============== box-e.tex ================
\startMPextensions
  input boxes
\stopMPextensions

\starttext
\startstaticMPfigure{fig}
  boxit.h(btex h etex);
  drawboxed(h);
\stopstaticMPfigure
\usestaticMPfigure[fig]
\stoptext
=======================================

But that produces 

  (texexec-mpgraph.mp
  >> boxit.h
  ! Isolated expression.
  <to be read again> 
		     (
  l.148  boxit.h(
		 btex  h etex
  ? 

because the added extensions ('input boxes') are not included in
texexec-mpgraph.mp.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: \sometxt in staticMPfigure

[Hans Hagen]

Sanjoy Mahajan wrote:
>> you can test the beta
>>     
>
> This gives the clearboxes error:
>
> =================== box.tex ===================
> \startMPinclusions
>   input boxes
> \stopMPinclusions
>
> \starttext
> \startstaticMPfigure{fig}
>   boxit.h(btex h etex);
>   drawboxed(h);
> \stopstaticMPfigure
> \usestaticMPfigure[fig]
> \stoptext
> =====================================
>
> The cause is that it produces this intermediate mp file:
>
> ========= box-fig.mp ===============
> input boxes
> boxit.h(btex h etex);
> drawboxed(h);
> ===================================
>
> This fails because all three lines go into a beginfig..endfig and
> metapost fails.  That may be a metapost bug in this case, but for
> robustness I think it should become:
>
> input boxes
> beginfig(1)
> boxit.h(btex h etex);
> drawboxed(h);
> endfig;
> end
>
> In order to do that transformation, box-fig.mp would need separate
> sections for the inclusions and for the main figure code.
>
> Am I using inclusions incorrectly?  i.e. Should I instead use
> MPextensions to get material placed at the top of the metapost file
> for use by all figures?  Like this:
>
> =============== box-e.tex ================
> \startMPextensions
>   input boxes
> \stopMPextensions
>
> \starttext
> \startstaticMPfigure{fig}
>   boxit.h(btex h etex);
>   drawboxed(h);
> \stopstaticMPfigure
> \usestaticMPfigure[fig]
> \stoptext
> =======================================
>
> But that produces 
>
>   (texexec-mpgraph.mp
>   >> boxit.h
>   ! Isolated expression.
>   <to be read again> 
> 		     (
>   l.148  boxit.h(
> 		 btex  h etex
>   ? 
>
> because the added extensions ('input boxes') are not included in
> texexec-mpgraph.mp.
>   
the problem (if you look into the mp file) is that there is *no* 
beginfig; this is because we now use a more stupid (stripped down) 
variant of saving the graphic.

\startstaticMPfigure{fig}
beginfig(1);
  boxit.h(btex h etex);
  drawboxed(h);
endfig;
\stopstaticMPfigure

i'll add the b/e to the main macro. 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

Hans Hagen wrote:

  the problem (if you look into the mp file) is that there is *no* 
  beginfig; this is because we now use a more stupid (stripped down) 
  variant of saving the graphic.

Right, I looked into the mp file and saw the new plan.

  \startstaticMPfigure{fig}
  beginfig(1);
    boxit.h(btex h etex);
    drawboxed(h);
  endfig;
  \stopstaticMPfigure

  i'll add the b/e to the main macro. 

I briefly thought about adding the beginfig..endfig by hand, but I
figured it would fail because texexec would wrap another
beginfig..endfig around it -- since it didn't know that some parts of
the file needed to go outside the beginfig..endfig.

However, a simple experiment trumps a fine theory: I added the
beginfig..endfig and it worked.  But the theory wasn't all wrong.
Here's a snippet of texexec-mpgraph.mp

==============================================
beginfig(1);
verbatimtex \global \loadfontfileoncetrue  etex;
input boxes


beginfig(1)
boxit.h(btex  h etex
);
drawboxed(h);
endfig;

;
endfig;
==============================================

Not sure how metapost managed to deal with the nested beginfig's, but it
did.  Here's what the log said:

  2 output files written: texexec-mpgraph.1 .. texexec-mpgraph.1

It looks like a fragile method.  Instead the beginfig..endfig should be
put in explicitly into the mp file (just as you said) and the inclusions
should go outside the beginfig..endfig.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   -- Bertrand de Jouvenal

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

Hans Hagen wrote:
> test case:
> 
> \setupcolors[state=start,textcolor=red]
> \starttext
>     red
>         \color[green]{green
>             \startMPcode
>                 label(\sometxt{green\color[blue]{blue}green}, origin) 
> withcolor red;
>                 draw fullcircle scaled 1cm xscaled 2;
>             \stopMPcode
>         green}
>     red
> \stoptext

The test case works as you say (2006.09.26 beta).  Though I don't
understand why [Note added later: I now understand, see at the
end...]: e.g. why the 'green' text in the \sometxt is green.
Shouldn't the withcolor red trump the \color[green] from ConTeXt?  I
take your point about the lack of a color stack in metapost and the
difficulty of getting the metapost and context stacks to interact.

Here's a shorter example of what I'm confused about.

\setupcolors[state=start,textcolor=yellow]
\starttext
            \startMPcode
                label(\sometxt{?red?}, origin) withcolor red;
            \stopMPcode
\stoptext

The label(\sometxt{...}) withcolor red would produce postscript code like

  1 0 0 setrgbcolor
  <font stuff for ?red?>
  0 0 0 setrgbcolor

and that would be surrounded by code to set textcolor to yellow.

Oh, I understand now.  The \sometxt{} wraps the ?red? in yellow
setrgbcolor, since that's seen first by ConTeXt, and *then* it's
wrapped by metapost in red setrgcolor, so the red is overridden by the
yellow inside it.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: \sometxt in staticMPfigure

[Hans Hagen]

Sanjoy Mahajan wrote:
> Hans Hagen wrote:
>   
>> test case:
>>
>> \setupcolors[state=start,textcolor=red]
>> \starttext
>>     red
>>         \color[green]{green
>>             \startMPcode
>>                 label(\sometxt{green\color[blue]{blue}green}, origin) 
>> withcolor red;
>>                 draw fullcircle scaled 1cm xscaled 2;
>>             \stopMPcode
>>         green}
>>     red
>> \stoptext
>>     
>
> The test case works as you say (2006.09.26 beta).  Though I don't
> understand why [Note added later: I now understand, see at the
> end...]: e.g. why the 'green' text in the \sometxt is green.
> Shouldn't the withcolor red trump the \color[green] from ConTeXt?  I
> take your point about the lack of a color stack in metapost and the
> difficulty of getting the metapost and context stacks to interact.
>
> Here's a shorter example of what I'm confused about.
>
> \setupcolors[state=start,textcolor=yellow]
> \starttext
>             \startMPcode
>                 label(\sometxt{?red?}, origin) withcolor red;
>             \stopMPcode
> \stoptext
>
> The label(\sometxt{...}) withcolor red would produce postscript code like
>
>   1 0 0 setrgbcolor
>   <font stuff for ?red?>
>   0 0 0 setrgbcolor
>
> and that would be surrounded by code to set textcolor to yellow.
>
> Oh, I understand now.  The \sometxt{} wraps the ?red? in yellow
> setrgbcolor, since that's seen first by ConTeXt, and *then* it's
> wrapped by metapost in red setrgcolor, so the red is overridden by the
> yellow inside it.
>   
indeed, another option is to replace more of mp's color stuff by context but then we may end up in other problems 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: \sometxt in staticMPfigure

[Sanjoy Mahajan]

Hans Hagen <pragma@wxs.nl> wrote:
> indeed, another option is to replace more of mp's color stuff by
> context but then we may end up in other problems

I'm guessing that pdftex+lua will make it easier to meld tex and
metapost.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   -- Bertrand de Jouvenal

Re: \sometxt in staticMPfigure

[Hans Hagen]

Sanjoy Mahajan wrote:
> Hans Hagen <pragma@wxs.nl> wrote:
>   
>> indeed, another option is to replace more of mp's color stuff by
>> context but then we may end up in other problems
>>     
>
> I'm guessing that pdftex+lua will make it easier to meld tex and
> metapost.
>   
not really, for that we need mp as a library (we did experiments with simulating that but it's kind of tricky) 

concerning lua ... i do have a mkiv file on my machine that uses lua to parse the mp output (precursor to mp natively spitting out such code); currently its a bit slower (two step conversion ps -> lua -> tex) but when using many pen shapes its faster because then we don't need the tex based concat code; also, less (and cleaner) code is needed for parsing 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------