upjisr-v のコロン

[aminophen]

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

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

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

[t-tk]

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

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

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

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

[aminophen]

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

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

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

[t-tk]

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]

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

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

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

• https://twitter.com/aminophen/status/888419482414194689
• https://twitter.com/aminophen/status/888420742106300416

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

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

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

[zr-tex8r]

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

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

[aminophen]

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

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

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

[t-tk]

この文章ではコロンに絞ります。
「単純に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]

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

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

[zr-tex8r]

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]

参考資料

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

[zr-tex8r]

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

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

[t-tk]

グリフの表ありがとうございます。コード表だけを見るのよりもはるかに実感が沸きます。
そうすると、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]

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

[aminophen]

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

[t-tk]

簡単なテストをしたところ、手元では 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]

縦組み字形は伏魔殿というのが率直な印象です。
世の中の各種規格や実装で迷走してるのが現実なので、どこかで線を引いてその先はユーザー各位の選択に任せるような形でクローズしたいです。
私の記憶によると、まだまだ、「＝≒≠≡」や矢印の方向、度・分・秒でもナントカ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]

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

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

に同意です。

• UniJIS-UTF16-V を選択すれば、Adobe標準CMapの範囲で処理される
• UniJISup-UTF16-V を選択すれば、JIS X 0213で例示されている縦組み字形を含めて処理される

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

[aminophen]

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

[t-tk]

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]

下記現状を踏まえると、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]

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

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

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

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

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

[zr-tex8r]

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

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

[doraTeX]

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

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

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

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

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

のコンパイル結果が

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

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

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

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

[aminophen]

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

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

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

[doraTeX]

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]

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

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

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

[doraTeX]

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

[t-tk]

謎だらけです。
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]

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]

日本語向けのフォントで 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]

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

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

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

[zr-tex8r]

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

[t-tk]

• 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]

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]

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

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

[t-tk]

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

[doraTeX]

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