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 directly? Hmm, I wonder how metapost does the rotating. Actually, here's a test: beginfig(1) draw thelabel(btex hello etex, origin) rotated 70; endfig; end produces this metapost eps file: %!PS %%BoundingBox: -7 -11 7 11 %%HiResBoundingBox: -6.75279 -10.8051 6.75278 10.80508 %%Creator: MetaPost 0.901 %%CreationDate: 2006.06.29:2102 %%Pages: 1 %*Font: cmr10 9.96265 9.96265 65:912 %%BeginProlog %%EndProlog %%Page: 1 1 gsave [0.34203 0.9397 -0.9397 0.34203 -0.2515 -10.8051 ] concat 0 0 moveto (hello) cmr10 9.96265 fshow grestore showpage %%EOF 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? -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.