[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
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 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
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
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
[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.
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
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 -----------------------------------------------------------------
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
-
Aditya Mahajan -
Hans Hagen -
Sanjoy Mahajan -
Taco Hoekwater