縦書きグリフ

書字方向依存グリフ

[1] 書字方向によってグリフを選ぶ必要がある文字もあります。

日本語

[4] 長音を表す 「」 と、その異体字の 「」、 「」 は、 左横書きでは横線右向き、 縦書きでは縦線下向きです。 異体字は近年のもので、 現代では特殊な場面でしか使われない右横書きの用例があるか不明ですが、 論理的には横線左向きとなるべきで、 鏡像化が必要です。 (「」 は左右対称にも見えますが、 フォント設計次第でグリフを変える必要が出てきます。)

[458] 長音記号も参照。

[336] 他に !, ?, ;, ,, あたりも鏡像化する可能性があります。 もでしょうか (どうやって?)。 , 小書き仮名などはアキの調整が必要な場合もあるかもしれません。

[339] 小書き仮名左横書き用に左下に寄せた設計のフォントのとき、 右横書きでは右下に寄せるよう変更する必要があります。 (鏡像化ではありません。)

[340] 進行方向書きの実例を見ると、小書き仮名は左右どちら向きでも違和感がないような書体設計になっているようです。 左横書き用をそのまま使っているっぽい事例もいくつか。

[315] 縦書き踊り字横書きで使いづらいためもあってか、 現代の日本では 「いろ2」、 「いろ×2」、 「いろ」、 「それ2゙」 といった上付き小書きで反復を表す表現が使われています。 ただし一部で使われるスラングのような扱いで、 公的な場面に現れるには至っていません。 こうした表現は左横書きに特化していて、 逆に縦書きでの表現方法に難があります。

[423] 貯蓄債券の広告, , http://tokyowanyosai.com/soft/shakai/pr-saiken.html

昭和17年2月の原文「二月二十一日三月四日Webページの翻刻「二月二十一日→三月四日」

[433] 第139回 「菩薩」の略字―現代の抄物書き | 漢字の現在(笹原 宏之) | 三省堂 ことばのコラム, https://dictionary.sanseido-publ.co.jp/column/kanji_genzai139

[434] 第140回 中学生の文字 | 漢字の現在(笹原 宏之) | 三省堂 ことばのコラム, https://dictionary.sanseido-publ.co.jp/column/kanji_genzai140

「縦書き・横書き?」という生徒さんの書き込みもあった。なるほど縦書きにはどことなく「歳」が似合うため、大人でもそういう人がいる。

[436] 仮名漢字の後に「↑」「↓」 「⤴」「⤵」「↗」「↘」 などの矢印を使い、 「こ↑こ↓」 のように高低アクセントを記述する方法があります。 もっぱら左横書きで使われます。 上縦書き右横書きで表示されるとき、 どうなるべきか明らかではありません。

[437] 246dfa655aeb95cb82f093e2a484d5bd.jpeg (300×600) () https://ads.nicovideo.jp/assets/images/24/246dfa655aeb95cb82f093e2a484d5bd.jpeg

広告画像

総合戦力

3.99K⭡̣⭡̣上に長い

この上向き矢印は「up」 「上昇」 の意味。上向きであることに意味がある。

[456] からあげのるつぼさんはTwitterを使っています 「そう簡単に変わらないゾ #現場猫 https://t.co/FHvG3PReCz」 / Twitter, 午前8:15 · 2020年12月26日 , https://twitter.com/karaage_rutsubo/status/1342610060451540992/photo/1

漫画台詞「www

[461] アクセント記号解説, , http://www.akenotsuki.com/kyookotoba/kisoaccent.html

縦書きの時は90度右回転させた◐→◓・◑→◒)を使って表記します。

[483] 近代から平成時代初期頃まで、 数値縦書きでは漢数字横書きでは欧州数字 (漢数字でもよい) という使い分けが定着していました。 横書き英字を使っても、 縦書きではカタカナにするのが好ましいとも言われていました。 (単位記号組み文字カタカナ表記なのは、縦書きカタカナ表記に開いた結果長くなりすぎてスペースを取る & 読みにくくなるという事情もある。) 21世紀に入る頃から縦書きでも英数字がよく使われるようになり、 書字方向の違いよりも媒体のポリシーや個人の好みによる選択に寄ってきています。

[484] この縦書き向け、横書き向けの書き換えは膨大な辞書データや自然言語解析 (例えば「一石二鳥」や「九十九折」は欧州数字に置き換えられません。「四十九日」を置き換えていいのかはわかりません。) なく機械的に実現するのは難しく、 縦書き字形横書き字形の切り替えとは別次元の機構で扱う必要があります。

[541] 囲み文字

句読法

[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] 横書き移行に伴う変化について, , http://www.shosha.kokugo.juen.ac.jp/oshiki/essay/97yokoga.htm

[542] 押木 エッセイ等, , http://www.shosha.kokugo.juen.ac.jp/oshiki/essay/henkumi.htm

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

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

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

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

中文

[521] S02.pdf, , http://www.classics.jp/RCS/Sousho/S02.pdf#page=52

境界を示す符号の「|」は、シャヴァンヌは数字の「ー」 と釈す。

#page=58

横線の「|」

この論文左上横書きなので縦線で表されていますが、 現物では横線らしいです (その点は特に説明されていない)。

中華人民共和国

[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] CLREQUnicode縦書き符号位置は使うべきではなく、 他の仕組みで字形を置き換えるべきとしていました。 >>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] フォントによっては GSUBcamp 機能を使って文字コード書字方向と関係なく前後関係からグリフの縦横を変化させます。

蒙古文字、満州文字

契丹文字

[547] BabelStone Fonts : Khitan Small Script Fonts, https://www.babelstone.co.uk/Fonts/KhitanSmall.html

ハングル

[151] KLREQ は、 横書きでは ,. を使い、 縦書きでは を使うとしていました。 >>150

[538] ハングル声調符号 - 縦書きでは左、横書きでは左または上 (Unicode表現と書字方向についてハングル声調符号参照。)

中東系文字

[110] 疑問符アラビア文字ヘブライ文字で向きが違います。 ?

[161] 正立された縦書き孤立形で縦に並べる例 >>160

[162] アラビア文字と混在して使われる数式における鏡像化

ヒエログリフ

[107] ヒエログリフ書字方向が自由でした。 生物書字方向を表すように字形が変化して使われていました。 >>106, >>108

[552] 23185-n5239-hieroglyphic-arrows.pdf, , https://www.unicode.org/L2/L2023/23185-n5239-hieroglyphic-arrows.pdf

アルファベット系文字

[109] 古代ギリシャ文字牛耕式で書かれ、 書字方向によって鏡像化していました。 >>108

[425] 通常の左横書きで装飾上用いられる合字は、 1文字ずつ正立させて縦書きするときは使いません。 例えば「office」を縦書きすると 「office」 になり、「ffi」は合字化されません。 (前後の文字と続けて書かれるのが普通のアラビア文字ですら、 1文字単位に分離して縦に並べられます。)

[426] ローマ数字は例外で、 縦中横合字化されることが多いようです。 日本語文中では例えば「Ⅲ その他」のように箇条書きの記号として縦書きでもよく使われますが、 分解して縦に並べたり、寝かせたりすることはまずありません。 (フォント依存で「III その他」 と分離した字形になることはありますが、縦中横にはされます。)


[535] 現代日本語ではしばしばラテン文字を1文字ずつ正立させて上縦書きします。 通常の左横書きラテン文字字形小文字の上に約半文字分のアキが生じてしまうので、 縦に並べた時に字間が不自然に見えてしまいます (特に大文字と混在する場合)。 そこで上縦書き字形アキ量を調整したり、 字形自体を変更したりするようです。

人工文字

[545] CSUR に収録されている人工文字Sarkai 文字 (サルカイ文字) は上縦書きしますが、 対応フォントには縦書き用字形をそのまま収録したものと、 回転して横書きにして収録したものがあります。 CSUR

[546] CSUR に収録されている人工文字Kazat ʔakkorou 文字 (カザット・アッコロウ文字) は左上縦書きしますが、 対応フォントは回転して横書きにして収録しています。 CSUR

数式・科学的記法

[459] 「℃」などは1文字扱いの合字で広く実装されています。 横書きでも縦書きでも、この字形のまま正立させます。

[460] 縦書きで、「°」をその前の数字とまとめて縦中横し、 「C」を次の文字として正立させる例もあります。

矢印類、方向のある図形

[550] アクセント表記: >>436

[551] 矢印長音: 長音

[549] Miwa / Ensan - azooKeyの開発者さんはTwitterを使っています: 「細かすぎて伝わらない日本語入力気になるポイント:縦書きテキストの中で「みぎ」で変換すると、下向き矢印が出てくる https://t.co/FtYZzXd8ew」 / Twitter, , https://twitter.com/miwa_ensan/status/1681181183735107584

[514] 影鷹 : 以前の更新履歴 - リリース 0.1, , http://www.kagetaka.org/histories/0.1.html

「△▲▽▼」を回転させないようにした

文字コード

[476] 書字方向とそれによって生じる違いを文字コード文書形式 (マーク付けスタイル付け等)、 フォントのどの層でどう扱うかべきは難問で、試行錯誤が繰り返されてきました。 書字方向モデル

[477] 現代においては書字方向の違いだけから生じる字形の違いは文字コード層では扱わないとする原則が確立されています (が例外も多々あります)。

文字の名前と書字方向

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

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

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

例示字形の書字方向

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

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

[488] GB蒙古文字満州文字規格では

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

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


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

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

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

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

JIS の縦書き用例示字形

[19] JIS漢字縦書き用字形の示された規格

[22] JIS X 0208:1997書字方向が明示されない例示字形を示した他に、 非漢字の一部に参考として縦書き例示字形を示していました。 縦書きが示された場合、そうでない方は横書き用の字形が示されていましたが、 特にそうであるとは明言されていませんでした。

[23] 縦書きは網羅的でないとされており、その選択根拠は不明です。 例えば IDEOGRAPHIC FULL STOP には縦書きを示し、 FULL STOP には示していませんでした。 COLON には縦書きを示し、 SEMICOLON には示していませんでした。 EM DASH には縦書きを示し、 HYPHEN には示していませんでした。 EQUAL SIGN には縦書きを示し、 NOT EQUAL TO, GREATER-THAN OVER EQUAL TO, MINUS SIGN には示していませんでした。 LEFT ANGLE BRACKET には縦書きを示し、 LESS-THAN SIGN には示していませんでした。

[27] JIS X 0213:2000書字方向が明示されない例示字形と、 非漢字の一部に縦書き例示字形を示していました。 縦書き例示字形のみの文字が4つありました。 それ以外は縦書きが示された場合、横書き用の字形も1つ以上示されていましたが、 特にそうであるとは明言されていませんでした。 例示字形の2つ目以後は参考とされ、 縦書きのみの4文字以外の縦書きはすべて2つ目以後の字形として示されました。

[31] 4文字については附属書7に、 「一般の日本語では, 縦書き以外での利用がほとんど認められないことから, これらの図形文字の例示字体は, 縦書きのものだけを掲げている」 と説明がありました。

[47] この4文字のうち3文字はくの字点で、2文字を組合せて1セットで使うものでした。 縦書きグリフを2つ縦に並べれば繋がりますが、 横に並べると繋がりません。

[28] 縦書きはやはり網羅的でないとされており、その選択根拠は不明です。 JIS X 0208 にある文字は、 LEFT DOUBLE QUOTATION MARK, RIGHT DOUBLE QUOTATION MARK縦書き字形が削られた他は、 有無を変更しなかったようです。

[32] 附属書7によると、変更は 「実際の使用例などを勘案」 して JIS X 0208 の措置が不適切としたことによるようです。 しかし字形の状況は等しい LEFT SINGLE QUOTATION MARK, RIGHT SINGLE QUOTATION MARKJIS X 0213 も従来通りとしました。

[29] LEFT SQUARE BRACKET, RIGHT SQUARE BRACKET, KATAKANA LETTER SMALL RO は明らかに縦書きの字形に縦書きであると明記されておらず、 誤植と思われます。 (厳密に言えば縦書きの印が無いものは横書きとは書いていないので、 印がなくても誤りとは言えないのですが、まあ誤りでしょう。)

[30] 附属書7 によれば DOUBLE EXCLAMATION MARK, DOUBLE QUESTION MARK は 「縦書きでの利用を強く意識して」 追加されたもののようですが、横書きでも字形差がないためなのか、 縦書き字形とはされませんでした。

[34] 元号合字は横並びの形のみ示され、その他に縦書き字形は示されませんでした。

[21] JIS X 0208:1997 附属書4 (規定)

b) 文字 当該区点位置で表現される図形文字の字体を字形として例示したもの。

c) 縦書き 当該区点位置で表現される図形文字の字体を縦書きで表示する場合の字形を例示したもの。この例示は, 一部の区点位置についてだけ行った。この欄は, 参考であって規定の一部ではない。

[26] JIS X 0213:2000 附属書4 (規定)

c) 文字 当該面区点位置で表現される図形文字の字体を字形として例示したもの。

備考 “(SP)”, “(NBSP)” 及び “(SHY)” は, それぞれ SPACE, NO-BREAK SPACE 及び SOFT HYPHEN を表 し, 字形の例示ではない。

d) 字形例 当該面区点位置で表現される図形文字の字体で, 参考となるその他の字形がある場合の字形を例示 したもの。この例示は, 一部の面区点位置についてだけ行った。また, 縦書き用の字形が異なることがある 場合も字形例で示した。この欄は, 参考であって規定の一部ではない。

*は該当面区点位置で表現される図形文字において, 主に縦書きで使用される字形を例示したものである。

Unicode の縦書き用代表字形

[260] UCD特性 Vertical_Orientation (>>214) が Tu, Tr文字は、 符号表の他に、 UAX #50代表字形 (representative glyph) の例示があります。 横書き字形は、 符号表と同じような字形の他に、 別の字形例が示された文字もあります。 縦書き字形は、 それぞれ1つ以上字形が示されており、 中には横書き字形と同じものが示された文字もあります。 >>259

[261] この縦書き字形や追加の横書き字形は、 フォントの実装が必ず用意しなければならないものではなく、 フォントの開発者は想定する地域の実情を調査し適当なグリフを提供するべき (shoud) とされています。 >>259

[262] 複数の縦書き字形が例示された文字は、 小書きの位置や正立か寝かすかの違いで、 地域ごとに慣習が異なるものです。 同種の記号だからと使い方の違うものを1つの符号位置にまとめた皺寄せとも感じられます。

[269] せめてその情報を開発者向けにまとめておいてほしいものですが...

[263] 複数の横書き字形が示されたものは、 注音字母 U+3127 BOPOMOFO LETTER I (>>153) だけです。 横書き字形縦書き字形の第一はどちらも横棒です。 横書き字形はそれに加えて縦棒が示されています。 >>259 なお符号表では横棒が示され、 「the vertical stroke form is considered a rendering variant」 と注記されています >>264

[290] 複数の縦書き字形が示されたものは、 4パターンあります。

[303] 組み文字のうち仮名を組合せたものは、 Tu で、 横書き縦書きで仮名各文字の配置が違い「ー」の向きも違う字形が示されています。 漢字を組合せたものと、なぜか扱いが違っています。

[304] U+1F201 SQUARED KATAKANA KOKO は、 Tu ですが、 横並びの「ココ」を四角形で囲った字形です。 横書き縦書きも同様の字形ですが、 横書きはやや下寄せになっています。 意図は謎ですが、実際の利用形態がそうなのでしょうか。

[350] 句読点符号表の例示字形や UAX #50 の横書き例示字形が1つでも、 Standardized Variants として 「corner-justified form」 と 「centered form」 が登録されています >>348, >>349符号表には小さいですが一応両方の字形例も示されています。 縦書きの各字形の差異も同程度に区別可能であるべき異体のように感じられますが、 Standardized VariantsUAX #50 の関係性はよくわかりません。 なお、 Standardized Variants が登録されているのはなぜか全角文字の方だけで、 ASCII文字の方にはありません。


[296] Tr には括弧類が多く含まれています。 いずれも横書き字形を時計回りに90°回転したものが縦書き字形として示されています。

[297] なぜ R でなく Tr としたのか、 よくわかりません。 書体の設計次第で横書き縦書きに特有の調整があり得るとも考えられますが、 それをいうなら R で調整し得る文字は他にもいくらでもあるはずです。

[298] Bidi_Mirrored に含まれる鏡像化グリフ文字と比べると、 Tr括弧はごく一部に限られていることがわかります。 主に欧文用とみなされている括弧 (例えば >>307) や、 数式用とされている括弧括弧として使われることもあるものの本来不等号の記号類などは、 R とされているようです。

[311] U+2329 などは東アジア文字コードにない括弧ですが、 なぜか Tr で縦書き字形が示されています。

[299] U+301D REVERSED DOUBLE PRIME QUOTATION MARK, U+301E DOUBLE PRIME QUOTATION MARK, U+301F LOW DOUBLE PRIME QUOTATION MARKTr ですが、 横書き縦書きでは線の向きと位置が異なっています。 フォールバックの回転が適切とも思えませんが、 正立よりは確かにまだましな字形になりそうです。

[301] は、 Tu で、 横書きは左上小書き縦書きは右下小書きとなっています。 これらは結合文字ではなく単独の文字ですが、 通例「あ゛」のように結合済の文字がないときの代用として、 結合文字的に使われています。 横書き字形は基底文字の後に使われるのに適しています。 ところが縦書き字形は基底文字の前に使わないといけません。 右横書きでの鏡像化の対象にはなっていませんが、 縦書きの場合と同じように基底文字の前に左書きと同じ字形を置かなければならないことになります。 Unicode書字方向によって文字の配置順序を変えさせる例はあまりなく、 本当にこれが意図したものなのか疑問です。

[439] なお半角カナ濁点半濁点結合文字ではありませんが、 書記素クラスターとしては似たような扱いを受けます。

Unicode の蒙古文字等符号表の字形

[256] Unicode 7.0 から、 符号表MongolianPhags-pa横書き文に埋め込まれて使う、 時計回りに90°回転した字形に改められました。 それまでは通常の縦書き字形でした。 >>254

[257] Unicode縦書きの表示方法を表す Vertical_Orientation 特性の値は、 この横書き用の字形を基準に定められています。 この符号表の形式は、 OpenType のような近年のレンダリングシステムとも一貫していて実装しやすい形である >>254 とされています。

書字方向専用の符号位置

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

[15] 縦書き専用符号位置のある文字コード

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

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


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

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

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

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

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

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

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

[478] 「組版の機能」について、 JIS X 0213 の制定と同時期に (似たメンバーにより) JIS X 4051 が改定されました。

[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_OrientationR なので、 縦書き環境では逆に横向きになります。

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

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

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

[479] 確かにゴマ傍点縦書きで主に使われますが、 横書きの用例がないわけでもありません。 傍点

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

[358] 実際のフォントは大書きの字形にしているものもあります。

[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) もあります。

[334] アラビア語句読点は他に .:! などがあるが、ラテン文字用と unify されている。 bidi 処理により左横書き右横書きか自動決定され、 必要ならそれに応じてグリフの選択がなされる。

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

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

[403] Jドキュメントについて (, ) https://web.archive.org/web/20011102200606/http://www.nec.co.jp/bungo/10info/support/jdoc.html

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

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

[539] null, , https://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ReadMe.txt

類似字形による代替表現

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

組合せて使う文字

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

Teletex

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

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

フォントのグリフ

[400] フォントとその周辺の文字のレンダリング関連システムは、

... といった機構を持つ必要があります。

JIS フォント

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

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

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

[90] このフォント規格はその後改正も廃止もされずに放置されているようです。 JIS X 0208-1990, JIS X 0208:1997, JIS X 0213:2000, JIS X 0213:2004 とは整合していない上に追加された文字も欠けたままです。
[62] JIS X 9052-1983 2.

(3) 縦書き用字形 各行の文字が縦読みになるような文字の並びにおいて使用する文字。

[59] JIS X 9051-1984 2.

(3) 縦書き用字形 各行の文字が縦読みになるような文字の並びにおいて使用する字形。

[63] JIS X 9052-1983

3.2 横書き用字形と縦書き用字形 文字の並びは, 横書き及び縦書きとする。

(1) すべての文字に対して横書き用字形を定める。

(2) 横書き用字形の外に縦書き用字形を定める文字は, JIS X 0208 に規定している特殊文字の内, 記述記 号12文字, 括弧記号18文字及び学術記号1文字, 並びに平仮名小文字10文字及び片仮名小文字12 文字の計53文字とする。

参考 上記(2)の53文字以外の文字の字形は, 横書きを基本として設計されているが, 縦書きにも用 い る文字については, 縦書きに用いることも配慮してある。

[60] JIS X 9051-1984

3.2 横書き用字形と縦書き用字形 文字の並びは, 横書き及び縦書きと次のとおりとする。

(1) すべての文字に対して横書き用字形を定める。

(2) 横書き用字形のほかに縦書き用字形を定める文字は, JIS X 0208 に規定している特殊文字の内, 記述 記号12文字, 括弧記号18文字及び学術記号1文字, 並びに平仮名小文字10文字及び片仮名小文字 12文字の計53文字とする。

参考 3.2(2)の53文字以外の文字の字形は, 横書きを基本として設計されているが, 縦書きにも用い る文字については, 縦書きに用いることも配慮してある。

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

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

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

OpenType のグリフと機能

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

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

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

[491] 座標原点が左下にあるので左横書きのときが一番使いやすいという偏りはありますが。 なお厳密には下端ではなく英数字基線原点を通るので、 英数字に一番適した座標系という偏りもあります。

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

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

[494] なお、shaping によって結合文字等の配置順序が表示順に入れ替えられることはあります。 論理順, 表示順という言い方をしてもそれが何についてなのか要注意。
[518] 当然ながらデータ構造論理順であるからといって、 そこで記述されるデータが書字方向非依存であることを意味しません。 例えばカーニングは隣接する2つの字形の距離を調整します。 同じグリフの組を同じ順序で並べていても、 左横書き用のカーニング値と右横書き用のカーニング値は、 一般に異なる値になります。

[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

[497]フォントの事例はフォント機能参照。
[553] 文字関係
key
opentype:vert
desc
OpenType 機能 vert (または相当)。
[554] 文字関係
key
opentype:hkna
desc
OpenType 機能 hkna (または相当)。
[555] 文字関係
key
opentype:vkna
desc
OpenType 機能 vkna (または相当)。
[557] 文字関係
key
opentype:vrtr
desc
OpenType 機能 vrtr (または相当)。
[556] 文字関係
key
opentype:vrt2
desc
OpenType 機能 vrt2 (または相当)。

[517] 縦組み 「:」が倒れていない · Issue #6 · trueroad/HaranoAjiFonts · GitHub, https://github.com/trueroad/HaranoAjiFonts/issues/6

[533] [HarfBuzz] default features for vertical text runs, , https://lists.freedesktop.org/archives/harfbuzz/2013-August/003490.html

[530] Adobe Technical Note #5901 - 5901.Kazuraki_Tutorial.pdf, , 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版に対応 - しろもじメモランダム, https://shiromoji.hatenablog.jp/entry/20120306/1331028598

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

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

[540] 貂明朝」は日本語フォントの新たな領域へ, , 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規定しています。

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

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

[528] Adobe-Korea1KS 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, https://github.com/adobe-type-tools/cmap-resources/issues/2

[532] To V, Or Not To V, , https://ccjktype.fonts.adobe.com/2015/09/to-v-or-not-to-v.html

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

[536] Japanese Windows and hangul---JApanese and KOrean konzai-bun, , https://ha1.seikyou.ne.jp/home/akairingosaita/hangul/jako.htm#ks

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

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

[337] 文字の取り扱い - 超漢字ウェブサイト, , http://www.chokanji.com/ckv/manual/03-07-02.html

[464] Windows日本語フォントでのUAX50問題文字のテスト, Shinyu MURAKAMI, , , https://lists.w3.org/Archives/Public/public-i18n-japanese/2022JulSep/0028.html

[515] 書体を登録する - 超漢字ウェブサイト, , 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-1995JIS X 0208:1997縦書き字形を比べると、 JIS X 4051-1995 にだけあるのは JIS X 0208 にない文字と「・」 (「・」は字形は似ているが縦横幅の違い)。 JIS X 0208 にだけあるのは「=」。

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

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

[41] JIS X 4051-1995 2.

(40) 省略記号

例1. 横書きにおける前置省略記号 ¥$£

例2. 横書きにおける後置省略記号 °’”%‰¢

参考 片仮名単位字を含む全角単位字及び JIS X 0208 に含まれる単位記号は, この規格では省略記号 として扱う。

縦書きの片仮名単位字

(57) 中点類 (なかてんるい)

横書きにおける中点類 ・:;

参考 縦書きの和文では, セミコロン “;” を使用しない。

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

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

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

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

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

[43] JIS X 4051-1995 3.1 (1)

(a) 縦書きで漢数字の位取り記 号として使われる読点 “” 及び小数点として使われる中点 “” の字幅は半角とするが,

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

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文字で表されるもの) もいくつか含まれていました。

[142] JIS X 4052:2004JIS X 4052-1995 の表をベースに UCS から JIS X 0213 に置き換えたので JIS の符号位置・名前と UCS のブロックが示されるという矛盾があり、 JLREQJIS X 4052:2004 の表をベースに JIS X 0213 から UCS に置き換えたのでこのようなおかしなことが起こっているのでしょう。

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

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

  • [118] 「、」: 「縦組では使用する」「横組で使用する」
  • [120] 「。」: 「縦組では使用する」「横組で使用する」
  • [119] 「,」、「.」: 「横組で使用する」
  • [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] この辺の整理は CLREQJLREQ の整理を踏襲しています。 「相同的書寫方向,依字母逐個排列」 「保持正常方向,橫排處理(如日文的縱中橫排)」 「順時針方向旋轉90°」 >>143 KLREQ にも似た分類がありました >>158

Unicode の鏡像化

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

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

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

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

[177] UCD特性 Bidi_Mirrored は、 規定であり >>167UnicodeData.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_GlyphThe OpenType Mirroring Pairs List (OMPL) と一致していました (>>189)。 その後の Unicode 側の変更で一致しなくなっています。 >>178

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

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

[212] 現在の UCD の分類では規定です。 Contributory ではありません。 しかしファイルのコメントには 「normative contributory data file」 とあり >>171、 両方の性質を備えているものであるようです。

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

[202] 例えば ( の型は o (開き括弧) で、 対応するのは ) です。 Bidi_Paired_Bracket_Type は対応する方ではなく、当該文字の方の種類を表しています。

[203] この情報は、

General_Category (A) = Ps

General_Category (B) = Pe

Bidi_Class (A) = Bidi_Class (B) = ON

Bidi_Mirrored (A) = Bidi_Mirrored (B) = Y

Bidi_Mirroring_Glyph (A) = B

... な 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_Typeo または c文字Bidi_Class=ON かつ Bidi_Mirrored=Y であることが保証されます。 実装はこれを利用して最適化できます。 >>178

[20] ISO/IEC 10646 15 双方向文脈での鏡像文字

[37] JIS X 0221-1:2001 19. 双方向文脈での文字 は 「左向き用及び右向き用と対をなす文字の種類」 として括弧類を列挙していました。 文字の名前が「LEFT」や「RIGHT」であっても、 左右ではなく開き、閉じの意味であるとされました。 (GB 13000.1-93 20 も同じ) 附属書F (参考) 代替書式文字 F.2.2 にこれに関係する代替書式文字の説明がありました。 (GB 13000.1-93 附属書D D1.3 も同じ) 附属書P (参考) 文字に関する追加情報 にうち2文字の補足説明がありました。

[38]附属書E (参考) アラビア語の双方向文脈での鏡像文字 は 「図形記号の鏡像として表示してもよい」 文字を列挙していました。括弧類数学記号などが含まれていました。 (GB 13000.1-93 附属書Cも同じ)

[39] JIS X 0221:2007 19 は一覧表がなく、附属書Eを参照する形に改められていました。 それはユニコードBidi Mirrored の一覧と等しいと注記がありました。 附属書E (規定) 双方向文脈での鏡像文字 は 「図形記号の鏡像として表示してもよい」 文字を列挙していました。括弧類数学記号などが含まれていました。 附属書F (参考) 代替書式文字 F.2.2 にこれに関係する代替書式文字の説明がありました。 附属書P (参考) 文字に関する追加情報 にうち2文字の補足説明がありました。

[40] JIS X 0221:2014 15 はユニコード標準第6.1版の Bidi_Mirrord を参照する形に改められていました。

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

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

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

[441] paired stateful controls である非推奨書式文字symmetric swapping format characters は、 symmetric characters (左側と右側の組になった文字) と共に使います。 >>440

[442] 文字の名前の左、右を、 開き、閉じと解釈するべきかどうかを表します。 >>440

[443] 状態は activated かどうかの2つです。 入れ子にして使うことはできません >>440

[444] 未使用の場合の既定の状態は、 activated です。 ISO/IEC 6429 など上位層プロトコルで上書きできます。 >>440

[448] 現在使われている bidi のアルゴリズムでは、 鏡像化左横書き右横書きかによって自動的に行われます。 括弧は文字の名前通りの左右ではなく、開き、閉じと解釈されます。 これが activated の挙動です。 activated でない場合、 自動の鏡像化は行われなくなります。

[445] symmetric swapping format characters は、 非推奨で、使うべきではありません。


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

OpenType の鏡像化

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

... の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 / rtlmltra / rtla を区別しているようです。 実際のフォントでは必ずしもそうなっていません。 何を想定して区別しているのかよくわからないです。

[98]フォントの事例はフォント機能参照。

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

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

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

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

[505] 日本語右横書きに必要な句読点OPML に入っていないものもあるので、 フォントGSUB lookup を持つ必要があります。

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

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

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

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

Unicode の縦書き字形選択

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

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

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

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

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

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

[482] 制御文字でもフォントプラットフォーム依存の代替字形ANSIコードページ字形が表示されることがあるので、 まったく無意味でもありません。

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

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

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

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

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

[382] UAX #50 (当初 UTR #50) は JLREQ文字クラスを整理し Unicode 全体に拡大するところから開発が始まったようです。 >>383 当初案では JLREQ 由来の文字クラスを根拠に文字の向きを説明しようと試みていました >>383, >>384

[392] 一時期、方向を表す特性は複数に分けられていました。

  • [393] Default Vertical Orientation (dvo) >>386 改め Stacked Vertical Orientation (svo, SVO) >>387 は、 「parts of the world where characters are mostly upright」 で使う縦書き用とされました。
  • [394] East Asian Vertical Orientation (eavo) >>386 改め Mixed Vertical Orientation (mvo, MVO) >>387 は、 東アジアとりわけ日本支那Korea で使う縦書き用とされました。
  • [395] Horizontal Orientation (ho) は、横書き用とされました。 >>391

[396] しかし svoho は廃止され >>390mvoVertical_Orientation となりました。 UAX #50 を参照する他の仕様書や議論が、 この廃止前の古い値を参照していることがあります。

[385] 字形の種別も何度か再編されました。

属する文字もかなり変更されていました。

[388] 長らく tailoring 用と称して brackets set >>387, arrows set >>389 が定義されていました。 しかし使われないまま廃止されました >>399

[322] CSS WG との関係は CSS Writing Modes 参照。


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

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

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

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

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

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

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

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

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

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

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

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

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


[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+2013U+2014JIS に縦書き字形がありますが、 Unicode では R です。 結局同じような表示になるのですが、 _| との扱いの違いは不思議です。

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

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

[310] U+2025U+2026JIS には縦書き字形が示されていますが、 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 を使うのが比較的一般的になっていると述べているのですが >>361JIS 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」 と入っていますが、 特に注釈もありません >>271JIS X 0213 の同の文字は大書きの縦書き字形と右寄せ小書き縦書き字形のどちらもあり得るとしていますが、 Unicode は大書きの字形しか示しておらず、どのようなスタンスなのか不明です。

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

[268] U+2A708 CJK UNIFIED IDEOGRAPH-2A708 (𪜈) はなぜか CJK統合漢字で、 互換分解もされません。 扱いが一貫していません。
[289] Decomposition_TypeVertical文字は、 本項執筆時点で、 この2つの合略仮名を除けば U+FE10-U+FE46 の縦書き専用符号位置だけです。 まったく性質の異なるそれらと同一に扱うこの互換分解には疑問があります。

[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°回転した状態になります。 @フォント

[97] 縦書き編集 (, ) http://0ban.com/araken/qxhelp/tategaki.htm

フォント設定により 縦書き用フォント(1文字目が @)を使用すると、縦書き編集できます。

縦書き編集はウィンドウが時計回りに90度回転していると考えてください。

矢印キー(→←↑↓)の機能も時計回りに90度回転します。つまり、通常の横書き編集のときは → で「1文字右に移動」が実行されるとすると、縦書き編集では、↓ で「1文字右に移動」が実行されます。

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.17tate 要素で 「欧文用文字を縦書き中で和字扱い6.18 と指定して欧字数字正立で縦に並べられました。

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

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

layout-flow

[412] 'layout-flow' は、

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

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

現代 Web プラットフォーム

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

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

メモ

[111] 法令における拗音及び促音に用いる「や・ゆ・よ・つ」の表記について (, ) http://www5d.biglobe.ne.jp/~Jusl/Bunsyo/yayuyotu.html

(4) 小書きにした「や・ゆ・よ・つ」は、タイプ又は印刷の配字の上では一文字文として取り扱うものとし、(注)に示すように、上下の中心に置き、右端を上下の字の線にそろえる。

[112] (, ) https://upload.wikimedia.org/wikipedia/commons/d/d5/%E6%9D%A1%E4%BE%8B%E3%80%81%E8%A6%8F%E5%89%87%E7%AD%89%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E6%8B%97%E9%9F%B3%E5%8F%8A%E3%81%B3%E4%BF%83%E9%9F%B3%E3%81%AB%E7%94%A8%E3%81%84%E3%82%8B%E3%80%8C%E3%82%84%E3%83%BB%E3%82%86%E3%83%BB%E3%82%88%E3%83%BB%E3%81%A4%E3%80%8D%E3%81%AE%E8%A1%A8%E8%A8%98%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%EF%BC%88%E9%80%9A%E7%9F%A5%EF%BC%89.pdf

[417] イコール(=)の記号を縦に書いても意味はイコールですか? - 英語圏の... - Yahoo!知恵袋 (Yahoo! JAPAN, ) https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10114045845

英語圏の友人にイコール記号を縦に書いた資料を渡したら、どういう意味?と聞かれました。

日本ではイコールの記号を縦向きに書いても、イコールの意味になりますよね?

[419] 縦書きで約物(≠)の表記方法 - DTP駆け込み寺掲示板過去ログ (吉田印刷所, ) https://dtp-bbs.com/dtpbbs/archives/_20071012080443.html#gsc.tab=0

①使ってはいけない

②そのまま横書きと同じ表記に

③90度回転のみ(横一線が左上から右上に)

④90度回転後、横一線を右上から左上にする

のどれかだと思うのですが、ご存知の方いましたらアドバイスを

いただければ幸いです。

» 001

5.マイナス90度回転のみ(横一線が左上から右下に)

[341] GIMPで縦書き - mynote () http://reddog.s35.xrea.com/wiki/index.php?GIMP%E3%81%A7%E7%B8%A6%E6%9B%B8%E3%81%8D#icc5aa31

[344] EPUBで縦書きや組版を綺麗に表示する電子書籍ソリューション | BPS株式会社 () https://www.bpsinc.jp/epub.html#typesetting-fonts

縦書きでは、図のようにフォントが回転してしまうこともありますが(左側)、CSSの指定で回避可能です(右側)。

1 -epub-text-orientation: upright;

[345] Web Fonts で指定したフォント符号化の独自絵文字が回転されるのを回避。

[364] Word で縦書きし印刷すると句読点などが崩れる: 世の中は不思議なことだらけ () https://snow-white.cocolog-nifty.com/first/2019/07/post-f228d1.html

[376] 小さい「っ」の表示位置がおかしい?他テキストツール要望 | CLIP STUDIO PAINTの要望・不具合ボード | CLIP STUDIO () http://www.clip-studio.com/clip_site/support/request/detail/svc/54/tid/34432

CSPの方は、小さい「っ」の表示位置がおかしいように感じます。

これに限らず、CSPのテキストには、日本語縦書きの表示としてはおかしい?と言うような

違和感を感じる部分が多々ありまして、

[420] 1「M's」や「B'z」といった文字を縦書きにするとどういう表記が... - Yahoo!知恵袋 (Yahoo! JAPAN, ) https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1367094243

[427] フォント関連仕様調査部会について | 一般社団法人 文字情報技術促進協議会 (, ) https://moji.or.jp/wg/spec/

2020年は、縦書きEPUB文書での文字横転にまず着手します。

縦書きEPUB書籍の文字が、フォントの違いによって、横転したりしなかったりすることを確認します。

CSS Writing Modes仕様書、Unicode仕様書、OpenType仕様書の関連部分を調査します。

Adobe-Japan1フォントについてのデータ(GitHubに公開されているもの)を調査します。

有力なフォントが縦書きにどう対応しているかを調査します。

[453] 印刷データ→電子書籍で外字化が必要な文字のまとめ | 電書魂, http://densyodamasii.com/?p=314

[454] InDesignとEPUBの縦書き時の文字の向きの差について | 電書魂, http://densyodamasii.com/?p=2314

[455] UTR50(Unicode縦書きの文字の向き仕様)で注意を要する文字 | CSS組版ブログ, https://blog.antenna.co.jp/CSSPage2/archives/100