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

tomo.（むにゃむにゃ） @MnjaMnia

組版の話自体に文字コードは関係ないのでは? 抽象文字概念に相当するものがあれば判断できるんじゃないかと思いますが RT @TokKoba: 「戦前の組版の例」戦前には文字コードはないと思います。活字組版の歴史と、コンピュータ（デバイス、文字コード、フォント、ソフト）による文書処…

Tokushige Kobayashi @TokKoba

@MnjaMnia 「戦前の組版の例」戦前には文字コードはないと思います。活字組版の歴史と、コンピュータ（デバイス、文字コード、フォント、ソフト）による文書処理の発生は別ものです。いまはほぼすべてコンピュータ組版ですが、二つの流れが如何に合流したか？

tomo.（むにゃむにゃ） @MnjaMnia

戦前の組版の例とかも挙げられてたような気がするのですが RT @TokKoba: …郎と松　http://t.co/QGuY7x5k　をみても、初期のデバイスなどの技術的制約のために縦組時に横倒しになってしまったと見られる半角英数字の方向を金科玉条のごとくに持ち上げるのは間違い。

Tokushige Kobayashi @TokKoba

縦組みにおける半角文字の方向―MS-DOSの一太郎と松　http://t.co/cCiTtLVh　をみても、初期のデバイスなどの技術的制約のために縦組時に横倒しになってしまったと見られる半角英数字の方向を金科玉条のごとくに持ち上げるのは間違い。

Tokushige Kobayashi @TokKoba

@longvillage 私たちの周りで組版について最高の見識をもつといわれている長村さんの賛同で勇気百倍です。現在、Formatterに実装してもらっていますので、その意義をいづれ立証できると思います。

Tokushige Kobayashi @TokKoba

http://t.co/uZDH67cR　この記事には、５０万部、１５歳（全角文字）と30歳（ASCIIコード）、30年間が両方混在している。横組みだとそれほど気にならないが、縦組み（MVO方式）では、全角文字は上下に並び、ASCIIコードは、横倒しか（自動）縦中横で表示される。

Tokushige Kobayashi @TokKoba

縦組みにおける半角文字の方向―MS-DOSの一太郎と松 http://t.co/cCiTtLVh

ものかの @monokano

@TokKoba Devanagari は分解のプロパティがありますけど、 GSUB はこれとは別レイヤーなので、一緒くたにして Unicode 時代と言うのもどうかとは思います。

Tokushige Kobayashi @TokKoba

@monokano 「さんが強引に一般化しすぎなんです〜」Unicodeの仕様書を読まれると、強引ではないことが良く分かると思いますよ。ブログでは、ビットマップディスプレイ＋Unicode＋OpenTypeと書きましたけどね。

ものかの @monokano

@TokKoba さんが強引に一般化しすぎなんです〜。OpenType機能を「Unicode時代」なんて言うんですから。Unicode時代というなら IVS こそ典型例です。

Tokushige Kobayashi @TokKoba

@monokano IVSは、Unicodeで異体字指定ができるという意味で、かなり特殊な例ではないでしょうか。文字コードレイヤとグリフレイヤの間の対応関係を一般化するのはそう簡単ではないと思います。

bun @POKEPEEK2011

ちょっと古い「新潮45」（2011/12月号）を読んでいたら、英数字の正立・回転の例となる記事があったのでスキャンした。iPod Touchで写真を取るよりきれい。例によってAIR草紙で再現と他の表示方式をテスト。http://t.co/9TYCi2nO。 #UTR50

拡大

Jun Tajima @JunTajima

@TokKoba ありがとうございます。InDesignは最終的に印刷で望ましい字形が出ればいいという考え方のもとに拡張を繰り返してきたと思うので、InDesignのデータをもとにEPUB等を作ろうとすると収拾がつかなくなるという・・・そこが終着点なら何の問題もないんですが。

Tokushige Kobayashi @TokKoba

@JunTajima いや、私はInDesignを使ったことがないのですが、良く問題を網羅していると思います。InDesignは表示字形＝印刷された字形がすべてという思想で作られているんですね。EPUBのような XML＝文字コードベースで情報を交換するという考えとは別の世界。

ものかの @monokano

@TokKoba IVS を例にするといいと思います〜

ものかの @monokano

@TokKoba マップは直接の対応関係を示すものだと思うので、直接ではない対応関係も含むのなら「InDesignはグリフを表示するまで多様なルートがある」と表現するのが適切かと思います。

Tokushige Kobayashi @TokKoba

@TokKoba @monokano 「広義では文字コード列から表示字形列への対応関係です。」リガチャはその例。特にDevanagari文字などでは、文字の並びによって表示字形の列ががらりと変わります。文字コード列から表示字形列への対応をソフトウエアで行なうのがUnicode時代

Jun Tajima @JunTajima

@TokKoba @monokano なるほど、参考になります。基本的にあれは技術面での専門知識のない編集者の方でもわかるように書いたもので、技術者向けの厳密な文書ではないので、詳しい方から見た場合細かいツッコミは無数に入るだろうとは思います。むしろ是非ツッコミお願いしますw。

Tokushige Kobayashi @TokKoba

@JunTajima @monokano いや、間違っているとは思っていません。 http://t.co/NOsp3j49　の４行目は文字コードからグリフへの対応という意味を広義に捉えれば適切な表現と思います。アドビはCIDが中核なのでUnicodeとアーキテクチャが違います。

Tokushige Kobayashi @TokKoba

@monokano 「グリフ置換は字体包摂の文脈だと思うのです」狭義ではそうですが、広義では文字コード列から表示字形列への対応関係です。InDesignでは①字体包摂、②複数の文字コードから一つの表示グリフへの対応、③独自文字番号から表示グリフへ対応等の多様なマップがある。

Jun Tajima @JunTajima

@TokKoba @monokano 横からすみません。私も現場の人間で今回のために調べて書いている感じですので、細かい部分での間違いはあって当然と思ってます。ブログなり何なりでガンガン突っ込んでください。いろんなレベルで反応が起きるのは望むところで、とてもありがたいです。

eXism info by KAZU @eXismInfo

@TokKoba 知りませんでした。読んでおきましょうか、、、。

Tokushige Kobayashi @TokKoba

@monokano 「それは文字とグリフの対応関係で」の「それ」は　http://t.co/NOsp3j49　の１頁４行目の親字（キャラクター）を指していますか？

ものかの @monokano

@TokKoba で、グリフ置換は字体包摂の文脈だと思うのですよ。これを符号位置と字形の分離の文脈を前景にして示すのは強引かなーと

ものかの @monokano

@TokKoba cmap と GSUB を介して対応関係にある、という言い方はできますね。