新元号対応, Adobe-Japan1-7 #13

t-tk · 2018-12-08T03:51:34Z

新元号対応についてです。
元号の組文字が Unicode と Adobe-Japan1-7 で追加されることが決まっているそうです。
新元号は2019年4月には発表されるそうなので、TeX Live 2019にぎりぎり間に合うタイミングでしょう。
ブランチ new-era を作っておきます。
sty/ajmacros.sty にも追加したいところですが、新元号の発表待ちです。

元号	Unicode	H	V
明治	U+337E (㍾)	7621 (AJ1-0)	12041( AJ1-4)
大正	U+337D (㍽)	7622 (AJ1-0)	12042 (AJ1-4)
昭和	U+337C (㍼)	7623 (AJ1-0)	12043 (AJ1-4)
平成	U+337B (㍻)	8323 (AJ1-1)	12044 (AJ1-4)
令和	U+32FF (㋿)	23058 (AJ1-7)	23059 (AJ1-7)

| 元号 | Unicode | H | V | |------|-----|-----|-----| | 明治 | U+337E | 7621 (AJ1-0) | 12041( AJ1-4) | | 大正 | U+337D | 7622 (AJ1-0) | 12042 (AJ1-4) | | 昭和 | U+337C | 7623 (AJ1-0) | 12043 (AJ1-4) | | 平成 | U+337B | 8323 (AJ1-1) | 12044 (AJ1-4) | | ??? | U+32FF | 23058 (AJ1-7) | 23059 (AJ1-7) |

aminophen · 2018-12-08T08:30:04Z

そういえば，dvipdfmx などが使うはずの Adobe CMap resources の最新版は TeX Live にまだ降りてきていないようです。今までどなたが CTAN に上げてくださっていたのでしょうか？

＃ Adobe-Japan1-7 に対応した CMap がないと，japanese-otf(-uptex) も正常動作しないのではないでしょうか。また，Adobe-KR9 (#11) の件も同様かと。

t-tk · 2018-12-08T09:07:31Z

Master/texmf-dist にあるものは
CTAN の adobemapping から来ているようです。
Maintainer は Adobe Systems Incorporated になっています。
誰に頼めばよいのでしょうかね。

aminophen · 2018-12-10T03:45:52Z

CTAN の README は Karl さんが作ったもののようですから，最初に問い合わせるなら Karl さんでしょうか。時間が出来たら CMap の変更点を読んで，必要そうならリクエストしてみます。

t-tk · 2018-12-13T12:36:59Z

CMapの変更点は勿論公式のドキュメントでご確認いただけると確実ですが、
簡単に言うとAdobe-Japan1-7 の追加分は新元号の組文字のグリフ2個(23058, 23059), Unicodeではコードポイント1個(U+32FF)のみです。
新元号の組文字を使うときだけ必要になると言えます。
Adobe-KR9はAdobe-Korea1-2 と全く別物です。Adobe-KR9のCIDを実装したフォントを使う場合には必要になるでしょう。

Karlさんへ問い合わせていただけるとのこと、ありがとうございます。

aminophen · 2018-12-13T12:43:23Z

ちょうど昨日 mapping-resources-pdf も更新されたようです。これでモノは揃った？？

t-tk · 2018-12-13T12:46:50Z

ついさっき知ったのですが、Adobe-Japan1-8 の候補が検討されているそうです。
いつ出るのかも分かりませんが、出たら対応を考えます。

aminophen · 2018-12-14T11:59:00Z

先ほど Karl さんに問い合わせメールを送りました。 > adobemapping

aminophen · 2018-12-16T01:19:34Z

adobemapping の CTAN upload 担当を Karl さんから引き継ぎました。

https://github.com/aminophen/ctan-adobemapping

この内容で今夜にでも upload するつもりです。

aminophen · 2019-01-09T12:44:19Z

https://tug.org/pipermail/tlbuild/2019q1/004310.html

22feb: sources committed, builds begin.
1mar: tlnet (and TL'18) frozen, tlpretest starts, CTAN updates continue there.
22mar: code freeze for final build, major bug fixes only.
5apr: final updates from CTAN, final doc tweaks.
12apr: deliver TL image for TeX Collection packaging/testing.
19apr: deliver TeX Collection DVD image for manufacturing.
30apr: public release (also of MacTeX).

4/1 新元号発表，4/5 が CTAN からの最終インポートなので，忙しいですがなんとか間に合いますね。（もちろん，「3/22 時点のソースから出来るバイナリが正常に作動する」という前提ですが。）

何かうまい事前テスト方法はありますでしょうか。既に Adobe のリソースは TeX Live に収録されているので，適当なフォントさえあれば準備できるかもしれません。（例えば
https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=unicodebmpfallbackfont
のようなフォールバックフォントがあると良いかも？）

仮に新しい元号が江戸だったとして \ajLig{江戸} を U+32FF に飛ばせるか（実装の練習も兼ねて）
\UTF{32FF} や \CID{23058} が U+32FF になるか
ToUnicode 情報が正しく埋め込まれるか
（OpenType と TrueType で仕組みが違うので，両方試した方が良いはず）

t-tk · 2019-01-13T08:45:17Z

新元号合字のU+32FFは Unocode blocksでは
"3200..32FF; Enclosed CJK Letters and Months"に含まれているので
Unicode 1.1.0 の頃からあるはずで、
ご紹介頂いたフォールバックフォント(Unicode 6.1)でテスト出来そうですね。

やろうとしていることは、実装としては「平成」の合字と同じことなので
単純ミスさえ無いことが確認できれば綿密なテストまでしなくても大丈夫に思います。

それから、一つ気にしているのは
原作者の齋藤さんがメンテナンスしている部分にあたるので
コミュニティの我々がパッチのご提案をするとしても
新版としてリリースするところは齋藤さんにお願いしたいと思います。

ついでに #8 のtypoの一箇所 (redeffont.sty)
11bb84a
も対応できればよいと思います。

t-tk · 2019-02-07T09:14:25Z

ご紹介いただいたSILのフォールバックフォント(Unicode 6.1) を試してみたところ、未定義のコードポイントは載せない方針のようで、U+32FF のグリフはありませんでした。
代わりに GNU Unifont というものを見つけました。
ここの unifont-11.0.03.ttf には U+32FFにコード値が書かれたグリフが入っていました。
Unicode経由の場合のテストはこれで出来そうです。

t-tk · 2019-02-09T15:07:44Z

色々テストしていますが思ったより難しいです。
japanese-otf-uptex/test/uplatex/era.tex のようなサンプルで試していますが
それらしい結果はまだ得られていません。

otfパッケージ側では正しいことをしていると思うのですが、
dvipdfmx のソースに拡張が必要なのか、設定書き換えだけでいけるのか分かっていません。

kanjix.map の otf-cjmr-h Identity-H ipaexm.ttf/AJ16 %!PS IPAexMincho のような書式で AJ17 は対応済み?
dvipdfm-x のソースの data/glyphlist.txtの中に heiseierasquare;337B のような行があるが、これにも新元号対応が必要なのか?

dviware に改造が必要となると、あまり時間はありませんね…

aminophen · 2019-02-10T01:50:33Z

japanese-otf-uptex/test/uplatex/era.tex のようなサンプルで試していますが
それらしい結果はまだ得られていません。

master → new-era (b5b1d5b) で変化したバイナリは OFM と VF ですが，plain text で可視化しなおすと，VF は多分まだ意図通りにはなっていないようです。

OFM ファイル群

japanese-otf/ofm/otf-cjgb-h.ofm
japanese-otf/ofm/otf-cjgb-v.ofm
japanese-otf/ofm/otf-cjge-h.ofm
japanese-otf/ofm/otf-cjge-v.ofm
japanese-otf/ofm/otf-cjgr-h.ofm
japanese-otf/ofm/otf-cjgr-v.ofm
japanese-otf/ofm/otf-cjmb-h.ofm
japanese-otf/ofm/otf-cjmb-v.ofm
japanese-otf/ofm/otf-cjmgr-h.ofm
japanese-otf/ofm/otf-cjmgr-v.ofm
japanese-otf/ofm/otf-cjml-h.ofm
japanese-otf/ofm/otf-cjml-v.ofm
japanese-otf/ofm/otf-cjmr-h.ofm
japanese-otf/ofm/otf-cjmr-v.ofm

これらすべてに以下の行が追加された。

横の場合：

(CHARACTER D 23058
   (CHARWD R 1.000000)
   (CHARHT R 0.880000)
   (CHARDP R 0.120000)
   )
(CHARACTER D 23059
   (CHARWD R 1.000000)
   (CHARHT R 0.880000)
   (CHARDP R 0.120000)
   )

縦の場合：

(CHARACTER D 23058
   (CHARWD R 1.000000)
   (CHARHT R 0.500000)
   (CHARDP R 0.500000)
   )
(CHARACTER D 23059
   (CHARWD R 1.000000)
   (CHARHT R 0.500000)
   (CHARDP R 0.500000)
   )

VF ファイル群

japanese-otf/vf/cidjgb0-h.vf
japanese-otf/vf/cidjgb0-v.vf
japanese-otf/vf/cidjgb1-h.vf
japanese-otf/vf/cidjgb1-v.vf
japanese-otf/vf/cidjgb2-h.vf
japanese-otf/vf/cidjgb2-v.vf
japanese-otf/vf/cidjgb3-h.vf
japanese-otf/vf/cidjgb3-v.vf
japanese-otf/vf/cidjgb4-h.vf
japanese-otf/vf/cidjgb4-v.vf
japanese-otf/vf/cidjgb5-h.vf
japanese-otf/vf/cidjgb5-v.vf
japanese-otf/vf/cidjge0-h.vf
japanese-otf/vf/cidjge0-v.vf
japanese-otf/vf/cidjge1-h.vf
japanese-otf/vf/cidjge1-v.vf
japanese-otf/vf/cidjge2-h.vf
japanese-otf/vf/cidjge2-v.vf
japanese-otf/vf/cidjge3-h.vf
japanese-otf/vf/cidjge3-v.vf
japanese-otf/vf/cidjge4-h.vf
japanese-otf/vf/cidjge4-v.vf
japanese-otf/vf/cidjge5-h.vf
japanese-otf/vf/cidjge5-v.vf
japanese-otf/vf/cidjgr0-h.vf
japanese-otf/vf/cidjgr0-v.vf
japanese-otf/vf/cidjgr1-h.vf
japanese-otf/vf/cidjgr1-v.vf
japanese-otf/vf/cidjgr2-h.vf
japanese-otf/vf/cidjgr2-v.vf
japanese-otf/vf/cidjgr3-h.vf
japanese-otf/vf/cidjgr3-v.vf
japanese-otf/vf/cidjgr4-h.vf
japanese-otf/vf/cidjgr4-v.vf
japanese-otf/vf/cidjgr5-h.vf
japanese-otf/vf/cidjgr5-v.vf
japanese-otf/vf/cidjmb0-h.vf
japanese-otf/vf/cidjmb0-v.vf
japanese-otf/vf/cidjmb1-h.vf
japanese-otf/vf/cidjmb1-v.vf
japanese-otf/vf/cidjmb2-h.vf
japanese-otf/vf/cidjmb2-v.vf
japanese-otf/vf/cidjmb3-h.vf
japanese-otf/vf/cidjmb3-v.vf
japanese-otf/vf/cidjmb4-h.vf
japanese-otf/vf/cidjmb4-v.vf
japanese-otf/vf/cidjmb5-h.vf
japanese-otf/vf/cidjmb5-v.vf
japanese-otf/vf/cidjmgr0-h.vf
japanese-otf/vf/cidjmgr0-v.vf
japanese-otf/vf/cidjmgr1-h.vf
japanese-otf/vf/cidjmgr1-v.vf
japanese-otf/vf/cidjmgr2-h.vf
japanese-otf/vf/cidjmgr2-v.vf
japanese-otf/vf/cidjmgr3-h.vf
japanese-otf/vf/cidjmgr3-v.vf
japanese-otf/vf/cidjmgr4-h.vf
japanese-otf/vf/cidjmgr4-v.vf
japanese-otf/vf/cidjmgr5-h.vf
japanese-otf/vf/cidjmgr5-v.vf
japanese-otf/vf/cidjml0-h.vf
japanese-otf/vf/cidjml0-v.vf
japanese-otf/vf/cidjml1-h.vf
japanese-otf/vf/cidjml1-v.vf
japanese-otf/vf/cidjml2-h.vf
japanese-otf/vf/cidjml2-v.vf
japanese-otf/vf/cidjml3-h.vf
japanese-otf/vf/cidjml3-v.vf
japanese-otf/vf/cidjml4-h.vf
japanese-otf/vf/cidjml4-v.vf
japanese-otf/vf/cidjml5-h.vf
japanese-otf/vf/cidjml5-v.vf
japanese-otf/vf/cidjmr0-h.vf
japanese-otf/vf/cidjmr0-v.vf
japanese-otf/vf/cidjmr1-h.vf
japanese-otf/vf/cidjmr1-v.vf
japanese-otf/vf/cidjmr2-h.vf
japanese-otf/vf/cidjmr2-v.vf
japanese-otf/vf/cidjmr3-h.vf
japanese-otf/vf/cidjmr3-v.vf
japanese-otf/vf/cidjmr4-h.vf
japanese-otf/vf/cidjmr4-v.vf
japanese-otf/vf/cidjmr5-h.vf
japanese-otf/vf/cidjmr5-v.vf

これらすべてに入った変更はヘッダ行のみ。

-(VTITLE JVF for Adobe-Japan1-6)
+(VTITLE JVF for Adobe-Japan1-7)

aminophen · 2019-02-10T02:29:46Z

plain text で可視化しなおすと，VF は多分まだ意図通りにはなっていないようです。

すみません，誤解だったようで，「元々 VF は CID 23058〜23059 も含んでいたから変化しなかった」ということのようです。例えば cidjmr5-h.vf を見てみると

(CHARACTER H 5842
   (CHARWD R 1.000000)
   (MAP
      (SETCHAR H 5A12)
      )
   )

が最初から入っていて，0x5A12 = CID 23058 なので。そうすると，よくわからなくなってきました。

aminophen · 2019-02-10T03:29:07Z

私のところでは④をテストするにあたり

uphminr-h UniJIS-UTF16-H unifont-11.0.03.ttf
uphminr-v UniJIS-UTF16-V unifont-11.0.03.ttf
otf-ujmr-h UniJIS-UTF16-H unifont-11.0.03.ttf
otf-ujmr-v UniJIS-UTF16-V unifont-11.0.03.ttf
otf-cjmr-h Identity-H unifont-11.0.03.ttf/AJ16
otf-cjmr-v Identity-V unifont-11.0.03.ttf/AJ16

という otfunifont.map を作って dvipdfmx -f otfunifont.map era.dvi としています。できた PDF はこれで，見た目は想定内のものでした（non-CID フォントなので，縦組字形が切り替わらないのは IPAex フォントの明治〜平成でも同様なので気にしない）。

なお，dvipdfmx 実行中に

dvipdfmx:warning: TrueType post table name index 32768 > 32767

dvipdfmx:warning: GSUB feature vrt2/vert not found.

の警告が出ました。後者は「縦書き字形がない」ということなのだと思います。前者はよくわかりませんが，ソースを見た感じでは害はないようです。

うまくいっていないのは ToUnicode でした。ただし，PDF ビューア（Adobe Acrobat DC）の問題かもしれないので気にしなくてもいいのかもしれません。

kanjix.map の otf-cjmr-h Identity-H ipaexm.ttf/AJ16 %!PS IPAexMincho のような書式で AJ17 は対応済み?

これは上記の map で通っていますし，できた PDF を見ると

  /BaseFont /YNBFFM+UnifontMedium
  /CIDSystemInfo <<
    /Ordering (Japan1)
    /Registry (Adobe)
    /Supplement 7
  >>

というエントリがあるので，問題なさそうです。

dvipdfm-x のソースの data/glyphlist.txtの中に heiseierasquare;337B のような行があるが、これにも新元号対応が必要なのか?

多分これは Adobe の glyphlist.txt だと思います。これは新元号が公表されないとグリフ名が決まらないはずですし，公表され次第 Adobe の方で glyphlist.txt を更新してくださると期待しておけばいいと思います。（もしかして，ToUnicode が効かないのはこれがまだだから？）

t-tk · 2019-02-10T05:11:11Z

検証ありがとうございます。こちらの手元でも、想定通りの結果を得ることが出来ました。
想定通りとは、unifont-11.0.03.ttf を指定し "32FF" のグリフをpdfに埋め込むことに \ajLig, \UTF,\CID, UTF-8, \kchar ともに成功するところまでです。

うまく行かなかったケースは、dvipdfmx のバージョンが古かった場合です。
NG: dvipdfmx Version 20170318
OK: TeX Live svn の最新をコンパイルしたもの

vf (7書体 x 2方向 x 6サブフォント, cidj*[0-5]-{h,v}.vf)は、ご指摘の通り、コメント部分の更新のみです。もともと CID:23058..23059 に対応していました。\UTFで使われる方も以前から U+32FF に対応していました。
ofm(7書体 x 2方向, otf-cj*-{h,v}.ofm)は、今回の更新で内容に変動があります。

dvipdfmxのwaring はこちらも同様に再現しています。
おそらく、正規のフォントになれば消えるものだと思っています。
kanjix.map の記述で AJ16 と AJ17 の間には特に差が生じていないように見えます。

Adobe の glyphlist.txt

永いこと更新がされていないようですが、その果たす役割が分かっていません。

dviware に拡張が必要でないならば、そろそろ齋藤さんに相談しましょうか。

t-tk · 2019-02-10T05:41:39Z

（OpenType と TrueType で仕組みが違うので，両方試した方が良いはず）

適当なテスト用の OpenType があると良いのですが。
まあ、おそらく大丈夫だとは思いますが。

psitau · 2019-03-30T15:25:05Z

フォントがないのでテストできないですが，新元号に対応したOTFパッケージを4/1に公開できるように作業しております．
直前のご連絡となり，申し訳ございません．

t-tk · 2019-03-31T11:49:26Z

@psitau さん有難うございます。
上記のように私も OpenType ではテストできていませんが、おそらく大丈夫と思っています。

t-tk · 2019-04-02T14:35:24Z

@psitau さんリリース有難うございました。
上流でリリースされたソースの取り込み、ここの README の修正、vfの生成などの作業を行い、CTANへ投稿しました。
ここも 2019-04-02 のタグを打って nonfree のアーカイブを置きました。
https://github.com/texjporg/japanese-otf-mirror/releases/tag/2019-04-02

@norbusan さん、
TLContrib にnonfreeのインストールをお願いできますか?

明日から旅行に出るため CTAN のトラブルがあったらどなたかフォローしていただけると助かります。

norbusan · 2019-04-02T14:45:31Z

@t-tk 田中先生、更新しました。よろしくお願いいたします。

norbusan · 2019-04-02T14:48:03Z

@munepi texjpのtlcontribは、僕は更新しないといけませんか？自動になりますか？

t-tk · 2019-04-14T13:09:51Z

AJ1-7なOpenType として @trueroad さんの原ノ味ゴシック 20190413でテストしました。@trueroad さん、有難うございます。
期待通りのpdf出力結果を得ることが出来ました。縦組みグリフもちゃんと出ました。以前出ていた dvipdfmx の警告も消えました。
kanjix.map は試しに以下のようにしました。

otf-cjmr-h      Identity-H      HaranoAjiGothic-Regular.otf
otf-cjmr-v      Identity-V      HaranoAjiGothic-Regular.otf
otf-ujmr-h	UniJISup-UTF16-H	HaranoAjiGothic-Regular.otf
otf-ujmr-v	UniJISup-UTF16-V	HaranoAjiGothic-Regular.otf
uphminr-h	UniJISup-UTF16-H	HaranoAjiGothic-Regular.otf
uphminr-v	UniJISup-UTF16-V	HaranoAjiGothic-Regular.otf

ただし、evinceで pdf の該当文字列をコピー&ペーストしようとすると「㍾」「㍽」「㍼」「㍻」はペースト先で「明治」「大正」「昭和」「平成」となるのに対し令和の合字「㋿」は選択できずコピーも出来ません。

japanese-otf 側の問題で無いことは確かですが、前に述べられていた adobe の glyphlist.txt の問題でしょうか。
そこにお願いすればよい?

aminophen · 2019-04-14T13:46:04Z

ToUnicode の問題をすっかり忘れていました…。いま出先にいて数日は戻れないので，とりあえず知っている範囲でコメントしておきます。

前に述べられていた adobe の glyphlist.txt の問題でしょうか。そこにお願いすればよい？

dvipdfmx のマニュアルに以下の記述がありますから，“多分そうだろう”と思っています。（すみません，実際の挙動調査はしていません。）

\dvipdfmx\ looks for the file \code{glyphlist.txt} when conversion from
PostScript glyph names to Unicode sequences is necessary.
This conversion is done in various situations; when creating ToUnicode CMaps
for 8-bit encoding fonts, finding glyph descriptions from TrueType and OpenType
fonts when the font itself does not provide a mapping from PostScript glyph
names to glyph indices (version 2.0 ``post'' table), and when the encoding
\code{unicode} is specified for Type1 font.

もし glyphlist.txt の問題だけであれば，このファイルは dvipdfmx バイナリに組み込まれるものではなく実行時に探されますから，リビルドは不要とみて良さそうです。

それにしても，glyphlist.txt に記述する PostScript glyph name は誰かが正式に決めるのだと思いますが，それは誰なんでしょう。Unicode の中の人？ Adobe？

trueroad · 2019-04-14T14:25:21Z

原ノ味フォントがお役に立ててなによりです。

ToUnicode ですが、私の理解では AJ1 の場合は dvipdfmx は ToUnicode CMap を生成せず
PDF に入っていない状態となり、PDF viewer 側が内蔵している Adobe-Japan1-UCS2 を使って
AJ1 CID → Unicode 変換して取り出すもの、と認識しています。

なので、 PDF viewer の持っている Adobe-Japan1-UCS2 を AJ1-7 のものに更新すれば
コピペできるようになるのでは？と思います。

確かめたわけではありませんし、外していたら申し訳ありません。

t-tk · 2019-04-14T14:41:23Z

コメントありがとうございます。

それにしても，glyphlist.txt に記述する PostScript glyph name は誰かが正式に決めるのだと思いますが，それは誰なんでしょう。Unicode の中の人？ Adobe？

https://github.com/adobe-type-tools/agl-aglfn の README.md に

AGL (Adobe Glyph List) simply provides mappings from glyph names to Unicode scalar values.

のようにAdobeとあるし PostScript も Adobe の私的規格のはずですから、きっと決めているのは Adobeでしょうね。

PDF viewer の持っている Adobe-Japan1-UCS2

うーーん。そうすると evince のソースを見に行かないといけないか。
Adobe Readerの対応状況も要調査です。

trueroad · 2019-04-16T13:33:16Z

うーーん。そうすると evince のソースを見に行かないといけないか。

evinceはpopplerをバックエンドに使っている、ということをどこかで見たので
poppler を見てみたところ、
https://gitlab.freedesktop.org/poppler/poppler-data/blob/master/cidToUnicode/Adobe-Japan1
という AJ1 CID → Unicode の独自？テーブルを持っているみたいですね。
最終更新は 1 年ぐらい前ですし、32ff がありませんので AJ1-7 未対応ではないかと思います。

Adobe Readerの対応状況も要調査です。

手元の環境は TeX Live 2018 のため pTeX で扱えなかったため XeTeX で
https://github.com/trueroad/HaranoAjiFonts-generator/blob/32f1022d951bb473793254398c916283772506ec/tex/test-aj17.xetex.tex
テスト用 PDF を作り、Adobe Acrobat Reader でコピーしてみたところ
U+32FF も正しく動作するようです。

Adobe Acrobat Reader のフォルダ内の Adobe-Japan1-UCS2 は AJ1-7 対応したものになっていました。
どこかのアップデートで更新されたものと思います。

aminophen · 2019-04-16T22:44:16Z

手元の環境は TeX Live 2018 のため pTeX で扱えなかったため XeTeX で
テスト用 PDF を作り、Adobe Acrobat Reader でコピーしてみたところ
U+32FF も正しく動作するようです。

XeTeX を使った場合は，ToUnicode が xdvipdfmx によって PDF に埋め込まれるので，PDF viewer の能力あるいはそれが内蔵する CMap などの変換テーブルの対応状況とは違うかもしれません。ただ，

Adobe Acrobat Reader のフォルダ内の Adobe-Japan1-UCS2 は AJ1-7 対応したものになっていました。どこかのアップデートで更新されたものと思います。

であれば，今は pTeX でも大丈夫な可能性はありますね。週末に出先から帰ったら試してみます。

aminophen · 2019-04-16T22:48:39Z

手元の環境は TeX Live 2018 のため pTeX で扱えなかったため

ちなみに TL2018 の pTeX / dvipdfmx のバイナリのままでも，CMap たちは TL2018 frozen の時点で AJ1-7 対応なので，OTF パッケージさえ更新すれば TL2018 で実験できそうに思います。

trueroad · 2019-04-17T11:58:35Z

XeTeX を使った場合は，ToUnicode が xdvipdfmx によって PDF に埋め込まれるので，PDF viewer の能力あるいはそれが内蔵する CMap などの変換テーブルの対応状況とは違うかもしれません。ただ，

いえ、 XeTeX （というか xdvipdfmx）は AJ1 なら ToUnicode CMap の生成をせず PDF に埋め込まれません。ソースを見ると、AJ1 を含むいくつかの ROS では生成せず埋め込まないという動作になっているようです。実際に上記 XeTeX 用テストの \special のコメントを外して無圧縮にした PDF を生成して確認したところ、やはり ToUnicode CMap は入っていませんでした。

なので、恐らく pTeX + dvipdfmx と条件は同じだと思います。

で、 PDF viewer 側ですが evince と同条件であろう poppler だとどうなるだろうと思い poppler 付属の pdftotext を試してみました。案の定、縦横とも U+32FF が出ず Adobe Acrobat Reader とは全く違う結果になりました。

さらに試しに、 poppler 付属の Adobe-Japan1 ファイルの行数を計ったら Adobe-Japan1-6 の CID 数と同じだったので、

# cd /usr/share/poppler/cidToUnicode

# wc -l Adobe-Japan1
23058 Adobe-Japan1

# echo "32ff" >> Adobe-Japan1

# echo "32ff" >> Adobe-Japan1

# wc -l Adobe-Japan1
23060 Adobe-Japan1

#

みたいなことをしてから再度 pdftotext を掛けてみたところ、縦書き横書きともに U+32FF が出るようになりました。

ただ、 poppler のこの AJ1 CID → Unicode 変換テーブルは、Adobe のものとフォーマットが違うだけではなく変換内容も違うみたいで、特に縦書きの扱いがかなり異なるように見えます。。。

かなり本題と外れてしまってきていて申し訳ないのですが、蛇足ついでに LuaTeX も試してみました。

LuaTeX は AJ1 か否かなどお構いなしに必ず ToUnicode CMap を生成して埋め込むみたいです。上記 XeTeX 用テストと同様の LuaTeX 用テスト
https://github.com/trueroad/HaranoAjiFonts-generator/blob/f99c4df2f0d8f50ed90395cb6432c2ab66da4e63/tex/test-aj17.luatex.tex
で \pdfvariable のコメントを外し無圧縮 PDF を生成して確認すると ToUnicode CMap が入っていました。

Adobe Acrobat Reader からコピペすると XeTeX の時とは文字列が異なります。横書きは XeTeX と同じ結果で U+32FF が出ますが、縦書きは出てきません。

LuaTeX の ToUnicode CMap 生成が OpenType feature を考慮していないから、と思います。 XeTeX でも AI0 なら ToUnicode CMap を生成して埋め込むので LuaTeX と同様の結果になると思います。

pdftotext だと Adobe Acrobat Reader 同様の横のみ U+32FF が出る結果となりました。 poppler 付属の Adobe-Japan1 ファイルの追記をしてもしなくても同じ結果です。 PDF に埋め込まれている ToUnicode CMap を優先して使い、 PDF viewer が持っているテーブルを使わないから、だと思います。

munepi · 2019-04-17T12:48:24Z

@norbusan >

@munepi texjpのtlcontribは、僕は更新しないといけませんか？自動になりますか？

すみません、見逃していました。
tlcontrib のミラー（current/tlcontrib）は、自動で更新されます！

norbusan · 2019-04-17T14:30:49Z

では、なにもしなくていいって、よかった。ありがとうございます。

t-tk · 2019-04-20T07:06:22Z

結局何がどこに効いているのか私は理解できていませんが、ざっくり言うと

AGL & AGLFN の glyphlist.txt を更新のお願いをする
poppler-data の cidToUnicode/Adobe-Japan1 の更新のお願いをする

ということを目指せばよいと理解しました。
Unicode 12.1は5月7日予定だそうです。ベータ版のドラフトは未だに"U+32FF SQUARE ERA NAME XXXXXX"となっていて"REIWA"の文字が ~~見えません。もう20日も経ったのに。~~ →出ていました。1 はUnicode 12.1が出た頃にAGL & AGFLNのGitHubに投げてみようと思います。
2. はAdobe-Japan1-7だけの話なのでもう既にネタは出揃っています。GitLab は初めてですがお願いしておきます。ここの話とは無関係ですが、2でAdobe-CNSも少し古いようです。→投稿済み

かなり本題と外れてしまってきていて申し訳ないのですが

私見ですが、この話題についていうとAdobe Japanとかpopplerのカテゴリーにピッタリな場所が TeX JP org 内には思い当たらず、移すべき先が無いということでここで続けてよいと思います。XeTeXやLuaTeX も解決策を探るために話題になることはよいことと思います。

t-tk · 2019-04-20T07:19:50Z

Adobe-Japan のGitHub では既に"reiwa"の文字があちこちに入っていました。

trueroad · 2019-04-21T08:46:18Z

遅ればせながら TL2019 をインストールしてみたので era.tex を試してみました。

pLaTeX, upLaTeX ともに Adobe Acrobat Reader からのコピペでは縦横とも U+32FF が出てきました。
pdftotext (poppler) では縦横とも U+32FF が出ませんでした。 /usr/share/poppler/cidToUnicode/Adobe-Japan1 に 32ff を 2 行追加すると縦横とも U+32FF が出るようになりました。ということで結果はやはり XeTeX と同じです。

はAdobe-Japan1-7だけの話なのでもう既にネタは出揃っています。GitLab は初めてですがお願いしておきます。ここの話とは無関係ですが、2でAdobe-CNSも少し古いようです。

これなんですが、 poppler-data の現行の cidToUnicode/Adobe-Japan1 はどうやって生成したものなのかよくわかりません。コミットメッセージを見ると xpdf から（そのまま）持ってきたもののように解釈できるのですが、 xpdf ではどうやって生成したものなのか記述を見つけることができませんでした。

何を気にしているかと言うと、Adobe純正の Adobe-Japan1-UCS2 とはテーブルの内容が大幅に違っているところがあり（特に縦書きグリフ）そのまま 32ff を 2 行追加していいのか疑問に思っています。

poppler-data の cidToUnicode/Adobe-Japan1 は、なんとなく何かのAJ1フォントのcmapテーブルを逆変換したような感じのテーブルになっていて、明治大正昭和平成の縦書き合字が出てきません。「（」の縦書きグリフは「︵」、「）」の縦書きグリフは「︶」になってしまいます。これに（何となく）あわせるのであれば、 32ff を 2 行追加するのではなくて

32ff
0000

みたいにしなければならないように思います。これなら明治大正昭和平成と同じく令和の縦書き合字も出なくなります。

さもなければちゃんと Adobe-Japan1-UCS2 と同じ内容のテーブルにする、つまり明治大正昭和平成の縦書き合字が出て、「（」や「）」の縦書きグリフが「（」や「）」になるように大幅修正する。いずれか決めなければならないように思います。我々で決めるものでもないとは思いますが poppler のメンテナは日本語フォントのこういう話には興味が無いのではないかとも思います。

t-tk · 2019-04-21T12:33:54Z

@trueroad さん、
popplerのAlbert さんから "patches welcome" とのご返事を頂いたので検討を開始したところ、私も同じ疑問に突き当たりました。いずれは改善案をまとめてpatchまたはpull request を送るつもりです。
とりあえず GitLab で検討できるよう、自分のところに folk を作りました。

もし @trueroad さんや関心のある皆さんが GitLab にも来ていただけるのでしたらそこで Issue を立てて議論を進めたいと思います。あるいは、ここで議論を進めたあと私の GitLab に結論だけ Issue に記録する形でもよいかと思います。
将来、後から関心を抱いた人にも議論の経過が見える形にしておきたい、見つかりやすい場所で議論を進めたい、という趣旨です。

trueroad · 2019-04-21T14:29:14Z

@t-tk さん
私は freedesktop.org の GitLab インスタンスにもアカウントがあります。あちらでも GitHub と同じく trueroad です。こちらでは日本語、あちらでは英語、ですかね？ Adobe-Japan1 という日本語用の仕組みの話なのであちらも日本語でいいのかもしれませんが、恐らく他の Adobe-CNS などでも同じような問題を抱えていそうですし、日本語話者以外にも議論を追いたいという人もいるかもしれません。結論は英語だけど経過は日本語にしておき、議論を追いたい日本語話者以外はGoogle翻訳してもらう、というのでもいいかもしれません。

t-tk · 2019-04-21T14:38:33Z

では GitLab に Issue を立てて進めたいと思います。今日は遅いので明日以降に。
自動翻訳も良くなってきているので、日本語で議論を進め、結論は英語で書く、でよいと思います。

t-tk · 2019-04-22T13:16:52Z

GitLab の私のところに issue を立てました。
よろしくお願いします。

t-tk · 2020-02-29T04:43:44Z

ここで最近話題になっていたことと少し違ってAdobe-Japan1-7 (07/30/2019 対応)のための更新を行いました。
ここも 2020-02-29 のタグを打って nonfree のアーカイブを置きました。
https://github.com/texjporg/japanese-otf-mirror/releases/tag/2020-02-29

@norbusan さん、
TLContrib にnonfreeのインストールをお願いできますか? → ご対応ありがとうございました。

t-tk · 2021-05-02T04:07:30Z

dviout にある \CID{}のための CID→Unicode 変換機能も
Adobe-Japan 1-7 (U+32FF 令和の合字)に対応させました。
TUG svn repository r257

t-tk added a commit that referenced this issue Dec 8, 2018

ajmacros.sty: add tentative entry (#13)

8f1299d

t-tk added a commit that referenced this issue Dec 8, 2018

ajmacros.sty: add tentative entry (#13)

1012d89

t-tk added the enhancement label Dec 8, 2018

t-tk added a commit that referenced this issue Feb 9, 2019

ofm/*.ofm, vf/*.vf: regenerate (#13)

8db546b

t-tk added a commit that referenced this issue Feb 9, 2019

Add test sample for new era (#13)

b5b1d5b

t-tk added a commit that referenced this issue Mar 23, 2019

Update test sample for new era (#13)

4c20b13

t-tk added a commit that referenced this issue Apr 1, 2019

New era: Reiwa (#13)

bc6a7ee

t-tk mentioned this issue Apr 2, 2019

[upTeX他] Unicode 11.0, 12.0, 12.1対応 texjporg/tex-jp-build#70

Closed

5 tasks

t-tk added a commit that referenced this issue Feb 28, 2020

[uptex] import japanese-otf-uptex v0.25, AJ1-7(07/30/2019) (#13)

d70e630

新元号対応, Adobe-Japan1-7 #13

新元号対応, Adobe-Japan1-7 #13

Comments

t-tk commented Dec 8, 2018 • edited Loading

aminophen commented Dec 8, 2018

t-tk commented Dec 8, 2018

aminophen commented Dec 10, 2018

t-tk commented Dec 13, 2018

aminophen commented Dec 13, 2018

t-tk commented Dec 13, 2018

aminophen commented Dec 14, 2018

aminophen commented Dec 16, 2018

aminophen commented Jan 9, 2019 • edited Loading

t-tk commented Jan 13, 2019 • edited Loading

t-tk commented Feb 7, 2019 • edited Loading

t-tk commented Feb 9, 2019

aminophen commented Feb 10, 2019 • edited Loading

OFM ファイル群

VF ファイル群

aminophen commented Feb 10, 2019

aminophen commented Feb 10, 2019

t-tk commented Feb 10, 2019 • edited Loading

t-tk commented Feb 10, 2019

psitau commented Mar 30, 2019

t-tk commented Mar 31, 2019

t-tk commented Apr 2, 2019 • edited Loading

norbusan commented Apr 2, 2019

norbusan commented Apr 2, 2019

t-tk commented Apr 14, 2019 • edited Loading

aminophen commented Apr 14, 2019

trueroad commented Apr 14, 2019

t-tk commented Apr 14, 2019

trueroad commented Apr 16, 2019

aminophen commented Apr 16, 2019

aminophen commented Apr 16, 2019

trueroad commented Apr 17, 2019

munepi commented Apr 17, 2019 • edited Loading

norbusan commented Apr 17, 2019

t-tk commented Apr 20, 2019 • edited Loading

t-tk commented Apr 20, 2019

trueroad commented Apr 21, 2019

t-tk commented Apr 21, 2019

trueroad commented Apr 21, 2019

t-tk commented Apr 21, 2019

t-tk commented Apr 22, 2019

t-tk commented Feb 29, 2020 • edited Loading

t-tk commented May 2, 2021

t-tk commented Dec 8, 2018 •

edited

Loading

aminophen commented Jan 9, 2019 •

edited

Loading

t-tk commented Jan 13, 2019 •

edited

Loading

t-tk commented Feb 7, 2019 •

edited

Loading

aminophen commented Feb 10, 2019 •

edited

Loading

t-tk commented Feb 10, 2019 •

edited

Loading

t-tk commented Apr 2, 2019 •

edited

Loading

t-tk commented Apr 14, 2019 •

edited

Loading

munepi commented Apr 17, 2019 •

edited

Loading

t-tk commented Apr 20, 2019 •

edited

Loading

t-tk commented Feb 29, 2020 •

edited

Loading