teTeX-3.0 + cmsuper や TeX Live 2007 で、cmsuper + dvipdfm を用いると、合字？がおかしくなるという不具合が永田様から報告されてました（[Q&A:47695]）。
その解決法として、updmap に修正を入れるというのを提案しましたし（[Q&A:47735]）、それを updmap の作者にお知らせいただいきました（[Q&A:47736], [Q&A:47754]）。
ところが、TeX Live 2008 には反映されてないのか、あいかわらず同じ不具合があるように思うのですが、私の勘違いでしょうか？少なくとも、私のパッチは採用されてないようです。別の方法で直してもらってればそれで構わないのですが、そうでもないようなので...
TeX Live の ML でお願いすべきかどうか、勘違いがないかどうか、確認をしたくてお尋ねする次第です。よろしくお願いします。
#お知らせいただいたことを疑うつもりはありません。
#T.E さんの手元で眠ってるだけだろうと想像してます。
#手元のパッチを整理したいだけだったりします。
ご無沙汰しております。栗山です。
Latin Modern についてですが，ラテン文字のみの使用であればもう cm-super は不要だろうと思います。
ただ，その名の通りラテン文字しかサポートしないので，例えばT2エンコーディング（キリル文字）のType1フォントを使いたい場合は cm-super が必要になります。また Latin Modern はキリル文字やギリシャ文字と併用する場合にちょっとしたバグがありました（もう解決されたでしょうか？）。
ゆくゆくは TeX Gyre などに吸収されてラテン文字・非ラテン文字を意識することなく使えるようになるのだろうと思いますが，まだ少し先のようです。
Latin Modern についてですが，ラテン文字のみの使用であればもう cm-super は不要だろうと思います。
ただ，その名の通りラテン文字しかサポートしないので，例えばT2エンコーディング（キリル文字）のType1フォントを使いたい場合は cm-super が必要になります。また Latin Modern はキリル文字やギリシャ文字と併用する場合にちょっとしたバグがありました（もう解決されたでしょうか？）。
ゆくゆくは TeX Gyre などに吸収されてラテン文字・非ラテン文字を意識することなく使えるようになるのだろうと思いますが，まだ少し先のようです。
以下は個人的な見解で，ディストリビューション云々というレベルではありません。
Latin Modern + キリル文字についてですが，安田さんが LHキリル T2D/OT2
Type1 フォントを公開されていらっしゃるので，それを使用すれば cm-super
は不要だろうと思います。
T2D フォントは，おおざっぱにいえば T2A （主に現代ロシア語用）+ "80～"BF
の範囲に古スラヴ語・教会スラヴ語の字母・アクセント類を含むフォンなので，
ロシアの少数民族の言語を扱うのでなければ T2A と同様に利用できるかと
思います。
Latin Modern とギリシア・キリル文字を併用する場合の問題点ですが，バグで
はなく，フォントを使用する際の定義ファイルの問題ではないかと思います。
http://www2.tba.t-com.ne.jp/ing/ing/latinmodern.html に対応策の例を
掲載しましたので，ご意見を伺わせていただければ幸いです。
Latin Modern + キリル文字についてですが，安田さんが LHキリル T2D/OT2
Type1 フォントを公開されていらっしゃるので，それを使用すれば cm-super
は不要だろうと思います。
T2D フォントは，おおざっぱにいえば T2A （主に現代ロシア語用）+ "80～"BF
の範囲に古スラヴ語・教会スラヴ語の字母・アクセント類を含むフォンなので，
ロシアの少数民族の言語を扱うのでなければ T2A と同様に利用できるかと
思います。
Latin Modern とギリシア・キリル文字を併用する場合の問題点ですが，バグで
はなく，フォントを使用する際の定義ファイルの問題ではないかと思います。
http://www2.tba.t-com.ne.jp/ing/ing/latinmodern.html に対応策の例を
掲載しましたので，ご意見を伺わせていただければ幸いです。
稲垣さん，今晩は。いつもお世話になります。
Latin Modern とギリシャ語の問題については以前TeX Q&A掲示板でも問題になりましたね。
私としては，他の非ラテン文字と併用する場合に，デフォルトであり得ないエンコーディング（LGRlmrなど）を勝手に作ってしまうというのは，充分バグだと思います（ラテン文字のフォントなのにギリシャ文字のエンコーディングを再定義しなければならないこと自体，変です）。
稲垣さんの対応策については大変便利で感謝しております。ただ，最終的にはアップストリームで対応しなければならない問題だろうと考えます。
情けないことに，当時アップストリームへ報告したかどうか記憶が定かではありません。
現時点での最新版をテストしてみる必要がありますね。
もし直っていなければ報告を上げることにします。
# ひょっとして TeX Gyre リリースまで我慢しろと言われる可能性もあるでしょうか...
Latin Modern とギリシャ語の問題については以前TeX Q&A掲示板でも問題になりましたね。
私としては，他の非ラテン文字と併用する場合に，デフォルトであり得ないエンコーディング（LGRlmrなど）を勝手に作ってしまうというのは，充分バグだと思います（ラテン文字のフォントなのにギリシャ文字のエンコーディングを再定義しなければならないこと自体，変です）。
稲垣さんの対応策については大変便利で感謝しております。ただ，最終的にはアップストリームで対応しなければならない問題だろうと考えます。
情けないことに，当時アップストリームへ報告したかどうか記憶が定かではありません。
現時点での最新版をテストしてみる必要がありますね。
もし直っていなければ報告を上げることにします。
# ひょっとして TeX Gyre リリースまで我慢しろと言われる可能性もあるでしょうか...
この問題、すなわち
lmodern パッケージ使用下で Babel のギリシャ・ギリル文字使用を併用すると LGR 等に対するファミリが LGR/lmr という無効なものになること
の根本的な原因は「Babel の機能不足」と考えています。（個人的見解として）
例えば自分で、
\usepackage{lmodern}
\fontencoding{LGR}\selectfont
のように書くと当然フォント設定は LGR/lmr （無効な設定）になります。でも勿論これは何かのパッケージのバグではなく、自分が書いたコードが間違っている訳です。
エンコーディング切り替えを自動化している Babel では、こうならないようにフォントファミリも管理すべきだと考えています。しかし、現状の Babel 本体はエンコーディング・ファミリの管理の機能がほぼ完全に欠落している状態で、従って、切替が必須になる各言語定義(.ldf)がそれぞれアドホックに管理をしている状態で、この為に衝突が起こることもあります。（例えば、ロシア語とウクライナ語で別のエンコーディングを指定できない、等。）
残念ながら、特にラテン以外の言語処理の拡充については、今後は Unicode TeX （XeTeX、LuaTeX）上でのものが主になっていって、Babel の本質的な拡張はもう行われないと 予測しています。（Babel のドキュメントを読むと、当初はフォントの管理も実装する予定であったことがわかります。）
LGR の cm-super を LGR/lmr に充てるというのは、この Babel の機能不足を回避するための一つの有用な策です。注意すべきは、cm-super はあくまで本来 lmr と見なすべきでないフォントなので、この設定を「既定」にするのは筋違いだということです。（本来不正な設定が文書ソースの裏に隠れてしまうのは問題のある設計です。）
私によってより良いと思われる回避策は、
- 例えば fxmr とかの新しいファミリを作って、T1/fxmr を T1/lmr と、LGR/fxmr を LGR/cmr と同じにする。
- フォント選択機構に手を入れて、「LGR/lmr は LGR/cmr で代替する」という指定を明示的にできるようにする。
等です。後者は実験的に実装したことがあります。Babel にどういう機構があるべきかについてはまた改めて書こうと思います。
ZRさん，お久しぶりです。
コメントありがとうございます。
エンコーディングの指定についてBabelの機能不足と考える点は参考になります。
ただ，それを承知しているのなら尚更，それなりの「対策」が後発のパッケージ（例えばLatin Modern）に用意されてしかるべきでは？とも思います。もちろんパッケージの作者はラテン文字以外の振る舞いに興味を持っていない（重要視していない）ということも考えられますが。
Babelの本質的拡張が行われるか否かという問題は措いておきますが，日本ですらUnicode化に四苦八苦している現状から考えると，各国の言語で非Unicodeパッケージが併用される状況がしばらく続くのではないかと思います。
また，少なくとも多言語を使う立場としては，使いたい言語が必ずしもUnicodeに対応しているとは限らない（使いやすいか否かという点も含めて）ので，当面はBabelを上手に使っていくしかないのかとも感じます。
その点で，上流で対応できないなら個別に対応していくのもよいのかも知れません。
Upstreamではどのように考えているのかについても，情報を収集できればと思います。
コメントありがとうございます。
エンコーディングの指定についてBabelの機能不足と考える点は参考になります。
ただ，それを承知しているのなら尚更，それなりの「対策」が後発のパッケージ（例えばLatin Modern）に用意されてしかるべきでは？とも思います。もちろんパッケージの作者はラテン文字以外の振る舞いに興味を持っていない（重要視していない）ということも考えられますが。
Babelの本質的拡張が行われるか否かという問題は措いておきますが，日本ですらUnicode化に四苦八苦している現状から考えると，各国の言語で非Unicodeパッケージが併用される状況がしばらく続くのではないかと思います。
また，少なくとも多言語を使う立場としては，使いたい言語が必ずしもUnicodeに対応しているとは限らない（使いやすいか否かという点も含めて）ので，当面はBabelを上手に使っていくしかないのかとも感じます。
その点で，上流で対応できないなら個別に対応していくのもよいのかも知れません。
Upstreamではどのように考えているのかについても，情報を収集できればと思います。
ZRさん，皆さん，こんばんは。
話題が少し拡散気味で，しかも元の話題（cm-super）と離れてきたので，スレッドを分けようと思います。とりあえずLatin Modernとギリシャ語，ロシア語などの非ラテン言語との共存については最新版をチェックしました。近々別スレッドで報告いたします。
簡単に言えば，ギリシャ語についてはcbfonts側で対応（2008年1月版より）することにより，現在はLatin Modernと共存できるようになっています。ロシア語については未確認ですが，少なくともLHフォントのパッケージには含まれていないようです。こちらもそのうち整理して報告します。
最新版のBabel（3.8l）もfrenchb.ldfやspanish.ldfなどで小さな問題（命令の競合など）を抱えているようです。こちらも追って報告します。
話題が少し拡散気味で，しかも元の話題（cm-super）と離れてきたので，スレッドを分けようと思います。とりあえずLatin Modernとギリシャ語，ロシア語などの非ラテン言語との共存については最新版をチェックしました。近々別スレッドで報告いたします。
簡単に言えば，ギリシャ語についてはcbfonts側で対応（2008年1月版より）することにより，現在はLatin Modernと共存できるようになっています。ロシア語については未確認ですが，少なくともLHフォントのパッケージには含まれていないようです。こちらもそのうち整理して報告します。
最新版のBabel（3.8l）もfrenchb.ldfやspanish.ldfなどで小さな問題（命令の競合など）を抱えているようです。こちらも追って報告します。
Babel でまともにスクリプト毎のファミリの管理を行うにはどのような設計が考えられるかという話です。かなり大掛かりになり、かつ、アドホックな対応をしている現状の ldf と互換性がないので、実際に実装してみるというのはあまり現実的ではありませんが…。
まず次のようなテーブルを用意します。
ScrForLng(言語) → (スクリプト) # ScrForLng は基本的に固定のはず EncForScr(スクリプト) → (エンコーディング) EscForLng(言語) → (エンコーディング) PtnForLngEnc(言語,エンコーディング) → 分綴パターン FamForEncGen(エンコーディング,汎用ファミリ) → ファミリ FamForLngEncGen(言語,エンコーディング,汎用ファミリ) → ファミリ # 汎用ファミリ = serif, sans, mono
設定の例。
ScrForLng(english) → Latin ScrForLng(lithuanian) → Latin ScrForLng(russian) → Cyrillic ScrForLng(abkhaz) → Cyrillic ScrForLng(serbianc) → Cyrillic ScrForLng(serbianl) → Latin # スクリプトが違うのは別言語とみなす方が合理的 EncForScr(Latin) → T1 EncForScr(Cyrillic) → T2A EncForLng(lithuanian) → L7x EncForLng(abkhaz) → T2C PtnForLngEnc(english,T1) → english PtnForLngEnc(russian,T2A) → russianT2A PtnForLngEnc(russian,OT2) → russianOT2 # russianT2A, russianOT2 は language.dat に登録 FamForEncGen(T1,serif) → lmr # Latin Modern FamForEncGen(T2A,serif) → cmr # cm-super FamForLngEncGen(serbianc,T2A,serif) → ftmsrb # 適当なもの # セルビア語(キリル)は一部のグリフが「標準」と異なる
上の設定では各言語で次のようなファミリとパターンが使われます。
言語 ファミリ(roman) 分綴パターン english T1/lmr english lithuanian L7x/lmr - russian T2A/cmr russianT2A abkhaz T2C/cmr - serbianc T2A/ftmsrb -
ここで、例えば russian を OT2/wncyr にしようと思った場合は、
EncForLng(russian) → OT2 FamForEncGen(OT2,serif) → wncyr
を追加設定すればよいことになります。
実は、XeTeX の多言語処理パッケージである Polyglossia はこんな感じの設計になっているように見えます。（フォントエンコーディングの切替は含まれていない―Unicode 固定である―はずですが。）
永田様：
T.E. さんがTeXを卒業されたのなら、致し方ないことです。私こそ「T.E.にお知らせ...」と提案ましたので、責任は私にもあります。ですのでお気にされませんよう。
個人的にはBabelの深い話が聞けたので、よかったと思ってます。(^_^)
Z.R.様：
dvipdfmx を前提にしてよいのなら、そもそも -r を付加する処理はいらなくなるんでしょうか...
dvipdfmは消えてるかと思って、今、TeX Live のsvnを見たのですが、「no more omega/lambda binaries」の文字を発見してしまいました。本当にomegaコマンドが消されてるので、ちょっと驚きです。みんなluatexに集結するんでしょうか。
http://tug.org/svn/texlive?view=rev&revision=13241
T.E. さんがTeXを卒業されたのなら、致し方ないことです。私こそ「T.E.にお知らせ...」と提案ましたので、責任は私にもあります。ですのでお気にされませんよう。
個人的にはBabelの深い話が聞けたので、よかったと思ってます。(^_^)
Z.R.様：
dvipdfmx を前提にしてよいのなら、そもそも -r を付加する処理はいらなくなるんでしょうか...
dvipdfmは消えてるかと思って、今、TeX Live のsvnを見たのですが、「no more omega/lambda binaries」の文字を発見してしまいました。本当にomegaコマンドが消されてるので、ちょっと驚きです。みんなluatexに集結するんでしょうか。
http://tug.org/svn/texlive?view=rev&revision=13241