ギュメの追加

[aminophen]

upjis 系に

« -- U+00AB (JIS X 0213 1-09-08 始め二重山括弧引用記号/始めギュメ)
» -- U+00BB (JIS X 0213 1-09-18 終わり二重山括弧引用記号/終わりギュメ)

も追加して良いのではないでしょうか。ukinsoku.tex では既にこれらは約物としてペナルティ設定されていますし，· -- U+00B7 (JIS X 0213 1-09-14 中点(ラテン)) と同様に JIS X 0213 に規定があります。

---

追記：以下のように Adobe の文字集合に入っていることから，日本語，韓国語への追加を提案します。

U+00B7

• Adobe-Japan1 CID+117
• Adobe-Korea1 CID+104（全角幅） （UniKS-UTF16-H）
• Adobe-GB1 CID+99（全角幅） （UniGB-UTF16-H）
• Adobe-CNS1 CID+115（全角幅） （UniCNS-UTF16-H）

U+00AB

• Adobe-Japan1 CID+109
• Adobe-Korea1 CID+176（全角幅） （UniKS-UTF16-H）

U+00BB

• Adobe-Japan1 CID+123
• Adobe-Korea1 CID+177（全角幅） （UniKS-UTF16-H）

[aminophen]

\documentclass{ujarticle}
\usepackage[uplatex]{otf}

% U+00AB, U+00BB, U+00B7 が全て全角幅でデザインされている「HGGothicE」を使う
% for uptex-fonts
\AtBeginDvi{\special{pdf:mapline uprml-h UniJIS-UTF16-H :0:HGRGE.TTC}}
\AtBeginDvi{\special{pdf:mapline uprml-hq UniJIS-UCS2-H :0:HGRGE.TTC}}
% for japanese-otf-uptex
\AtBeginDvi{\special{pdf:mapline uphminr-h UniJIS-UTF16-H :0:HGRGE.TTC}}
\AtBeginDvi{\special{pdf:mapline otf-cjmr-h Identity-H :0:HGRGE.TTC}}

\begin{document}
\fboxsep0pt

\fbox{☃}% U+2603
\fbox{«}% U+00AB
\fbox{»}% U+00BB
\fbox{·}% U+00B7
\fbox{《}% U+300A
\fbox{》}% U+300B
\fbox{・}% U+30FB

\fbox{\inhibitglue ☃\inhibitglue}%
\fbox{\inhibitglue «}%
\fbox{»\inhibitglue}%
\fbox{\inhibitglue ·\inhibitglue}%
\fbox{\inhibitglue 《}%
\fbox{》\inhibitglue}%
\fbox{\inhibitglue ・\inhibitglue}

\end{document}

[t-tk]

U+301E の話題 #7 もあり、括弧類を包括的に検討した方がよいような気がして少しづづ調べています。
まだ雑な調査ですが Unicode Vertical Text Layout などを参考にしつつ少しづづまとめています。
https://github.com/texjporg/uptex-fonts/blob/guillemet/source/punctuation.md

まだ、意見を言えるほど私の中で整理できていませんが、例えばU+301A, U+301B の組なども気になります。

[t-tk]

U+FE59..U+FE5E は Big5, Adobe-CNS1, GBK, Adobe-GB1 にあるようです。
U+301A, U+301B の組は、どの表を見ても見つかりません。CJK向けに登録されたもののようですが、出典やUnicodeに導入された経緯が不明です。

Wikipediaの引用符を見ると、言語ごとに多彩なことに驚きます。

[t-tk]

Adobe-Korea1 の CID176, 177は近くの記号が数学記号ですし、字形はAdobe-Japan1 の CID763, 764 (JIS X 0208の02-67, 02-68, U+226A, U+226B, ≪,≫ ) にそっくりです。
本来、数学記号であり括弧類のギュメや山括弧としてデザインされたものではないと思います。
それが、UniKS-UTF16-HではU+00AB, U+00BBとの対応になっているのは、規格のバグと呼んで構わないように思います。想像ですが、韓国語のレガシーエンコーディング(UHC等)とUnicodeの変換表を作った時に対応が不適切だったとか何かがあるような気がします。
Adobe-Korea1 の CID176, 177 は、括弧類としてではなく、全角文字(type 0)として組めれば充分と思います。

JIS X 0213 の 1-09-08, 1-09-18 への対応については、まだ考えがまとまっていません。

[aminophen]

いろいろ調査いただいてありがとうございます。

Adobe-Korea1 の CID176, 177
字形はAdobe-Japan1のCID763, 764 (JIS X 0208の02-67, 02-68, U+226A, U+226B, ≪,≫) にそっくり
本来、数学記号であり括弧類のギュメや山括弧としてデザインされたものではないと思います。
それが、UniKS-UTF16-HではU+00AB, U+00BBとの対応になっているのは、規格のバグと呼んで構わないように思います。

なるほど字形が数式の不等号みたいな ≪ ≫ のようですね。韓国語からは外しましょう。

[t-tk]

括弧類で、Unicodeの East Asian Width が W(wide), F(fullwidth), A(ambiguos) のいずれかのもので、かつAdobe-* にあるもので現在追加・削減を考えているものは以下になります。
U+301D..301F は #7 もご参考。

upjis, upjpn (追加)
type1: U+2329
type2: U+232A, U+301E

upsch, uptch (追加)
type1: U+2329, U+FE59, U+FE5B, U+FE5D
type2: U+232A, U+301E, U+FE5A, U+FE5C, U+FE5E

upkor (削除)
type1: U+301Dを削除
type2: U+301Fを削除

[t-tk]

upjisr-{h,v}.pl などを作成するのに、今までは makepl.perl を作成し、それを使って生成するようにしていました。
当初の意図としては、オリジナルの pTeX のものとの関係を追いかけやすくするとともに、もしpTeXの方に変更があった場合追従しやすくするものでした。
しかし、CJKの約物の差異が複雑化してきておりメンテナンス性がいいとは言いがたい一方、今なら git で履歴管理できるのでmakepl.perl はもう廃止しようかと思います。

[t-tk]

U+301A, U+301B の組 (〚, 〛) の出自が分かる資料を未だに発見出来ていませんが、IPA明朝,IPAゴシックの中にもあるみたいなので、upjis, upjpnに加えようと思います。中国語、韓国語フォントはよく判らないので、upjis, upjpnだけにとどめておきます。

U+00AB, U+00BB の組は下記の理由で少々迷いましたが、upjis, upjpnに加えることに賛成することにしました。

U+00AB, U+00BB の組を入れるのに消極的な理由

• UnicodeのEast Asian Width が N (Neutral), Vertical Orientation が R (Rotated 90 degrees clockwise compared to the code charts)であり、明らかに欧文向けを意識しており、CJK向けでは無いと思われる
• 似た字形のU+2039, U+203A (‹, ›) との整合性はどうなるか、悩ましい
• Adobe-Japan1では欧文向けのグリフしか無い

U+00AB, U+00BB の組を入れるのに積極的な理由

• JIS X 0213 によると「二重山括弧引用記号は、欧文文脈でも使用されることを想定している」とあり、暗に「和文文脈でも使用されること」も想定しているようだ。縦組字形も例示されている。
• そのようなJIS X 0213の規定に基づき、和文用として組むことができるフォントは入手しやすいと予想できる。

そうすると、今の私の考えで、追加・削除する括弧類は以下です。

upjis, upjpn (追加)
type1: U+00AB, U+2329, U+301A
type2: U+00BB, U+232A, U+301B, U+301E

upsch, uptch (追加)
type1: U+2329, U+FE59, U+FE5B, U+FE5D
type2: U+232A, U+301E, U+FE5A, U+FE5C, U+FE5E

upkor (削除)
type1: U+301Dを削除
type2: U+301Fを削除

https://github.com/texjporg/uptex-fonts/blob/guillemet/source/punctuation.md の表の中で
East Asian Widthが W または F である括弧類は、makejvf の write.c に入れておこうと思います。
先ほどTeX Live にコミットしました。r46796

[t-tk]

あまり一貫性のないルールですが

• 括弧類で、Unicodeの East Asian Width が W(wide), F(fullwidth) のものはAdobe-*に無くてもなるべく入れる
• ただしAdobe-*で妥当に組めないものはグリフが存在しても入れない
• U+00AB, U+00BB は例外的にupjis, upjpn のみに入れる
• U+FE59..U+FE5E は例外的にuptchのみに入れる
• "PRESENTATION FORM FOR VERTICAL LEFT/RIGHT ... BRACKET" は入れない

ということにして、作ってみました→ 1e53831
テストしてみて大丈夫そうなら仕様をfixして CTAN へリリースしたいと思います。

◇upjis, upjpn
type1:
追加 U+00AB, U+2329, U+301A
type2:
追加 U+00BB, U+232A, U+301B, U+301E

◇upsch
type1:
追加 U+2329, U+301A
type2:
追加 U+232A, U+301B, U+301E

◇uptch
type1:
追加 U+2329, U+301A, U+FE59, U+FE5B, U+FE5D
type2:
追加 U+232A, U+301B, U+301E, U+FE5A, U+FE5C, U+FE5E

◇upkor
type1:
追加 U+2329, U+301A
削除 U+301D
type2:
追加 U+232A, U+301B
削除 U+301F

[aminophen]

おそらく大丈夫だと思いますので，master にマージしておきました。

[t-tk]

マージありがとうございます。
リリースまでやりたい作業が若干残っています。
チェックリストを作るほどでも無いのですが、チェックリスト機能を使ってみたかったので書いておきます。

• UniJISup-UTF16-V に U+301E → CID7957 を追加 1175205
• tfm, vfの再生成 c923014
• uptex-base の samples にサンプルを追加 texjporg/uptex-base@b461978
• readmeなどの修正 c52a842
• CTANリリース 498ae38

[t-tk]

makejvf を使った vf の再生成で少々引っかかりました。
https://github.com/texjporg/uptex-fonts/blob/master/source/makejvf-upjis.cnf
の55行目 %%% over BMP の行の直後でエラーが出てしまいます。
以前は通っていたので
makejvf の usrtable.c を texjporg/tex-jp-build@3fcb544 のように revert したいのですがよろしいでしょうか?

[aminophen]

revert していただいて構いません。時間が出来たら，「本当に空行の場合はフラグをリセット，コメント読み飛ばしの結果空行になる場合はリセットしない」という処理が可能かどうか，検討してみます。

[t-tk]

若干ロジックが違いますが「CHARSETの継続行は必ず先頭が"%"または"+"である」ということにして、
それ以外はフラグをリセットするようにしてみました。
手元の動作確認で大丈夫そうなのでTeX Live svnにもコミットしました。r46970

[t-tk]

readmeのupdateおよびChageLog記載をしました。
https://github.com/texjporg/uptex-fonts/blob/master/README_uptex_font.md
間違いが無いよう気をつけたつもりですが、細かくてややこしいので少々不安です。
特に中国語簡体字、繁体字のところが意図通りの仕様を正しく記述できているのか自信がありません。
チェックしていただけると助かります。

ChangeLogのところの日付は仮に本日にしていますが、チェック完了およびリリース日に合わせればよいです。

uptex-fontsのリリース前にやりたい作業は私としてはここまでです。
私がCTANに投稿するとしたら、今夜かまたは来週のどこかになります。

uptex-baseの方は、サンプルの追加だけなので今回はCTANでのupdateは次の機会でもよいかなと思っています。
例えば、japanese-otf-uptexでも、ここと同様の更新を行いそれと同時とか。
あるいは、uptex-fontsのCTAN投稿もjapanese-otf-uptexの更新まで止めていてもよいです。

[aminophen]

（msfd26 の会場にいます。）

簡単な typo やリリーススクリプト等を少しだけ直しました。詳細はまた後日確認します。

[aminophen]

uptex-fonts で約物としたものについては，「ukinsoku.tex で禁則扱いにするかどうか」という論点もあると思います。禁則パラメータのデフォルトの量が多くなると

• 処理が重くなるかも？
• ユーザが自由に設定できる領域が狭くなる（上限256個までのため）

ことが懸念としてあるので，個人的には利用頻度の低そうな今回の追加分はナシでいいと思っていますが，如何でしょうか？

[t-tk]

• 処理が重くなるかも？

計測した訳ではありませんが、あったとしてもほこり程度だと思います。入れる方向にしても外す方向にしても判断材料に加えなくともよいと思います。

• ユーザが自由に設定できる領域が狭くなる（上限256個までのため）

それは知りませんでした。
ukinsoku.tex で設定されている禁則の設定をユーザー側のソースの記述で打ち消すことは出来ないんでしたっけ?

利用頻度の低そうな

うーん。それを言うなら、U+00AB, U+00BB について、
前述のようにUnicode的には「欧文扱い」されていますし、
和文として使うのは頻度が低そうですし、
T1等の 0xAB, 0xBB でも効いてしまう予測困難な副作用が気になっていたところなので、
これらを外す方向で考えたいです。
「U+00AB, U+00BBはvf, tfmには入れるが、ukinsoku.tex からは外す」というのはどうでしょうか。

もし、頻度を理由に外すなら、同じ理屈で
「通常和文では組まない U+00AA(ª), U+00BA(º)はukinsoku.tex からは外す」というのはどうでしょうか。

[aminophen]

処理が重くなるかも？

これは jtex.pdf (in ptex-base) の「この テーブルには最大 256 文字まで登録可能であるが、むやみに多くの文字を登録してテー ブルを満たすことは、禁則文字検索のオーバーヘッドを大きくし、パフォーマンスに大 きな影響を与えるので注意する必要がある。」を気にしていました。今の時代，誤差程度なら無視しましょう。

ukinsoku.tex で設定されている禁則の設定をユーザー側のソースの記述で打ち消すこと

これまた jtex.pdf の記述に「この禁則テーブルからの登録の削除は、ペナルティ値 ‘0’ を設定することによって行われる」とあります。TeX Live 2017 までの (u)pTeX は実はこの記述に沿っていなくて削除できませんでしたが，ようやく texjporg/tex-jp-build#26 を以て，可能になりました。

利用頻度の低そうな

は，JFM のタイプに追加してほしいというユーザからの要望があったわけでもなく，使用例も知らないからです。U+00AB, U+00BB はそれとはレベルが違う印象です。現に JIS でも JLReq でも和文の約物として想定されている分，実際に abenori さんの jlreq.cls でもその通り実装されていることが好例です。

[t-tk]

#2 で@aminophenさんに調べていただいた 0x80..0xFF の ukinsoku.tex での設定は↓でした。

\postbreakpenalty`«=10000 % U+00AB
\prebreakpenalty`»=10000  % U+00BB
\postbreakpenalty`¡=10000 % U+00A1
\postbreakpenalty`¿=10000 % U+00BF
\prebreakpenalty`·=10000  % U+00B7（今回追加）
\prebreakpenalty`ª=10000  % U+00AA
\prebreakpenalty`º=10000  % U+00BA
\prebreakpenalty`¹=10000  % U+00B9
\prebreakpenalty`²=10000  % U+00B2
\prebreakpenalty`³=10000  % U+00B3

この中で、Unicode の EastAsianWidth が A (Ambiguous) のものは
U+00A1, U+00BF, U+00B7, U+00AA, U+00BA, U+00B2, U+00B3 でした。CJKでも使われるのですね。意外に多いです。
Adobe-Korea1-2 の UniKS-UTF16-H で U+00A1, U+00BF, U+00B7, U+00AA, U+00BA, U+00B9, U+00B2, U+00B3 がそれぞれ全角の CID208, 209, 104, 668, 675, 842, 843, 844 に割り当てられています。
頻度のことは判りませんが、ある意味妥当な設定と言えそうです。

U+00AB, U+00BB はそれとはレベルが違う印象です。現に JIS でも JLReq でも和文の約物として想定されている

JLReq でもそうなのですね。ならば私の提案の削る方向は取り下げます。
今回vf,tfmに追加した方はこれからのことなので、ukinsoku.texの禁則設定については「defaultの禁則設定の不足があれば、ユーザー各位の必要に応じてに加えて使ってください」という考え方で妥当だと思います。

[t-tk]

前回行った中国語の約物のchar_typeの変更は、以下で合っていますか?
#2 の議論と現状の master ブランチのソースとを見比べながらまとめてみました。

• 中国語簡体字 upsch

  • 〈：〉U+FF1A,〈；〉U+FF1B (type3) を〈，〉U+FF0C と同じクラス(type2)に変える。(横書きのみ)
  • 〈？〉U+FF1F,〈！〉U+FF01 (type0) を〈。〉U+3002 と同じクラス(type4)に変える。(横書きのみ)

• 中国語繁体字 uptch

  • 〈、〉U+3001,〈，〉U+FF0C (type2) を〈：〉U+FF1A,〈；〉U+FF1B と同じクラス(type3)に変える。
  • 〈。〉U+3002,〈．〉U+FF0E (type4) を〈：〉U+FF1A,〈；〉U+FF1B と同じクラス(type3)に変える。

[aminophen]

禁則について，確認ありがとうございます。

前回行った中国語の約物のchar_typeの変更

ドキュメント化もありがとうございます。U+00B7 の追加も，今回ではなく前回実施した内容ですね。

[t-tk]

https://github.com/texjporg/uptex-fonts/releases/tag/2018-03-28 の状態でCTANへ投稿しました。
uptex-baseの方は、サンプルの追加だけなのでCTANでのupdateは次の機会にします。
一応ここは閉じますが、なにかあれば再開してくださいませ。