なんだかかなり前からですが，TeX Wiki で dvipdfmx を排除しようとしている方がいます．
https://texwiki.texjp.org/?dvipdfmx
https://texwiki.texjp.org/?PDF%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9
バックアップなどご覧下さい（編集されるとリンク先が変わりそうなので張れない）．
現実に dvipdfmx を使ってはいけない具体的な理由はあるのでしょうか．
日常利用のレベルで，もしくは印刷所のレベルでなど，何かご存知の方はお教えいただけると参考になります．
それから，dvipdfmx がだめならば xelatex もだめなんじゃないか（xdvipdfmx を使うから）と思うのですが，
どうなんでしょうか．
> 排除しようとしている方がいます．
前田さんのご発言がどの辺りに由来するのかなと思ってバックアップを見てみました。
**敢えて**「PDF の作り方」のバックアップの該当しそうな箇所 115 (2015-12-12 (土) 23:25:33)
を貼ります（これは現在は削除済みです）：
===== 以下引用 =====
//現在，日本ではdvipdfmxを用いたPDF生成が主流となっておりますが，
//完全なガラパゴスです．dvipdfmx に対しては，様々な方々から苦言が出ています：
//emathの作者として有名なtDB氏の発言，
//-[[dvipdfm(x)にはご注意を:http://hpcgi3.nifty.com/emath/treebbs.cgi?kako=1&//log=5586]]
//>特に
//> 教室で使用するプリントで emath をお使いの方は信用の失墜に
//> 商用で emath をお使いの方は経済的損失に
//> つながりかねませんからご注意ください。
//
//-[[emathPs と PDF形式:http://hpcgi3.nifty.com/emath/treebbs.cgi?kako=1&all=8805&s=8840]]
//># それにしても，
//># つかえねぇ～ dvipdfmx にこれほどまで振り回されるとは
//># くたばれ dvipdfmx と毒づきたくもなるというものです。
//
//TeX ユーザの集い 2015 実行委員会代表，きえだゆうすけ氏の発言，
//-[[いかなる意味の印刷もしないのならば:https://twitter.com/p_typo/status/624638576509059072]]
//>いかなる意味の印刷もしないのならばdvipdfmxの利用は考えてもいいかもしれない
//
//様々な有用なパッケージの作者であるZR氏もこう言っています，
//-[[まあ、何せ、dvipdfmxは:https://mobile.twitter.com/zr_tex8r/status/643221404301701121]]
//>まあ、何せ、dvipdfmxはアレなので……。
//
//Adobe Acrobat DC を使うか，LuaTeX への移行を勧めます．
===== 引用終わり =====
これがいちばん顕著に根拠のよくわからない排除傾向だと私は理解しました。
こういう断片的な収集は相手にしなくてよいのかなと思います。
そのうえで：dvipdfmx があまり好かれていないという話は私も聞いたことがあって、でも私は
印刷業界の人ではないのでよくわかっていません。詳しい方のご意見があれば、この機会に
ここで発言いただけると勉強になります。もしかすると dvipdfmx 本体や dvipdfmx.cfg の
設定次第でよくなるかもしれませんし、どういうときに使うべきでないかなど知見が集まる
ことはよいことだと思います。よろしくお願いします。
前田さんのご発言がどの辺りに由来するのかなと思ってバックアップを見てみました。
**敢えて**「PDF の作り方」のバックアップの該当しそうな箇所 115 (2015-12-12 (土) 23:25:33)
を貼ります（これは現在は削除済みです）：
===== 以下引用 =====
//現在，日本ではdvipdfmxを用いたPDF生成が主流となっておりますが，
//完全なガラパゴスです．dvipdfmx に対しては，様々な方々から苦言が出ています：
//emathの作者として有名なtDB氏の発言，
//-[[dvipdfm(x)にはご注意を:http://hpcgi3.nifty.com/emath/treebbs.cgi?kako=1&//log=5586]]
//>特に
//> 教室で使用するプリントで emath をお使いの方は信用の失墜に
//> 商用で emath をお使いの方は経済的損失に
//> つながりかねませんからご注意ください。
//
//-[[emathPs と PDF形式:http://hpcgi3.nifty.com/emath/treebbs.cgi?kako=1&all=8805&s=8840]]
//># それにしても，
//># つかえねぇ～ dvipdfmx にこれほどまで振り回されるとは
//># くたばれ dvipdfmx と毒づきたくもなるというものです。
//
//TeX ユーザの集い 2015 実行委員会代表，きえだゆうすけ氏の発言，
//-[[いかなる意味の印刷もしないのならば:https://twitter.com/p_typo/status/624638576509059072]]
//>いかなる意味の印刷もしないのならばdvipdfmxの利用は考えてもいいかもしれない
//
//様々な有用なパッケージの作者であるZR氏もこう言っています，
//-[[まあ、何せ、dvipdfmxは:https://mobile.twitter.com/zr_tex8r/status/643221404301701121]]
//>まあ、何せ、dvipdfmxはアレなので……。
//
//Adobe Acrobat DC を使うか，LuaTeX への移行を勧めます．
===== 引用終わり =====
これがいちばん顕著に根拠のよくわからない排除傾向だと私は理解しました。
こういう断片的な収集は相手にしなくてよいのかなと思います。
そのうえで：dvipdfmx があまり好かれていないという話は私も聞いたことがあって、でも私は
印刷業界の人ではないのでよくわかっていません。詳しい方のご意見があれば、この機会に
ここで発言いただけると勉強になります。もしかすると dvipdfmx 本体や dvipdfmx.cfg の
設定次第でよくなるかもしれませんし、どういうときに使うべきでないかなど知見が集まる
ことはよいことだと思います。よろしくお願いします。
不具合があるからと言って排除するのではなく、バグならバグと報告して、改善する方向で話をして欲しいですね。
【1点目】次の記事でZRさんが伝えて下さった古いバグは解決したのでしょうか？
https://okumuralab.org/tex/mod/forum/discuss.php?d=1026&parent=6546
graphics パッケージをはじめ各種ドライバで回避措置が必要になり、ドライバを書く人には嫌われそうです。
【2点目】これは graphics パッケージ用の dvipdfmx.def の話ですが、
tikz-3dplot の \tdplotsphericalsurfaceplot で surfaceplot をしようとすると色がおかしくなります。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% サンプル
\documentclass[dvipdfmx]{minimal}
\usepackage{tikz,tikz-3dplot}
\begin{document}
\tdplotsetmaincoords{70}{135}
\begin{tikzpicture}[line join=round, tdplot_main_coords,scale=5, fill opacity=.7]
\tdplotsphericalsurfaceplot[parametricfill]{12}{12}{1}{black}{\tdplotphi}%
{\draw[color=black,thick,->] (0,0,0) -- (2,0,0) node[left] {$x$};}%
{\draw[color=black,thick,->] (0,0,0) -- (0,2,0) node[right]{$y$};}%
{\draw[color=black,thick,->] (0,0,0) -- (0,0,2) node[above]{$z$};}%
\end{tikzpicture}
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
dvipdfmx からは次の warning が出力されます。
dvipdfmx:warning: Unrecognized color name: hsb, keep the current color
dvipdfmx.def には hsb も定義されているようなのですが認識されていません。
これについては、color まわりのコードを xetex.def のものに差し替えれば、正常化します。
【1点目】次の記事でZRさんが伝えて下さった古いバグは解決したのでしょうか？
https://okumuralab.org/tex/mod/forum/discuss.php?d=1026&parent=6546
graphics パッケージをはじめ各種ドライバで回避措置が必要になり、ドライバを書く人には嫌われそうです。
【2点目】これは graphics パッケージ用の dvipdfmx.def の話ですが、
tikz-3dplot の \tdplotsphericalsurfaceplot で surfaceplot をしようとすると色がおかしくなります。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% サンプル
\documentclass[dvipdfmx]{minimal}
\usepackage{tikz,tikz-3dplot}
\begin{document}
\tdplotsetmaincoords{70}{135}
\begin{tikzpicture}[line join=round, tdplot_main_coords,scale=5, fill opacity=.7]
\tdplotsphericalsurfaceplot[parametricfill]{12}{12}{1}{black}{\tdplotphi}%
{\draw[color=black,thick,->] (0,0,0) -- (2,0,0) node[left] {$x$};}%
{\draw[color=black,thick,->] (0,0,0) -- (0,2,0) node[right]{$y$};}%
{\draw[color=black,thick,->] (0,0,0) -- (0,0,2) node[above]{$z$};}%
\end{tikzpicture}
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
dvipdfmx からは次の warning が出力されます。
dvipdfmx:warning: Unrecognized color name: hsb, keep the current color
dvipdfmx.def には hsb も定義されているようなのですが認識されていません。
これについては、color まわりのコードを xetex.def のものに差し替えれば、正常化します。
dvipdfmx での TikZ の patterns ライブラリサポートの不具合というのもありました。ご報告まで。
きちんと検証したわけではありませんが，「dvipdfmx で graphicx 系の命令と TikZ 系の命令を同時に使うと時々図が変な位置に飛んでしまう現象」については，TeX Live 2014 の時点で解決されたように感じています。
trimclip.sty での不具合も解消しているようなのですが、pdf:btrans スペシャルの挙動は変わっていないようです。
#82 (x)dvipdfmx problem: btrans inside bcontent incorrect
で指摘されているのは次のコードで2が変な位置に飛んでしまうというものです。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{minimal}
\begin{document}
(
\special{pdf:bcontent}
1
\special{pdf:btrans scale 2}
2
\special{pdf:etrans}
3
\special{pdf:econtent}
)
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
これは TeXLive2016 でも変な位置に飛びます。もはやこれは仕様として受け入れてTeX側で対処する事になったのかも知れませんね。
#82 (x)dvipdfmx problem: btrans inside bcontent incorrect
で指摘されているのは次のコードで2が変な位置に飛んでしまうというものです。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{minimal}
\begin{document}
(
\special{pdf:bcontent}
1
\special{pdf:btrans scale 2}
2
\special{pdf:etrans}
3
\special{pdf:econtent}
)
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
これは TeXLive2016 でも変な位置に飛びます。もはやこれは仕様として受け入れてTeX側で対処する事になったのかも知れませんね。
すみません，意図がわかりづらくなっていました．
「TeX Wiki で dvipdfmx を排除しようとしている」というのは，
「PDFの作り方」の 2015-10-24 (土) 04:23:50 の差分
https://texwiki.texjp.org/?cmd=backup&action=diff&page=PDF%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9&age=98
あたりからの流れのことを指しています．
PukiWiki はバックアップが120を超えると削除していくようで番号がずれるので，
上のリンクはそのうち意味をなさなくなると思います．
後日ご覧になった方は日付で探してください．
今朝も dvipdfmx に関する記述を削除する編集が入っていたので，
そこまでしなければならない具体的な根拠が何かあるのかと思って書きました．
「TeX Wiki で dvipdfmx を排除しようとしている」というのは，
「PDFの作り方」の 2015-10-24 (土) 04:23:50 の差分
https://texwiki.texjp.org/?cmd=backup&action=diff&page=PDF%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9&age=98
あたりからの流れのことを指しています．
PukiWiki はバックアップが120を超えると削除していくようで番号がずれるので，
上のリンクはそのうち意味をなさなくなると思います．
後日ご覧になった方は日付で探してください．
今朝も dvipdfmx に関する記述を削除する編集が入っていたので，
そこまでしなければならない具体的な根拠が何かあるのかと思って書きました．
いろいろ twitter で拾っていますが、ひとつはっきりさせたいので：
「dvipdfmx を排除」したところで、代わりに“その人”は何を推奨したいのでしょう？
考えられるのは
・dvips + distiller（ただし有償）
・pdfTeX
・LuaTeX
でしょうか。で、2016年 06月 21日(火曜日) 11:22 の私の投稿で引用した部分に
> Adobe Acrobat DC を使うか，LuaTeX への移行を勧めます．
とありますが、フリーソフトに限ってしまえば実質「日本語なら LuaTeX」なわけですよね。
（Acrobat (Distiller) はそもそも Linux オンリーだとダメだし。）
でも、（仮に dvipdfmx に問題があると仮定して、）dvipdfmx でなく LuaTeX にしたらほんとうに
解決する問題なのでしょうか。“その人”が根拠としている方々の発言の文脈をみるに、LuaTeX 推奨は
片鱗も見えないので、何がしたいのかさっぱりわかりません。（まあ理解したくもないけど…）
「dvipdfmx を排除」したところで、代わりに“その人”は何を推奨したいのでしょう？
考えられるのは
・dvips + distiller（ただし有償）
・pdfTeX
・LuaTeX
でしょうか。で、2016年 06月 21日(火曜日) 11:22 の私の投稿で引用した部分に
> Adobe Acrobat DC を使うか，LuaTeX への移行を勧めます．
とありますが、フリーソフトに限ってしまえば実質「日本語なら LuaTeX」なわけですよね。
（Acrobat (Distiller) はそもそも Linux オンリーだとダメだし。）
でも、（仮に dvipdfmx に問題があると仮定して、）dvipdfmx でなく LuaTeX にしたらほんとうに
解決する問題なのでしょうか。“その人”が根拠としている方々の発言の文脈をみるに、LuaTeX 推奨は
片鱗も見えないので、何がしたいのかさっぱりわかりません。（まあ理解したくもないけど…）
twitter で拾った意見でいったん中間報告(?)
# 私が拾える範囲内という時点でかなりバイアスがかかっていることは確か
# ですし、それを中立に集約できるはずもないので私の印象にすぎませんが：
昔（10年くらい前？）は dvipdfmx 出力で「画面で正常なのに印刷すると文字化け、ズレ、変色」
というトラブルがあった。こういうのはよく分からないので二度と使いたくないと思った。
dvips + distiller が古くからノウハウ蓄積していて、当時はそれが主流だった。
でも最近は dvipdfmx で作った PDF を Acrobat のプリフライトか何かでゴニョゴニョして
しまえば大体解決する。そして印刷所でのトラブルも少なくなった。
といった感じなんでしょうかね。お金が絡むので表に出せないのでしょうけど、いろいろ
苦労なさっているということだけは確かなんですかね？
TeX 使ってるみなさん、そんなに印刷所に PDF 入稿されているのかと驚きです。
「distiller を使えば解決」とかそんな単純な問題でもないのだと思いました。たぶん distiller を
使うときも設定をゴニョゴニョしないといけないのでしょうし、それを書かずに「distiller 推奨」
とだけ書く風潮もいかがなものかと思います。
# 私が拾える範囲内という時点でかなりバイアスがかかっていることは確か
# ですし、それを中立に集約できるはずもないので私の印象にすぎませんが：
昔（10年くらい前？）は dvipdfmx 出力で「画面で正常なのに印刷すると文字化け、ズレ、変色」
というトラブルがあった。こういうのはよく分からないので二度と使いたくないと思った。
dvips + distiller が古くからノウハウ蓄積していて、当時はそれが主流だった。
でも最近は dvipdfmx で作った PDF を Acrobat のプリフライトか何かでゴニョゴニョして
しまえば大体解決する。そして印刷所でのトラブルも少なくなった。
といった感じなんでしょうかね。お金が絡むので表に出せないのでしょうけど、いろいろ
苦労なさっているということだけは確かなんですかね？
TeX 使ってるみなさん、そんなに印刷所に PDF 入稿されているのかと驚きです。
「distiller を使えば解決」とかそんな単純な問題でもないのだと思いました。たぶん distiller を
使うときも設定をゴニョゴニョしないといけないのでしょうし、それを書かずに「distiller 推奨」
とだけ書く風潮もいかがなものかと思います。
Twitter ばかりに書かれるので情報が散り散りになっちゃってる感じはありますが，
皆さまありがとうございました．
「PDFの作り方」のページを改めて見直してみたのですが，
「PDF の上手な作り方を解説します．」としながら Chrome は HTML を
気軽に PDF に変換できるとか，OS X は標準で印刷から PDF 保存ができる
とか書いてあったりして，その一方で dvipdfmx だけはだめとしようと
しているのは，やっぱりなんだかよくわからない主張ですね．
あまり悪い例を出すのはよくないかもですが，プロプライエタリだから（もしくは開発チームの
規模が大きいから）信頼できるということは全くないのではないかと．
http://www.screen.co.jp/ga_dtp/dtp/guideline16/20150724_pdfmaker_quartz.html
Twitter を見ながら考えた，私の dvipdfmx についての雑感：
・個人レベル（自分のプリンタで印刷）だと国内ではよく使われていて，
問題が出ることはあってもそんなに多くはないのではないか．
どこまでが問題と考えるか，というのもあるかもしれないけれども．
・論文や商用書籍の出版でも，ほぼ間違いなく業者の手が入る
（著者原稿そのままのケースはあまりなさそうな）こともあって，
dvipdfmx が原因での問題は出ないケースが多い？
・博論データを印刷所に持ち込むことはよくあると思うが，
これも問題は出ていない？ 出ててもいちいち報告はないかも．
英文なら pdflatex を使うか．
・身近で一番問題が起きやすそうなのは学会予稿集だと思う．
色々なバージョンの dvipdfmx の出力を統合するので，色々起きやすいのでは．
6, 7年ぐらい前にある学会の予稿集で数式の文字が抜けているのを
見たことがある．「フォントを埋め込んでいないせい」と誰かから聞いたけれども，
本当にそれが原因だったのかどうかは知らない．
全てのフォントを埋め込むように周知されてからはトラブルはないようだ．
（というか，電子化で PDF をそのまま配布するようになって，紙版は出なくなったような．）
いずれにせよ，未だに問題があるならば（出せる範囲でよいので）バグ報告せよということになりますかね．
皆さまありがとうございました．
「PDFの作り方」のページを改めて見直してみたのですが，
「PDF の上手な作り方を解説します．」としながら Chrome は HTML を
気軽に PDF に変換できるとか，OS X は標準で印刷から PDF 保存ができる
とか書いてあったりして，その一方で dvipdfmx だけはだめとしようと
しているのは，やっぱりなんだかよくわからない主張ですね．
あまり悪い例を出すのはよくないかもですが，プロプライエタリだから（もしくは開発チームの
規模が大きいから）信頼できるということは全くないのではないかと．
http://www.screen.co.jp/ga_dtp/dtp/guideline16/20150724_pdfmaker_quartz.html
Twitter を見ながら考えた，私の dvipdfmx についての雑感：
・個人レベル（自分のプリンタで印刷）だと国内ではよく使われていて，
問題が出ることはあってもそんなに多くはないのではないか．
どこまでが問題と考えるか，というのもあるかもしれないけれども．
・論文や商用書籍の出版でも，ほぼ間違いなく業者の手が入る
（著者原稿そのままのケースはあまりなさそうな）こともあって，
dvipdfmx が原因での問題は出ないケースが多い？
・博論データを印刷所に持ち込むことはよくあると思うが，
これも問題は出ていない？ 出ててもいちいち報告はないかも．
英文なら pdflatex を使うか．
・身近で一番問題が起きやすそうなのは学会予稿集だと思う．
色々なバージョンの dvipdfmx の出力を統合するので，色々起きやすいのでは．
6, 7年ぐらい前にある学会の予稿集で数式の文字が抜けているのを
見たことがある．「フォントを埋め込んでいないせい」と誰かから聞いたけれども，
本当にそれが原因だったのかどうかは知らない．
全てのフォントを埋め込むように周知されてからはトラブルはないようだ．
（というか，電子化で PDF をそのまま配布するようになって，紙版は出なくなったような．）
いずれにせよ，未だに問題があるならば（出せる範囲でよいので）バグ報告せよということになりますかね．
数年前から気にはなっていたのですが、縦書きの文書でルビをふったものを
platex + dvipdfmx で PDF を生成し、手元の Mac 上の Acrobat 経由で印刷
すると、ルビがずれる、ということが起きています。
添付ファイル中の test01.tex で作成した test01.pdf を、上述手順で印刷
した紙面を撮影（昼といえあまり時間がないのでスキャンでなくて御勘弁）
したのが test01_printed.jpg です。画面上のキャプチャ test01_displayed.jpg
ではずれているようには見えないんですが、印刷するとこのようにずれて
いるわけです。
juajitlatex + juatex-ja で縦書きでルビをふった文書を上述手順で印刷した
一例を lualatex-case_printed.png に示しますが、こちらはずれません。
まだ原因の切り分けができていませんので、あくまで御参考まで。
一例を lualatex-case_printed.png に示しますが、こちらはずれません。
まだ原因の切り分けができていませんので、あくまで御参考まで。
興味深い事例、ありがとうございます。
CJK パッケージ群の ruby.sty なのですね。
さて：
(1) 手元で zip からとりだした test01.pdf を OS X Lion (10.7.5) の
Acrobat Pro X (10.1.14) で開いて FUJI XEROX プリンタで印刷すると
正常でした。プリンタ依存性とかあるのでしょうか…？
(2) 同じく zip からとりだした test01.tex を手元の TeX Live 2016
(MacTeX-2016) でタイプセットしてみると、ルビの文字が小書きに
ならず、大きな仮名が画面上で表示されました。(test01-aminophen.pdf)
上田さんの test01.pdf も dvipdfmx (20160307) なので同じく 2016
環境のようなのですが…これはどうしてなのでしょうか？
(3) 仮に \usepackage{ruby} でなく \usepackage{pxrubrica} として
みると、どうなるでしょうか？ 私の手元ではこちらは小書きのルビが
画面上で表示されています。
CJK パッケージ群の ruby.sty なのですね。
さて：
(1) 手元で zip からとりだした test01.pdf を OS X Lion (10.7.5) の
Acrobat Pro X (10.1.14) で開いて FUJI XEROX プリンタで印刷すると
正常でした。プリンタ依存性とかあるのでしょうか…？
(2) 同じく zip からとりだした test01.tex を手元の TeX Live 2016
(MacTeX-2016) でタイプセットしてみると、ルビの文字が小書きに
ならず、大きな仮名が画面上で表示されました。(test01-aminophen.pdf)
上田さんの test01.pdf も dvipdfmx (20160307) なので同じく 2016
環境のようなのですが…これはどうしてなのでしょうか？
(3) 仮に \usepackage{ruby} でなく \usepackage{pxrubrica} として
みると、どうなるでしょうか？ 私の手元ではこちらは小書きのルビが
画面上で表示されています。
>(1)
私はプリンタの互換性より Acrobat の方を少し疑っています。手元の Mac
に入っている Acrobat は CS 3 収録のものなので。OS は Yosemite ですが……
ちなみにプリンタに関しては、現在使用している LED プリンタの前に使用
していたインクジェットのプリンタでも同様の現象を確認しているので、
おそらくそこではないと思うのですが……
> (2)
件のファイルは私の手元の Linux（Debian sid）上の texlive 2016（Debian
供給のものではなく install-tl-unx を使用してインストール、tlmgr で定期的に
アップデート）で作成したものです。texlive のシステムはインストールした
そのままに等しい（luajitlatex を使うための改変をした位）です。
# ルビが小書きにならないというのは、ちょっと理由が思いつかないです
# ねー。
> (3)
pdf を添付します。Mac 上でどうなるかはまた深夜に。
(2) 「ルビが小書きにならない」は forum:1748 で解決しました。
(3) の話の回答として
> # ただし、大本の「ずれる」のは、okumacro でも pxrubrica でも
> # やはりずれるわけですが。
といただきましたので、可能な範囲で調べてみましょう。
# スレッドが分岐しすぎてごちゃごちゃしてしまいましてすみません…
(3) の話の回答として
> # ただし、大本の「ずれる」のは、okumacro でも pxrubrica でも
> # やはりずれるわけですが。
といただきましたので、可能な範囲で調べてみましょう。
# スレッドが分岐しすぎてごちゃごちゃしてしまいましてすみません…
Wikiという形で知識の集積をはかる場合、「どの立場にとってdvipdfmxでもよくて、どの立場にとってAcrobatがよいのか」ということを明確にすればよいと思います。
学生がレポートをTeXで作って自宅や研究室のプリンタで出力することを考えれば、多くの場合dvipdfmxで事足りるでしょう（そこで少々ずれていても、問題にならなかったり、最悪切り貼りで修正すればよいでしょう）。
一方で、商業印刷においてTeXを利用するのであれば、いろいろ（過去は、なのか現在も、なのか）致命的な問題があるのでしょう。
私は、TeX Wikiの主たる読者は「レポート・論文をTeXで書かざるを得なくなった」学生、研究者だと思っています（フォーラムはマニアの巣窟だと思ってますが）。その中で、記事を目にすることが多い層のニーズに合った情報提供をすることが重要なのだと思います。
TeXで書いてPDFで提出「せざるを得ない」（しかも卒論1本だけかもしれない）人に、数万円出してAcrobat買え、というのは無茶な主張だと思います。
もちろん、「誰が読むかなんて関係ない、自分の知識・見解をまとめているだけだ」というスタンスも否定はしませんが、それを公開する必要は何なのでしょう。
他の記事にも言えることかもしれませんが、「PDFで完結／プリンタ出力」レベルの人向けの情報・主張と商業印刷レベルの情報・主張は切り分けて記述することが必要ではないでしょうか。
学生がレポートをTeXで作って自宅や研究室のプリンタで出力することを考えれば、多くの場合dvipdfmxで事足りるでしょう（そこで少々ずれていても、問題にならなかったり、最悪切り貼りで修正すればよいでしょう）。
一方で、商業印刷においてTeXを利用するのであれば、いろいろ（過去は、なのか現在も、なのか）致命的な問題があるのでしょう。
私は、TeX Wikiの主たる読者は「レポート・論文をTeXで書かざるを得なくなった」学生、研究者だと思っています（フォーラムはマニアの巣窟だと思ってますが）。その中で、記事を目にすることが多い層のニーズに合った情報提供をすることが重要なのだと思います。
TeXで書いてPDFで提出「せざるを得ない」（しかも卒論1本だけかもしれない）人に、数万円出してAcrobat買え、というのは無茶な主張だと思います。
もちろん、「誰が読むかなんて関係ない、自分の知識・見解をまとめているだけだ」というスタンスも否定はしませんが、それを公開する必要は何なのでしょう。
他の記事にも言えることかもしれませんが、「PDFで完結／プリンタ出力」レベルの人向けの情報・主張と商業印刷レベルの情報・主張は切り分けて記述することが必要ではないでしょうか。
＃どこにぶら下げるか悩みましたが・・・
印刷屋としては・・・
dvipdfmxを積極的に使うか？と聞かれれば
私としては「今はNo」です．
ただ，それは一点を除けば技術的な理由ではないです．
その一点ですが，CIDを使うか否かです．
MacにインストールされているCIDを
Mac上のDitillerで埋め込まなければいけない
案件が大量にあります．そうなると，dvipsなんですね．
ついでにいうとPSTricksによる資産ももろもろあるもんで．
CIDかOTFかというのは大きな問題で，例えば
RyuminL (CID)なんてRyuminProL (OTF)でいいじゃんと
思われるかもしれませんが，
両者のグリフの差は大きな問題になります．
例えば句読点の大きさに注目していただければ，
すぐにわかりますので，
本屋さんでTeX組+RyuminLと思しきものを
物色していただけるとよいかと．
もっとも，vfで句読点だけ飛ばせばいいのですが，
そうなると今度は案件ごとに飛ばし先が異なるという
ややこしい事態になったり・・・
ですんで，OTFで問題なければ，
私的にはdvipdfmxを排除する意義はわかりません．
というか排除は無意味でしょうね．
dvipsよりもdvipdfmの方が優れている部分も
沢山ありますしね．例えば，hyperrefを使うとなると
理解できない制限がdvipsにはあります．
また，引用されているつぶやきなどは
それがいつのものかという情報がない限り無意味ですよね．
ただ，印刷屋はPostScriptにどっぷりの時代が長かったので，PDFで痛い目をみたためにPDFを避けるという傾向はあります．ただ，これは実際のところ運用の問題ですね．
画像の部分では，PDF以外の画像を使うときに，基本的にはghostscriptでPDFにしますよね，
ghostscriptが変換に失敗したりするともうダメです．
ですので，仕事でdvipdfmxを使うと決めた場合，
画像も「正しいPDF」にするとか
いろいろルールを決めないとダメなんです．
ましてや画像専門の部署がある場合，
部署間の調整をしないといけないので，
「運用の問題」です．
経験上では，カラーはcmyk，フォントは埋め込み，
なんちゃららボックスはみんな同じにする
くらいのPDFの画像ならOKです．
基本は「怪しい機能・先端的なものは使わない」です．
RIPとかの問題も考えないといけないですが，
dvipdfmxでないとどうにもならない案件もあるわけで，
そういう場合は注意してRIPを通しますが，
まあ，私のところではdvipdfmxそのものに
起因する問題は起きてません．
もちろん，RIPに通す前に
いろいろチェックはしてますよ．
印刷屋としては・・・
dvipdfmxを積極的に使うか？と聞かれれば
私としては「今はNo」です．
ただ，それは一点を除けば技術的な理由ではないです．
その一点ですが，CIDを使うか否かです．
MacにインストールされているCIDを
Mac上のDitillerで埋め込まなければいけない
案件が大量にあります．そうなると，dvipsなんですね．
ついでにいうとPSTricksによる資産ももろもろあるもんで．
CIDかOTFかというのは大きな問題で，例えば
RyuminL (CID)なんてRyuminProL (OTF)でいいじゃんと
思われるかもしれませんが，
両者のグリフの差は大きな問題になります．
例えば句読点の大きさに注目していただければ，
すぐにわかりますので，
本屋さんでTeX組+RyuminLと思しきものを
物色していただけるとよいかと．
もっとも，vfで句読点だけ飛ばせばいいのですが，
そうなると今度は案件ごとに飛ばし先が異なるという
ややこしい事態になったり・・・
ですんで，OTFで問題なければ，
私的にはdvipdfmxを排除する意義はわかりません．
というか排除は無意味でしょうね．
dvipsよりもdvipdfmの方が優れている部分も
沢山ありますしね．例えば，hyperrefを使うとなると
理解できない制限がdvipsにはあります．
また，引用されているつぶやきなどは
それがいつのものかという情報がない限り無意味ですよね．
ただ，印刷屋はPostScriptにどっぷりの時代が長かったので，PDFで痛い目をみたためにPDFを避けるという傾向はあります．ただ，これは実際のところ運用の問題ですね．
画像の部分では，PDF以外の画像を使うときに，基本的にはghostscriptでPDFにしますよね，
ghostscriptが変換に失敗したりするともうダメです．
ですので，仕事でdvipdfmxを使うと決めた場合，
画像も「正しいPDF」にするとか
いろいろルールを決めないとダメなんです．
ましてや画像専門の部署がある場合，
部署間の調整をしないといけないので，
「運用の問題」です．
経験上では，カラーはcmyk，フォントは埋め込み，
なんちゃららボックスはみんな同じにする
くらいのPDFの画像ならOKです．
基本は「怪しい機能・先端的なものは使わない」です．
RIPとかの問題も考えないといけないですが，
dvipdfmxでないとどうにもならない案件もあるわけで，
そういう場合は注意してRIPを通しますが，
まあ，私のところではdvipdfmxそのものに
起因する問題は起きてません．
もちろん，RIPに通す前に
いろいろチェックはしてますよ．
印刷屋の観点からの貴重な知見をありがとうございます．
Twitter の書き込みにも個別にお礼を書くべきなのですが，私は Twitter のアカウントを持っていないので，
ここでまとめての御礼で失礼いたします．
書いていただいたことはかなり専門的なことで，著者レベルではどうしようもないというか，
気にしてもあまり意味がないことですね．RIP とか一般人は知らないですし．
（私は調べないとわからなかった．）
以前から断片的に見聞きしていたような気はしますが，
PostScript の資産が膨大なこと，初期の PDF 移行時のトラブルでのトラウマがあること，
その他（プロレベルでの）細かな問題があって忌避されるということがあるのですね．
一方で，dvipdfmx の方が dvips よりも有利な点もあるということで，大変参考になりました．
きえださんも書かれていましたが，結局どのソフトウェアを使おうが，
最終出力の前にはチェックが大切ということですね．
> 例えば句読点の大きさに注目していただければ，
> すぐにわかりますので，
> 本屋さんでTeX組+RyuminLと思しきものを
> 物色していただけるとよいかと．
なんだかどんどん本の内容が頭に入らなくなっていきそうなんですが，気付いたときには見てみます．
Twitter の書き込みにも個別にお礼を書くべきなのですが，私は Twitter のアカウントを持っていないので，
ここでまとめての御礼で失礼いたします．
書いていただいたことはかなり専門的なことで，著者レベルではどうしようもないというか，
気にしてもあまり意味がないことですね．RIP とか一般人は知らないですし．
（私は調べないとわからなかった．）
以前から断片的に見聞きしていたような気はしますが，
PostScript の資産が膨大なこと，初期の PDF 移行時のトラブルでのトラウマがあること，
その他（プロレベルでの）細かな問題があって忌避されるということがあるのですね．
一方で，dvipdfmx の方が dvips よりも有利な点もあるということで，大変参考になりました．
きえださんも書かれていましたが，結局どのソフトウェアを使おうが，
最終出力の前にはチェックが大切ということですね．
> 例えば句読点の大きさに注目していただければ，
> すぐにわかりますので，
> 本屋さんでTeX組+RyuminLと思しきものを
> 物色していただけるとよいかと．
なんだかどんどん本の内容が頭に入らなくなっていきそうなんですが，気付いたときには見てみます．