Re: [NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
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 ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
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 - ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
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 ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
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 ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
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
-
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
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
-
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
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
[NTG-context] \sometxt bodyfontsize in staticMPfigure (2006.09.27 beta)
[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
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
