On Sat, 23 Sep 2006 15:03:57 +0100 Sanjoy Mahajan wrote:

[Hans: Feature suggestion for figure inclusion at the end...]

I wrote:

...

So, is --final a requirement when using metafun, or am I hacking around a problem I've caused by leaving something out?

An answer is that I should set \runMPgraphicstrue. I thought it was automatically set, half-remembering what Aditya said in the previous thread on metafun. So the following works (changing the r changes the result right away without requiring --final or requiring two texexec runs):

========= cut here ================== \runMPgraphicstrue \starttext

\startreusableMPgraphic{a} r := 1cm; fill fullcircle scaled r; \stopreusableMPgraphic

\placefigure[force,none]{}{\reuseMPgraphic{a}}

the figure above should be a small circle

\stoptext ========= cut here ==================

To see where and when \runMPgraphicstrue was done, I looked into the metafun interface code, and asked grep for help:

$ grep '\\runMPgraphicstrue' *.tex s-pre-02.tex:113:%D switch \type {\runMPgraphicstrue} to the local file \type supp-mps.tex:1195:%D \runMPgraphicstrue supp-mps.tex:1209:%D \type{\runMPgraphicstrue}, the \METAPOST\ scratch file supp-mps.tex:1653:%D \global\runMPgraphicstrue supp-mps.tex:1991: \runMPgraphicstrue

So it's commented-in only at line 1991, which is part of a new (to me) method of figure inclusion: \startstaticMPgraphic, which says "Dedicated to Aditya Mahajan. See meta-ini for usage", so I see how Aditya would conclude that \runMPgraphicstrue is always true :-)

The following therefore also works to get instant updating, and is more efficient than reusable MP graphics in that it reruns metapost on included figures only when they change:

========= cut here ================== % no need to set \runMPgraphicstrue \starttext

% see how smart staticMPfigure is by changing r here but not % in the figure definition itself. Will it re-metapost the graphic? % Answer: It's smart. \startMPinclusions r := 1cm; \stopMPinclusions

\startstaticMPfigure{a} fill fullcircle scaled r; \stopstaticMPfigure

\placefigure[force,none]{}{\usestaticMPfigure[a]}

the figure above should be a small or large circle

\stoptext ========= cut here ==================

Which I just now see is on the Wiki page about metafun (I'd been working from the excellent metafun manual).

It's doubly smart in that changing the papersize (which changes the layout parameters, which are included in the metapost file) will rerun the graphic, even if r stays the same. So the graphic can base itself on those parameters and be updated when needed.

Thanks, Hans and Aditya!

While experimenting with the methods of figure inclusion, I've been changing among \reuseMPgraphic, \usestaticMPfigure, \useMPgraphic, and \externalfigure to call up the figure. Do all the figure labels live in the same namespace? In which case (warning: feature suggestion!) when they are defined, e.g. with \useexternalfigure, \startstaticMPfigure, ..., could the label have associated with it the command that calls it up? So one could do for all types:

\usefigure[thelabel]

and ConTeXt would figure out what kind of figure it is and turn \usefigure into the appropriate one (\reuseMPgraphic, ...).

Then speaking purely hypothetically of course: If, after learning metafun, one decides to turn many external metapost figures into metafun figures (and then static figures instead of reusable figures), the figure placement commands don't have change.

-Sanjoy

Hi Sanjoy, you should also look in your cont-sys.tex if \runMPgraphicstrue is enabled for every ConTeXt run. Wolfgang

On Sat, 23 Sep 2006 17:46:56 +0100 Sanjoy Mahajan wrote:

Wolfgang,

Thanks for the pointer. I don't have a cont-sys.tex, but cont-sys.rme has these lines

% \runMPgraphicstrue % \runMPTEXgraphicstrue

The .rme extension meant I'd missed it when I ran grep on the .tex files. I'll uncomment them.

Oh, that's not a good idea, because the next context update will overwrite cont-sys.rme. So I should copy cont-sys.rme to cont-sys.tex first, then uncomment the lines in cont-sys.tex. But then a context update will overwrite cont-sys.rme, and the new version will be ignored because I have a cont-sys.tex.

So maybe the best approach is to edit cont-sys.rme directly, then merge changes (using a revision control system like mercurial or git) that arrive with the new context distributions.

-Sanjoy

You could make a copy of cont-sys.rme and save it as cont-sys.tex without problems. The cont-sy.rme file is only loaded when ConTeXt can't find a cont-sys.tex file on your system. Don't bother about changes in the cont-sys.rme with a new ConTeXt release, because the standalone Distribution for Windows comes with both files and they have also differences. cont-sys.rme says defaultencoding=ec and cont-sys.tex says defaultencoding=texnansi :-) AFAIK this is somewhere mentioned in one of the manuals. Wolfgang

Mojca Miklavec wrote:

On 9/23/06, Sanjoy Mahajan wrote:

...

So maybe the best approach is to edit cont-sys.rme directly, then merge changes (using a revision control system like mercurial or git) that arrive with the new context distributions.

Changes in cont-sys.rme don't happen that often. You can safely create cont-sys.tex, edit that one and check for changes once in a (long) while.

Changes to the .rme files are always explicitly flagged in the release notes. Taco

On Sun, 24 Sep 2006, Hans Hagen wrote:

...

Oh, that's not a good idea, because the next context update will overwrite cont-sys.rme. So I should copy cont-sys.rme to cont-sys.tex first, then uncomment the lines in cont-sys.tex. But then a context update will overwrite cont-sys.rme, and the new version will be ignored because I have a cont-sys.tex.

right, that's the idea ; just occasionally peek in the shipped cont-sys.rme to see if something important came up ... not that frequently

What do you think about a cont-sys.tex like this: \input cont-sys.rme \runMPgraphicstrue \runMPTEXgraphicstrue \endinput ? Cheers, Peter -- http://pmrb.free.fr/contact/

sure, that's an option, but up to the user (maybe wikify this suggestion)

Patrick: Not sure if it's a firefox-only problem or one that the contextgarden wiki can help with by sending more detailed mime types, but... If I try to edit the top level of a page by clicking the edit tab at the top, then I get a dialog box from Firefox (on Linux). I just tried it with http://wiki.contextgarden.net/Cont-sys.tex and got "You have chosen to open index.php which is a: PHP script. What should Firefox do with this file?..." If I'm logged in to the wiki then it happens. If I'm not logged in, then I get the wiki editor page and all is fine. If a page has sections, I can click the edit link to the right of the section title and it works fine whether or not I'm logged in. -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.