句読法

[103] 日本政府の文部省の文書として、 くぎり符號の使ひ方, くりかへし符號の使ひ方 がありました。 昭和21年に公表され、 少なくても昭和38年に一度再出版されており、 後者は前者を再録したに過ぎないのですが、 前者が縦書き、 後者が左横書きで、 字形もそれに合わせて変わったり、変わらなかったりしていました。

[319] 「――」 や 「……」 については組合せて使う文字参照。

[421] 括弧付き文字は、縦書きでも縦中横で書かれます。 括弧付き文字

[422] 右横書き用括弧の事例 「, 引用符, 括弧

[424] アラビア語では鏡像化される 「?」 ですが、 日本語では左横書きと同じ字形が使われた事例がありました。 ?

[516] 括弧

書字方向と字形設計

[239] 日本では幕末以来、 縦書きで使われてきた日本語文字と欧米由来の横書きの調和に様々な提案がなされてきました。 その中には、 横書き前提の新字 (まったく新しい用字系) を開発したものや、 横書き向きに仮名や漢字を大胆に改造したものもありました。 日本語近代化

[240] 大胆な提案はいずれも受け入れられることなく消えていきました。 現在では書体設計時に左横書き前提のバランス調整をする程度となっています。

[102] https://repository.ninjal.ac.jp/?action=repository_action_common_download&item_id=1306&item_no=1&attribute_id=43&file_no=1

[431] 「ー」の縦書き用、横書き用を間違えて使った (または未分化の時代の) 看板や書籍の事例:

[543] 横書き移行に伴う変化について, 1999-04-07T04:04:34.000Z, 2022-10-29T09:32:43.405Z http://www.shosha.kokugo.juen.ac.jp/oshiki/essay/97yokoga.htm

[542] 押木 エッセイ等, 1999-04-07T04:04:06.000Z, 2022-10-29T09:30:22.930Z http://www.shosha.kokugo.juen.ac.jp/oshiki/essay/henkumi.htm

[435] 第141回 中2世代の「02娘01」 | 漢字の現在(笹原 宏之) | 三省堂 ことばのコラム, 2020-11-23T02:25:51.000Z https://dictionary.sanseido-publ.co.jp/column/kanji_genzai141

「事」のはね方など書風、字形

[548] 復刻 文部省活字 ~ひらがなカタカナを中心に~|minosuke, 2023-07-14T05:46:07.000Z https://note.com/minosuke_note/n/n7d33397b8c70

また横書き用の「ー(長音記号)」は尋常小学算術ではマイナス記号が代用され、カズノホンでは縦書き用の長音記号を90度倒して代用されている等まともなものがなかったので新たに制作しました。

中華人民共和国

[77] 中文の句読点の用法を規定する GB/T 15834-1995 には、原則の横書きの規定の他に、 縦書きについて次のようにありました。

6 直行文稿与横行文稿使用标点符号不同。

6.1 句号、问号、叹号、顿号、分号和冒号放在字下偏右。

6.2 破折号、省略号、连接号和间隔号放在字下居中。

6.3 引号改用双引号“『』”和单引号“「」”。

6.4 着重号标在字的右侧,专名号和浪线式书名号标在字的左侧。

[78] 引用符だけ字形がまったく異なるので明示されていますが、 その他の位置の変更、向きの変更は文章の説明しかありませんでした。

[79] GB/T 15834-2011 では句読点の種類が増えた分の規定が増えていますが、 字形は (、) が追加されたのみで、他は文章の説明でした。

[80] 中文の数の表記法を規定する GB/T 15835-1995 には、原則の横書きの規定の他に、 縦書きで 「顺时针方向转90度」 する旨の規定がありました。 実際時計回りに90°回転した英数字が混じった文例がありました。 この規定の本題から外れますが、例示には 「:」、「,」、「。」の縦書き字形が示されていました。

[81] GB/T 15835-2011 にも同様の規定がありましたが、 なぜか例示から「:」は削られていました。

[82] GB/T 17961-2000 には横書きと縦書きの例文があって、 縦書きの句読点の実例として 「,」と「。」が含まれていました。

[83] GB/T 17961-2010 には関係する文字のリストが追加されていましたが、 横書きのみ示されていました。 例文は別のものに変わっており、 縦書きの句読点として 「、」、 「,」、 「;」、 「。」 が含まれていました。

CLREQ

[147] CLREQ は横書きと縦書き、 中国大陸、台湾、香港で句読点を書く位置が違う点を説明していました。 括弧や横線類と書字方向についても説明していました。 >>146

[145] CLREQ は Unicode の縦書き用符号位置は使うべきではなく、 他の仕組みで字形を置き換えるべきとしていました。 >>146

[149] CLLRQ の文字クラス表には、 時計回りに90°回転するべき文字が示されていました。 >>148 (句読点のように位置が変わるものはこれに含まれていませんでした。)

注音字母

[153] 注音字母の 「ㄧ」 は、 元々縦書きで横線、 横書きで縦線でしたが、 現在では主としてどちらでも横線が使われているそうです。 >>152, >>155, >>154

[156] フォントによって横線が表示されたり、縦線が表示されたりします。

[157] Wikipedia は画像を使ったり >>154、 漢字の 「一」と「丨」を使ったり >>155、 記号の「ㄧ」 を使ったり >>152 して書き分けようとしているようです。

[468] 台湾原住民の言語の表記では専ら縦線字形が使われるそうです。 >>467

[462] 「ㄧ」から派生した 「ㆪ」 「ㆳ」 は、 Unicode ではなぜか別の文字として扱われています。

爻

[134] 爻は、 縦に並べて使われます。 2つ並べて四象、 3つ並べて八卦、 6つ並べて六十四卦となります。

[135] 普通、八卦がおおむね漢字1文字程度で表示されます。

[136] 伝統的には単独の記号として使ったり、縦書きの漢字文中で使ったりしてきました。 記号的に使う場合、 銭に円形に配置するなど、 場面や宗教的意味に応じた書き方がされてきました。

[137] 現在では左横書き文中で、縦配置のままの字形で使うことが多くなっているようです。

[138] Unicode は1つから6つまでの全組み合わせをそれぞれ単独の文字として割り当てています。 (Unicode はこういうのを複数の符号位置の組合せにしたがりがちですが、 爻はそうしなかったようです。) 例示字形はすべて縦配置のままです。 六十四卦も1文字分のスペースに詰め込まれています。 Vertical_Orientation=U で、縦書きでもそのままの正立字形とされます。

[140] このサイト (初出はメルマガ) は、 Unicode に割り当てられる前に書かれたもので、 記号による代用表記を使っていました。 複数行を使う縦書き表記 (遠目に見ると Unicode の例示字形と同じ) と、 「:::|||」 のような左横書き表記を使っていました。 このような横書き字形が一般的なものかどうかは不明です。

算木

[352] 算木数字と蘇州号碼には縦式と横式の2種類の字形があります。 桁ごとに違えて使い、 横書き、縦書きとはあまり関係しないようです。

[470] Big5, CNS 11643, Unicode が縦横区別して符号化しています。

[469] フォントによっては GSUB の camp 機能を使って文字コードや書字方向と関係なく前後関係からグリフの縦横を変化させます。

文字の名前と書字方向

[220] Unicode では括弧類には LEFT や RIGHT のような文字の名前が与えられています。 しかしこれらは開き括弧、閉じ括弧を意味し、 書字方向に関わらず方向ではなく意味で使うとされています >>2, >>13。

[480] ISO/IEC 10646 の 19 によれば、文字名称の LEFT や RIGHT は、 (鏡像文字の場合) 「左向き」、「右向き」 ではなく「開き」、「閉じ」を意味するのだそうです。

[481] ISO/IEC 10646 と統合する前の Unicode 1.0 では文字の名前も OPEN とか CLOSE だったのに。 なぜ悪い方に揃えたのか。

例示字形の書字方向

[252] 文字コードの仕様書の本文や符号表に使われる文字の表示は、 仕様書が通常横書きされることもあってか、 横書きの字形とすることが多いようです。

[253] JIS も左横書き用字形を基本に、 適宜縦書き字形を補う形を採っています (>>22)。 文字コード規格だけでなく、 フォントでも同じです (>>38)。

[255] Unicode は、 符号表で横書き用の字形を使っています。 >>254

[487] Unicode は明らかに左横書きを優遇しています。 異体列のように1つの符号点に複数の代表字形を示した例もあるので符号表に複数の字形を示してもいいはずなのに、 右横書きや縦書きの字形はなぜか載せてもらえません。 蒙古文字や Phaistos Disc Symbols のように本来の用法とは違う向きがあえて選択されているものまであります。 東アジア向けの縦書きの代表字形は The Unicode Standard 本体に載せずに UAX #50 に分離されています (>>260)。

[486] 蒙古文字等は本来縦書きされますが、 左横書き形で Unicode 符号表に掲載されています (>>485)。

[369] Unicode U+101D0 - U+101FF の Phaistos Disc Symbols は、 原典が円盤に渦巻状に書かれた古代文字で、 敢えて言えば右横書きに当たります。 しかし研究書で左横書き文中に記述することが多い便宜上、 Unicode では左横書き扱いになっています。 符号表の字形も、 鏡像化した左横書き用のもので、 原典とは逆になっています。 >>368 Bidi_Mirrored は偽ですが、 右横書きで表示させるときは鏡像化グリフにする必要があります。

[371] Unicode U+10300 - U+1032F の Old Italic は、 左横書きでも右横書きでも書かれました。 符号表の字形は左横書き用のものです。 >>370 Bidi_Mirrored は偽ですが、 右横書きで表示させるときは鏡像化グリフにする必要があります。

[374] Unicode U+1680 - U+169F の Ogham は、 原典の石碑では下から上の縦書きで左下から右上へと書かれましたが、 研究書などでラテン文字に混ぜて左横書きされます。 >>373 符号表は左横書き字形を示しています >>375。 Vertical_Orientation は R です。

書字方向専用の符号位置

[246] 古くからある文字コードには、 特定の書字方向用の文字が符号化されていました。 一部は Unicode に取り込まれて現在まで残っています。 (古い製品に実装されていても Unicode にはないものもいろいろあります。)

[463] 古い Mule には 「Right-to-Left ASCII」 がありました。 Fp, 書字方向モデル

[457] Google検索では、 縦書きの PDF の検索結果に縦書き用の字形の括弧類が含まれる事例が大量にでてきます。 OCR によるものでしょうか。 それとも PDF の内部の文字の表現に由来するものでしょうか。

[76] GB 12345 は GB 2312 にない縦書きの文字を追加していました。 追加の説明にその旨がありましたが、 それ以外にどう使うものか説明はありませんでした。 括弧類は横書き用が左、右という名前で、 縦書き用が上、下という名前でした。 それ以外の記号類は横書き用に特に説明はなく、 縦書き用にはその旨が名前にかかれていました。

[247] 中華人民共和国では原則的には簡体字と左横書きが使われています。 簡体字の漢字コードである GB 2312 は、明言されていませんが、 左横書きを前提とした漢字コードだったのでしょう。

繁体字が必要になる場面を想定したとき、縦書きの記号も必要だということで、 GB 2312 由来の左横書き用の記号とは別に縦書き用を GB 12345 にだけ追加したのでしょう。

[84] CNS 11643 は横書き用と縦書き用の文字を符号化していました。 横書き用と離れたところに縦書き用を並べていた JIS X 0208 の非標準の各社の拡張や GB 12345 とは違って、 CNS 11643 は順番に並べていました。例えば括弧なら、 左括弧、右括弧、上括弧、下括弧のように並べられていました。 ただし CNS 11643 は符号位置と字形例を示しただけで、 各文字の説明はほとんどありませんでした。

[414] KPS 9566-97 は、 1区に句読点を横書き用と縦書き用の2組符号化していました。 朝鮮民主主義人民共和国関係者は、 この縦書きは JIS X 0208 にもあるものだと主張していました >>415。 (ただし実際には JIS は1つの区点位置で横書きと縦書きを表しており、 根拠として示されたのはその縦書き例示字形でした。)

[416] KPS 9566-97 は、 句点と閉じ括弧が一体化した合字も2つ符号化していました。 横書きと縦書きを区別するなら、 他に縦書き用もあって然るべきですが、 なぜかありませんでした。 横書きでしか使わないものなのでしょうか。

[248] JIS X 0201 や JIS X 0208 には横書き用、縦書き用と決められた文字はありませんでした。 初版の JIS X 0208-1978 からそうだったのかはわかりませんが、 JIS X 0208:1997 には横書き用の例示字形と、 縦書き例示字形が示されていました (>>22)。

左横書きだけでなく縦書きもよく使われている日本の漢字コードが縦書き専用の文字を用意しなかったのは、 書字方向を文字コードレイヤーで扱うべきでないという考えによるものだったのでしょう。

[249] ただ実用上それでは不便なこともあったようで、 JIS X 0208 の文字を左横書き用とみなし、 非標準の拡張で縦書き用の文字を割り当てることもありました。 また1文字分のスペースに複数の文字を縦横に並べて詰め込む組み文字も、 非標準の拡張として広く使われていましたが、 実用性より理論を重視したのか JIS は長らく無視してきました。

[25] JIS X 0213:2000 の制定時の公開レビュー公開資料 非漢字類の選定について, 1998年11月6日版によると、 候補に縦書き用の字形が大量に収集されましたが、

縦書きの用途を想定した縦書き用連数字のように,組版の機能を利用することで実現可 能なものについては,基本的に,追加候補としないこととした。

... という理由で収録されなかったそうです。 縦書き文中で縦中横的に数字やラテン文字の単位記号を横に並べるため1文字扱いとしたものや、 縦書きの新聞などでよく使われる片仮名の単位の組み文字などが、 独自の拡張や外字として広く使われていました。

例外的に 「㍉」 などのNEC特殊文字だけは互換性のため標準化されました。 Windows などに実装され、 左横書き字形と縦書き字形が使われていたので、 JIS X 0213:2000 もその両方を例示していました。 縦書き専用という形にはなっていませんでした。

[250] JIS X 0213 は縦書き専用の文字は規定していませんでしたが、 縦書き用例示字形のみを示した文字 (踊り字) がいくつかありました (>>27)。

[452] MacJapanese は縦書き字形を別の区点位置に割り当てていましたが、 Unicode に相当する文字が存在しないものもありました。 そこで Apple は私用文字として異体選択子的なものを独自に定義し、 独自の異体列的なものに対応付けていました。 variant tag

[251] 右横書きのアラビア文字やヘブライ文字を使うに当たり、 左横書きのラテン文字や算用数字との混在を踏まえ、 現在では bidi アルゴリズムを前提とした論理順が使われますが、 当初はすべて左横書きによる表示順も使われました。 その場合鏡像化もなく、 すべて左横書き用の文字として扱われました。 現在でも ISO-8859-8 の処理にその名残りを留めています。

[105] ヘブライ文字のアレフは、 Unicode では常用の右横書きの 「א」 と、 数学記号の左横書きの 「ℵ」 で重複符号化されています。 本来同じ文字のはずですが、 用法の違いからグリフも違っていることがあります。 鏡像化はなく、書字方向由来の違いではありません。

[335] CJK 以外の端末エミュレーションで縦書きに使った記号として、 U+23B4 TOP SQUARE BRACKET, U+23B5 BOTTOM SQUARE BRACKET, U+23B6 BOTTOM SQUARE BRACKET OVER TOP SQUARE BRACKET があります >>332。 最初の2つは CJK 用として別に縦書きの符号位置があるにも関わらず、 なぜか別に符号化されています。 符号表には縦書き字形が示されており、 Vertical_Orientation は R なので、 縦書き環境では逆に横向きになります。

[338] 数式で適当な幅に引き伸ばして使う水平の括弧として、 U+23DC - U+23E1 があります >>332。 別に同じような縦書きの符号位置があるにも関わらず、 別に符号化されています。 符号表には縦書き字形が示されており、 Vertical_Orientation は R なので、 縦書き環境では逆に横向きになります。

[343] U+FE10 - U+FE19 に Vertical Forms として縦書き用の符号位置があります >>342。 U+FE30 - U+FE44, U+FE47, U+FE48 にもあります >>346。 前者は GB 18030, 後者は CNS 11643 との互換性のためとされています >>14。 いずれも <vertical> な互換分解で通常の符号位置に変換されます >>342, >>346。 Vertical_Orientation=U で、 横書きでも縦書きでも同じ字形となります。 なお句読点の例示字形は : や ? も含め右寄せ小書きの中文式です。 互換等価とされるのは通常の句読点ですが、 それとは別に符号表には SMALL 形の文字へ参照が記述されています。

[347] U+FE45 SESAME DOT, U+FE46 WHITE SESAME DOT の Unicode 符号表には 「sesame dots are used beside vertical text for emphasis」 とあります >>346。 特別に縦書きに限定されてはいませんが、 縦書きでの利用を想定しているようです。 JIS X 0213:2000 にも同名の文字がありますが、 そちらでは特に縦書き限定の字形とはされていません。 Unicode Standard は、 「、」と関係しているがただの縦書き字形ではなく、 機能が違うので分けたとあります >>14。 なお 「、」の Standardized Variants に同形のものがあります (>>350)。

[354] U+3190 - U+319F に漢文用の文字があります >>353。 返り点が一通り用意されていますが、 使い方が謎であまり利用されていないとみられます。

• [355] U+3190 IDEOGRAPHIC ANNOTATION LINKING MARK は、 「tateten」 と説明があり、上下の漢字をひとまとめにすることを表す訓点を意味するようです。 例示字形は上半中央付近の短い縦線です。 Vertical_Orientation=U です。 互換分解はなぜかありません。 <vertical> HYPHEN 辺りになっていても良さそうなものですが。
• [356] U+3191 IDEOGRAPHIC ANNOTATION REVERSE MARK は、 「kaeriten re」 と説明があり、レ点を表すようです。 例示字形は上半やや左寄りの「レ」の字型ですが、 片仮名の「レ」の例示字形とはやや異なるように見えます。 Vertical_Orientation=U です。 互換分解はありません。
• [357] U+3192 - U+319F は、 返り点の漢字を意味するようです。 例示字形は右上寄りの小書きの漢字です。 Vertical_Orientation=U です。 互換分解は <super> で元の漢字になり、 上付きという扱いになっているようです。 上付き (superscript) に見えるのは、 横書き視点なのでしょうか。

[325] , は鏡像化されませんが、 U+060C ARABIC COMMA として中央大書きのコンマを180°回転した字形が別に符号化されています >>323。

[326] ; は鏡像化されませんが、 U+061B ARABIC SEMICOLON として180°回転した字形が別に符号化されています >>323。 他に左右反転させた U+204F REVERSED SEMICOLON, 同じく180°回転した U+2E35 TURNED SEMICOLON が用意されています。

[327] ? は鏡像化されませんが、 U+061F ARABIC QUESTION MARK として左右反転させた字形が別に符号化されています >>323。 同じ字形の U+2E2E REVERSED QUESTION MARK, U+2426 SYMBOL FOR SUBSTITUTE FORM TWO (Vertical_Orientation=U) もあります。

[367] チェス記号として、 正立字形の他に、 45°、 90°、 135°、 180°、 225°、 270°、 315° 回転させた字形が符号化されています。 旧時代の印刷用の便宜のための慣習によるものと説明されています。 >>365, >>366

[471] 将棋の駒を表す記号の☖, ☗は、 攻守の違いを表す180度回転した⛉, ⛊があります。 ARIB外字由来で Unicode に追加されました。 新聞等の盤面の表示では駒だけでなく他の文字列も、 180度回転された状態となることがあります。 なぜか駒の記号だけ専用の文字コードがあります。

[403] Jドキュメントについて (2020-10-25T06:40:19.000Z, 2001-11-02T20:07:16.050Z) https://web.archive.org/web/20011102200606/http://www.nec.co.jp/bungo/10info/support/jdoc.html

フォーム9~14では一部の文字は縦書きに適した向きで表示されますが、電子メールで受信すると、縦書きに適した向きになりません。これらの文字の使用は控えましょう。

[410] 詳細不明ですが、縦書き記述に無理のある方法を使っていたのでしょうか。

[539] null, 2005-04-08T15:38:04.000Z, 2022-10-16T13:19:23.669Z https://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ReadMe.txt

類似字形による代替表現

[104] 縦書きに対応していない環境で強引に縦書きを実現する手法として、 縦書き字形に似た横書きの文字で代用するというものがあり、 そこそこ広く用いられているようです。 縦書きエミュレーション

組合せて使う文字

[318] 複数の文字を組合せて使う文字群があります。 grapheme cluster と同様、 書字方向とグリフの扱いが全体として一貫している必要があります。 組合せて使う文字

Teletex

[8] T.61 は日本語用の縦書きと中文用の縦書きを定めていました。

[438] いくつかの文字に横書き字形と縦書き字形が示されていました。 日本語と中文で違っていました。

JIS フォント

[87] JIS は、 JIS X 0208-1983 の時代に、 ビットマップフォントを2種類規定していました。

[88] 基本は横書き用の字形としつつ、 縦書きで字形が異なる場合も規定していました。

[89] このフォントをそのまま使う場合、 敢えて縦書きの字形が規定されたもの以外は、 横書き用の字形をそのまま縦に並べることが想定されたようです。

[92] 縦書き用の字形が定められた文字の一覧:

[67] 9051 と 9052 の縦書き用字形がある文字は一致していました。

後の JIS X 0208:1997 の縦書き用字形がある文字とは多少出入りがありました。

OpenType のグリフと機能

[489] OpenType フォントはグリフの集合体として構成されています。 フォントの cmap 表によって文字コードから代表のグリフを取得し、 フォントの GSUB 表から書字方向に応じた機能を適用して適切なグリフに置換します。

[490] グリフそれ自体のデータ構造は書字方向に依存せず、 正立状態の左下が座標原点、右が X軸、 上がY軸の座標平面で記述されます。 OpenTypeの座標

[466] グリフ自体には「横書き」「縦書き」のような性質はなく、 GSUB 表の構成次第で縦横共用にしたり、 左右で使い分けたり、縦横で使い分けたりできます。

[492] グリフの相互配置に必要な基線や文字幅・文字高などの情報は BASE 表や GPOS 表などにあり、 書字方向に依存して適用することになります。 グリフ位置決定

[493] GPOS 表や GSUB 表の lookup は書字方向に依存していません。 lookup の後戻り列や入力列や先読み列に入力のグリフ列が一致すると lookup の指定が適用されますが、この列の順序は論理順です。

[380] OpenType は基礎的な部分が横書き前提で、 縦書きの場合に一部別の規定が適用されるという形になっています。 横書き利用、縦書き利用を想定した寸法情報を hhea / hmtx 表、 vhea / vmtx 表に記述できます。

[465] OpenType には基線情報を記述する BASE 表があって、 横書き用と縦書き用の各種基線の位置を設定できます。

[495] OpenType には縦書きと横書きの違いに特に関係して chws, cpct, halt, kern, vchw, vhal, vkrn, vpal といった GPOS 機能があります。

[496] OpenType には右横書きグリフのための機能等があります。 (>>183)

[10] OpenType には縦書きグリフのための GSUB vert 機能があります >>9。

[378] OpenType には仮名の横書き字形のための GSUB hkna 機能 >>377、 縦書き字形のための GSUB vkna 機能 >>9 があります。

[379] OpenType には縦書き用に時計回りに90°回転して使うための回転前の字形用の GSUB vrtr 機能と、 同じく回転済の字形用の GSUB vrt2 機能があります。 >>9

[517] 縦組み 「:」が倒れていない · Issue #6 · trueroad/HaranoAjiFonts · GitHub, 2022-09-07T07:02:07.000Z https://github.com/trueroad/HaranoAjiFonts/issues/6

[533] [HarfBuzz] default features for vertical text runs, 2013-12-19T02:33:52.000Z, 2022-10-10T15:22:05.664Z https://lists.freedesktop.org/archives/harfbuzz/2013-August/003490.html

[530] Adobe Technical Note #5901 - 5901.Kazuraki_Tutorial.pdf, 2021-02-18T01:31:12.000Z, 2022-09-29T14:52:38.106Z https://adobe-type-tools.github.io/font-tech-notes/pdfs/5901.Kazuraki_Tutorial.pdf#page=23

グリフそのものは、2 つともまったく同じものですが、その字幅や、X 軸および Y 軸方向のデフォルトの位置設定に違いがあります。縦組用に、すべてのグリフを重複させて持たせる必 要がありました。これは、OpenType の「vmtx」テーブル内でグリフを X 軸と Y 軸の双方に沿ってシフ トする機能に制限があったことに加えて、アプリケーションが GSUB や GPOS の機能に依存せずに、こ れらの機能が有効でない場合でも、デフォルトで期待する動作が得られるようにしたいと考えたからで す。

[534] 花園明朝OTを0.510に更新、IVD 2012-03-02版に対応 - しろもじメモランダム, 2022-10-10T15:41:56.000Z https://shiromoji.hatenablog.jp/entry/20120306/1331028598

Windowsでは、CFFアウトラインのOpenTypeフォントのGSUBテーブルにvrt2 featureが定義されていないのにvhea/vmtxテーブルがあると、OSに不正なフォントして弾かれます。

縦書きグリフを追加するのではなく vhea/vmtx テーブルを削除する方法もあるが、これを試したところ Microsoft Word で縦書きができなくなった(花園明朝OTを指定してもMS明朝で描画される)ので採らなかった。

[540] 「貂明朝」は日本語フォントの新たな領域へ, 2020-11-19T06:22:31.000Z, 2022-10-18T06:24:31.980Z https://ccjktype.fonts.adobe.com/2017/11/ten-mincho-ja.html

GPOS フィーチャーの vert が含まれているのは、U+3099 (COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK) と U+309A (COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK) が縦組みで役に立つからです。残念ながら、この特定の GPOS フィーチャーに対応している環境は現時点では限られていて、少数ではありますが、これを含めておくことは、先駆的な一歩を踏み出すことであり、長期的には有用なことに違いありません。

[559] 書字方向と文字のレンダリングとフォントの関係については、 結合文字、ZWJ も参照。

Adobe CID

[523] CMap では WMode (writing mode の意) の値 0 により左上横書きを、 1 により右上縦書きを表現できました。 >>522

[524] またその名前は、 末尾に -H (horizontal の意) や -V (vertical の意) を付けることで区別しています。 >>522, >>529

[85] Adobe-Japan1 は、 横書き用の字形の CID と別に、 縦書き用の字形の CID も規定しています。

• [86] JIS X 0208 や JIS X 0213 の規格票に縦書き用の例示字形が示されたものはカバーしているようにみえます。
• [95] JIS に縦書き用の例示字形がなくても縦書き用の字形が示されたものがあるようです。
• [93] それ以外の独自の片仮名の単位の組み文字などの非漢字で横書きと縦書きの字形が示されたものがあります。
• [94] K-JIS 由来らしい、縦書き用の括弧と数字の組み文字があります。
• [96] ラテン文字その他について、 縦書き用の時計回りに90°回転した字形があります。 vert2 用です。
• [558] 非標準の拡張で、互換性への配慮が理由で縦書き字形を増やしたものがあります。 AJ1

[525] Adobe-CNS1 は CNS 11643 や Big5 に必要な縦書き字形の他、 vrt2 用の回転字形を収録しています。

[526] Adobe-GB1 は GB 12345 用縦書き字形の他、 vrt2 用の回転字形を収録しています。

[528] Adobe-Korea1 は KS X 1001 用縦書き字形の他、 vrt2 用の回転字形を収録しています。

[527] Adobe-KR は縦書き字形を収録しています。 おおむね KS X 1001 非漢字に対応するのに必要な分が揃っているようです。 (vrt2 専用グリフはありません。)

[531] Mapping for U+2B05, U+2B06 & U+2B07 in vertical writing · Issue #2 · adobe-type-tools/cmap-resources · GitHub, 2022-09-30T07:45:27.000Z https://github.com/adobe-type-tools/cmap-resources/issues/2

[532] To V, Or Not To V, 2020-11-19T06:22:26.000Z, 2022-09-30T07:47:13.102Z https://ccjktype.fonts.adobe.com/2015/09/to-v-or-not-to-v.html

フォントのグリフ実装状況

[536] Japanese Windows and hangul---JApanese and KOrean konzai-bun, 2006-03-10T14:05:15.000Z, 2022-10-11T05:38:55.700Z https://ha1.seikyou.ne.jp/home/akairingosaita/hangul/jako.htm#ks

「、」や「。」はKSでは縦書き専用のようです。 (注: フォントにより差異があります。)

[537] 実際には KS X 1001 はそのようにはなっていないのですが、 当時大韓民国で使われていたフォントはそういうものが多かったようです。 (「、」や「。」は当時の韓国語であまり使わず縦書き専用扱いだった?)

[337] 文字の取り扱い - 超漢字ウェブサイト, 2010-11-10T00:20:37.000Z, 2022-08-25T14:53:10.774Z http://www.chokanji.com/ckv/manual/03-07-02.html

[464] Windows日本語フォントでのUAX50問題文字のテスト, Shinyu MURAKAMI, 2022-07-12 14:46:45 +09:00, 2022-07-12T10:43:40.000Z, 2022-07-13T02:14:51.723Z https://lists.w3.org/Archives/Public/public-i18n-japanese/2022JulSep/0028.html

[515] 書体を登録する - 超漢字ウェブサイト, 2010-11-10T00:15:32.000Z, 2022-09-03T06:28:43.139Z http://www.chokanji.com/ckv/manual/01-07-10.html

超漢字にはフォント単位で 「横書き文字」、「縦書き文字」の属性があるらしい。

JIS X 4051

[48] JIS X 4051-1995 は文字クラスを本体4.1.1で規定し、 附属書で JIS X 0221 との対応関係を規定していました。 JIS X 4051:2004 は文字クラスを本体6.1.1で規定し、 附属書で JIS X 0213 との対応関係を規定していました。

[45] JIS X 4051-1995 4.1.1 から参照された 表1 文字クラス に「横書き用文字」 と 「縦書き用文字」 が示されました。 縦横は差分ではなく、縦横同じ字形で示された文字もありました。 横にだけ示された文字もありました。 JIS X 4051:2004 6.1.1 から参照された 表4 文字クラス もいくつか追加がある以外はほぼ同じでした。

[46] JIS X 4051-1995 附属書 国際符号化文字集合 (JIS X 0221) との対応 は 「縦書き・横書きの文字種につ いては, 横書きを基準として決め, 縦書き時にはそれを縦書き用文字に変換することを原則とし,」 て字形欄に横書きと縦書きの字形例を示しました。

[64] JIS X 4051:2004 附属書1 (規定) 7ビット及び8ビットの2バイト情報交換用 符号化拡張漢字集合 (JIS X 0213) との対応 は 「縦書き・横書きの文字種 については, 横書きを基準として決め, 縦書き時にはそれを縦書き用文字に変換することを原則とし,」 て字形欄に横書きと縦書きの字形例を示しました。

[49] 本体表と附属書を比べると、本体表は附属書の一部の文字に限って示しているように見えます。 (本体表は字形だけで、文字を同定できる情報が他に示されていないので、 断言しがたいですが。)

[50] 附属書では一部の文字クラスは符号位置だけが示されており、 それ以外は縦横の字形を明記して示していました。

[69] 本体表、附属書とも、 1995 と 2004 で出入りがありました。 1995 は JIS X 0221 の日本語文字、 2004 は JIS X 0213:2000 を対象としているのが変更の主たる要因のようです。 2004 には Unicode で1つの符号位置で表せない (が JIS X 0213 では1つの面区点位置で表される) 文字も含まれました。

[70] 縦横は差分ではなく、縦横同じ字形で示された文字もありました。 横にだけ示された文字もありました。 2004 には縦にだけ示された文字もありました。 1995 と 2004 の字形は必ずしも等しくありません。

[73] JIS X 4051:2004 にはなぜか JIS X 0213:2000 にあるㇷ゚は含まれていませんでした。 (字形が示された文字クラスに入るべきもののうち唯一 Unicode で1つの符号位置で表されないものでした。 他の1つの符号位置で表されない文字は、附属書表1の字形を示さない文字クラスにすべて含まれていました。)

[55] JIS X 4051-1995 と JIS X 0208:1997 の縦書き字形を比べると、 JIS X 4051-1995 にだけあるのは JIS X 0208 にない文字と「・」 (「・」は字形は似ているが縦横幅の違い)。 JIS X 0208 にだけあるのは「=」。

[74] JIS X 4051-1995 と JIS X 0213:2000 の縦書き字形を比べると、 若干の出入りがあります。

[51] 他に本体中の例示でいくつか示されていました。

[42] (60) 始め括弧類 の「例 横書きにおける始め括弧類」

(71) 分離禁止文字 の 「例 横書きにおける分離禁止文字」

[52] 例示中の「㌔」は表1にも附属書にも字形例がなく、 ここでだけ字形が示された文字でした。

[57] JIS X 4051:2004 でも似たような例示 (項目と例示される文字は多少変更あり)。

[53] 例示でない本文 (横書き) 中で敢えて縦書き字形を示したのが1個所。

(縦書きの実例あり。ここでの半角とは縦幅のこと。)

2004 4.2 a) 1) では本文中の字形が削除されていた。 (実例は 2004 にもある。)

[58] JIS X 4051:2004 では 5.2, 表2, 表3 に漢文用の文字が縦書き字形で示された。

[113] JLREQ >>17 には JIS X 4051 の文字クラスに相当するものが示されていましたが、 字形は左横書き用が一部挙げられているに過ぎませんでした。 ISO/IEC 10646 の文字の一覧表には、 一部の文字に、 「横組で使用」 または 「縦組で使用」 と書かれていました >>133。

[141] なお、書かれている文字の名前は半角の方なのに、 使われている文字は FULLWIDTH の方でした。 また対象は ISO/IEC 10646:2003/Amd.3:2008 285 BASIC JAPANESE と 286 JAPANESE NON IDEOGRAPHICS EXTENSION の文字と説明されていましたが、 実際にはUnicode文字以外に2つの符号位置の列 (JIS X 0213 では1文字で表されるもの) もいくつか含まれていました。

[114] JLREQ は小書き仮名について、 「縦組では文字の外枠の天地中央で右寄り,横組では文字の外枠の左右中央で下寄りに字面を配置」 と言及していました >>18。

[117] JLREQ は縦横専用の文字を次のように述べていました。 >>116

• [118] 「、」: 「縦組では使用する」「横組で使用する」
• [120] 「。」: 「縦組では使用する」「横組で使用する」
• [119] 「,」、「.」: 「横組で使用する」
  • 書かれている文字の名前は半角の方なのに、 使われている文字は FULLWIDTH の方
• [121] 「「」、「」」: 「縦組では用いる」, (横) 「最近は,かぎ括弧の使用が増えている」
• [122] 「“」、「”」、「‘」、「’」: 「横組では用いる」「横組専用の括弧類であり,縦組では使用しない」「縦組において欧文用文字(cl-27)などを時計回りに90度回転させて配置する場合に使用する例がある」
• [123] 「〝」、「〟」: 「縦組専用の括弧類であり,横組では使用しない」
• [124] 「〔」、「〕」: 「縦組用に変形したものである」
• [125] 「[」、「]」: 「特別な場合を除き,横組ではブラケットを使用する」
• [126] 句点類、読点類: 「縦組用と横組用では,文字の外枠に対する字面の配置位置が異なる」
• [127] 始め括弧類、終わり括弧類、ハイフン類: 「縦組用と横組用で字面の向きを変更する」
• [128] 小書きの仮名: 「文字の外枠に対する字面の位置が縦組用と横組用では異なる」
• [129] 長音記号: 「字形の向きを変更するだけではなく,字形そのものも変更している.横組用の長音記号は,縦組用の長音記号を単純に反時計回りに90度回転したものではない」
• [132] 「全角単位字は,主に縦組で使用するもので,横組で使用するのは,体裁がよくないので避けた方がよい」 >>131

[115] その他 JLREQ も例文中にいくつか縦書き字形が現れてはいました。

[164] 文字クラスの一覧表で縦組でまたは横組で使うと明記されているもの:

[44] (時計回り90度回転の左横書き) 1995 3.5 (6) 2004 4.6 f) 「縦書きの行中で, 連数字及び単位記号の文字の向きを右回りに90° 回転して横書きにした場合」 1995 3.6 (2) 2004 4.7 b)「縦書きの行中では, 欧文の文字の向きを右回りに90° 回転して欧文を横書きにし,」 2004 4.13 d) 「文字の向きを右回りに90°回転して横書きにする」 JIS X 4052:2000 6.1 a) 3) 「文字の並びの横軸を時計回りに 90度回転させた横書き」 JLREQ >>16 「文字を時計回りに90度回転し,配置」

(広義の縦中横) 1995 3.5 (7) 2004 4.6 g) 「縦書きの行中で, 連数字及び単位記号を縦書きの文字の向きのまま横書きにした場合」 1995 3.6 (2) 備考 2004 4.7 b) 備考 「縦書きの欧字又は数字を和字として扱う場合」「添え字付きの欧字を縦中横を使用して配置する場合」 1995 3.7 2004 4.8「縦中横処理 縦中横処理は, 縦書きの行中で, 縦書きの字の向きのまま横書きになるように文字列 を中央に配置する。」 1995 3.9 (4) 2004 4.13 d) 「文字の向きを右回りに90° 回転して横書きにする」 JIS X 4052:2000 6.18 「欧文用文字を縦書き中で和字扱いとする」 (1文字ずつ正立させること) JLREQ >>16 「正常な向きで,1字1字配置」 「正常な向きのまま,横組」 (縦中横)

[144] この辺の整理は CLREQ が JLREQ の整理を踏襲しています。 「相同的書寫方向,依字母逐個排列」 「保持正常方向,橫排處理(如日文的縱中橫排)」 「順時針方向旋轉90°」 >>143 KLREQ にも似た分類がありました >>158。

Unicode の鏡像化

[225] Unicode は bidi を表示順ではなく意味順に文字を並べることで実現しています。 その結果左横書きと右横書きで同じ意味でも字形が逆になるケースが出てきますが、 あくまで文字データは意味順で適切なものを選び、 表示の際に相応しいグリフを選ぶこととしています。

[221] Unicode Bidirectional Algorithm の L4 は、 文字の解決済方向性が R であって、かつ文字の Bidi_Mirrored 特性値が真である場合、その場合に限って、 鏡像化グリフで描画することと定めています >>6。 ただし HL6 が適用される場合は例外となります >>6, >>5, >>2。

[226] 意図した意味 (semantics) を表す適切な文字を使うため、 また相互運用性やセキュリティーを防ぐため、 実装は L4 に従い適切に鏡像化しなければなりません (must) 。 >>2

[222] Unicode Bidirectional Algorithm の HL6 は、 上位層プロトコル次第で、 特定の状況で、 Bidi_Mirrored 特性値が偽であっても、 鏡像化グリフで描画できるとしています。 歴史的な用字系とその句読点、 私用文字、 数式中の文字などの状況が想定されます。 次のいずれかまたは両方の条件に合致する文字となります。 >>5

• [223] 解決済方向性が R の文字
• [224] 解決済方向性が L で、 双方向的型が R または AL の文字

[177] UCD の特性 Bidi_Mirrored は、 規定であり >>167、 UnicodeData.txt >>175 に収録されています。 DerivedBinaryProperties.txt >>210 にも収録されています (こちらの方が使いやすいかもしれません)。 値はブール型です。 真は鏡像化される (mirrored) ことを、 偽はそうでないことを表します >>167。 大部分の符号位置は偽です。

[227] 鏡像化には、 括弧のように組になった文字があって、 一方の鏡像化が他方になっているケースと、 そうでないケースがあります。 組になっている文字の情報は、 Bidi_Mirroring_Glyph として提供されています >>2。

[179] UCD の特性 Bidi_Mirroring_Glyph (bmg) は、 参考であり、 BidiMirroring.txt >>178 に収録されています。 鏡像化によって想定されるグリフを持った文字を表します >>168。 例えば開き括弧の符号位置の特性値は、 閉じ括弧になっています。

[176] 値は符号位置か <none> です。 Bidi_Mirrored が真であっても、 鏡像化して他の文字のグリフと一致しないものは、 この値を持ちません。

[180] Unicode 5.1 時点の Bidi_Mirroring_Glyph は The OpenType Mirroring Pairs List (OMPL) と一致していました (>>189)。 その後の Unicode 側の変更で一致しなくなっています。 >>178

[181] この写像のうちいくつかは 「"BEST FIT" mirroring pairs」 とされるものがあって、 BidiMirroring.txt に BEST FIT とマーキングされています >>178。 その場合、 組になっている方と入れ替えてレンダリングしても構いませんが、 理想的には鏡像化グリフは他の字形となるべきです >>2。 開き括弧と閉じ括弧で左右対称になっていない字形要素が含まれるようなケースが該当しているようです。

[200] UCD の特性 Bidi_Paired_Bracket_Type, Bidi_Paired_Bracket は、 規定であり、 BidiBrackets.txt >>171 に収録されています。 Bidi_Mirroring_Glyph とよく似ていますが、 Bidi_Mirroring_Glyph がフォント設計に関係しているのに対し、 Bidi_Paired_Bracket は Unicode Bidirectional Algorithm のアルゴリズムに関係しています。

[201] Bidi_Paired_Bracket_Type は、 組になった括弧のうちの当該文字の型を表します >>169。 値は o (Open), c (Close), n (None) のいずれかです >>178。 Bidi_Paired_Bracket は、 開き括弧に対応する閉じ括弧またはその逆を表します >>170。 値は符号位置または <none> です >>178。 この情報は Unicode Bidirectional Algorithm で使われます。

[203] この情報は、

... な A, B について、 Bidi_Paired_Bracket (A) := B, Bidi_Paired_Bracket (B) := A, Bidi_Paired_Bracket_Type (A) := o, Bidi_Paired_Bracket_Type (B) := c としたものです。 >>178

[204] U+298D LEFT SQUARE BRACKET WITH TICK IN TOP CORNER (⦍), U+298E RIGHT SQUARE BRACKET WITH TICK IN BOTTOM CORNER (⦎), U+298F LEFT SQUARE BRACKET WITH TICK IN BOTTOM CORNER (⦏), U+2990 RIGHT SQUARE BRACKET WITH TICK IN TOP CORNER (⦐) は U+298D - U+2990, U+298F - U+298E と対応していることに特に注意が促されています。 >>178

[205] U+FD3E ORNATE LEFT PARENTHESIS (﴾) と U+FD3F ORNATE RIGHT PARENTHESIS (﴿) は legacy reason で括弧の組として扱われていません >>178。 後方互換性のため、 これらは鏡像化されません >>6。

[206] The Unicode property value stability policy により、 Bidi_Paird_Bracket_Type が o または c の文字は Bidi_Class=ON かつ Bidi_Mirrored=Y であることが保証されます。 実装はこれを利用して最適化できます。 >>178

[228] なお Unicode の用語としての鏡像化 (mirror) は、 左横書き用 vs 右横書き用で逆になることを意味していて、 必ずしも左右対称であることを意味していないようです。

[359] 数式では 「]a,b[」 のように意図的に通常と異なる括弧の向きで使われることがあり、 右横書きでも同じようになることが特に注意されています >>13。

[360] 引用符は、 括弧と似た性質を持ちつつも、 言語ごとにいろいろな字形といろいろな用法があり、 フォントによっても字形が違い、 相当複雑な状況になっています >>13。 « や 「 の類は Bidi_Mirrored ですが、 ” の類はそうではありません。 ’ が引用符かつアポストロフィーであることも厄介なようです。 Vertical_Orientation も R や Tr ですが、必ずしもそれが適切な表示となるとは限りません (>>309)。

[372] U+16A0 - U+16F0 の Runic は、 左横書き、 右横書き、 牛耕式などいろいろに書かれました。 字形にも鏡像化や上下反転のものがありました。 また書字方向関連以外でもいろいろな字形の異体字がありました。 >>370 Bidi_Mirrored は偽なので、 グリフの選択には別の手段を使う必要があります。

OpenType の鏡像化

[183] OpenType は左横書き / 右横書きのため、

• [184] Character-level mirroring
• [185] Glyph-level mirroring
• [186] LTR glyph alternates / RTL glyph alternates

... の3種類の方法を提供しています。 >>182

[188] Glyph-level mirroring は、 フォント機能 rtlm / ltrm によって鏡像化された別グリフを選ぶものです。 >>182, >>190, >>499

[192] LTR glyph alternates / RTL glyph alternates は、 フォント機能 ltra, rtla によって鏡像化でない別グリフを選ぶものです。 >>182, >>191, >>499

[500] ltra, ltrm, rtla, rtlm は、普通は GSUB 表の lookupType 1 を使うことが想定され >>190, >>191, >>499、 その場合1つのグリフを1つのグリフへと置換する規則を記述できます。

[501] 左横書きが主な用法なら cmap で左横書き用のグリフを指定し、 rtlm / rtma で右横書き用のグリフに置き換えるように設計できます。 右横書きが主な用法なら cmap で右横書き用のグリフを指定し、 ltrm / ltra で左横書き用のグリフに置き換えるように設計できます。

[99] OpenType の仕様書は対称形かどうかで ltrm / rtlm と ltra / rtla を区別しているようです。 実際のフォントでは必ずしもそうなっていません。 何を想定して区別しているのかよくわからないです。

[189] 左横書きのグリフから右横書きのグリフの置き換えは Character-level mirroring によっても行われます。これはまず OpenType Mirroring Pairs List (OMPL) の文字の組に基づき他の文字にまず置き換え、 その文字のグリフを選ぶものです。

[502] このリストは Unicode 5.1 の Bidi_Mirroring_Glyph でした (>>180)。 今後も変更されることはないとされています。 >>182, >>187

[503] 以後 Unicode に追加された文字は他の2つの手法で扱うことになります。

[504] 利用頻度が高く古くから Unicode にあったアラビア文字やヘブライ文字に関係する文字は OPML に入っているものが多く、 それらはフォント内の情報ではなく固定の表を使って右横書きグリフが選択されることになります。 それより新しい文字や、フォント依存で右横書きグリフが存在するもの、 通常右横書きで左横書きグリフに置き換えるものは、 フォント内に情報を入れることになります。

[506] OPML に含まれている文字については、 フォントの rtlm (や rtla) に規則を含めてはいけません。 (そうしないと二重適用されて鏡像化しない状態に戻ってしまいます。) >>498

[507] OpenType フォントからのグリフの選択は、 次のようにして行います。 >>498

• [508] even resolved level (左横書き) の連なりにあっては、
  • [509] ltrm 機能と ltra 機能を連なり全体に適用します。
• [510] odd resolved level (右横書き) の連なりにあっては、
  • [512] OPML に含まれる文字は、 OPML によって置き換えられた文字が cmap において非 0 値 (グリフID) を持つなら、 そのグリフを使います。
  • [511] rtlm 機能と rtla 機能を連なり全体に適用します。

[513] Character-level mirroring (>>512) は文字からグリフへの変換であることに注意。 shaping engine で文字から文字への変換と実装することもできるのでしょうが。

[544] なお、 MERG はグリフの配置が決定した後に適用され、 ltr 用と rtl 用が記述できます。

Unicode の縦書き字形選択

[214] UCD特性 Vertical_Orientation (vo >>213) は、 参考であり >>174、 VerticalOrientation.txt >>173 に収録されています。

[215] Vertical_Orientation は列挙特性で、 値は次のいずれかです。 ファイルに明記されていないときの既定値は R です。 >>213

• [216] U は、正立 (Upright) で、 符号表と同じ向き (orientation) で表示されます >>213, >>243。
• [217] R は、 符号表から時計回りに90°回転して (Rotated) >>213, >>243、 横向き (sideways) に表示されます >>243。
• [218] Tu は、 typographical 的に変形したもの (Transformed typographically) で、 Upright にフォールバックします。
• [219] Tr は、 typographical 的に変形したもの (Transformed typographically) で、 Rotated にフォールバックします。

[244] Tu と Tr は、縦書き専用の、符号表とは異なるグリフが必要なものです。 専用グリフがないときのフォールバックとして U 型か R 型かで2分されています。 >>243

[208] 既定値は、 ほとんどの符号位置では R ですが、 predominantly Upright な用字系に関連付けられたブロックの未割当符号位置では U です。 >>207, >>213

[451] 私用文字も U です >>213 が、変更も認められます。 私用文字

[237] 既定値が R となっており、 値を決めかねるものはすべて R になっているようです。例えば制御文字や非文字は R になります。

[245] 日常語の文字に相当する概念は Unicode文字ではなく書記素クラスターです。 Unicode の縦書きにおける向き (orientation) は書記素クラスター単位で扱われます。 書記素クラスターの向きは、 最初の文字の向きです >>213。 ただし、 書記素クラスターが enclosing combining mark (General_Category=Me) を含むとき、 書記素クラスターの Vertical_Orientation は U です >>213。

[258] Vertical_Orientation は Unicode Standard の符号表の例示字形を基準に記述されています。 上位層プロトコルや応用は、 Vertical_Orientation とフォントの情報を勘案し適切なグリフの向きを決定することが求められています。 >>254

[418] Vertical_Orientation が Tu, Tr の文字は、 符号表の他に、 UAX #50 に代表字形がいくつか例示されています (>>260)。

[270] そのいずれも実装義務はありません。 Unicode 本体と UAX #50 を実装しているというだけでは、 どの字形が表示されるのかわからず、 別途上位層プロトコルの情報を加えれなければならないということになります。 グリフの選択

[381] bidi に対しては文字の向きを定め、 それが混在するときにどうレンダリングするか Unicode Bidirectional Algorithm で定め、 その既定のレンダリングが適切でないときに挙動を調整する特殊な文字が用意されています。 特殊な文字の代わりに上位層プロトコルで制御することも認められています。 一方縦書きに対しては、 文字の向きだけが定められ、 横書きとの混在の方法や、 既定の挙動が適切でないときの制御法を UAX #50 は定めておらず、すべて上位層プロトコルに任せられています。 bidi との対比でいえば、 縦中横や回転を調整する特殊な文字があってもよさそうなものですが。

[275] Unicode の半角の ASCII文字は、 すべて R とされています。 相当する全角英数字の方は、 文字ごとに U, R, Tu, Tr が決められているようです。 半角で欧字、 全角で「和字扱いの欧字」 (>>44) を表す出版業界の慣行に配慮したのでしょうか。 しかしそのせいで、 例えば日本語文中で句点としてよく使われる ? や ! が R なので倒した表示になってしまいます。

[277] 全角英数字は、 ラテン文字や算用数字を含む多くの文字が U です。縦書きで1字ずつ正立で並べる方法に使う想定なのでしょう。 半角文字は R で横倒し、 全角文字は U で正立で使い分ける便宜なのかもしれませんが、 「Â」 のような合成済文字は1種類しかないですし (全角の方は全角基底文字 + 結合文字で書けないこともないですが)、 JIS X 0208 にあって通例全角文字扱いのギリシャ文字やキリル文字も Unicode には1種類しかないので、 どうしても扱いに一貫しない面が出てきます。

[313] U 以外のもの >>276 をみると、

• [278] 表示位置などの問題がある句読点が U+FE01 (!), U+FE0C (,), U+FE0E (.), U+FE1F (?) の Tu、 U+FE1A (:), U+FE1B (;) の Tr にわかれています。
• [279] 3組の括弧は Tr となっています。
• [280] U+FF1C <, U+FF1D =, U+FF1E >, U+FF0D - が R となっています。
• [281] U+FF3F _, U+FF5C | が Tr となっています。
• [286] U+FF5E ~ が Tr となっています。

[282] 括弧が R、 実際上括弧として使われることも多い不等号が Tr と分かれていますが、 結局どちらも字形は縦型になることにはかわりありません。

[283] 数学記号としてもハイフンとしても使われることがある = や - が R なのは、妥当な判断でしょう。数学記号の + や * は U なので異なります。後者の字形が横書きか縦書きかで異なることも有り得そうですが、 フォントの設計次第ということで仕様的にはこれでいいのでしょう。 ただ U+00B1 (±) や U+00F7 (÷) が U なのと整合しないのは気になります。

[287] |, _ が Tr ですが、字形例を見ても特別なところがなく、 なぜ R でないのか不明です。 U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHEN も Tr で同様です。

[285] ~ が Tr なのは、 横書き例示字形が左半が上側へ、右半が下側へと丸まっている字形なのに対し、 縦書き例示字形が上半が左側へ、下半が右側へと丸まっている字形で、 単純な時計回り回転ではないためでしょう。 U+007E TILDE, U+02DC SMALL TILDE が R なのと扱いが違いますが、 U+301C WAVE DASH とは一致しています。 U+301C も Tr で、同じような字形です。 U+3030 WAVY DASH も Tr で、 山と谷の数が違いますが、 横書きと縦書きの関係は同様です。

[328] WAVE DASH と似た横書き字形の文字として数学記号扱いの U+223C TILDE OPERATOR があります。 その上下反転字形 U+223D REVERSED TILDE、 丸みを増した字形 U+223E INVERTED LAZY S もあります。 >>324 これらはいずれも Vertical_Orientation が R です。 Unicode の符号表の例示字形に従えば、 WAVE DASH の縦書きは U+223D REVERSED TILDE の方に近づきます。 なおこれら3文字は Bidi_Mirrored なので、 鏡像化される点が WAVE DASH や TILDE などとは違います。

[329] なお REVERSED TILDE は符号表に 「= lazy S」、 「reversed tilde and lazy S are glyph variants」 とあります。 >>324 例示字形は TILDE OPERATOR と REVERSED TILDE が組になっているように見えますが、 REVERSED TILDE は INVERTED LAZY S とも組になっているようです。 実際 JIS X 0208 では日本でよく見かける相似記号の字形が REVERSED TILDE となっていて、 むしろ 「∞」 に近い字形設計ですが、 どちらかといえば INVERTED LAZY S と組にするべきといえます。 ちなみにその 「∞」 は U です。 字形が似ていたとしても、 演算子の 「∽」 と数字や変数に準じるのであろう 「∞」 とでは扱いが異なるということでしょう。

[295] " や ' や ` や ^ は U です。なぜ R にしなかったのかは謎ですが、この辺は扱いが難しそうです。

[284] 半角カナは、日本語文字であるにも関わらず、 句読点や鉤括弧も含めすべて R です。

[312] U+FE50 - U+FE6B の SMALL 系の句読点類は、 相当する全角英数字等とも扱いが微妙に違っています。

[288] ともかく半角と全角でこれほど扱いが違うので、 安易に互換分解 (NFKC、NFKD) するのは危険です。

[317] 日本語の長音符号 (>>4) のうち U+30FC ー は、 Tr で、 横書きは横線、 縦書きは縦線となっています。 例示字形は筆押さえがあって単純な回転ではありません。 書体設計次第では回転でも十分かもしれませんが、 一般には Tr としておくのが妥当でしょう。 よく誤って長音符号として使われるハイフンや負符号の類は R で、向きは同じように変化します。 Unicode は日本語の右横書きを想定していないようで、 鏡像化の対象には指定されていません。

[316] 長音符号の異体字の記述に使われる 「〜」 および関係する文字は、 同じく Tr です (>>285)。 これらも鏡像化の対象に指定されていません。

[302] 長音符号の異体字の記述に使われる 「→」 は、 R です。 この他矢印の類は概ね R で、指す方向が変化します。 鏡像化の対象には指定されておらず、 左横書きと右横書きでは変化しないのに、 縦書きにすると変化するのは一貫していません。 日本語の右横書きを持ち出さずとも、 化学変化式で使われることを考えると、 不等号が鏡像化されるのと一貫していません。

[300] 小書き仮名は、 Tu で、 横書きは下寄せ小書き、 縦書きは右寄せ小書きとなっています。 鏡像化の対象にはなっていませんが、 フォントの設計次第では左右で字形を変える必要があるかもしれません。

[241] JIS X 0213 の縦書き例示字形がある文字や、 JIS X 4051 の縦書き字形がある文字と Tr, Tu, R を比較すると、 やや出入りがあります。 >>242

[305] ; は JIS に縦書き字形がなく、 Unicode には縦書き字形が回転したものとしていないもので、 複数示されています。

[306] _ や | や ~ は JIS に縦書き字形がありませんが、 Unicode では縦書き字形が示されています。

[308] 逆に U+2013 の – や U+2014 の — は JIS に縦書き字形がありますが、 Unicode では R です。 結局同じような表示になるのですが、 _ や | との扱いの違いは不思議です。

[307] U+00AB の « などは JIS には縦書き字形が示されていますが、 Unicode では R です。結局同じような表示になるのですが、 Unicode は他の括弧類を Tr としていて一貫していません。

[309] U+2018 の ‘ や U+2019 の ’ は JIS には縦書き字形が示されていますが、 Unicode では R です。

[310] U+2025 の ‥ や U+2026 の … は JIS には縦書き字形が示されていますが、 Unicode では R です。結局同じような表示になるのですが、 これらの文字は欧文横書きでは下点、 日本語横書き・縦書きでは中点と別な表示になるものを同じ符号位置に統合してしまっている点が要注意です。

[362] Unicode Standard は横書きについてはこの 「East Asian typographic traditions, particularly in Japan」 における中点の表現を 「In practice, it is relatively common for authors of East Asian text to substitute U+22EF midline horizon- tal ellipsis for this.」 と U+2026 のかわりに U+22EF を使うのが比較的一般的になっていると述べているのですが >>361、 JIS X 0208 と対応関係にあるのはあくまで U+2026 で、そうでない U+22EF が一般的になっているようには見えません。どこか特殊な業界でのことでしょうか。

[363] 縦書きについては、 U+2026 東アジアのフォントは縦書き字形を持つのが一般的で、 U+22EF も一般的になっている (has become popular) ので U+22EF の縦書き字形も持つことになる (will) とされています >>361。 縦書きグリフ選択が使えないシステムでは U+FE19 を使うのが望ましく、 U+22EE は数式用なので望ましくないとされています >>361。 (組合せて使う文字も参照。)

[272] Unicode の符号表で U+3031 - U+3035 のくの字点は、 「These characters are only used in vertical writing of Japanese.」 と注釈されています。 U+3031 VERTICAL KANA REPEAT MARK (〱) と U+3032 VERTICAL KANA REPEAT WITH VOICED SOUND MARK (〲) は、 例示字形が縦書き字形を1文字分の高さに圧縮したものでした。 「implemented as glyphs that are two-em tall」 と注釈がありました。 U+3033 VERTICAL KANA REPEAT MARK UPPER HALF (〳), U+3034 VERTICAL KANA REPEAT WITH VOICED SOUND MARK UPPER HALF (〴), U+3035 VERTICAL KANA REPEAT MARK LOWER HALF (〵) は、 例示字形が縦書き字形でした。 最初の2つに対して 「implemented as glyphs that are one-em tall and that combine with the following character to form ligated two-em glyphs for the complete repeat marks」 と注釈がありました。 >>271 これらはみな Vertical_Orientation=U でした。

[273] 縦書きで使う蒙古文字が符号表では横書き用に倒された字形で、 縦書きでは回転させることになっている (>>256) のとは、 扱い方が違っています。 2文字分に分かれた3文字などは、 符号表のままの字形では左横書きで使うことがまず不可能なのですが。

[274] U+303B VERTICAL IDEOGRAPHIC ITERATION MARK (〻) も文字の名前に 「VERTICAL」 と入っていますが、 特に注釈もありません >>271。 JIS X 0213 の同名の文字は大書きの縦書き字形と右寄せ小書きの縦書き字形のどちらもあり得るとしていますが、 Unicode は大書きの字形しか示しておらず、どのようなスタンスなのか不明です。

[266] Unicode に含まれる合略仮名の U+309F HIRAGANA DIGRAPH YORI (ゟ) >>267 と U+30FF KATAKANA DIGRAPH KOTO (ヿ) >>265 について、 符号表には通常の字形が表示されていますが、 相当する仮名2文字に <vertical> で互換等価という扱いにされています >>267, >>265。 符号表には 「historically used in vertical contexts, but now found also in horizontal layout」 と注釈があります >>267, >>265。

[314] U+00B2 の ² を始め、上付き、下付きの文字は R となっています。 この種の表現の縦書きは難しく苦心しているようですが 小書き 、 「いろ²」 のような日本語の踊り字の用法に R は馴染みません。(かといって U もおかしいですが。)

[351] U+25B6 BLACK RIGHT-POINTING TRIANGLE (▶) の類は U です。 U+23F5 BLACK MEDIUM RIGHT-POINTING TRIANGLE (⏵) の類は U です。 後者は特に媒体タイムラインの操作ボタンとしての利用が想定されているようです。 これらは矢印の類が R なのと扱いが違います。 三角形を矢印的なものや箇条書きのマークとして使うことがあるので要注意です。

@ フォント

[100] Windows ではフォント名に @ をつけると縦書きフォントになります。

[101] 左横書き環境でこのフォント名を使うと、 縦書き字形が選択された上で、 仮名や漢字は反時計回り90°回転した状態になります。 @フォント

RTF

[411] RTF には進行方向の指定 書字方向 や、 フォントの回転の指定がありました。

• 「vertically, non-vertical font」
• 「Font rotation」: 「Right」「Down」「Left」「Up」

JustView

[401] JustView の <multicol baseline=vert> を使った縦書きの実装は、 適用されるフォントの縦書き用の字形に切り替えていたようです。

[402] 左横書きで同じような横線に見えても縦書きで縦線に変わる文字とそうでない文字があったり、 プロポーショナルフォントを使うと字形が縦に揃わなかったりと不便があったようです。

<multicol baseline=vert>

JIS X 4052

[405] JIS X 4052:2000 6.1 によると、 '組方向' が '縦' (「縦書き」) または '横' (「横書き」、左横書きのこと) で指定できました。 body に必ず指定するよう求められていました。

[406] 「欧文用文字クラス及び連数字クラス」 は既定値が 「横書き」 で、 縦書き時は 「文字の並びの横軸を時計回りに 90度回転させた横書きとして表現」 することとされました。

[409] yoko 要素で縦中横が指定できました 6.17。 tate 要素で 「欧文用文字を縦書き中で和字扱い」 6.18 と指定して欧字や数字を正立で縦に並べられました。

[407] 「組方向に依存した約物の使い方及び表記方法 (数字の書き方など)」 は組方向変更時に書き換えなければならないとされていました。

[408] 'スラント' は、 横書きでは右側、 縦書きでは下側に変形するとされました。 6.2 4.2)

layout-flow

[412] 'layout-flow' は、

• 横書きで正立
• 横書きで正立、ただし縦書き文字は反時計回り90°回転
• 縦書き右左で正立、ただし横書き文字は時計回りに90°回転
• 縦書き左右で正立

の4モードを指定できるとしていました。 回転の有無の変更や縦中横は入れ子の指定で実現していました。

[413] 例示では「。」の位置が縦横で変わっていましたが、 規定本文には言及がありませんでした。

現代 Web プラットフォーム

[238] HTML の仕様書は bidi 処理を CSS を使って記述しています。 CSS は Unicode Bidirectional Algorithm を使って左横書きと右横書きの扱いを規定しています。 HTML にも CSS にも鏡像化に関する規定はなく、 Unicode のアルゴリズムの挙動を著者が制御する手段は提供されていません。

[520] 縦書き用字形の決定については、 仕様上は明確に定まっている (ことになっている) ものの、 現実は混乱した状況が続いています。 フォントごとにグリフの有無がまちまちである上、 UAX #50 と CSS の規定がそれぞれ問題を抱えており、 各Webブラウザーが仕様とは異なる独自の処理を行っているため、 相互運用性が低い状態です >>519。