Re: [NTG-context] placefigure, usetikzlibrary and readfile
On 8/1/2021 10:27 PM, Jigé via ntg-context wrote:
Hello all.
It seems that \usetikzlibrary is sometimes read, sometimes not, and I don't
understand why.
Rationale:
I would like, using one file, to use it to produce a picture, as with LaTeX's
Standalone class,
but to be able to include it in a calling document as well, for better
management of fonts, etc.
Thus this is most convenient. I have everything in the main document and I can
quickly reuse any figure elsewhere.
What I did:
I use \readfile in a main ConTeXt file document.tex to include the file
included.tex .
The file included.tex should contain *just* the TikZ picture and what is needed to
compile it "standalone".
The issue:
It seems I can call the file with the TikZ picture description multiple times,
with \readfile,
from within the very same \placefigure.
However, if I call it by using two successive \placefigure commands,
the \usetikzlibrary[blabla] in the included file doesn't seem to be recognised.
E.g. with the provided example below, the key "right angle" is not understood,
as if \usetikzlibrary[angles] was not there.
One workaround would be to use
\usetikzlibrary[allTheLibrariesISupposeMightEverBeNeeded]
in the calling file. But I don't like it. I would rather have only the TikZ
libraries relevant to some picture included in the corresponding file.
I'm quite startled by the fact that :
> \placefigure[here][]{This is a figure}{
>\readfile{included}{}{File not found.}
>\readfile{included}{}{File not found.}
> }
compiles but
> \placefigure[here][]{This is a figure}{
>\readfile{included}{}{File not found.}
> }
> \placefigure[here][]{This is a figure}{
>\readfile{included}{}{File not found.}
> }
does not.
modules are loaded only once so you just have to call it in the main
document (more efficient than reloading each time anyway)
loading some module inside a figure is actually problemantic because you
can end up with a mix of global and local definitions depending on how a
module is set up (and tikz being pretty large it might be that at some
point you can expect problems, apart from loading taking time)
you can try to do \input {m-tikz.mlxl} or whatever but don't expect much
help when there is an isseu due to multiple loading of tikz
if there's a lot of extra tikz stuff then you can put that in a privane
module or environment (these are also loaded once) and load that one
if you use the project structure you can actually share environments and
again these are then loaded once
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] placefigure, usetikzlibrary and readfile
Hello all.
It seems that \usetikzlibrary is sometimes read, sometimes not, and I don't
understand why.
Rationale:
I would like, using one file, to use it to produce a picture, as with LaTeX's
Standalone class,
but to be able to include it in a calling document as well, for better
management of fonts, etc.
Thus this is most convenient. I have everything in the main document and I can
quickly reuse any figure elsewhere.
What I did:
I use \readfile in a main ConTeXt file document.tex to include the file
included.tex .
The file included.tex should contain *just* the TikZ picture and what is needed
to compile it "standalone".
The issue:
It seems I can call the file with the TikZ picture description multiple times,
with \readfile,
from within the very same \placefigure.
However, if I call it by using two successive \placefigure commands,
the \usetikzlibrary[blabla] in the included file doesn't seem to be recognised.
E.g. with the provided example below, the key "right angle" is not understood,
as if \usetikzlibrary[angles] was not there.
One workaround would be to use
\usetikzlibrary[allTheLibrariesISupposeMightEverBeNeeded]
in the calling file. But I don't like it. I would rather have only the TikZ
libraries relevant to some picture included in the corresponding file.
I'm quite startled by the fact that :
> \placefigure[here][]{This is a figure}{
>\readfile{included}{}{File not found.}
>\readfile{included}{}{File not found.}
> }
compiles but
> \placefigure[here][]{This is a figure}{
>\readfile{included}{}{File not found.}
> }
> \placefigure[here][]{This is a figure}{
>\readfile{included}{}{File not found.}
> }
does not.
All the best!
Example:
Begin document.tex
\usemodule[tikz]
\starttext
\usetikzlibrary[angles] % Doesn't compile if this is commented out.
%\placefigure[here][]{This is a figure}{
% \readfile{included}{}{File not found.}
% \readfile{included}{}{File not found.}
%}
\placefigure[here][]{This is a figure}{
\ReadFile{included}{}
}
\placefigure[here][]{This is a figure}{
\ReadFile{included}{}
}
\stoptext
End document.tex
Begin included.tex
\usemodule[tikz]
\usetikzlibrary[angles]
%\doifnotmode{*text,*bodypart}{ \startTEXpage[fit] }
\doifnotmode{*text,*bodypart}{ \startTEXpage[fit] \usemodule[tikz]
\usetikzlibrary[angles] }
\hbox{\starttikzpicture[]
\draw[]
(0,0) coordinate (A) node[left] {$A$}
-- (4,0) coordinate (B) node[right] {$B$}
-- (0,3) coordinate (C) node[left] {$C$}
-- cycle
pic [draw, angle radius=0.5cm] {right angle = B--A--C} ;
\stoptikzpicture}
\doifnotmode{*text,*bodypart}{ \stopTEXpage }
End included.tex
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] readfile not understood
I do not understand while \readfile behaves differently from \input with regard
to TeX-code processing.
I have the following code:
\readfile{metapost-setup} %(file with metapost inclusions)
\starttext
\startMPpage
..
\stopMPpage
\stoptext
Replace the \readfile by:
\input ../../../metapost-setup %(file with metapost inclusions)
works ok.
But with \readfile seems to be skipped silently, that is without any sign of it
in the log. The convenience of \readfile should be, if I understand correctly,
that it searches upwards to the root of directory tree. Which makes the series
of ../'s unnecessary and allows for easily pushing the tex-files further down
when their number grows.
Can it be explained?
Hans van der Meer
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] readfile not understood
Am 29.09.2011 um 20:57 schrieb Meer, H. van der:
I do not understand while \readfile behaves differently from \input with
regard to TeX-code processing.
I have the following code:
\readfile{metapost-setup} %(file with metapost inclusions)
\starttext
\startMPpage
..
\stopMPpage
\stoptext
Replace the \readfile by:
\input ../../../metapost-setup %(file with metapost inclusions)
works ok.
But with \readfile seems to be skipped silently, that is without any sign of
it in the log. The convenience of \readfile should be, if I understand
correctly, that it searches upwards to the root of directory tree. Which
makes the series of ../'s unnecessary and allows for easily pushing the
tex-files further down when their number grows.
Can it be explained?
\readfile expects three arguments, replace it with \ReadFile which expects only
one.
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] readfile not understood
Finding the file works with \ReadFile{} works. But is generates another problem
because
\input ../../../metapost-setup
and
\ReadFile{metapost-setup}
behave differently! The \input process my \startMPinclusions correctly but the
ReadFile does not, because the following metapost has the definitions missing.
Hans van der Meer
On 29 sep. 2011, at 21:05, Wolfgang Schuster wrote:
Am 29.09.2011 um 20:57 schrieb Meer, H. van der:
I do not understand while \readfile behaves differently from \input with
regard to TeX-code processing.
I have the following code:
\readfile{metapost-setup} %(file with metapost inclusions)
\starttext
\startMPpage
..
\stopMPpage
\stoptext
Replace the \readfile by:
\input ../../../metapost-setup %(file with metapost inclusions)
works ok.
But with \readfile seems to be skipped silently, that is without any sign of
it in the log. The convenience of \readfile should be, if I understand
correctly, that it searches upwards to the root of directory tree. Which
makes the series of ../'s unnecessary and allows for easily pushing the
tex-files further down when their number grows.
Can it be explained?
\readfile expects three arguments, replace it with \ReadFile which expects
only one.
Wolfgang
___
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] readfile not understood
Am 29.09.2011 um 21:10 schrieb Meer, H. van der:
Finding the file works with \ReadFile{} works. But is generates another
problem because
\input ../../../metapost-setup
and
\ReadFile{metapost-setup}
behave differently! The \input process my \startMPinclusions correctly but
the ReadFile does not, because the following metapost has the definitions
missing.
When you have files which are shared between many different files, then put the
file in the tex directory.
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On Sat, Oct 16, 2010 at 11:09 PM, Aditya Mahajan adit...@umich.edu wrote:
Hi,
In MkII, I can say
\ReadFile{/tmp/filename}
to read a file in /tmp directory. However, in MkIV, that fails because
ReadFile is defined as
\unexpanded\def\ReadFile #1{\doreadfile{any}
{.}{#1}\donothing\donothing}
so it explicitly searches in the . (current) directory.
Bug or feature?
What happen if you put a path like
./../../../../../tmp/filename
?
--
luigi
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On Sun, 17 Oct 2010, luigi scarso wrote:
On Sat, Oct 16, 2010 at 11:09 PM, Aditya Mahajan adit...@umich.edu wrote:
Hi,
In MkII, I can say
\ReadFile{/tmp/filename}
to read a file in /tmp directory. However, in MkIV, that fails because
ReadFile is defined as
\unexpanded\def\ReadFile #1{\doreadfile{any}
{.}{#1}\donothing\donothing}
so it explicitly searches in the . (current) directory.
Bug or feature?
What happen if you put a path like
./../../../../../tmp/filename
It works, but does not fit my need. I wanted to add an option to the
filter module to allow the user to say:
\setupexternalfilters[directory=$TEMP]
and have all the tmp files created in $TEMP. Having to set this as a
relative path will be really ugly.
I am just looking for macro that takes the filename as a (brace
delimited) parameter and typesets it. I can define one on my own; but I
thought that \ReadFile is already supposed to do that.
It is straight forward to fix \ReadFile so that absolute paths work:
\unexpanded\def\readfile #1{\doreadfile{any} \empty{#1}}
\unexpanded\def\ReadFile #1{\doreadfile{any} \empty{#1}\donothing\donothing}
I just wondering if the current behavior is a design decision or an
oversight.
Aditya___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On Sun, 17 Oct 2010, Aditya Mahajan wrote: I am just looking for macro that takes the filename as a (brace delimited) parameter and typesets it. Err.. I mean \inputs it. Aditya ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] \ReadFile in MkII vs MkIV
Am 17.10.2010 um 19:21 schrieb Aditya Mahajan:
It works, but does not fit my need. I wanted to add an option to the filter
module to allow the user to say:
\setupexternalfilters[directory=$TEMP]
and have all the tmp files created in $TEMP. Having to set this as a relative
path will be really ugly.
I am just looking for macro that takes the filename as a (brace delimited)
parameter and typesets it. I can define one on my own; but I thought that
\ReadFile is already supposed to do that.
It is straight forward to fix \ReadFile so that absolute paths work:
\unexpanded\def\readfile #1{\doreadfile{any} \empty{#1}}
\unexpanded\def\ReadFile #1{\doreadfile{any}
\empty{#1}\donothing\donothing}
I just wondering if the current behavior is a design decision or an oversight.
What i get from the comments in the source is that \readfile looks for the
requested file
in the current directory, the parent directories and the tex directory and
\ReadFile is
a alternative form for \readfile without the second and third argument.
You can define your own command \ReadFilter which is based in \readsetfile or
\readfixfile.
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
Am 17.10.2010 um 19:58 schrieb Aditya Mahajan:
I wanted something that will work consistently in MkII and MkIV. I can do:
\doifmodeelse{\s!mkii}
{\let\ReadFilter\ReadFile}
{\def\ReadFilter#1{\doreadfile{any}\empty{#1}\donothing\donothing}}
but, I wanted to avoid such things if possible :-/
Does this work:
\def\ReadFilter#1%
{\readsetfile{/tmp/}{#1}\donothing\donothing}
(BTW, why is system mode *mkii not set in MkII?)
Maybe Hans forgot it for mkii but it doesn’t matter whether mkii/mkiv is a
normal mode or a system mode.
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On Sun, 17 Oct 2010, Wolfgang Schuster wrote:
Am 17.10.2010 um 19:58 schrieb Aditya Mahajan:
I wanted something that will work consistently in MkII and MkIV. I can do:
\doifmodeelse{\s!mkii}
{\let\ReadFilter\ReadFile}
{\def\ReadFilter#1{\doreadfile{any}\empty{#1}\donothing\donothing}}
but, I wanted to avoid such things if possible :-/
Does this work:
\def\ReadFilter#1%
{\readsetfile{/tmp/}{#1}\donothing\donothing}
Yes, for both MkII and MkIV. But this still does not fit the requirement
of my module.
\setupexternalfilters
[directory=,
outputfile=~/output/\externalfilterinputfile.tex,
readcommand=\ReadFilter]
will fail. (The above will generate all the *-*.tmp files in current
directory, which can be purged by passing --purge. The output files are
generated in ~/output directory for future reference. But \ReadFilter
cannot read the file.
I think that I will go with separate definitions for MkII and MkIV, or
perhaps even redefine \ReadFile just before the read function is defined.
(BTW, why is system mode *mkii not set in MkII?)
Maybe Hans forgot it for mkii but it doesn’t matter whether mkii/mkiv is a
normal mode or a system mode.
IIRC, system modes cannot be reset using \(enable|disable)mode.
Aditya___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On 17-10-2010 7:58, Aditya Mahajan wrote:
On Sun, 17 Oct 2010, Wolfgang Schuster wrote:
Am 17.10.2010 um 19:21 schrieb Aditya Mahajan:
It works, but does not fit my need. I wanted to add an option to the
filter module to allow the user to say:
\setupexternalfilters[directory=$TEMP]
and have all the tmp files created in $TEMP. Having to set this as a
relative path will be really ugly.
I am just looking for macro that takes the filename as a (brace
delimited) parameter and typesets it. I can define one on my own; but
I thought that \ReadFile is already supposed to do that.
It is straight forward to fix \ReadFile so that absolute paths work:
\unexpanded\def\readfile #1{\doreadfile{any} \empty{#1}}
\unexpanded\def\ReadFile #1{\doreadfile{any}
\empty{#1}\donothing\donothing}
I just wondering if the current behavior is a design decision or an
oversight.
What i get from the comments in the source is that \readfile looks for
the requested file
in the current directory, the parent directories and the tex directory
and \ReadFile is
a alternative form for \readfile without the second and third argument.
Then the MkII implementation is wrong because it allows absolute paths.
You can define your own command \ReadFilter which is based in
\readsetfile or \readfixfile.
I wanted something that will work consistently in MkII and MkIV. I can do:
\doifmodeelse{\s!mkii}
{\let\ReadFilter\ReadFile}
{\def\ReadFilter#1{\doreadfile{any}\empty{#1}\donothing\donothing}}
but, I wanted to avoid such things if possible :-/
(BTW, why is system mode *mkii not set in MkII?)
because you can do \doifnotmode{mkiv}
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On 17-10-2010 8:54, Aditya Mahajan wrote: Maybe Hans forgot it for mkii but it doesn’t matter whether mkii/mkiv is a normal mode or a system mode. IIRC, system modes cannot be reset using \(enable|disable)mode. there is nothing special about system modes: they just have a * in front so you can enable and disable them (but of course deep down they can be set as well) - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On Sun, 17 Oct 2010, Hans Hagen wrote:
On 17-10-2010 7:58, Aditya Mahajan wrote:
(BTW, why is system mode *mkii not set in MkII?)
because you can do \doifnotmode{mkiv}
:)
Documented on the wiki page on modes.
Aditya
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On Sun, 17 Oct 2010, Hans Hagen wrote:
On 17-10-2010 8:54, Aditya Mahajan wrote:
Maybe Hans forgot it for mkii but it doesn’t matter whether mkii/mkiv
is a normal mode or a system mode.
IIRC, system modes cannot be reset using \(enable|disable)mode.
there is nothing special about system modes: they just have a * in front so
you can enable and disable them (but of course deep down they can be set as
well)
OK. So the * is just so that they are not accidently overwritten.
But I do not like the different treatment for MkII:
cont-new.mkii
\enablemode[mkii]
cont-env.mkiv
\enablemode[mkiv] \newsystemmode{mkiv} \setsystemmode{mkiv}
One more minor difference to remember.
Aditya___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] \ReadFile in MkII vs MkIV
On 17-10-2010 11:02, Aditya Mahajan wrote:
On Sun, 17 Oct 2010, Hans Hagen wrote:
On 17-10-2010 8:54, Aditya Mahajan wrote:
Maybe Hans forgot it for mkii but it doesn’t matter whether mkii/mkiv
is a normal mode or a system mode.
IIRC, system modes cannot be reset using \(enable|disable)mode.
there is nothing special about system modes: they just have a * in
front so you can enable and disable them (but of course deep down they
can be set as well)
OK. So the * is just so that they are not accidently overwritten.
But I do not like the different treatment for MkII:
cont-new.mkii
\enablemode[mkii]
cont-env.mkiv
\enablemode[mkiv] \newsystemmode{mkiv} \setsystemmode{mkiv}
One more minor difference to remember.
Ah, ok, I can add that to mkii of course (actuallym, it shoul dnot be in
cont-new any longer) ... I just had forgotten that there was a mkii mode
at all.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] \ReadFile in MkII vs MkIV
Hi,
In MkII, I can say
\ReadFile{/tmp/filename}
to read a file in /tmp directory. However, in MkIV, that fails because
ReadFile is defined as
\unexpanded\def\ReadFile #1{\doreadfile{any} {.}{#1}\donothing\donothing}
so it explicitly searches in the . (current) directory.
Bug or feature?
Aditya
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
