[1] 書字方向によってグリフを選ぶ必要がある文字もあります。
[4] 長音を表す 「ー」 と、その異体字の 「〜」、 「→」 は、 左横書きでは横線右向き、 縦書きでは縦線下向きです。 異体字は近年のもので、 現代では特殊な場面でしか使われない右横書きの用例があるか不明ですが、 論理的には横線左向きとなるべきで、 鏡像化が必要です。 (「ー」 は左右対称にも見えますが、 フォント設計次第でグリフを変える必要が出てきます。)
[336] 他に !
, ?
, ;
, ,
, 、
あたりも鏡像化する可能性があります。
ゝ
や 〱
もでしょうか (どうやって?)。
。
, 小書き仮名などはアキの調整が必要な場合もあるかもしれません。
[339] 小書き仮名が左横書き用に左下に寄せた設計のフォントのとき、 右横書きでは右下に寄せるよう変更する必要があります。 (鏡像化ではありません。)
[340] 進行方向書きの実例を見ると、ーや小書き仮名は左右どちら向きでも違和感がないような書体設計になっているようです。 左横書き用をそのまま使っているっぽい事例もいくつか。
[315] 縦書きの踊り字が横書きで使いづらいためもあってか、 現代の日本では 「いろ2」、 「いろ×2」、 「いろ②」、 「それ2゙」 といった上付きの小書きで反復を表す表現が使われています。 ただし一部で使われるスラングのような扱いで、 公的な場面に現れるには至っていません。 こうした表現は左横書きに特化していて、 逆に縦書きでの表現方法に難があります。
[423] 貯蓄債券の広告, , http://tokyowanyosai.com/soft/shakai/pr-saiken.html
昭和17年2月の原文「
[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
漫画台詞「
[461] アクセント記号解説, , http://www.akenotsuki.com/kyookotoba/kisoaccent.html
縦書きの時は90度右回転させた◐→◓・◑→◒)を使って表記します。
[483] 近代から平成時代初期頃まで、 数値は縦書きでは漢数字、 横書きでは欧州数字 (漢数字でもよい) という使い分けが定着していました。 横書きで英字を使っても、 縦書きではカタカナにするのが好ましいとも言われていました。 (単位記号の組み文字がカタカナ表記なのは、縦書きでカタカナ表記に開いた結果長くなりすぎてスペースを取る & 読みにくくなるという事情もある。) 21世紀に入る頃から縦書きでも英数字がよく使われるようになり、 書字方向の違いよりも媒体のポリシーや個人の好みによる選択に寄ってきています。
[484] この縦書き向け、横書き向けの書き換えは膨大な辞書データや自然言語解析 (例えば「一石二鳥」や「九十九折」は欧州数字に置き換えられません。「四十九日」を置き換えていいのかはわかりません。) なく機械的に実現するのは難しく、 縦書き字形、横書き字形の切り替えとは別次元の機構で扱う必要があります。
[103] 日本政府の文部省の文書として、 くぎり符號の使ひ方, くりかへし符號の使ひ方 がありました。 昭和21年に公表され、 少なくても昭和38年に一度再出版されており、 後者は前者を再録したに過ぎないのですが、 前者が縦書き、 後者が左横書きで、 字形もそれに合わせて変わったり、変わらなかったりしていました。
[319] 「――」 や 「……」 については組合せて使う文字参照。
[421]
括弧付き文字は、縦書きでも縦中横で書かれます。
[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 には関係する文字のリストが追加されていましたが、 横書きのみ示されていました。 例文は別のものに変わっており、 縦書きの句読点として 「、」、 「,」、 「;」、 「。」 が含まれていました。
[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
機能を使って文字コードや書字方向と関係なく前後関係からグリフの縦横を変化させます。
[547] BabelStone Fonts : Khitan Small Script Fonts, https://www.babelstone.co.uk/Fonts/KhitanSmall.html
[151]
KLREQ
は、
横書きでは ,
、.
を使い、
縦書きでは 、
、。
を使うとしていました。
>>150
[538] ハングル声調符号 - 縦書きでは左、横書きでは左または上 (Unicode表現と書字方向についてハングル声調符号参照。)
[110]
疑問符はアラビア文字とヘブライ文字で向きが違います。
[161] 正立された縦書き、孤立形で縦に並べる例 >>160
[107] ヒエログリフは書字方向が自由でした。 生物の頭が書字方向を表すように字形が変化して使われていました。 >>106, >>108
[552] 23185-n5239-hieroglyphic-arrows.pdf, , https://www.unicode.org/L2/L2023/23185-n5239-hieroglyphic-arrows.pdf
[109] 古代ギリシャ文字は牛耕式で書かれ、 書字方向によって鏡像化していました。 >>108
[425]
通常の左横書きで装飾上用いられる合字は、
1文字ずつ正立させて縦書きするときは使いません。
例えば「
[426]
ローマ数字は例外で、
縦中横で合字化されることが多いようです。
日本語文中では例えば「
[535] 現代日本語ではしばしばラテン文字を1文字ずつ正立させて上縦書きします。 通常の左横書き用ラテン文字字形は小文字の上に約半文字分のアキが生じてしまうので、 縦に並べた時に字間が不自然に見えてしまいます (特に大文字と混在する場合)。 そこで上縦書き用字形はアキ量を調整したり、 字形自体を変更したりするようです。
[545]
CSUR に収録されている人工文字の Sarkai 文字 (サルカイ文字)
は上縦書きしますが、
対応フォントには縦書き用字形をそのまま収録したものと、
回転して横書きにして収録したものがあります。
[546]
CSUR に収録されている人工文字の
Kazat ʔakkorou 文字 (カザット・アッコロウ文字)
は左上縦書きしますが、
対応フォントは回転して横書きにして収録しています。
[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
では括弧類には 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
です。
[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 MARK
は JIS X 0213
も従来通りとしました。
[29]
LEFT SQUARE BRACKET
,
RIGHT SQUARE BRACKET
,
KATAKANA LETTER SMALL RO
は明らかに縦書きの字形に縦書きであると明記されておらず、
誤植と思われます。
(厳密に言えば縦書きの印が無いものは横書きとは書いていないので、
印がなくても誤りとは言えないのですが、まあ誤りでしょう。)
[30]
附属書7
によれば
DOUBLE EXCLAMATION MARK
,
DOUBLE QUESTION MARK
は
「縦書きでの利用を強く意識して」
追加されたもののようですが、横書きでも字形差がないためなのか、
縦書き字形とはされませんでした。
[34] 元号合字は横並びの形のみ示され、その他に縦書き字形は示されませんでした。
KATAKANA LETTER AINU P
[260]
UCD特性
Vertical_Orientation
(>>214)
が
Tu
,
Tr
の文字は、
符号表の他に、
UAX #50
に代表字形の例示があります。
横書き字形は、
符号表と同じような字形の他に、
別の字形例が示された文字もあります。
縦書き字形は、
それぞれ1つ以上の字形が示されており、
中には横書き字形と同じものが示された文字もあります。
>>259
[261] この縦書き字形や追加の横書き字形は、 フォントの実装が必ず用意しなければならないものではなく、 フォントの開発者は想定する地域の実情を調査し適当なグリフを提供するべきとされています。 >>259
[262] 複数の縦書き字形が例示された文字は、 小書きの位置や正立か寝かすかの違いで、 地域ごとに慣習が異なるものです。 同種の記号だからと使い方の違うものを1つの符号位置にまとめた皺寄せとも感じられます。
[263]
複数の横書き字形が示されたものは、
注音字母
U+3127
BOPOMOFO LETTER I
(>>153)
だけです。
横書き字形と縦書き字形の第一はどちらも横棒です。
横書き字形はそれに加えて縦棒が示されています。
>>259
なお符号表では横棒が示され、
「the vertical stroke form is considered a
rendering variant」
と注記されています >>264。
[290] 複数の縦書き字形が示されたものは、 4パターンあります。
Tu
で、
中央に大書きした字形と、
橋に寄せて小書きした字形が示されています。
台湾では大書きの字形が横書きでも使われるものも、
なぜか縦書きにだけ大書きの字形が示されています。:
と
;
は、
Tr
で、
正立で中央に大書きした字形、
横に寄せて小書きした字形、
時計回りに90°回転した字形の
3つが示されています。Tu
で、
横書きと縦書きに横並び半角ずつの字形が示され、
縦書きにはそれに加えて縦並び半角ずつの字形が示されています。Tu
で、
横書きと縦書きには左上から右下に「Z」型に配置した字形が示され、
縦書きにはそれに加えて右上から左下に「N」型に配置した字形が示されています。[303]
組み文字のうち仮名を組合せたものは、
Tu
で、
横書きと縦書きで仮名各文字の配置が違い「ー」の向きも違う字形が示されています。
漢字を組合せたものと、なぜか扱いが違っています。
[304]
U+1F201
SQUARED KATAKANA KOKO
は、
Tu
ですが、
横並びの「ココ」を四角形で囲った字形です。
横書きと縦書きも同様の字形ですが、
横書きはやや下寄せになっています。
意図は謎ですが、実際の利用形態がそうなのでしょうか。
[350] 句読点は符号表の例示字形や UAX #50 の横書き例示字形が1つでも、 Standardized Variants として 「corner-justified form」 と 「centered form」 が登録されています >>348, >>349。 符号表には小さいですが一応両方の字形例も示されています。 縦書きの各字形の差異も同程度に区別可能であるべき異体のように感じられますが、 Standardized Variants と UAX #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 MARK
は
Tr
ですが、
横書きと縦書きでは線の向きと位置が異なっています。
フォールバックの回転が適切とも思えませんが、
正立よりは確かにまだましな字形になりそうです。
[301]
゛
と
゜
は、
Tu
で、
横書きは左上小書き、
縦書きは右下小書きとなっています。
これらは結合文字ではなく単独の文字ですが、
通例「あ゛」のように結合済の文字がないときの代用として、
結合文字的に使われています。
横書き字形は基底文字の後に使われるのに適しています。
ところが縦書き字形は基底文字の前に使わないといけません。
右横書きでの鏡像化の対象にはなっていませんが、
縦書きの場合と同じように基底文字の前に左書きと同じ字形を置かなければならないことになります。
Unicode
で書字方向によって文字の配置順序を変えさせる例はあまりなく、
本当にこれが意図したものなのか疑問です。
[256] Unicode 7.0 から、 符号表の Mongolian と Phags-pa は横書き文に埋め込まれて使う、 時計回りに90°回転した字形に改められました。 それまでは通常の縦書き字形でした。 >>254
[257]
Unicode
で縦書きの表示方法を表す
Vertical_Orientation
特性の値は、
この横書き用の字形を基準に定められています。
この符号表の形式は、
OpenType
のような近年のレンダリングシステムとも一貫していて実装しやすい形である
>>254
とされています。
[246] 古くからある文字コードには、 特定の書字方向用の文字が符号化されていました。 一部は Unicode に取り込まれて現在まで残っています。 (古い製品に実装されていても Unicode にはないものもいろいろあります。)
[463]
古い Mule には
「Right-to-Left ASCII」
がありました。
[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 の制定時の公開レビュー公開資料 非漢字類の選定について, 版によると、 候補に縦書き用の字形が大量に収集されましたが、
縦書きの用途を想定した縦書き用連数字のように,組版の機能を利用することで実現可 能なものについては,基本的に,追加候補としないこととした。
... という理由で収録されなかったそうです。 縦書き文中で縦中横的に数字やラテン文字の単位記号を横に並べるため1文字扱いとしたものや、 縦書きの新聞などでよく使われる片仮名の単位の組み文字などが、 独自の拡張や外字として広く使われていました。
例外的に 「㍉」 などのNEC特殊文字だけは互換性のため標準化されました。 Windows などに実装され、 左横書き字形と縦書き字形が使われていたので、 JIS X 0213:2000 もその両方を例示していました。 縦書き専用という形にはなっていませんでした。
[250] JIS X 0213 は縦書き専用の文字は規定していませんでしたが、 縦書き用例示字形のみを示した文字 (踊り字) がいくつかありました (>>27)。
[452]
MacJapanese
は縦書き字形を別の区点位置に割り当てていましたが、
Unicode
に相当する文字が存在しないものもありました。
そこで
Apple
は私用文字として異体選択子的なものを独自に定義し、
独自の異体列的なものに対応付けていました。
[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。
返り点が一通り用意されていますが、
使い方が謎であまり利用されていないとみられます。
U+3190
IDEOGRAPHIC ANNOTATION LINKING MARK
は、
「tateten」
と説明があり、上下の漢字をひとまとめにすることを表す訓点を意味するようです。
例示字形は上半中央付近の短い縦線です。
Vertical_Orientation=U
です。
互換分解はなぜかありません。
<vertical>
HYPHEN
辺りになっていても良さそうなものですが。U+3191
IDEOGRAPHIC ANNOTATION REVERSE MARK
は、
「kaeriten re」
と説明があり、レ点を表すようです。
例示字形は上半やや左寄りの「レ」の字型ですが、
片仮名の「レ」の例示字形とはやや異なるように見えます。
Vertical_Orientation=U
です。
互換分解はありません。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
)
もあります。
.
、
:
、!
などがあるが、ラテン文字用と 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
と同様、
書字方向とグリフの扱いが全体として一貫している必要があります。
[400] フォントとその周辺の文字のレンダリング関連システムは、
... といった機構を持つ必要があります。
[87] JIS は、 JIS X 0208-1983 の時代に、 ビットマップフォントを2種類規定していました。
[88] 基本は横書き用の字形としつつ、 縦書きで字形が異なる場合も規定していました。
[89] このフォントをそのまま使う場合、 敢えて縦書きの字形が規定されたもの以外は、 横書き用の字形をそのまま縦に並べることが想定されたようです。
[67] 9051 と 9052 の縦書き用字形がある文字は一致していました。
後の JIS X 0208:1997 の縦書き用字形がある文字とは多少出入りがありました。
[489]
OpenType フォントはグリフの集合体として構成されています。
フォントの cmap
表によって文字コードから代表のグリフを取得し、
フォントの GSUB
表から書字方向に応じた機能を適用して適切なグリフに置換します。
[490]
グリフそれ自体のデータ構造は書字方向に依存せず、
正立状態の左下が座標原点、右が X軸、
上がY軸の座標平面で記述されます。
[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, 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 フィーチャーに対応している環境は現時点では限られていて、少数ではありますが、これを含めておくことは、先駆的な一歩を踏み出すことであり、長期的には有用なことに違いありません。
[523]
CMap では WMode
(writing mode の意)
の値
0
により左上横書きを、
1
により右上縦書きを表現できました。
>>522
[524]
またその名前は、
末尾に
-H
(horizontal の意)
や
-V
(vertical の意)
を付けることで区別しています。
>>522, >>529
[85] Adobe-Japan1 は、 横書き用の字形の CID と別に、 縦書き用の字形の CID も規定しています。
vert2
用です。[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, 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
[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] 例示中の「
[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
[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) 「
(広義の縦中横) 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。
[225] Unicode は bidi を表示順ではなく意味順に文字を並べることで実現しています。 その結果左横書きと右横書きで同じ意味でも字形が逆になるケースが出てきますが、 あくまで文字データは意味順で適切なものを選び、 表示の際に相応しいグリフを選ぶこととしています。
[221]
Unicode Bidirectional Algorithm
の
L4
は、
文字の解決済方向性が
R
であって、かつ文字の
Bidi_Mirrored
特性値が真である場合、その場合に限って、
鏡像化グリフで描画することと定めています
>>6。
ただし HL6
が適用される場合は例外となります
>>6, >>5, >>2。
[226] 意図した意味を表す適切な文字を使うため、 また相互運用性やセキュリティーを防ぐため、 実装は L4 に従い適切に鏡像化しなければなりません。 >>2
[222]
Unicode Bidirectional Algorithm
の
HL6
は、
上位層プロトコル次第で、
特定の状況で、
Bidi_Mirrored
特性値が偽であっても、
鏡像化グリフで描画できるとしています。
歴史的な用字系とその句読点、
私用文字、
数式中の文字などの状況が想定されます。
次のいずれかまたは両方の条件に合致する文字となります。
>>5
[177]
UCD
の特性
Bidi_Mirrored
は、
規定であり >>167、
UnicodeData.txt
>>175
に収録されています。
DerivedBinaryProperties.txt
>>210
にも収録されています (こちらの方が使いやすいかもしれません)。
値はブール型です。
真は鏡像化されることを、
偽はそうでないことを表します
>>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。
開き括弧と閉じ括弧で左右対称になっていない字形要素が含まれるようなケースが該当しているようです。
Bidi_Mirroring_Glyph
のある文字の一覧
https://chars.suikawiki.org/set/%24unicode%3Ahas-Bidi_Mirroring_GlyphBEST FIT
の文字の一覧
https://chars.suikawiki.org/set/%24unicode%3Ahas-Bidi_Mirroring_Glyph-BEST-FITBidi_Mirrored
と
Bidi_Mirroring_Glyph
の比較
https://chars.suikawiki.org/set/compare?expr=%24unicode%3ABidi_Mirrored&expr=%24unicode%3Ahas-Bidi_Mirroring_Glyph&expr=$unicode:has-Bidi_Mirroring_Glyph-BEST-FIT[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
で使われます。
[202] 例えば (
の型は o
(開き括弧) で、
対応するのは )
です。
Bidi_Paired_Bracket_Type
は対応する方ではなく、当該文字の方の種類を表しています。
[203] この情報は、
... な A, B について、
Bidi_Paired_Bracket (A) := B
,
Bidi_Paired_Bracket (B) := A
,
Bidi_Paired_Bracket_Type (A) :=
,
o
Bidi_Paired_Bracket_Type (B) :=
としたものです。
>>178c
[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
[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_
[228] なお Unicode の用語としての鏡像化は、 左横書き用 vs 右横書き用で逆になることを意味していて、 必ずしも左右対称であることを意味していないようです。
[359] 数式では 「]a,b[」 のように意図的に通常と異なる括弧の向きで使われることがあり、 右横書きでも同じようになることが特に注意されています >>13。
[360]
引用符は、
括弧と似た性質を持ちつつも、
言語ごとにいろいろな字形といろいろな用法があり、
フォントによっても字形が違い、
相当複雑な状況になっています >>13。
«
や
「
の類は
Bidi_Mirrored
ですが、
”
の類はそうではありません。
’
が引用符かつアポストロフィーであることも厄介なようです。
Vertical_Orientation
も R
や
Tr
ですが、必ずしもそれが適切な表示となるとは限りません (>>309)。
[441] paired stateful controls である非推奨書式文字の symmetric swapping format characters は、 symmetric characters (左側と右側の組になった文字) と共に使います。 >>440
[442] 文字の名前の左、右を、 開き、閉じと解釈するべきかどうかを表します。 >>440
U+206A
INHIBIT SYMMETRIC SWAPPING
は、
それ以後、
symmetric characters
を左側、右側と解釈することを表します。
>>440U+206B
ACTIVATE SYMMETRIC SWAPPING
は、
それ以後、
symmetric characters
を開き、閉じと解釈するべきことを表します (activated)。
>>440[443] 状態は activated かどうかの2つです。 入れ子にして使うことはできません >>440。
[444] 未使用の場合の既定の状態は、 activated です。 ISO/IEC 6429 など上位層プロトコルで上書きできます。 >>440
[448] 現在使われている bidi のアルゴリズムでは、 鏡像化は左横書きか右横書きかによって自動的に行われます。 括弧は文字の名前通りの左右ではなく、開き、閉じと解釈されます。 これが activated の挙動です。 activated でない場合、 自動の鏡像化は行われなくなります。
[445] symmetric swapping format characters は、 非推奨で、使うべきではありません。
[372]
U+16A0
- U+16F0
の
Runic
は、
左横書き、
右横書き、
牛耕式などいろいろに書かれました。
字形にも鏡像化や上下反転のものがありました。
また書字方向関連以外でもいろいろな字形の異体字がありました。
>>370
Bidi_Mirrored
は偽なので、
グリフの選択には別の手段を使う必要があります。
UnicodeData.txt
DerivedBinaryProperties.txt
BidiMirroring.txt
BidiBrackets.txt
[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
/ rtlm
と ltra
/ rtla
を区別しているようです。
実際のフォントでは必ずしもそうなっていません。
何を想定して区別しているのかよくわからないです。
[189] 左横書きのグリフから右横書きのグリフの置き換えは Character-level mirroring によっても行われます。これはまず OpenType Mirroring Pairs List (OMPL) の文字の組に基づき他の文字にまず置き換え、 その文字のグリフを選ぶものです。
[502]
このリストは
Unicode 5.1
の
Bidi_Mirroring_Glyph
でした (>>180)。
今後も変更されることはないとされています。
>>182, >>187
Bidi_Mirroring_Glyph
の文字の一覧
https://chars.suikawiki.org/set/%24unicode5.1%3Ahas-Bidi_Mirroring_GlyphBidi_Mirroring_Glyph
の比較
(付: Bidi_Mirroring_Glyph
BEST FIT)
https://chars.suikawiki.org/set/compare?expr=%24opentype%3Aompl-char&expr=%24unicode%3Ahas-Bidi_Mirroring_Glyph&expr=$unicode:has-Bidi_Mirroring_Glyph-BEST-FIT[503] 以後 Unicode に追加された文字は他の2つの手法で扱うことになります。
[504] 利用頻度が高く古くから Unicode にあったアラビア文字やヘブライ文字に関係する文字は OPML に入っているものが多く、 それらはフォント内の情報ではなく固定の表を使って右横書きグリフが選択されることになります。 それより新しい文字や、フォント依存で右横書きグリフが存在するもの、 通常右横書きで左横書きグリフに置き換えるものは、 フォント内に情報を入れることになります。
[506]
OPML に含まれている文字については、
フォントの rtlm
(や rtla
) に規則を含めてはいけません。
(そうしないと二重適用されて鏡像化しない状態に戻ってしまいます。)
>>498
[507] OpenType フォントからのグリフの選択は、 次のようにして行います。 >>498
[513] Character-level mirroring (>>512) は文字からグリフへの変換であることに注意。 shaping engine で文字から文字への変換と実装することもできるのでしょうが。
[544]
なお、 MERG
はグリフの配置が決定した後に適用され、
ltr 用と rtl 用が記述できます。
[214]
UCD特性
Vertical_Orientation
(vo
>>213)
は、
参考であり >>174、
VerticalOrientation.txt
>>173
に収録されています。
[215]
Vertical_Orientation
は列挙特性で、
値は次のいずれかです。
ファイルに明記されていないときの既定値は
R
です。
>>213
U
は、正立で、
符号表と同じ向きで表示されます
>>213, >>243。R
は、
符号表から時計回りに90°回転して
>>213, >>243、
横向きに表示されます >>243。Tu
は、
typographical 的に変形したもので、
Upright にフォールバックします。Tr
は、
typographical 的に変形したもので、
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
の縦書きにおける向きは書記素クラスター単位で扱われます。
書記素クラスターの向きは、
最初の文字の向きです >>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 との対比でいえば、 縦中横や回転を調整する特殊な文字があってもよさそうなものですが。
[382] UAX #50 (当初 UTR #50) は JLREQ の文字クラスを整理し Unicode 全体に拡大するところから開発が始まったようです。 >>383 当初案では JLREQ 由来の文字クラスを根拠に文字の向きを説明しようと試みていました >>383, >>384。
[392] 一時期、方向を表す特性は複数に分けられていました。
[396]
しかし svo と ho は廃止され >>390、
mvo は
Vertical_Orientation
となりました。
UAX #50 を参照する他の仕様書や議論が、
この廃止前の古い値を参照していることがあります。
[385] 字形の種別も何度か再編されました。
U
>>383S
(sideways) >>383 → R
>>387SB
(sideways, bracket) >>383 → R
>>387L
(反時計回り90°回転) >>389 → 廃止 >>390T
, TK
(位置をずらす小書き仮名) >>383 → T
>>384T
→ T
, Tu
, Tr
>>387T
→ Tx
>>397 → 廃止 >>398属する文字もかなり変更されていました。
[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種類しかないので、
どうしても扱いに一貫しない面が出てきます。
U+FE01
(!
),
U+FE0C
(,
),
U+FE0E
(.
),
U+FE1F
(?
)
の
Tu
、
U+FE1A
(:
),
U+FE1B
(;
)
の
Tr
にわかれています。Tr
となっています。U+FF1C
<
,
U+FF1D
=
,
U+FF1E
>
,
U+FF0D
-
が
R
となっています。U+FF3F
_
,
U+FF5C
|
が
Tr
となっています。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。
Decomposition_Type
が
Vertical
な文字は、
本項執筆時点で、
この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
なのと扱いが違います。
三角形を矢印的なものや箇条書きのマークとして使うことがあるので要注意です。
VerticalOrientation.txt
@
フォント[100]
Windows
ではフォント名に
@
をつけると縦書きフォントになります。
[101]
左横書き環境でこのフォント名を使うと、
縦書き字形が選択された上で、
仮名や漢字は反時計回り90°回転した状態になります。
@
フォント
[411] RTF には進行方向の指定
[401]
JustView
の
<multicol baseline=vert>
を使った縦書きの実装は、
適用されるフォントの縦書き用の字形に切り替えていたようです。
[402] 左横書きで同じような横線に見えても縦書きで縦線に変わる文字とそうでない文字があったり、 プロポーショナルフォントを使うと字形が縦に揃わなかったりと不便があったようです。
[405]
JIS X 4052:2000 6.1
によると、
'組方向'
が
'縦'
(「'横'
(「body
に必ず指定するよう求められていました。
[406]
「
[409]
yoko
要素で縦中横が指定できました 6.17。
tate
要素で
「
[407]
「
layout-flow
[412]
'layout-flow'
は、
の4モードを指定できるとしていました。 回転の有無の変更や縦中横は入れ子の指定で実現していました。
[413] 例示では「。」の位置が縦横で変わっていましたが、 規定本文には言及がありませんでした。
[238] HTML の仕様書は bidi 処理を CSS を使って記述しています。 CSS は Unicode Bidirectional Algorithm を使って左横書きと右横書きの扱いを規定しています。 HTML にも CSS にも鏡像化に関する規定はなく、 Unicode のアルゴリズムの挙動を著者が制御する手段は提供されていません。
[520] 縦書き用字形の決定については、 仕様上は明確に定まっている (ことになっている) ものの、 現実は混乱した状況が続いています。 フォントごとにグリフの有無がまちまちである上、 UAX #50 と CSS の規定がそれぞれ問題を抱えており、 各Webブラウザーが仕様とは異なる独自の処理を行っているため、 相互運用性が低い状態です >>519。
[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
[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
[345] Web Fonts で指定したフォント符号化の独自絵文字が回転されるのを回避。
[364] Word で縦書きし印刷すると句読点などが崩れる: 世の中は不思議なことだらけ () https://snow-white.cocolog-nifty.com/first/2019/07/post-f228d1.html
[420] 1「M's」や「B'z」といった文字を縦書きにするとどういう表記が... - Yahoo!知恵袋 (Yahoo! JAPAN, ) https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1367094243
[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