先日は色々とご迷惑をおかけ致しまして誠に申し訳ございません
さて，標題の件ですが，OTFパッケージについてメンテナンスをした方が良いと思われる点があるようですので，私の考えている指針を述べさせて戴きたいと存じます．皆様のご意見をお聞かせ願いたく存じます．
1. disablejfamオプション使用時の不具合
・3/20付けで修正版を出しました．
2. JIS2004字形への対応
・JIS X 0208内については，新たにtfm, vfを用意し，shapeの切り替えによって切り替えられるようにする．
・\UTF, \CIDで指定する文字については何もしない．
一番目については，vfの段階でCIDに変換しておき，CMapはIdentityを使う方法と，vfではJISのコードのままにしておき，然るべきCMap（何を使えばよいのか，まだ調べていません）で変換する方法の2種類が考えられますが，どちらがよいでしょう？
3. ぶら下げ組への対応
リクエストがあったので，ぶら下げ組み用のtfm, vfを作成しましたが，これを取り込もうと考えています．
現在は，パッケージのオプションで切り替えするようにしていますが，これもshapeの切り替えでした方が良いと考えています．
4. speed up patchの適用
土村様へのお願いとなりますが，ptexliveで使用されているspeed up patchを取り込ませて戴けないでしょうか．
5. 開発版，安定版の変更
・現在の安定版（ver. 1.2.9）はzipファイルの名称を変更して（例えばotf1.2.9.zip）残しておく．
・開発版（ver. 1.5.5）を安定版（ver. 1.6）としotfstable.zipとする．
・上記2, 3への対応をするものを，当面ベータ版としてotfbeta.zipとする．
他にした方が良いと思われることがありましたら，ご指摘下さい．
・OFMLEVELエントリの追加
・土村さんのspeed up patchの適用
・uplatexへの対応
上記の変更を致しました．
C版のovp2ovfが通るかお試し戴ければと存じます．
・土村さんのspeed up patchの適用
・uplatexへの対応
上記の変更を致しました．
C版のovp2ovfが通るかお試し戴ければと存じます．
すっかり出遅れてしまいました。
uplatex パッチの採用、ありがとうございました。
uplatex 使用時の本文用vfを作成するため
齋藤様作成の"mkjvf"を改変しunicode動作可能にした"umkjvf"を作成し
すでに公開してしまっています。
(upTeX配布の中のotfstable-uptex-0.04.tar.gzの中のumkjvf)
otfパッケージに別名で追加して使う形にはなっていますが、
otfパッケージのライセンス上
「改変の上再配布」のようなことをしてしまってよいものか少々引っかかっていました。
断りも無く「改変の上再配布」を勝手に実行していたのを
お詫び申し上げます。
umkjvf以外は著作権とかライセンス云々というほどの内容はないので
問題ないと思っています。
mkjvfをumkjvfにする際の差分はそれなりの量になっていることと、
uplatexの将来性をどう捉えるかの問題もあるし、
メンテナンスのためにはuptex環境の準備をする手間もかかるとあって、
otfパッケージ開発元の齋藤様にメンテナンスをお願いするのは気が引けます。
このままumkjvfを私がメンテナンス、公開をしても差し支えないでしょうか?
お考えを伺えたらありがたく存じます。
uplatex パッチの採用、ありがとうございました。
uplatex 使用時の本文用vfを作成するため
齋藤様作成の"mkjvf"を改変しunicode動作可能にした"umkjvf"を作成し
すでに公開してしまっています。
(upTeX配布の中のotfstable-uptex-0.04.tar.gzの中のumkjvf)
otfパッケージに別名で追加して使う形にはなっていますが、
otfパッケージのライセンス上
「改変の上再配布」のようなことをしてしまってよいものか少々引っかかっていました。
断りも無く「改変の上再配布」を勝手に実行していたのを
お詫び申し上げます。
umkjvf以外は著作権とかライセンス云々というほどの内容はないので
問題ないと思っています。
mkjvfをumkjvfにする際の差分はそれなりの量になっていることと、
uplatexの将来性をどう捉えるかの問題もあるし、
メンテナンスのためにはuptex環境の準備をする手間もかかるとあって、
otfパッケージ開発元の齋藤様にメンテナンスをお願いするのは気が引けます。
このままumkjvfを私がメンテナンス、公開をしても差し支えないでしょうか?
お考えを伺えたらありがたく存じます。
釈迦に説法の部分もあるかと思いますが説明させていただきます．以下，disablejfam
オプションは使用していないという前提で話をします．
\AtBeginDocument 内の2つの \reDeclareMathAlphabet の部分は，\mathrm, \mathbf
がそれぞれ \mathmc, \mathgt の機能を合わせ持つようにするためのものです．
そして，現在の jarticle class では，これらは mathrmmc オプションを付加したとき
に同等のコードが発行されます．これは，\reDeclareMathAlphabet が脆弱であるのと
和文ゴシック体は実際には使わないのに \mathbf としただけで数式famが1つ消費される
ことのためです．従って，mathrmmc オプションを使わずに，\documentclass{jarticle}
として 3/20版の otf.sty を用いた場合，mathrmmc が指定されていないにもかかわらず
その機能が実現されるという意味論上の不整合が生じます．
一方，jsarticle class では mathrmmc オプションは実装されておらず，とくに
オプションを記述しなくても上記のコードが発行されます．このあたりは，class が
違えば考え方も違うということでしょう．この場合はなんの不整合も生じていません．
\reDeclareMathAlphabet はそれが同じ設定なら，一回発行すればそれで十分なものです．
そして，\if@enablejfam が存在しているならば，class file 内で
\reDeclareMathAlphabet{\mathrm}{\@mathrm}{\@mathmc}
\reDeclareMathAlphabet{\mathbf}{\@mathbf}{\@mathgt}
の2つが「必要ならば発行されているし，必要ないならば発行されていない」ことが
十分に予想できると考えられます．
で，結論です．otf.sty 内ではこれらは発行しないというのはいかがでしょうか？
(つまり \AtBeginDocument{...} を削除) 既に class file 内で必要ならば発行されて
いるはずなので，問題なく意図どおりに動作すると思われます．
%%% 以下，雑談というか... %%%
せっかく開発版 otf.sty を使うのなら，\mathbf で和文ゴシック体(\mathgt) が割り
当てられるのではなく和文太字が割り当てられるのがかっこいいかなと一瞬思いました．
しかし，あまり需要はないと思われます．数式を記述する場合に和文数式文字が必然と
なることは非常に少ないので，上の方に述べたことも「明朝体が数式内で手軽に使える」
ならば，どのようになっていてもクレームは付かないんじゃないかなと考えています．
オプションは使用していないという前提で話をします．
\AtBeginDocument 内の2つの \reDeclareMathAlphabet の部分は，\mathrm, \mathbf
がそれぞれ \mathmc, \mathgt の機能を合わせ持つようにするためのものです．
そして，現在の jarticle class では，これらは mathrmmc オプションを付加したとき
に同等のコードが発行されます．これは，\reDeclareMathAlphabet が脆弱であるのと
和文ゴシック体は実際には使わないのに \mathbf としただけで数式famが1つ消費される
ことのためです．従って，mathrmmc オプションを使わずに，\documentclass{jarticle}
として 3/20版の otf.sty を用いた場合，mathrmmc が指定されていないにもかかわらず
その機能が実現されるという意味論上の不整合が生じます．
一方，jsarticle class では mathrmmc オプションは実装されておらず，とくに
オプションを記述しなくても上記のコードが発行されます．このあたりは，class が
違えば考え方も違うということでしょう．この場合はなんの不整合も生じていません．
\reDeclareMathAlphabet はそれが同じ設定なら，一回発行すればそれで十分なものです．
そして，\if@enablejfam が存在しているならば，class file 内で
\reDeclareMathAlphabet{\mathrm}{\@mathrm}{\@mathmc}
\reDeclareMathAlphabet{\mathbf}{\@mathbf}{\@mathgt}
の2つが「必要ならば発行されているし，必要ないならば発行されていない」ことが
十分に予想できると考えられます．
で，結論です．otf.sty 内ではこれらは発行しないというのはいかがでしょうか？
(つまり \AtBeginDocument{...} を削除) 既に class file 内で必要ならば発行されて
いるはずなので，問題なく意図どおりに動作すると思われます．
%%% 以下，雑談というか... %%%
せっかく開発版 otf.sty を使うのなら，\mathbf で和文ゴシック体(\mathgt) が割り
当てられるのではなく和文太字が割り当てられるのがかっこいいかなと一瞬思いました．
しかし，あまり需要はないと思われます．数式を記述する場合に和文数式文字が必然と
なることは非常に少ないので，上の方に述べたことも「明朝体が数式内で手軽に使える」
ならば，どのようになっていてもクレームは付かないんじゃないかなと考えています．
> 土村様へのお願いとなりますが，ptexliveで使用されているspeed up patchを取り込ませて戴けないでしょうか．
お返事遅くなってすいません。もちろんご自由に扱っていただいて構いません。
私の場合、何度も make する必要から、待ち時間が短くなったらいいなぁ、というぐらいの動機で作ったパッチです。他の処理も見てみるとある意味で共通性があるというか、拡張性を確保してあるのだなぁ、と思ったので、わざわざ開発者にパッチの存在をお知らせするほどのこともないと思って、そのままにしてきました。お目にとまって恐縮しています。必要と思われる範囲で、ご自由にお使いいただけましたら幸いです。
お返事遅くなってすいません。もちろんご自由に扱っていただいて構いません。
私の場合、何度も make する必要から、待ち時間が短くなったらいいなぁ、というぐらいの動機で作ったパッチです。他の処理も見てみるとある意味で共通性があるというか、拡張性を確保してあるのだなぁ、と思ったので、わざわざ開発者にパッチの存在をお知らせするほどのこともないと思って、そのままにしてきました。お目にとまって恐縮しています。必要と思われる範囲で、ご自由にお使いいただけましたら幸いです。
角藤先生
ご指摘の通り，OFMLEVELを0に変更しておきました．
山本和義様
解説ありがとう御座います．ご指摘通り\AtBeginDocument{...}の部分を削除しておきました．
以上の修正をしたものを，ver. 1.5.6として公開致しました．
併せて，安定版，UTFパッケージも同様の修正を致しました．
2004字形への対応とぶら下げ組みの対応については，shapeで切り替えない方が良いような気がしてきました．
とりあえず，ぶら下げ組みについてはパッケージのオプションで対応することにして週末に作業をしようと思います．
2004字形はフォントメーカーごとの実装の違いなどで，ちょっと混乱しています．
ご指摘の通り，OFMLEVELを0に変更しておきました．
山本和義様
解説ありがとう御座います．ご指摘通り\AtBeginDocument{...}の部分を削除しておきました．
以上の修正をしたものを，ver. 1.5.6として公開致しました．
併せて，安定版，UTFパッケージも同様の修正を致しました．
2004字形への対応とぶら下げ組みの対応については，shapeで切り替えない方が良いような気がしてきました．
とりあえず，ぶら下げ組みについてはパッケージのオプションで対応することにして週末に作業をしようと思います．
2004字形はフォントメーカーごとの実装の違いなどで，ちょっと混乱しています．