Hans Hagen wrote:

  this is runtime tex into passed to the graphic ... imagine that we
  flush this to the mp file ... it can contain info that is not known in
  that session (like overlay info) which willbreak the mp run

  the issue here is that a static graphic is processed in another,
  independent run, that's the whole idea behind static graphics (quick
  hack for independent graphics)

That makes sense.  So should I use reusableMPgraphic instead of
staticMPfigure?  My figures started as standalone mpost figures that I
incorporate chapter by chapter into the ConTeXt source file.  I was
using staticMPfigure because I'd noticed the code in the ConTeXt sources
and it's so fast.

  we can spend a lot of time to make it more advanced but within a year
  from now we will have mp as a library in tex which will reduce runtime
  to nearly zero (at least that 's what experiments show) so ....

Great!  Although earlier you had said, when I wondered whether
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

Oh I understand what you were saying: that pdftex+lua is not sufficient
for clean metapost intergration, one also needs metapost as a library (I
guess in lua?).  Anyway, don't bother to answer that.  Develop in peace,
and I'm looking forward to the result (and will be happy to test when
that's useful).

  what we can do [for staticMPfigure] is pass info from the mpenvironment"

It works well, thanks for another instant improvement.  The 2006.09.28
beta passes the following test case (I will commit it to the contexttest
repository).  It gives a 12pt "outside sometxt" and a 20pt "in sometxt":

============= with-static.tex ================================
\startMPenvironment
\setupbodyfont[20pt]
\stopMPenvironment

\starttext

\startstaticMPfigure{fig}
  label(\sometxt{in sometxt},origin);
\stopstaticMPfigure

outside sometxt\quad
\usestaticMPfigure[fig]
\stoptext
=============================================

Another difference (not important to fix, just a strange corner case)
between staticMPfigure and reusableMPgraphic is the depth of the
resulting box.  With staticMPfigure, the 'in sometxt' is raised to have
its baseline about at the midline of the 'outside sometxt':

============= with-static12.tex ================================
\starttext
\startstaticMPfigure{fig}
  label(\sometxt{in sometxt},origin);
\stopstaticMPfigure
outside sometxt\quad
\usestaticMPfigure[fig]
\stoptext
=============================================

In the reusableMPgraphic method, the outside and inside texts have their
baselines aligned:

============= with-reusable12.tex ================================
\starttext
\startreusableMPgraphic{fig}
  label(\sometxt{in sometxt},origin);
\stopreusableMPgraphic
outside sometxt\quad
\reuseMPgraphic{fig}
\stoptext
=============================================

BUT: I don't need this fixed!  It's a corner case I happened to notice,
and I'm noting it in case it indicates a bug in the box manufacturing.
'See loose thread, any loose thread, pull thread' is how I debug.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   -- Bertrand de Jouvenal
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Reply via email to