bug in minimals: dvipdfmx.dll not found
Mojca: I think you forgot to put the windows version of dvipdfmx.dll in the minimals tree. also: mp help tools like mpto and dvitomp are not needed anymore. you can safely remove them. Yue Wang
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. 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. ## 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
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 ___________________________________________________________________________________
On Sat, Dec 6, 2008 at 6:52 PM, Yue Wang wrote:
On Sat, Dec 6, 2008 at 10:25 PM, Mojca Miklavec
wrote: 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.
Interesting. (No piece of code in the minimals did change in that respect, at least none that I would know of.) Maybe the old dvipdfmx.exe did not require the dll file to be present?
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.
Does XeTeX also place MP graphics to the wrong place? (I still use mostly pdfTeX for documents that do not require any programming or foreign fonts, so I did not notice weird behaviour yet.)
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.
That's why I wonder if dvi-based workflows work at all. I've seen some issues and none of theme were likely to be fixed. How different is it when you work with dvipdfmx compared to xetex or luatex?
BTW, the latest dvipdfmx driver supports metafun, as announced on the official web page of dvipdfmx.
That's nice :) Mojca
Hi,
Interesting. (No piece of code in the minimals did change in that respect, at least none that I would know of.) Maybe the old dvipdfmx.exe did not require the dll file to be present?
well, maybe.... and maybe I am wrong.
Does XeTeX also place MP graphics to the wrong place? (I still use mostly pdfTeX for documents that do not require any programming or foreign fonts, so I did not notice weird behaviour yet.)
yes, and it also point hyperlinks to the wrong place too. (see the latest latex/context war on this mailing list)
That's why I wonder if dvi-based workflows work at all. I've seen some issues and none of theme were likely to be fixed.
How different is it when you work with dvipdfmx compared to xetex or luatex?
well, the experience of using dvipdfmx \approx the experience of using xetex. but pdftex-> dvipdfmx is much faster and consumes much less space. and since luatex and xetex can hardly be used for production (because mkiv/luatex changes all the time, and context does not support xetex very well.), so I use pdftex (usually for English documents) or etex->dvipdfmx (usually for Chinese documents) for our journal. [Our compile server stay at the 2005.01.30 version and does not upgrade any more to ensure the document will always produce the same result during the years.] But usually I will use luatex for personal purpose like composing my essays. but I still use pdftex or etex-> dvipdfmx to prepare the draft documents before the final luatex compilation since they are quite fast (inasmuch as my old computer [Core 2 Duo T5050, 1G Mem] cannot suffice for such huge mem/cpu usage footprint). On the final compilation, I only adjust the layout and fonts. So LuaTeX is nice and can produce much better results at the cost of memory and speed ^_^ (and sometimes mkiv will run into problems and does not work as expected, so I have no choice but to downgrade the minimals)
BTW, the latest dvipdfmx driver supports metafun, as announced on the official web page of dvipdfmx.
That's nice :)
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 ___________________________________________________________________________________
Yue Wang
Mojca Miklavec wrote:
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.
Mark II installs "texexec --mptex" as MPXCOMMAND, and that needs dvitomp. makempx and mpto can go. Best wishes, Taco
participants (3)
-
Mojca Miklavec
-
Taco Hoekwater
-
Yue Wang