Re: Eric Muller からの提案

ナットです。

InDesignでは、次の順番で文字を組んでいます：


  1.  ユニコードとフォント情報とOTF機能のリストを使用して字形と配置位置を計算する。これによって、字形の標準配列は得られる。GSUB, GPOSの機能の効果も入っている。メトリックスのkernはここに入っている。オプティカルカーニングは、欧文文字の字形の形（”O”や”Y”など）の最適な間隔をベースにしてカーニングペアを計算する。なので、和文の字形の計算結果は正しいとは保証がないです。
  2.  日本語の場合、行の高さが仮想ボディーで、字形幅をフォントデータの幅からJIS X 4051によるべた組の幅に直し、配置位置を変更する。幅の差は「文字組みツメ」と呼ぶ。ツメ量はユニコードかオプションでAdobe-Japan1のCIDかでわかる。フォントによって日本語用括弧類の標準字形が全角じゃない場合には問題が発生するので特別処理も必要。時にはバグが発生。
  3.  アキ量設定の最適値を計算して、適切に字形の配置位置を変更する。ユニコードで文字組みクラスを計算することが多いが、Adobe-Japan1のCIDフォントの場合はCID（字形）で計算するオプションもある。前のクラス、後ろのクラスがわかればアキ量設定の値はわかる。各クラスのペア（クラス数26^2が最大可能なコンビ）は空き量は最小値、最適値、最大値、ツメる優先順位とがある。両端揃えの場合などに、最適値と最大値の間に文字間隔を広げる場合は優先順位はなく、均等にアキを入れる。万が一、最大値よりも広げないといけない時は均等に広げて、行の良さをさらに低く計算する。
  4.  行の折り返し位置の候補を計算し、行末に禁則文字群がきた場合には行内のアキ量やツメの優先度を参考にして、候補行の「良さ」を判断する。良さの計算は行の折り返し位置がフレーム幅に近くて、アキ量設定の最適値に近くて、Justification Settings（欧文の場合）の最適値に近い、のがベストです。段落コンポーザーは全ての行の平均良さ、単数行のは各行の良さで、折り返しを決定する。
  5.  最終アキ量やJustification Settings（欧文の場合）を決定し、字形の最終配置位置を決定する。

文字組みのツメ量（括弧類を全角から半角にする挙動）は、ユーザは編集できないですが、空き量は編集できます。空き量は全角ベースですので、プロポーショナル幅の場合はユーザは空き量を編集しないといけない（２分アキはいつも全角の２分です、プロポーショナル幅の50%ではなくて）。これはもうちょっと使いやすくしたいところです。

Glueの話ですが、インデザインはその概念はないですが、Knuthの “Breaking Paragraphs into Lines<http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf>” ではその概念は初めて見ました。Ericはその概念を参考にしてFlashのテキストエンジンやKindleの新しいエンジンを開発したと思います。

Glue refers to blank space that can vary its width in specified ways; it is an elastic mortar used between boxes in a typeset line. When item xi of a paragraph specifies glue, there are three real numbers (wi, yi, zi) of importance to the line-breaking
algorithm:
wi is the ‘ideal’ or ‘normal’ width;
yi is the ‘stretchability’;
zi is the ‘shrinkability’.
For example, the space between words in a line is often specified by the values wi= 1/3 em, yi= 1/6 em, zi= 1/9 em, where one em is the set size of the type being used (approximately the width of an uppercase ‘M’ in classical type styles). The actual amount of space occupied by this glue can be adjusted when justifying a line to some desired width; if the normal width is too small, the adjustment is proportional to yi, and if the normal width is too large the adjustment is proportional to zi. The numbers wi, yi, and zi may be negative, subject to certain natural restrictions explained later; for example, a negative value of wi indicates a backspace. When yi = zi = 0, the glue has a fixed width wi. Incidentally, the word ‘glue’ is perhaps not the best term, because it sounds a bit messy; a word like ‘spring’ would be better, since metal springs expand or compress to fill up space in essentially the way we want. However, we shall continue to say ‘glue’, a term used since the early days of T E X (1977), because many people claim to like it. A glob of glue is often called a skip by TEX users, and it seems preferable to speak of boxes and skips rather than boxes and springs or boxes and glues. A skip, by any other name, is of course the same abstract concept, embodied by the three values (wi,yi,xi).

文字組アキ量設定の複雑さの一つは、その可能なコンビネーションの数です。でも、実際には26^2は必要なく、ダブっているクラス関係（挙動）はたくさんあります。しかも、Glueの種類（アキ量範囲と優先度の種類）もそんなに多く使用されていない。Glueの概念をCSSに入れることによってより精密に文字配置がコントロールできればいいと思いますが、日本語文字組みに必要とするアキ量の伸縮はInDesignでは３段階（縮小、拡大、万が一）もあり、Knuthのglueよりも遥かに複雑です。どこまでが「基本」なのかは議論すべきですね。

国際化のことですが、同じ行に日本語と英語、日本語とインド語、日本語とアラビア語、などでは、行のメトリックス、各フォントのメトリックス関係（バランス）を考えないといけないと思います。段落ベースで各行の基準点（上端と下端）と行送り基準点を決めます。この段落は、英語。この段落は、日本語。その中で同じ言語を組むというのは簡単ですが、多言語を混植する場合は、日本語組版ルールの基準の中で（例えば仮想ボディー）でインド語のhanging baselineや英語のRoman baselineをバランスよく配置しないといけないです。で、もし次の段落が主に英語ベースであれば行のメトリックスは欧文用のAscentとdescentで高さが決まり、行送りは前の行の欧文ベースラインとの距離で、その中に日本語かインド語かをバランスよく組む。それぞれの結果は違うと私は信じています。微妙に。結局何が違うかというと、両端揃えのやり方（アラビア語を先に伸ばす？　和欧間？　単語間？　括弧のアキ量？）優先順位は段落の基準ルールで決まるのでしょう。あと、行の高さですが、仮想ボディーベースで計算するとHindiのhanging baselineとそれより高いascentとdescentを入れると、仮想ボディーを守らないと余白のバランスは崩される恐れ<https://github.com/w3c/csswg-drafts/issues/5647>があります。でも、英語ルールで組むのであれば余白の美なんかは日本のと違う。Hindiを入れると行がズレる、それでいい。とか。

なので、言語の組版ルールを段落ベースで決めた方がいいと思います。各ルールでは、多言語用優先順位も決めないといけないでしょう。両端揃えのために、何が先、どこまである言語の余裕を使っていいのかなど。行末に長いものがきたら、いつ日本語のアキ量を縮小するかとか。

以上です。綺麗な絵は作成しないで長い文を書いてしまって申し訳ないです。

From: 田嶋　淳 <tajima@sanyosha.co.jp>
Date: Thursday, October 29, 2020 at 8:09 PM
To: Yasuo Kida <kida@mac.com>
Cc: public-i18n-japanese@w3.org <public-i18n-japanese@w3.org>
Subject: Re: Eric Muller からの提案
木田さま

JLreqに関しては敏先生に答えていただいた方がよいとして、InDesignでのケースとしては文字組みアキ量設定でのツメ／アキ量設定値とフォントのツメ指定を有効にした場合のツメ／アキ量のどちらが優先適用されるかという話なのかなと思います。ちょっとテストしてみました。

[cid:image001.png@01D6AEDC.93090B90]

全て文字組アキ量設定は「行末約物半角」で同一、プロポーショナルメトリクスのチェックを有効にして文字詰めのアルゴリズム設定のみ変えています。和文等幅とメトリクスでは変わらず、「オプティカル」のケースのみ詰まっているように見えますね。オプティカルはフォントの内部情報ではなくInDesignがアキを計算して組むという設定のようなので、つまりInDesignでは優先順位を設定で切り替えられるという理解でよいのでしょうか。Natさんの解説を待ちたいところです。


2020/10/30 11:41、KidaYasuo <kida@mac.com<mailto:kida@mac.com>>のメール:

田嶋さん、

ありがとうございます。結構読み応えがありますでしょ。

疑問に思われた点ですが、いま、例えば JLReq 基準的に、もしくはInDesign ではどうなっているんでしょう？

木田
iPhoneから送信


2020/10/30 11:20、田嶋 淳 <tajima@sanyosha.co.jp<mailto:tajima@sanyosha.co.jp>>のメール:

木田さま
みなさま

　田嶋です。頑張って読みました。一点だけ疑問があるのですが、これフォントが内部的に持っているツメ情報との関連はどうなる想定なのでしょうか。Opentypeフォントを利用していてfont-feature-settingsでツメ情報を呼び出したようなケースです。フォント側の情報が優先されて適用されるのか、Unicode Characterが優先なのか、あるいはそれ以外の解があるのか。


2020/10/29 22:29、木田泰夫 <kida@mac.com<mailto:kida@mac.com>>のメール:

私の理解で Eric の提案の重要なポイントをまとめますと：

・行の折り返しは UAX14 / CLDR に任せていること。これは Unicode 化にあたって順当ですね。我々は、UAX14 / CLDR と JLReq の相違している点をチェックする必要がありますね。


・それによって文字クラスは字間だけ取り扱えば良いことになります。字間クラスと呼び変えた方が良さそうです。で、それを Unicode のプロパティとして提案するという点。これは我々の議論でも出てきていましたが、重要なポイントですね。


・パラグラフの最初、縦中横、などの仮想的なクラスの提案。先週我々が議論した、文脈依存の文字クラス、を含めて統一的に処理できるように思います。なぜこれを思いつかなかたんだ！と思っております。


・縦書き専用クラス、横書き専用クラスのあること。これの具体的な利点がまだよく理解できていないのですが、重要なポイントの可能性があるので挙げておきます。


・糊、つまりデフォルトの字間とその調整の流儀を明に扱おうという提案。


・また、マークアップにより字間クラスを明に変更できるようにとの提案。




細かな点での新規性も色々あるのですが、大まかに重要な点はこんなところかと。


木田







***************************************
（株）三陽社
 メディア開発室
 http://www.sanyosha.co.jp/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sanyosha.co.jp%2F&data=04%7C01%7Cnmccully%40adobe.com%7C3aa19dda63c947d660ce08d87c813859%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637396241729944046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ljl0mKbs0e0u2G5PjFt8N%2BYzjemuEeUZuLKWgrzquHk%3D&reserved=0>

 田嶋 淳
 tajima@sanyosha.co.jp<mailto:tajima@sanyosha.co.jp>

 ※ブログ運営中です。
　　ご意見をいただければ幸いです。
　　http://densyodamasii.com/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdensyodamasii.com%2F&data=04%7C01%7Cnmccully%40adobe.com%7C3aa19dda63c947d660ce08d87c813859%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637396241729944046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rYVmNJBuxzVPS%2BwdCA%2F7rl1nqOVE%2F5CtSvuGMVLAJOY%3D&reserved=0>
***************************************


***************************************
（株）三陽社
　メディア開発室
　http://www.sanyosha.co.jp/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sanyosha.co.jp%2F&data=04%7C01%7Cnmccully%40adobe.com%7C3aa19dda63c947d660ce08d87c813859%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637396241729954038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZlxqtCrfplitmiCnW%2BYGSVZvPPjL%2FgRp4hdMWzA%2Bq04%3D&reserved=0>

 田嶋 淳
 tajima@sanyosha.co.jp<mailto:tajima@sanyosha.co.jp>

　※ブログ運営中です。
　　ご意見をいただければ幸いです。
　　http://densyodamasii.com/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdensyodamasii.com%2F&data=04%7C01%7Cnmccully%40adobe.com%7C3aa19dda63c947d660ce08d87c813859%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637396241729954038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oa1QihZ4y1CdAb0moLSsbYqBO69wpC0Cuqs690uOznY%3D&reserved=0>
***************************************