On Sat, Dec 6, 2008 at 10:25 PM, Mojca Miklavec
On Fri, Dec 5, 2008 at 1:29 PM, Yue Wang wrote:
Mojca:
Hello Yue Wang,
Thanks a lot for your reports.
I think you forgot to put the windows version of dvipdfmx.dll in the minimals tree.
Mea culpa! I fixed that. I didn't notice that one needs dll and nobody has complained so far.
Well, I use an old release of context (august) and it seems to have it. but after upgrade to the latest version, something broken here.
Out of curiosity: how do you use it? Does ConTeXt work OK with it at all? That binary is on the shortlist of being put to a special section that one would need to install as a separate module (option in mtx-update.lua for example), so I would like to know how/when it is still used. Also: that binary is badly supported in tikz for ConTeXt for example. So it is nice to know how much one needs to invest in trying to keep compatibility with those engines.
Well, I should say it works in some cases: especially for documents with no hyperlinks and metapost graphics (and no hz features enabled too). And it is fun to use it for CID font embedding (it is the most popular tex driver in Asia since it have good support for CJK font. in fact luatex also use dvipdfmx code for CID font embedding). However, hyperlinks are always point to the wrong place, and MPGraphics are usually in the wrong place too. I send a bug report to Hans, but it seems not fixed yet. (Also, focus=standard is not fixed yet. it is still higher or lower than the content it points to). These are not dvipdfmx specific problems. XeTeX->xdvipdfmx has those problems too. When I use teTeX 3.0 (context version 2005.1.30 pdfetex 1.21), many dvi specific features work well. One important reason is that ConTeXt use dvi as default output at that time. So when there is a bug, it will be easy to get report from users. However, pdf became the default output in the late 2005, and after four years of development, dvi features support are somewhat buggy now. BTW, the latest dvipdfmx driver supports metafun, as announced on the official web page of dvipdfmx.
## afm2pl.exe afm2tfm.exe ttf2afm.exe ## bibtex.exe ## dvipdfmx.exe dvips.exe ## Knuthian pltotf.exe tftopl.exe vftovp.exe vptovf.exe
also: mp help tools like mpto and dvitomp are not needed anymore. you can safely remove them.
I removed makempx.exe, and mpto.exe. I did that for unix flavours last time, but forgot about windows. Now about dvitomp.exe. Last time when I tried removing dvitomp it failed, but I forgot to ask Taco at what place one should fix it. See the conversation below.
I'm just wondering: should these binaries go out of W32TeX as well? Taco? Does "are no longer distributed" mean: "sorry, we don't care about trying to compile and distribute them ourselves" or rather "no reason why one would distribute them/one should not distribute them"?
The one but big user-visible change is that the btex ... etex label conversion is now handled internally instead of via the external "mpware" programs. These programs are therefore no longer distributed.
With a minimal example
\starttext \startMPcode draw btex xYz etex; \stopMPcode \stoptext
I still get
This is MetaPost, version 1.110 (kpathsea version 3.5.7) (./xpost-mpgraph.mp
xpost-mpgraph.mp xpost-mpgraph.mpx ! Unable to make mpx file. l.147 draw btex xYz etex
It does, but only if MAKEMPX is not set (which it probably is).
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________