TANAKA, Takuji

[Unihan data base](https://www.unicode.org/charts/unihan.html) at [Unicode.org](www.unicode.org) provides [mapping](https://www.unicode.org/reports/tr38/index.html#kRSAdobe_Japan1_6) between ucs and Adobe-Japan including variants. According to the variants mapping, I suggest following mapping by the Unihan data base. Especially mapping of...

I suggest mapping CIDs to code points mapped by the latest UniJIS-UTFxx as following | CID | CID hex | Adobe-Japan1-UCS2 | UniJIS-UTFxx | |-------|---------|-------------------|-----------------------| | 13691 | 0x357b |...

I suggest CIDs mapping as follows. | CID | CID hex | Adobe-Japan1-UCS2 | UniJIS-UTFxx-H | suggest | |-------|---------|-------------------|----------------|---------| | 8312 | 0x2078 | 0x2193,0x2191 ↓↑| U+21F5 ⇵ Unicode3.2(2002) |...

I suggest following mapping to code points mapped by UniJIS-UTFxx not to combination of ASCII numbers. Because U+277F,24EB..24F4 are included in Unicode3.2 and JIS X 0213, I guess most of...

I suggest mapping CIDs to code points mapped by the latest UniJIS-UTFxx as following. I guess the current mapping of Adobe-Japan1-UCS2 is for a variant but the latest UniJIS-UTFxx mapping...

> jsclassesはもともと縦組みをサポートしていなかった ああ、そういう事でしたか。 > jsclassesによる縦組みの例 縦組みのクラスがないので、あるとしたら、縦組みのボックスを作った場合のその中だけですね。 仕様変更は許されそうですね。

> どこが文末なのかは自動判定できないと考えると，それも仕様としてはありえる気がします． OTF パッケージの縦組系で文中なので"？", "！"の後に全角アキを入れたくない場合は、グルーを消すように手動でマークアップを入れなければならない、ということなんですか。 jis-v とは考え方の違い、と理解しました。揃える必要があるのかどうか? japanese-otf-uptex の縦組みで、[区切り約物 cl-04](https://www.w3.org/TR/jlreq/ja/#cl-04) を同列に扱おうとするならば、以下の4グリフもtype 6 にすべきのようです。 CIDの対応はUniJIS-UTF16-{H,V}のもの U+203C ‼ CID:12111 全角 U+2047 ⁇ CID:16278 全角 U+2048 ⁈ CID:16279 全角 U+2049 ⁉ CID:12112 全角

> 「見たことがない→困る人は多分いない→変えて良い」という論理は ok なのでしょうか？ 私の発言ではありませんが、私が思うに、 新しく推進したい機能Aを入れようとすると別の観点で有用な機能Bが損なわれるケースはままあり、 機能Aと機能Bがトレードオフになってしまう場合があります。 「機能Bに相当するものが存在しなければ、機能Aを入れるのに障害が無い」 というロジックとして捉えました。 今回の文脈では 「jsclassesのボックスの中の縦組みのデフォルトのメトリックが好ましいと思って使っている人は多分いない」 ですね。 #66 の @aminophen さんの↓の問いかけと似たような趣旨かもしれません。 > [1] メトリック然り，[2] abstract インデント然り，『従来の挙動を好ましいと思っている人，特に再定義等せずそのまま使っている方』って，どれくらいいらっしゃるのでしょうか？

少し私見を述べます。 * 「ドキュメント化すれば、将来も挙動は維持されると期待でき、安心して利用できる」 という命題に、私は同意していません。 upTeX の例で言えば、 @zr-tex8r さんの[LaTeX の「アレなデフォルト」 傾向と対策](https://qiita.com/zr_tex8r/items/297154ca924749e62471)に指摘があった2点「upLaTeXでBMP外の字を使うとアレ」「upTeXの和文カテゴリコードがアレ」に関して 両方とも、公式のソース配布の[ドキュメント](http://www.t-lab.opal.ne.jp/tex/01uptex_doc_utf8.txt)に記載してある内容でした。しかし最近の upTeX-1.23 で、ドキュメントの記述を変更し、デフォルト動作を変更することにしました。 perl ではスマートマッチ機能が一度公式化されたものの、その後実験的機能に格下げになった例を思い出します。 熟慮して慎重に決定した仕様をドキュメントに記載したところで、「利便性」「直感的」「安全性」「周囲の状況の変化」など様々な理由で、不評な動作は変更を迫られることもあるし、時の経過とともに過去の決定が適切で無くなる場合もあるということです。 ドキュメント化をすれば、不都合なデフォルト動作が免罪されるわけでもないですし、不便が消えるわけでも不評を鎮圧できるわけでもありません。 pTeXのような「枯れた」しかも普及しているソフトウェアの場合は、ドキュメント化されていなければ動作を変えていいというわけでも無いでしょう。 デフォルト動作を変えたい、もしくは変えるべき、ということならば、正面切ってそういう議論をしたらいいと思います。

取り留めのない雑談になりますが… pTeX および関連ソフトについてざっと振り返ってみると、 ASCII社さんの公式のリリースの最終更新が2009年、公式Webの公開が2016年まで継続していました。 日本語TeX開発コミュニティーの発足は2015年6月でした。 振り返ってみるとupTeXの仕様を固めるのに2007年1月の開発開始から1年位かかっていました。 2007年頃の雰囲気は、ASCII社さんによるpTeX, pLaTeXの開発が収束に向かいつつある一方、 e-TeX拡張、XeTeX, LuaTeXなどは遠い世界でした。 そういう状況の中では、p{,La}TeXは、開発リソースの面でも将来性の面でも 世界から取り残されると知りつつも背伸びが出来ず、 「枯れていて，普及もしているから」変えない、という戦略には説得力があったように思います。 また、p{,La}TeXはASCII社さんが開発・公開してきたソフトなのだから、 2016年までは、動作を少しでも変更するような改変は、ASCII社さんに取り込んでもらうか、 さもなくば名前を変えて行うべし、という意見に説得力があったように思います。 (ptexenc拡張やe-TeX拡張のような方向性は別として。) 一方、最近の欧文LaTeXの激しい動きにpLaTeX, upLaTeXを追従させるべく 努力していただいている点はありがたく思っています。 up{,La}TeX は、間接的に p{,La}TeX を利用する立場なので、p{,La}TeX がきちんとメンテされることは有難いです。 2007年のupTeXの仕様決めの際にTeX掲示板でご意見を募り、pTeXのしがらみを断つ方が望ましい項目として 「標準フォントをmin10系ではなくjis系に、正方形が望ましい」と伺い、そう変えていったと 記憶しています。 焦点は、p{,La}TeXを取り巻く状況が変化する中、2018年の現在から将来を見据えてp{,La}TeXの仕様はどうあるべきか、ということになると思います。 p{,La}TeXの動作で不都合な点と言われるもののうち、p{,La}TeX以外に移行すれば済むものもあります。...