[NTG-context] ConTeXt + asymptote
sanjoy at mrao.cam.ac.uk
Fri Jun 30 03:12:40 CEST 2006
> In regard to the remark I saw posted about "monster eps" files
That was from me. The size was one issue and probably, as you say,
disappears in the size of the final pdf file (I didn't test it
extensively but I think that happened).
However, a related issue to the size is that ConTeXt parses the
metapost output inline, doable since metapost puts out such a
restricted subset of postscript. So it is easy (at least for tex
wizards!) to integrate metapost with ConTeXt (i.e. for inline metapost
code, like the asymptote environment in latex). The asymptote eps
files, because of including fonts and using pstricks, are full
postscript and would be harder to parse.
> We will need to replace pstricks (which is used only for rotating text)
> There is a rotate.tex package in dvips but it would have to be
> modified to typeset at arbitrary angles...
Won't pstricks eventually have to go when asymptote produces pdf
Hmm, I wonder how metapost does the rotating. Actually, here's a
draw thelabel(btex hello etex, origin) rotated 70;
produces this metapost eps file:
%%BoundingBox: -7 -11 7 11
%%HiResBoundingBox: -6.75279 -10.8051 6.75278 10.80508
%%Creator: MetaPost 0.901
%*Font: cmr10 9.96265 9.96265 65:912
%%Page: 1 1
gsave [0.34203 0.9397 -0.9397 0.34203 -0.2515 -10.8051 ] concat 0 0
(hello) cmr10 9.96265 fshow grestore
So it uses raw postscript to make an affine coordinate transform and
avoids using an external tex/latex package. The resulting postscript
is nice for parsing.
> We could use epsf to include PostScript figures or else the miniltx
> package. I see from some posts that some ConTeXt users are thinking
> of using \epsfbox instead of \includegraphics. Any preferences here?
That also was me. I have almost no experience of LaTeX and have
always used \epsfbox from plain TeX days. But that may just be a bad
habit or a preference for the simplicity of \epsfbox.
> Another issue I would be happy to discuss sometime is the need for
> implicit equation solving.
I don't know if I can make a good case for it. But the
declarative/implicit style matches how I think about drawing technical
figures (perhaps because the feature exists!): specify a bunch of
constraints and let the computer figure it out. But it's probably a
lot of work to implement, not least because it would require a new
operator. Maybe ?= for implicit equals and = for regular equals?
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
More information about the ntg-context