UTR#50（Unicodeの縦書きの文字の向き）の話題 #UTR50

Taro Yamamoto @ragged_right

より正確には、直接対応付けていなくても、何らかの形で対応付けることを前提としている。#UTR50

Tokushige Kobayashi @TokKoba

#UTR50 の議論が複雑になるのは紙上に見える文字はグリフを可視化した結果であるのに対し、MVO・SVO案は文字のコードポイントに対する属性として定義しようとするものであること。UnicodeではCharacter-Glyphモデルで両者を分けているがそれを理解できていない。

村上真雄 MURAKAMI Shinyu @MurakamiShinyu

http://t.co/0ekLk1wU この回答によると、やはりCSS3 text-orientation:uprightは矢印に使えない。こうなるとEPUB3制作ガイド等で「矢印など方向性がある記号を正立させるには正立指定ではなく縦中横を使うこと」と周知する必要 #UTR50

村上真雄 MURAKAMI Shinyu @MurakamiShinyu

CSS3縦書きで text-orientation:upright を指定してもフォントによって矢印の向きが変わる問題についてwww-styleに投稿。http://t.co/WPitF9lj 向きが重要な文字に向きを正立にする指定が使えないような仕様はだめだと思う #UTR50

村上真雄 MURAKAMI Shinyu @MurakamiShinyu

#UTR50: ☝☟☜☞や矢印類のことで、EPUBの縦書きで問題だと思うのは、正立させようと-epub-text-orientation:uprightを指定してもビューワとフォントによって矢印の向きが変わってしまうこと。前にも書いたけど→http://t.co/VxQOaOcx

村上真雄 MURAKAMI Shinyu @MurakamiShinyu

#UTR50: ☝☟☜☞WHITE UP POINTING INDEX等はMVO=R（縦書きで回転）なのに👆👇👈👉U+1F446 WHITE UP POINTING BACKHAND INDEX等がU（正立）は疑問なので書いた☞http://t.co/5Sck8eHk

村上真雄 MURAKAMI Shinyu @MurakamiShinyu

@TokKoba コメント書きました。#UTR50 http://t.co/HFuvx602

Tokushige Kobayashi @TokKoba

UTR#50のフォーラムでの質問に答える http://t.co/i9U04cIV　Google translateでうまくいくだろうか？ #UTR50

Tokushige Kobayashi @TokKoba

日本語しか使わない縦組み文字の方向を英語で説明しなけれなならない情けなさったら･･･「http://t.co/V9Crkjbm」　RT @higashi2008 百家争鳴してる間に、米国にデファクトスタンダードを握られないよう祈る

Tokushige Kobayashi @TokKoba

http://t.co/V9Crkjbm The approach of UTR#50 is different from Japanese standards #UTR50 に投稿しました。タイトルは「違いについて」ですが、結論は「間違いについて」です。

Tokushige Kobayashi @TokKoba

＃UTR50 JIS X4051に準拠する、という観点から見るとMVOには致命的な問題点があるようです。縦組みのデフォルトというときは和字だけを考えて規定し、欧字は対象外としないといけない。和字と欧字の両方の振る舞いができる文字や記号は和字の振る舞いでデフォルトを与えること。

Tokushige Kobayashi @TokKoba

#UTR50 縦組みにおける記号の扱い―JIS X4051を検討して見えるもの http://t.co/fiM1SBiQ JIS X4051では数字や欧文記号は和字と欧文用文字に2重に分類している。つまり欧文を別世界と考えており縦組みで字形や方向が変わるのは和字としての記号だけ。

Tokushige Kobayashi @TokKoba

#UTR50 縦組みにおける英数字・記号の方向・字形変更は、文字のコードポイントからグリフへのマップの問題。コードポイント自体に方向を設定するのはハードコード方式であり、柔軟なマッピングを妨げるという点で望ましくない。JIS X4051、JIS X2013などにも違反する。

Tokushige Kobayashi @TokKoba

「縦組みにおける英数字正立論」0.50版としました（PDF, EPUB版を無償配布中）。これは日本語の縦組みにとっては重要な問題と思いますので、ご批判を賜りたく。http://t.co/qKo762Zn #UTR50

bun @POKEPEEK2011

3つ目の「：；（）」の正立。まさに#UTR50での文字の正立・回転の対象文字で、@aobekaさんは［＃縦組み］［＃縦組み終わり］注記の必要を示唆されていた（私は［＃縦中横］で対応できると思っていたが、やはり別に［＃縦組み］注記があったほうが良さそう）。 @aobeka

bun @POKEPEEK2011

６月に話題にしていた青空文庫　ポー「黄金虫」の注記見直し、そろそろまとめようとしたら、未解決のまま中断していた。問題は3つ。1つはこのごろ話題にしていた扉裏のエピグラム？の処理で、これは考察継続中。2つ目は縦中横中の数字の斜体、3つ目が「：；（）」の正立。

村上真雄 MURAKAMI Shinyu @MurakamiShinyu

http://t.co/QgoGezDk “text-orientation:upright is a forced upright; it always means upright (because #UTR50 does not define SVO anymore)”

藤井 太洋, Taiyo Fujii @t_trace

@MurakamiShinyu ありがとうございます。 #UTR50 が固まって、各種ビュワーが実装していれば原稿そのものを変更する箇所をもっと減らせたのですけど、現状のビュワーに対応しようとするとこのように別けるしかないのが辛いところです。

Tokushige Kobayashi @TokKoba

縦組み書籍における記号の方向に関する予備調査の結果 http://t.co/We6soUIj　記号の向きは本格的な調査が必要になりそうです。

Tokushige Kobayashi @TokKoba

@nitecruise Windowsのことは知らないんです。2倍ダッシュ問題は頭が痛いですが、縦書きだと、行の中央に来ないといけないのでそういう問題もありますね。しかし、罫線ですか？そういうやり方もあるんですね。

のりぃ @noly_sugii

ネックは他の関係仕様や実装に問題を起こしやすい要素がある事ですよね。フォントの縦書き用グリフがどう定義されているか？などは相当厄介なんじゃないかと思います。 RT @TokKoba: SVO/MVOの完全な実装は存在しない @nitecruise @MurakamiShinyu

Tokushige Kobayashi @TokKoba

@yasunori_sugii マークアップを実証的に試すには、SVO/MVOを実装した組版ソフトがないと試すことができません。でも仕様が未確定なので、完全な実装は存在しないのですが、まず、シミュレーションはできますでしょう。

のりぃ @noly_sugii

実装ありきのマークアップが良いとは全く考えていません。しかし、あらゆる実装が存在する中、一番問題を起こしにくい仕様内の作り方を採用し、それで意図通りにならない機種は、非推奨・非対応を謳えばよいと考えます。 @nitecruise @TokKoba @MurakamiShinyu

𝑛𝑖𝑡𝑒𝑐𝑟𝑢𝑖𝑠𝑒 @nitecruise

意図どおりに再現されないからマークアップがコスト要因になる文脈では？ 現に特定機種に合わせ込んだマークアップは氾濫しています。杉井さん、表現の話なのでカスタマーサポートなどに言及しないでください。@yasunori_sugii @TokKoba @MurakamiShinyu

のりぃ @noly_sugii

従いまして、意図的、明示的なマークアップはこれに見合う必要なコストであると私は考えます。 RT 制作ガイドラインを設計する立場でまず考えることは、出来るだけ問題を起こさず意図通りに制御できる制作方法です。 @TokKoba @MurakamiShinyu @nitecruise