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

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.

...

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.

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

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

...

\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

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.

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