upjisr-v のコロン - Githubissues

aminophen commented 7 years ago

\documentclass{utarticle}
\begin{document}
\fboxsep0pt
これは\fbox{\inhibitglue：\inhibitglue}です。
\end{document}

この結果が以下のようになるのですが

コロンは縦組で回転しなくて良かったのだろうか，と疑問に思います。
もし回転する対象でないとすれば，字幅と JFM グルーの設定が適切でないと思います。

t-tk commented 7 years ago

ドキュメントに記載したことと同じ課題かと思います。

◇ 今後の課題、要検討事項など [4] JIS→Unicode→CID の変換をupjis?-?.vfなどに対してうまくいく形にする。 JIS X 0208集合の横組はよくなったが、縦組の約物はまだ上手くいかない。 vf と標準の CMap だけでは限界があり、 CMapの整備が必要。

まだ検討すらできていません。なので、良い解決策があれば歓迎です。

おぼろげながら、縦組みのコロンは各種規格や実装で迷走していて頭痛がして放置したような記憶があります。

aminophen commented 7 years ago

ドキュメントにあったのですね，見つけることが出来ていませんでした。

縦組のコロンは中国語だと回さない（ただし仮想ボディの右に寄る）というのが一般的らしく，こっちで先ほど教えていただきました。CMap の整備は簡単ではないですね。触らずに TODO のままにしておきます…

もちろん，いい方法が浮かべばまた考え直すことにします。

t-tk commented 7 years ago

ASCII pTeXの方の jis-v のコロンは回転していますか? (疑問) 私はソースを見てコロン(0x2127)、セミコロン(0x2128)を回転操作していそうな該当部分を見つけることが出来ませんでした。

CMapの件、今の私案は以下です。 UniJIS-UCS2-Vとほぼ同じだが {右,左}{シングル,ダブル}引用符が UniJIS-UCS2-H のままであるような CMap を自作し、適当に回転し、upjisr-h と同様の方法 ( {右,左}{シングル,ダブル}引用符だけそのCMapに当てる、その他大多数は UniJIS-UTF16-V に当てる ) をすれば、今よりは良くなるように思います。以下、状況です。 UniJIS-UTF16-Hはシングル,ダブル引用符(U+2018,U+2019,U+201C,U+201D)が欧文用のグリフに当たっているので使用不可。UniJIS-UTF16-Vはシングル,ダブル引用符の使用を想定していないみたい。 UniJIS-UCS2-Vでは、CID8279〜8282 に当てられているが、位置が変になりそう。 Adobe-Japanじゃないフォントでも使いまわすことを想定すると、Hのグリフを回転するような古臭い方法の方が安全で汎用性がありそう。全角コロンU+FF1AのV字形はCID12101にあり、UniJISX0213-UTF32などでは割り当てられているが、使いにくそう。

aminophen commented 7 years ago

ASCII pTeXの方の jis-v のコロンは回転していますか? (疑問) 私はソースを見てコロン(0x2127)、セミコロン(0x2128)を回転操作していそうな該当部分を見つけることが出来ませんでした。

jis-v でもコロンは回転しません。（が，jsarticle なども縦書きは jis-v を採用していなくて tmin10 のままなので，jis-v を実用している人はほぼいません。tmin10 もコロンは回転していません。）

「jis-v も tmin10 も回転しないのに，upjis-v だけ回転しても構わないのか？」というと，私は構わないと考えています。例えば「度 °」「分 ′」「秒 ″」が pTeX と upTeX で違う

という例があります。makejvf が回しているわけではなく，V と UniJIS-UTF16-V で違う CID が当たるからです。両者で同じ出力を得るためには，JFM や VF のメトリックを変更するか，別の CMap に当てるかの特殊処理が必要ですが，現状はそうなっていないので，実際に違う出力になります。

CMapの件、今の私案は以下です。 UniJIS-UCS2-Vとほぼ同じだが [...] をすれば、今よりは良くなるように思います。

メトリックと実際の出力が合致しない例はコロン以外にもあるのでしょうか？どの方法をとるか（あるいは何もしないか）は，それらを列挙したあとに考えても良いのではと思えてきました。

zr-tex8r commented 7 years ago

そもそも、各種TrueTypeフォントあるいは各種CMapが“適切だと思う方”を選んでいるわけですよね。だとすると、「JFMで回転させる」（つまり“わざわざ逆にする”）という選択はありえないでしょう。

そうすると、自分には、「単純にUniJIS-UTF16-Vに従う」のが自然だと思うのですけど……。

aminophen commented 7 years ago

私も考えがまとまっていませんが，そもそも「現状では JFM で想定している字形と，実際に出力する字形が合致しないので，それで良いのだろうか」という疑問が発端でした。これが「良くない」ならば，

UniJIS-UTF16-V で実際に出力する文字にあうように，JFM のメトリックを変える
JFM のメトリックに合う文字を出力する CMap が現状ではなさそうなので，
- 新しく CMap を作ってそれに当てる
- 既存の CMap で擬似的に回転や移動を駆使する

のいずれかで，合致させれば良いわけです（どの方法も一長一短あります）。もし，「面倒だから別に構わない」なら，そのままで良いのです。どちらなのかが今のところ不明だ，というのが issue です。

t-tk commented 7 years ago

この文章ではコロンに絞ります。「単純にUniJIS-UTF16-Vに従う」と仮定すると、「全角コロンU+FF1Aを縦組みで使用することを想定していない」と読みとれるので、コロンのJFMとの矛盾は解消すべき不具合ではなく、「サポート対象外」でよいと思います。 upTeXがpTeXの後継を目指すという観点でも、jis-vやtmin10で回転していなかったのなら、頑張って整備する必要性は無いと言えます。一方、JIS X 0213では、コロン(1面1区7点)の縦書字形として回転されたものが例示されています。それをU+FF1Aで実現したいなら手段はあった方がいいでしょう。それを upjisr-v でやるべきかどうか…。

実際に出回っているフォントの実装では、縦書きの全角コロンU+FF1Aを回すかどうかはフォントによりバラバラみたいですね。こことかこことか。ただし、新しいものほど回す実装になっていそうな気がします。 U+FF1Aだけの都合で言うと、UniJISPro-UCS2-V はCID12101に対応づけられていました。CID12101で上手くいくなら「回転や移動を駆使」したくないところです。

aminophen commented 7 years ago

新しいものほど回す実装，というのはなんとなく実感としてあります。

Adobe にプルリクを出して，UniJIS-UTF16-V の縦書きコロンを CID12101 に変更してもらうと万事解決するのでしょうか？（もしそうだとして，実現可能性はどのくらいだろう？）

zr-tex8r commented 7 years ago

AJ1のcid2code.txtのコメントを見ると、「UniJISとUniJISX0213の使い分け」について次のようなことが書かれています。

フォントがAJ1-5を完全にサポートするならばUniJISX0213を推奨する。
- UniJISX0213-Hのマップ先はSupplement 5のグリフを含む。
- ちなみに縦書きコロンのグリフ（CID 12101）はSupplement 4にある。だから“Pro”以上のフォントならサポートされる。（「最近は縦書きコロン字形を良く見る」のはPro対応のフォントが増えているから？）
それ以外はUniJISを推奨する。

UniJIS-UTF16-V の縦書きコロンを CID12101 に変更してもらう

もしかすると、UniJISの方は“Std”でも使えないといけないから無理かも？

zr-tex8r commented 7 years ago

参考資料

※UJ=UniJIS, P=Pro, o=UCS2, n=UTF16/32, X=X0213

ajpunct

zr-tex8r commented 7 years ago

よく考えてみたら、UniJISX0213のCMapは、UTF32しか用意されてないので使えないのですね。

UniJISPro-UCS2-Vはクオートがミニュートになっているので、その意味でも魅力的ですね。

t-tk commented 7 years ago

グリフの表ありがとうございます。コード表だけを見るのよりもはるかに実感が沸きます。そうすると、Adobeの意図は、「U+FF1A(全角コロン)を縦組みでCID12101に割り当てることはAdobeも適切だと考えているが、文字集合の諸々のしがらみでUniJIS-UTF16-V にその割り当てを入れていない。」ということでしょうかね。

UniJISX0213のCMapは、UTF32しか用意されてないので使えないのですね。

我々のニーズに合うCMapがAdobe提供のセットの中に無いならば、作ってしまえばよいと思います。例えば、大多数の文字がUniJIS-UTF16-{H,V}と同じでかつ不都合なところだけ割り当てなおしたCMapを作ればよいのではないかと。 vf,tfmやマクロを自作するのと同じような感覚で、CMapも作ってしまえばよいと思います。もちろん、仮想ボディの箱を削ったりずらしたりはCMapでは不可能だしvf,tfmが受け持つべきです。さらに、文字コードとCIDの関係はCMapが受け持っているのだから、そこに入れたい機能があるならCMapに手を入れるのは自然なことです。以前はCMapがフリーソフトでは無かったような記憶がありますが、今はためらう理由になりません。

横組みの方は、私は UniJIS-UCS2-HとUniJIS-UTF16-Hを別のtfmに振り分ける、というややこしい仕組みをupjisr-hに入れてしまいましたが、今思えばCMapの自作で対応できることだったのに、という気がしてきました。

t-tk commented 7 years ago

ものは試しで、cmap-customize というブランチを作成し、UniJISup-UTF16-{H,V} というものを作ってみました。動作確認はまだ出来ていません。

aminophen commented 7 years ago

CMap というと，そういえば https://github.com/texjporg/jfontmaps/tree/master/jis04cmap_exp というのもありましたが（テフライブで配られるが，cmap フォルダにインストールされないので実際に使われてはいない），これも新しい CMap の検討に役立つでしょうか？これは縦組コロンを考慮していそうです。

t-tk commented 7 years ago

簡単なテストをしたところ、手元では UniJISup-UTF16-{H,V} で触った9個(‘’“”：㍾㍽㍼㍻)に関しては、所望の動作が得られました。 JIS X 0213で例示されている縦書字形は他にもあります(例えば ‥…〜ー＝―‐゠㍉㌔㌢㍍㌘㌧㌃㌶㍑㍗㌍㌦㌣㌫㍊㌻)が、それらは元のUniJIS-UTF16-Vで既に回転しているようです。見落としがなければ、JIS X 0213で例示されている縦書字形すべてカバーできたと思います。

jis04cmap_exp のご紹介ありがとうございます。CIDとの対応部分のネタ元は

UniJIS2004-UTF32-{H,V}: by Adobe

とあるので、既に参考にしている cid2code.txt の一部に当たります。

t-tk commented 7 years ago

縦組み字形は伏魔殿というのが率直な印象です。世の中の各種規格や実装で迷走してるのが現実なので、どこかで線を引いてその先はユーザー各位の選択に任せるような形でクローズしたいです。私の記憶によると、まだまだ、「＝≒≠≡」や矢印の方向、度・分・秒でもナントカVとカントカVで差がある、とか色々あったと思います。正直、きりがなく調査をする気さえ失せます。

拙作 UniJISup-UTF16-{H,V} と既存 upjisr-v の組み合わせでJIS X 0213の縦組み例示字形がカバーでき、さらに「㍾㍽㍼㍻」も対応できた(UniJISPro-UCS2-Vと同等レベル)と思います。私としてはここで一区切りつけ、

uptex-fonts のdefault の提供物はここまでにする
- UniJIS-UTF16-V を選択すれば、Adobe標準CMapの範囲で処理される
- UniJISup-UTF16-V を選択すれば、JIS X 0213で例示されている縦組み字形を含めて処理される
それ以上の要望がある場合はユーザー各位のオプション開発をお願いする

ということで合格点なのではないかと思います。

aminophen commented 7 years ago

ありがとうございます。私も

uptex-fonts のdefault の提供物はここまでにする

に同意です。

UniJIS-UTF16-V を選択すれば、Adobe標準CMapの範囲で処理される

UniJISup-UTF16-V を選択すれば、JIS X 0213で例示されている縦組み字形を含めて処理される

についてですが，ptex-fontmaps のマップに書かれるもの（現在は Adobe 標準）がデフォルトですね。選択の手段は，ユーザー各位に \special してもらう，という想定でよろしいでしょうか。

aminophen commented 7 years ago

今気づいたのですが，UniJIS2004up-* も作った方がよいのでしょうか？

t-tk commented 7 years ago

ptex-fontmaps のマップに書かれるもの（現在は Adobe 標準）がデフォルトですね。

あまり考えていませんでしたが、さてどうしましょう。私自身は cid-x.map を直接触ってしまうし、defaultが何かはあまり気にしないのですが、下記現状を踏まえると、UniJISup-UTF16-V をdefaultもしくは推奨とするのは危険なように思えます。 CID指定が可能なAdobe-Japanのフォント以外に割り当てるケースも多々あるでしょうし。

UniJIS-UTF16-V で可能な範囲は、「縦組みでダブルミニュートを出力する意図で、ダブルミニュートを入力する」→一般的なテキストファイル、テキストエディタ、フォントでも直感的な動作が期待できる。

UniJISup-UTF16-V で可能な範囲はさらに、「縦組みでコロンが回転する」→JIS X 0213では例示されているものの、出回っているフォントでは一般的とまではいえない。「縦組みでダブルミニュートを出力する意図で、ダブルクオートを入力する」→JIS X 0208では例示されているものの、JIS X 0213では削除されたもの。出回っているフォントのdefault動作では滅多にお目にかからない。「縦組みでシングルミニュートを出力するする意図で、シングルクオートを入力する」→JIS X 0208とJIS X 0213では例示されているものの、出回っているフォントのdefault動作では滅多にお目にかからない。

横組みの方の「シングルクオート(和文用)を出力する意図で、シングルクオートを入力する」「ダブルクオート(和文用)を出力する意図で、ダブルクオートを入力する」は、直感的なので、defaultにしておきたいです。現状維持(クオートだけ UniJIS-UCS2-H に割り当てる)にしましょうか。それとも振り分けを廃止して UniJISup-UTF16-H 一本にしましょうか。

UniJIS2004up-* も作った方がよいのでしょうか？

想定しているのは漢字の字形の差し替えでしょうか? 需要はありそうですね。メンテナンス性の面で言うと、Adobe提供CMapもちょくちょく改訂されていくので、一度作っておしまいには出来ないでしょうし、追従しやすい仕組みで作っておかないと更新遅れや追従不能のリスクが心配です。 UniJISup-UTF16-{H,V} は UniJIS-UTF16-{H,V} から作り、9字程度の更新だったので手作業でやりました。漢字の字形の差し替えだけなら、UniJISup-UTF16-{H,V} → UniJIS2004up-UTF16-{H,V} を変換するperl scriptでも作りましょうかね。

aminophen commented 7 years ago

下記現状を踏まえると、UniJISup-UTF16-V をdefaultもしくは推奨とするのは危険なように思えます。

現時点で，私も同じ考えです。つまり新しい CMap を提供するだけ，でよいと思います。

横組みの方の「シングルクオート(和文用)を出力する意図で、シングルクオートを入力する」「ダブルクオート(和文用)を出力する意図で、ダブルクオートを入力する」は、直感的なので、defaultにしておきたいです。

これは「現状維持(クオートだけ UniJIS-UCS2-H に割り当てる)」がよいと思います。Windows の游フォントのクオートの幅問題の対処として「クオートだけ別のフォントに割り当てる」という裏技（例えば pxchfon パッケージの yu-win10+ プリセットが使っている）もありうるので…。

http://d.hatena.ne.jp/zrbabbler/20170623/1498238917

UniJIS2004up-* も作った方がよいのでしょうか？

想定しているのは漢字の字形の差し替えでしょうか?

はい，そのとおりの想定でした。UniJISup- に需要があるならば，UniJIS2004up- にも同程度の需要が見込めると思います。

メンテナンス性の面で言うと、Adobe提供CMapもちょくちょく改訂されていくので、一度作っておしまいには出来ないでしょうし、追従しやすい仕組みで作っておかないと更新遅れや追従不能のリスクが心配です。 [...] 漢字の字形の差し替えだけなら、UniJISup-UTF16-{H,V} → UniJIS2004up-UTF16-{H,V} を変換するperl scriptでも作りましょうかね。

perl script があると確かに便利ですね。もし可能ならばどちらかといえば

UniJIS-UTF16-{H,V} → UniJISup-UTF16-{H,V}
UniJIS2004-UTF16-{H,V} → UniJIS2004up-UTF16-{H,V}

を変換できる方が，追従しやすいのではないかと思います。

t-tk commented 7 years ago

Adobe提供の UniJIS2004- と UniJISX02132004- は、多くの記号がプロポーショナルのグリフに対応づけられており、upTeX では嬉しくないです。そこで、 UniJIS2004up-UTF16- は UniJIS2004-UTF16- をベースにしたものではなく、

「UniJIS2004up-UTF16- は UniJIS-UTF16- をベースに、UniJISup-UTF16-* と同様の変更をしてさらに漢字を2004字形に差し替えたもの」

とするのがベストかと思います。名前は混乱を招きそうですが、対案が思いうかびません。生成方法は考えてみます。

「クオートだけ別のフォントに割り当てる」という裏技

こういう裏技は、*-V でも需要がありますかね? あまりややこしい実装を増やしたくはありませんが…

zr-tex8r commented 7 years ago

Adobe提供の UniJIS2004- と UniJISX02132004- は、多くの記号がプロポーショナルのグリフに対応づけられており、upTeX では嬉しくないです。

「多くの記号がプロポーショナルのグリフ」なのは“X0213”の特徴であって、“2004”と非“2004”の違いは漢字のグリフだけ、のはずですよ。（cid2code.txt の最後のNOTEを参照。）

doraTeX commented 7 years ago

UniJISup-* が開発中ということで，一つご提案を。

私の記憶によると、まだまだ、「＝≒≠≡」や矢印の方向、度・分・秒でもナントカVとカントカVで差がある、とか色々あったと思います。正直、きりがなく調査をする気さえ失せます。

私も矢印類の網羅的調査をしたわけではありませんが，UniJIS-UTF16-V を使った場合，

左←↑↓→☜☝☟☞⇦⇧⇩⇨⬅⬆⬇➡右

\mbox{\tate 上←↑↓→☜☝☟☞⇦⇧⇩⇨⬅⬆⬇➡下}

のコンパイル結果が

となります。⬅︎⬆︎⬇︎だけ回転がかからず，その結果⬇︎と➡︎の出力がともに⬇︎となり，縦書きで➡︎を出力する方法がなくなっています。

これはどう見ても不合理な挙動だと思いますので，他の矢印類に合わせて，⬅︎⬆︎⬇︎も回転すべく，UniJISup-* には

<2b05> 8208
<2b06> 8206
<2b07> 8207

を含めるとよいのではないでしょうか。

aminophen commented 7 years ago

となります。⬅︎⬆︎⬇︎だけ回転がかからず，その結果⬇︎と➡︎の出力がともに⬇︎となり，縦書きで➡︎を出力する方法がなくなっています。これはどう見ても不合理な挙動だと思いますので，

これは不合理という意見に同意です。

UniJISup-* でどうするかというよりも，Adobe にプルリクエストして直せる可能性はあるでしょうか？もしありそうなら，どういうレポートの仕方がよいでしょう？「dvipdfmx でうまく出ない」という内容の issue を立てるわけにもいかないと思いますし…

doraTeX commented 7 years ago

UniJISup-* でどうするかというよりも，Adobe にプルリクエストして直せる可能性はあるでしょうか？

確かに，本家の側でこの不合理を直してもらうのが本来の筋ではあるでしょうね。

もしありそうなら，どういうレポートの仕方がよいでしょう？「dvipdfmx でうまく出ない」という内容の issue を立てるわけにもいかないと思いますし…

「Acrobat Distiller の不具合」という体でレポートするという手はいかがでしょう。 upLaTeX + dvips で作ったPSファイルを Disiller で処理すると，UniJIS-UTF16-V に従う結果，やはり矢印の向きがおかしなPDFが生成されます。

（自分の持っている Acrobat 9 Pro for Mac の環境ですと） /Applications/Adobe Acrobat 9 Pro/Acrobat Distiller.app/Contents/MacOS/Data/psdisk/Resource/CMap/UniJIS-UTF16-V の中身に

3 begincidchar
<2b05> 8208
<2b06> 8206
<2b07> 8207
endcidchar

を書き加えてから Distiller で処理すると，矢印が意図通りのPDFが生成されるようになりました。

aminophen commented 7 years ago

なるほど Distiller なら妥当ですね。レポート先は

https://github.com/adobe-type-tools/cmap-resources

だと思うのですが，お願いできますか？ > @doraTeX

doraTeX commented 7 years ago

了解です。Issueを立てておきました。

t-tk commented 7 years ago

謎だらけです。 UnicodeのU+27A1(➡ BLACK RIGHTWARDS ARROW) と U+2B95 (⮕ RIGHTWARDS BLACK ARROW)は何が違うんでしょうか? 日本語向けのフォントで U+2B95 を U+2B05 (⬅ LEFTWARDS BLACK ARROW), U+2B06 (⬆ UPWARDS BLACK ARROW), U+2B07 (⬇ DOWNWARDS BLACK ARROW)と同様のデザインで実装している例はどの程度存在するのでしょう? U+2B95は、*up-UTF16-{H,V}では無視してもよいのでしょうか?

t-tk commented 7 years ago

cmap-customize ブランチを更新しました。

「多くの記号がプロポーショナルのグリフ」なのは“X0213”の特徴であって、“2004”と非“2004”の違いは漢字のグリフだけ、のはずですよ。（cid2code.txt の最後のNOTEを参照。）

ご指摘ありがとうございます。 UniJIS2004-UTF16-{H,V} をベースに UniJIS2004up-UTF16-{H,V} を作ってみました。 BLACK ARROWは、とりあえず U+2B95 を無視して、*-V では、U+2B05..2B07の3個を回転させるようにしてみました。

t-tk commented 7 years ago

日本語向けのフォントで U+2B95 を U+2B05 (⬅ LEFTWARDS BLACK ARROW), U+2B06 (⬆ UPWARDS BLACK ARROW), U+2B07 (⬇ DOWNWARDS BLACK ARROW)と同様のデザインで実装している例はどの程度存在するのでしょう?

ざっと調べてみたところ (ひょっとしたらfallbackにより別のものを取り違えている虞があります)

源ノ明朝は、U+27A1, U+2B05..2B07, U+2B95 が全てそっくりのデザイン。しかしこれは、例外的
游明朝は、U+27A1, U+2B05..2B07が揃っているが、U+2B95は別
IPAex明朝は、U+27A1, U+2B95は別, U+2B05..2B07はグリフが無い
Meiryo UIは、U+2B05..2B07が揃っているが、U+27A1, U+2B95はそれぞれ別
ＭＳ明朝は、U+2B05..2B07が揃っているが、U+27A1, U+2B95はそれぞれ別

U+27A1, U+2B05..2B0の4個のデザインが揃っているのでさえ例外的な印象を受けました。 U+2B95 は無視する方針にしたいと思います。

zr-tex8r commented 7 years ago

こんなのが見つかりました。

Proposal to add U+2B95 Rightwards Black Arrow to Unicode Emoji

これ自体はEmoji属性に関する提案ですが、その中で➡や⮕の来歴に関する話が載っています。

zr-tex8r commented 7 years ago

フォールバックが紛らわしいので、XeTeXで出力してみました。
（27A1 / 2B95 / 2B05 2B06 2B07）

image-allearrow-1

t-tk commented 7 years ago

Proposal to add U+2B95 Rightwards Black Arrow to Unicode Emoji

ドキュメントのご紹介とXeTeXの出力、ありがとうございます。なかなかの迷走ぶりです。そんなことなら最初から4個揃えて入れておけば良かったのに。 U+2B95が振られたのがUnicode 7.0 ということは2014年6月のことになるので、それ以前のフォントでグリフが無いのは当然です。 Unicode 7.0以降ではU+2B05..2B07とともにU+2B95が "sibling" だということなので、UniJIS*up-UTF16-{H,V} ではU+2B95を入れる方向で考えてみます。

t-tk commented 7 years ago

cmap-customize ブランチを更新しました。 U+2B95の縦組みとして回転させたCID8209を指定しました。手元の動作確認では、想定通りに上手く動います。

UniJIS-UTF16-{H,V}では、U+2196 (↖ NORTH WEST ARROW), U+2197 (↗ NORTH EAST ARROW), U+2198 (↘ SOUTH EAST ARROW), U+2199 (↙ SOUTH WEST ARROW)は横組でCID12204, CID12205, CID12202, CID12203に割り当てられていて、縦組みではそのままになっています。その他にもまだまだあるような気がします。これ以上ヤル気のある方はいらっしゃいますか?

私としては、ここまでの追加・修正を master にマージして本件をクローズしたいと思っています。なお、uptex-baseの方に入っている misc-check-h-utf8.tex, misc-check-v-utf8.tex も追加・修正する予定です。

aminophen commented 7 years ago

いろいろとありがとうございました。最近 (u)pLaTeX の方に力を入れているため，追いきれていませんでした。今少し動かした簡単なテストでは Adobe の UniJIS-UTF16-{H,V} よりも自然な挙動に思えました。

書いているうちに新しいコメントが入っていました。ここまでのマージ・クローズで賛成です。

t-tk commented 7 years ago

cmap-customize ブランチを master にマージしました。ここは Close しますが、不具合や改善意見などございましたら再開するなり Issue を立てるなりお願いします。

doraTeX commented 7 years ago

遅くなりましたが，皆様ご尽力ありがとうございました！

texjporg / uptex-fonts

upjisr-v のコロン #5