In regard to adding support for ConTeXt or plain TeX to Asymptote, it should be no problem to do this, but perhaps someone on this list can help provide some preliminary information, particularly regarding item 1 below on how best to rotate text at an arbitrary angle. Also, since I am not sure what the precise planned use of a plain tex/ConTeXt engine here is, it isn't clear to me whether the miniltx solution below would be an acceptable solution. Perhaps someone can also explain why so many context users are interested in this feature? Why exactly can't they let Asymptote do its typesetting with latex behind the scenes and then import the resulting ps or pdf files in context? Is the issue just that latex might not be installed? If so, the miniltx style file (which appears to be part of plain tex) seems like a viable and simple solution. In regard to the remark I saw posted about "monster eps" files, use the -aZ option and you will see that Asymptote output files are as compact as those of MetaPost. If you want tex labels, you have to process MetaPost output through dvips, etc. Asymptote simply does this automatically, perhaps giving some users the illusion that Asymptote files are bigger. In other words, you should compare the final postscript files that MetaPost produces, not the intermediate ones (I recall that there is a MetaPost command for running MetaPost output through dvips too). Another issue I would be happy to discuss sometime is the need for implicit equation solving. We could add it, given an appropriate syntax, but the majority of uses I have seen for it are covered by the extension function in math.asy. I find the latter more explicit and less confusing to new users. But we could be persuaded to add something similar if someone can justify the need. Asymptote already includes an explicit linear solver that uses LU decomposition. Anyway here are the two features we would need from a plain tex/ConTeXt engine: 1. We will need to replace pstricks (which is used only for rotating text) with PostScript or PDF \special commands. There is a rotate.tex package in dvips but it would have to be modified to typeset at arbitrary angles... 2. 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? Alternatively, here is the miniltx solution, which would be trivial to provide support for in an upcoming release of Asymptote: Here's an example: asy -k venn Edit venn_.tex to look like this (then tex+dvips): \input miniltx \input graphicx \input pstricks \newbox\ASYbox \newdimen\ASYdimen \def\ASYbase#1#2{\setbox\ASYbox=\hbox{#1}\ASYdimen=\ht\ASYbox% \setbox\ASYbox=\hbox{#2}\lower\ASYdimen\box\ASYbox} \def\ASYalign(#1,#2)(#3,#4)#5#6{% \setbox\ASYbox=\hbox{#6}% \rput[lB]{#5}(#1,#2){\ASYdimen=\ht\ASYbox% \advance\ASYdimen by\dp\ASYbox\kern#3\wd\ASYbox\raise#4\ASYdimen\box\ASYbox}} \def\ASYscale(#1,#2)(#3,#4)(#5,#6)#7#8{% \ASYalign(#1,#2)(#3,#4){#7}{\scalebox{#5}[#6]{#8}}}% \psset{unit=1pt} \includegraphics[bb=228.608356 320.125000 382.391644 470.875000]{venn_0.eps}% \ASYalign(-104.955775,75.657656)(-0.500000,-0.500000){0.000000}{$A$} \ASYalign(-49.404200,75.657656)(-0.500000,-0.500000){0.000000}{$B$} \ASYalign(-77.179988,134.822731)(-0.500000,0.000000){0.000000}{$A\cap B$} \ASYalign(-77.179988,16.492581)(-0.500000,-1.000000){0.000000}{$A\cup B$} \bye -- John Bowman Department of Mathematical and Statistical Sciences University of Alberta
John Bowman wrote:
In regard to adding support for ConTeXt or plain TeX to Asymptote, it should be no problem to do this, but perhaps someone on this list can help provide some preliminary information, particularly regarding item 1 below on how best to rotate text at an arbitrary angle. Also, since I am not sure what the precise planned use of a plain tex/ConTeXt engine here is, it isn't clear to me whether the miniltx solution below would be an acceptable solution.
i cannot answer for other users but i guess that they want a more integrated approach, i.e. include a code in the doc source, write style info at runtime, etc latex and context differ too much from what users wrote to this list, i understood that much tex related stuff in asymptote is hard coded, so it's probably enough when all the strings (in the c source) that now contain latex code can be configured; there is no need for you to look into context, when things can be configured, the users will do that for you
Perhaps someone can also explain why so many context users are interested in this feature? Why exactly can't they let Asymptote do its typesetting with latex behind the scenes and then import the resulting ps or pdf files in context? Is the issue just that latex might not be installed? If so, the
indeed, esp when they use the so called minimal distributions;
miniltx style file (which appears to be part of plain tex) seems like a viable and simple solution.
In regard to the remark I saw posted about "monster eps" files, use the -aZ option and you will see that Asymptote output files are as compact as those of MetaPost. If you want tex labels, you have to process MetaPost output through dvips, etc. Asymptote simply does this automatically, perhaps giving some users the illusion that Asymptote files are bigger. In other words, you should compare the final postscript files that MetaPost produces, not the intermediate ones (I recall that there is a MetaPost command for running MetaPost output through dvips too).
in context dvips is not used for mp graphics; context comes with an integrated mp output parser; this means that integration is also efficient (handy when you have a couple of hundred mp graphics) esp with regards to resources i suppose that others can comment on the rest of your mail 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 -----------------------------------------------------------------
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.
Sanjoy Mahajan wrote:
Won't pstricks eventually have to go when asymptote produces pdf directly?
why is pstricks needed anyway, i suppose that asymptote does the graphics
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
indeed, rotation is part of the graphic system
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.
in context we have our own inclusion macros; they also manage resources and such (please cc to bowman@math.ualberta.ca) Hans
participants (3)
-
Hans Hagen -
John Bowman -
Sanjoy Mahajan