\sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)

\sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)

[Sanjoy Mahajan]

[I'm testing the 2006.09.27 beta on Linux]

Thanks for the new \sometxt in staticMPfigures.  I'm just testing its
operation, and find that the text is not set in the document's bodyfont
size.  For example,

\setupbodyfont[20pt]
\starttext

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

outside sometxt
\usestaticMPfigure[fig]
\stoptext

produces a small "in sometxt" and a large "outside sometxt".  

With this file both are large, as I expected \sometxt to work:

\setupbodyfont[20pt]
\starttext

\startreusableMPgraphic{fig}
  label(\sometxt{in sometxt},origin);
\stopreusableMPgraphic{

outside sometxt
\reuseMPgraphic{fig}
\stoptext

I haven't figured out the full story.  But in the intermediate .mp files
generated by texexec, the staticMPfigure case has
"BodyFontSize:=12.0pt;" whereas in the reusableMPgraphic case, the file
has "BodyFontSize:=20.0pt;".

-Sanjoy

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

Re: \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)

[Hans Hagen]

Sanjoy Mahajan wrote:
> [I'm testing the 2006.09.27 beta on Linux]
>
> Thanks for the new \sometxt in staticMPfigures.  I'm just testing its
> operation, and find that the text is not set in the document's bodyfont
> size.  For example,
>
> \setupbodyfont[20pt]
> \starttext
>
> \startstaticMPfigure{fig}
>   label(\sometxt{in sometxt},origin);
> \stopstaticMPfigure
>
> outside sometxt
> \usestaticMPfigure[fig]
> \stoptext
>
> produces a small "in sometxt" and a large "outside sometxt".  
>
> With this file both are large, as I expected \sometxt to work:
>
> \setupbodyfont[20pt]
> \starttext
>
> \startreusableMPgraphic{fig}
>   label(\sometxt{in sometxt},origin);
> \stopreusableMPgraphic{
>
> outside sometxt
> \reuseMPgraphic{fig}
> \stoptext
>
> I haven't figured out the full story.  But in the intermediate .mp files
> generated by texexec, the staticMPfigure case has
> "BodyFontSize:=12.0pt;" whereas in the reusableMPgraphic case, the file
> has "BodyFontSize:=20.0pt;".
>   
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)

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 willreduce runtime to 
nearly zero (at least that 's what experiments show) so ....

what we can do is pass info from the mpenvironment"


\startMPenvironment[global]
    \setupbodyfont[20pt]
\stopMPenvironment

\starttext

\long\def\startstaticMPgraphic#1#2\stopstaticMPgraphic
  {\blabelgroup
   \def\MPgraphicfile{#1}% no \jobname here
   \let\MPwrite\MPstaticwrite
   \immediate\openout\MPwrite=\MPgraphicfile.mp
   \setMPrandomseedfalse
   \enableincludeMPgraphics
   \def\sometxt##1{\string\sometxt{##1}}%
   \the\everyMPgraphic
   \presetMPdefinitions
   \theMPinclusions % brrr
   \writeMPgraphic{\letterpercent mpenvironment: \the\everyMPTEXgraphic}%
   \writeMPgraphic{beginfig(1);}%
   \writeMPgraphic{#2}%
   \writeMPgraphic{endfig; end.}%
   \immediate\closeout\MPwrite
   \immediate\closeout\MPwrite
   \runMPgraphicstrue
   \executeMPgraphicfile
   \elabelgroup}

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

outside sometxt
\usestaticMPfigure[fig]
\stoptext

for this we need to patch tex.rb:

def processmpstatic
        if filename = getvariable('filename') then
            filename += ".mp" unless filename =~ /\..+?$/
            if FileTest.file?(filename) then
                begin
                    data = IO.read(filename)
                    File.open("texexec.tex",'w') do |f|
                        f << "\\setupoutput[pdftex]\n"
                        f << "\\setupcolors[state=start]\n"
                        data.sub!(/^%mpenvironment\:\s*(.*?)$/mois) do
                            f << $1
                            "\n"
                        end
                        f << "\\starttext\n"
                        f << "\\startMPpage\n"
                        f << data.gsub(/end\.*\s*$/m, '') # a bit of a hack
                        f << "\\stopMPpage\n"
                        f << "\\stoptext\n"
                    end
                    report("converting static '#{filename}'")
                    runtex("texexec.tex")
                    pdffile = File.suffixed(filename,'pdf')
                    File.silentrename("texexec.pdf",pdffile)
                    report ("#{filename} converted to #{pdffile}")
                rescue
                    report("error in converting #{filename} (#{$!}")
                end
            end
        end
        reportruntime
    end

but that's about it


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 bodyfontsize in staticMPfigure (2006.09.27 beta)

[Sanjoy Mahajan]

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

Re: \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)

[Hans Hagen]

Sanjoy Mahajan wrote:
> 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.
>   
consider a static graphic to be(have) like an external figure, it's 
basically mp code processes as startMPpage .. stopMPpage

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 bodyfontsize in staticMPfigure (2006.09.27 beta)

[Aditya Mahajan]

On Thu, 28 Sep 2006, 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)
>
> 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 willreduce runtime to
> nearly zero (at least that 's what experiments show) so ....

Even when mp is available as a lib, it will not reduce runtime to 
nearly zero? The time to start a mp process will be negligible, but 
processing an mp file will still take time. In the mp diagrams that I 
have, processing each diagram takes about 10 sec [1]. Occasionally 
there are around 10-15 diagrams and compiling all of them takes about 
2 minutes. With statics, the time for calculating the md5 sum of each 
mp file is negligible, and I can work with diagrams sources and text 
in the same file. Even after mp is available as a library, I will need 
statics.

[1] metaobj is slow. I really hope that sometime in the future, 
metapost gets programming abilities of a real language. Maybe 
asymptote already does this, but it is too latex oriented.

Aditya

Re: \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)

[Sanjoy Mahajan]

> [1] metaobj is slow. I really hope that sometime in the future,
> metapost gets programming abilities of a real language. Maybe
> asymptote already does this, but it is too latex oriented.

And gets native 3d curves, which asymptote also has.  For example, I'd
imagine this being a valid path:

p := (0,0)--(0,1)--(1,0)--(1,1,1)--(0,0);

where the third coordinate is 0 if not specified, so all of metapost's
current drawing would still work, but you could move in or out of the
piece of paper too.  And the default view would be face on but you
could change the viewpoint.

Not sure if asymptote has that kind of syntax, but it does do tension
and curl and splines a la metapost but generalized to 3d paths.  I
tried to convert asymptote away from its latex origins, and
surprisingly I found that latex isn't the main obstacle, and I'd
configured most of the latex strings away.  The main issue is that
asymptote uses PStricks to do lots of the figure transformations.  For
example, the rotation in the figure below is handled by metapost with
a postscript rotation operator:

 beginfig(1)
 draw thelabel(btex hello etex, origin) rotated 70;
 endfig;

In asymptote, if I remember right, the hello box is created and then
pstricks macros are used to rotate it.  But that approach means
incorporating the pstricks postscript headers, and makes it
complicated to do on-the-fly parsing of the postscript output and to
convert it to pdf (what the internal mptopdf can and does do in
ConTeXt for metapost's easy postscript).

In thinking about this more, I guess I like metapost's declarative
syntax (asymptote is purely procedural) including for constructing
paths.  I wish it had paths (composed of maybe disjoint subpaths) and
subpaths (what metapost calls paths now) a la postscript.  I wish it
had 3d.  Featpost is not bad but is a layer built on top of metapost,
not so well integrated.  I wish metapost had real mathematical
functions, not the sarith.mp hack for large numbers.  Asymptote for
example has bessel functions handy (the authors can easily and do add
functions from the GNU math library).

Oh and modern color model (and shading) would be good.  Then Hans
wouldn't have to do magic to get transparency or cmyk.

-Sanjoy

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

Re: \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)

[Taco Hoekwater]

Sanjoy Mahajan wrote:
>>[1] metaobj is slow. I really hope that sometime in the future,
>>metapost gets programming abilities of a real language. Maybe
>>asymptote already does this, but it is too latex oriented.

In metapost, things can depend on eachother using equations. Metaobj
makes heavy use of that, and I very much doubt asymptote can do
the same. It is slow because knuth never expected having hunderds
of equations partially solved at the same time, but it may be possible
to fix that. If so, metaobj runtimes may drop as much as 95%
(at the expense of a fair bit of extra memory consumption and
a small speed penalty for everything else, of course, because
that is how these things work).

> And gets native 3d curves, which asymptote also has.  For example, I'd
> imagine this being a valid path:
> 
> p := (0,0)--(0,1)--(1,0)--(1,1,1)--(0,0);
> 
> where the third coordinate is 0 if not specified, so all of metapost's
> current drawing would still work, but you could move in or out of the
> piece of paper too.  And the default view would be face on but you
> could change the viewpoint.

There is lots and lots of work involved with even basic 3d support.
Metapost will probably never support this sort of thing unless we get
some extra people to help programming it. Asymtote may be the better
option.

> In thinking about this more, I guess I like metapost's declarative
> syntax (asymptote is purely procedural) including for constructing
> paths.  I wish it had paths (composed of maybe disjoint subpaths) and
> subpaths (what metapost calls paths now) a la postscript.  

If you come up with a low-level syntax and algorithmic description,
that may actually happen.

> I wish it
> had 3d.  Featpost is not bad but is a layer built on top of metapost,
> not so well integrated.  I wish metapost had real mathematical
> functions, not the sarith.mp hack for large numbers.  Asymptote for

The spring 2007 version will have 64bit calculus. Not a complete
solution, but much better, and the extra precision will help interfacing
with existing math libraries like GNU math.

> Oh and modern color model (and shading) would be good.  Then Hans
> wouldn't have to do magic to get transparency or cmyk.

The autumn (TL2006) version will have greyscale and cmyk. No system
that exports solely level 1 or 2 postscript can do the kind of
transparency Hans uses, so I won't even try. Maybe later, when
(and if) metapost is no longer tied to ps output.

Cheers, Taco

Re: \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)

[Hans Hagen]

Aditya Mahajan wrote:
> On Thu, 28 Sep 2006, 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)
>>
>> 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 willreduce runtime to
>> nearly zero (at least that 's what experiments show) so ....
>>     
>
> Even when mp is available as a lib, it will not reduce runtime to 
> nearly zero? The time to start a mp process will be negligible, but 
> processing an mp file will still take time. In the mp diagrams that I 
> have, processing each diagram takes about 10 sec [1]. Occasionally 
>   
you mean that mp needs 10 sec per graphic? impressive
> there are around 10-15 diagrams and compiling all of them takes about 
> 2 minutes. With statics, the time for calculating the md5 sum of each 
> mp file is negligible, and I can work with diagrams sources and text 
> in the same file. Even after mp is available as a library, I will need 
> statics

> .
>
> [1] metaobj is slow. I really hope that sometime in the future, 
> metapost gets programming abilities of a real language. Maybe 
> asymptote already does this, but it is too latex oriented.
>   

try to find funding for taco to do luapost -)

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 bodyfontsize in staticMPfigure (2006.09.27 beta)

[Aditya Mahajan]

On Thu, 5 Oct 2006, Hans Hagen wrote:

> Aditya Mahajan wrote:
>> On Thu, 28 Sep 2006, Hans Hagen wrote:
>>
>>> 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 willreduce runtime to
>>> nearly zero (at least that 's what experiments show) so ....
>>>
>> Even when mp is available as a lib, it will not reduce runtime to
>> nearly zero? The time to start a mp process will be negligible, but
>> processing an mp file will still take time. In the mp diagrams that I
>> have, processing each diagram takes about 10 sec [1]. Occasionally
>>
> you mean that mp needs 10 sec per graphic? impressive

It is not just mp. It was a combination of mp ... textext ... metaobj 
... conversion to pdf. Doing some tests right now, I see that the main 
culprit was btex ... etex. Replacing all btex ... etex with \sometxt 
makes things really fast (~15 sec for 8 graphics). I just thought that 
metaobj was to blame but it is not. Maybe, I can get around without 
statics :-)

Aditya