Previous

Table of Contents

Bottom     

Next     


Quick Table of Contents
3 Introduction to Formatting
    3.1 Conceptual Procedure

3 Introduction to Formatting フォーマット化への導入

The aim of this section is to describe the general process of formatting, enough to read the area model and the formatting object descriptions and properties and to understand the process of refinement. この節この箇条では,フォーマット化の一般的な処理を示すことが目標である。それは,領域モデル,フォーマット化オブジェクト記述及び特性を十分に読むことができ,洗練化の処理を理解することである。

Formatting is the process of turning the result of an XSL transformation into a tangible form for the reader or listener. フォーマット化は,XSL変換の結果を読み手又は聞き手のために知覚可能な形式に変える処理である。 This process comprises several steps, some of which depend on others in a non-sequential way. この処理は,幾つかの段階を含み,逐次的でない方法に依存する場合もある。 Our model for formatting will be the construction of an area tree, which is an ordered tree containing geometric information for the placement of every glyph, shape, and image in the document, together with information embodying spacing constraints and other rendering information; ここでのフォーマット化のモデルは,領域木の構築である。この領域木は,順序付けされた木であって,間隔制約及び他のレンダリング情報を具体化する情報と共に,文書中のすべてのグリフ,形状及び画像の配置に関する幾何的情報を含む。 this information is referred to under the rubric of traits, which are to areas what properties are to formatting objects and attributes are to XML elements. この情報は,特色という項目のもとで参照される。ここで,特色とは,フォーマット化オブジェクトに対する特性,XML要素に対する属性などのように,領域に対するものである。 4 Area Model will describe the area tree and define the default placement constraints on stacked areas. 4 領域モデル は,領域木を記述し,スタック領域上のデフォルト配置制約を定義する。 However, this is an abstract model which need not be actually implemented in this way in a formatter, so long as the resulting tangible form obeys the implied constraints. しかし,このモデルは,結果として生じる知覚可能な形式が暗に示される制約に従う限り,抽象モデルであって,フォーマッタにおいてはこの方法で実際に実装される必要はない。 Constraints might conflict to the point where it is impossible to satisfy them all. 制約のすべてを満たすことができない場合,矛盾が生じるもしれない。 In that case, it is implementation-defined which constraints should be relaxed and in what order to satisfy the others. その場合には,どの制約を緩和し,どの順序で他の制約を満たすのが望ましいかは,実装定義である。

Formatting objects are elements in the formatting object tree, whose names are from the XSL namespace; フォーマット化オブジェクトは,フォーマット化オブジェクト木の要素であって,その名前はXSL名前空間に基づく。 a formatting object belongs to a class of formatting objects identified by its element name. フォーマット化オブジェクトは,その要素名が識別するフォーマット化オブジェクトのクラスに属する。 The formatting behavior of each class of formatting objects is described in terms of what areas are created by a formatting object of that class, how the traits of the areas are established, and how the areas are structured hierarchically with respect to areas created by other formatting objects. フォーマット化オブジェクトの各クラスのフォーマット化の振舞いは,そのクラスのフォーマット化オブジェクトがどの領域を生成するか,領域の特色がどのように設定されるか,及び他のフォーマット化オブジェクトが生成する領域に関連して,領域がどのように階層的に構造化されるかによって記述される。 6 Formatting Objects and 7 Formatting Properties describe formatting objects and their properties. 6 フォーマット化オブジェクト 及び 7 フォーマット化特性 は,フォーマット化オブジェクト及びその特性を記述する。

Some formatting objects are block-level and others are inline-level. フォーマット化オブジェクトには,ブロックレベルのものもあれば,行内レベルのものもある。 This refers to the types of areas which they generate, which in turn refer to their default placement method. これは,それらフォーマット化オブジェクトが生成する領域の型を参照しており,それらの型は,そのデフォルト配置メソッドを参照している。 Inline-areas (for example, glyph-areas) are collected into lines and the direction in which they are stacked is the inline-progression-direction. (グリフ領域などの)行内領域は,行の中に集められ,それらをスタックする方向は行内進行方向である。 Lines are a type of block-area and these are stacked in a direction perpendicular to the inline-progression-direction, called the block-progression-direction. 行は,一種のブロック領域であって,行内進行方向に垂直な方向にスタックされる。この方向をブロック進行方向と呼ぶ。 See 4 Area Model for detailed decriptions of these area types and directions. これらの領域の型及び方向に関する詳細な記述は,4 領域モデル を参照されたい。

In Western writing systems, the block-progression-direction is "top-to-bottom" and the inline-progression-direction is "left-to-right". 西欧の表記システムでは,ブロック進行方向は“下向き”であって,行内進行方向は“右向き”になっている。 This specification treats other writing systems as well and introduces the terms "block" and "inline" instead of using absolute indicators like "vertical" and "horizontal". この規定この標準仕様書(TS)は,他の表記システムも扱い,“垂直”及び“水平”といった絶対指示子を使用する代わりに,“ブロック”及び“行内”という用語を導入する。 Similarly this specification tries to give relatively-specified directions ("before" and "after" in the block-progression-direction, "start" and "end" in the inline-progression-direction) where appropriate, either in addition to or in place of absolutely-specified directions such as "top", "bottom", "left", and "right". 同様に,この規定この標準仕様書(TS)は,“上”,“下”,“左”及び“右”といった絶対指定方向に追加又は代わりとして,適切なところで相対指定方向(ブロック進行方向における“前”及び“後”,行内進行方向における“開始”及び“終了”など)を与えようとしている。 These are interpreted according to the value of the writing-mode property. これらは,表記方法特性の値に応じて解釈される。

Central to this model of formatting is refinement. フォーマット化のこのモデルの中心となるのは,洗練化である。 This is a computational process which finalizes the specification of properties based on the attribute values in the XML result tree. これは計算処理であって,XML結果木の属性値に基づく特性の指定を完成させる。 Though the XML result tree and the formatting object tree have very similar structure, it is helpful to think of them as separate conceptual entities. XML結果木及びフォーマット化オブジェクト木は,極めて類似した構造をもつが,それらを別の概念的実体として考えるのが有効である。 Refinement involves洗練化は,次を含む。

Some of these operations (particularly evaluating expressions) depend on knowledge of the area tree. これらの操作の幾つか(特に式を評価する操作)は,領域木の知識に依存する。 Thus refinement is not necessarily a straightforward, sequential procedure, but may involve look-ahead, back-tracking, or control-splicing with other processes in the formatter. そのため,洗練化は必ずしも直接的で順次処理的な手続きではないが,フォーマッタにおいて,処理を伴う先読み,後戻り又は他の処理との制御継ぎを含んでよい。 Refinement is described more fully in 5 Property Refinement / Resolution. 洗練化は,5 特性の洗練化及び解決 において更に詳しく記述される。

To summarize, formatting proceeds by constructing an area tree (containing areas and their traits) which satisfies constraints based on information contained in the XML result tree (containing element nodes and their attributes). 要約すると,フォーマット化は,(要素ノード及びその属性を含む)XML結果木に含まれる情報に基づいた制約を満たす(領域及びその特色を含む)領域木を構築することによって進行する。 Conceptually, there are intermediate steps of constructing a formatting object tree (containing formatting objects and their properties) and refinement; 概念上は,(フォーマット化オブジェクト及びその特性を含む)フォーマット化オブジェクト木及び洗練化を構築する中間段階が存在する。 these steps may proceed in an interleaved fashion during the construction of the area tree. これらの段階は,領域木の構築の間にインタリーブした方式で行われる。

3.1 Conceptual Procedure 概念的手続き

This subsection contains a conceptual description of how formatting could work. この節箇条3.1は,フォーマット化がどのように動作可能なのかの概念的記述を含む。 This conceptual procedure does not mandate any particular algorithms or data structures as long as the result obeys the implied constraints. この概念上の手続きは,結果が暗黙の制約に従う限り,どのような特定アルゴリズム又はデータ構造も要求しない。

The procedure works by processing formatting objects. Each object, while being processed, may initiate processing of other objects. 手続きは,フォーマット化オブジェクトを処理することによって動作する。 While the objects are hierarchically structured, the processing is not; 処理されている間,各オブジェクトは,他のオブジェクトでの処理を開始してよい。オブジェクトは階層的に構造化されるが,処理はそうではない。 processing of a given object is rather like a co-routine which may pass control to other processes, but pick up again later where it left off. 与えられたオブジェクトの処理は,いずれかというと,制御を他のプロセスに渡してよいが,制御を渡した箇所で,後に再びその制御を取り上げてもよいコルーチンに類似している。 The procedure starts by initiating the processing of the fo:root formatting object. 手続きは,fo:rootフォーマット化オブジェクトの処理を始めることによって開始する。

Unless otherwise specified, processing a formatting object creates areas and returns them to its parent to be placed in the area tree. 特に指定がなければ,フォーマット化オブジェクトを処理することは,領域を生成し,その領域を領域木の中に配置するためにその親に返却する。 Like a co-routine, when given control, it initiates, then continues formatting of its own children (if any), or some subset of them. コルーチンと同様に,それは,制御が与えられると動き出し,(存在する場合には)それ自体の子又はそれら子の部分集合のフォーマット化を継続する。 The formatting object supplies parameters to its children based on the traits of areas already in the area tree, possibly including areas generated by the formatting object or its ancestors. フォーマット化オブジェクトは,領域木に既にある領域の特色に基づいて,パラメタをその子に提供する。 It then disposes of the areas returned by its formatting object children. この領域木は,フォーマット化オブジェクト又はその先祖が生成する領域を含む可能性がある。 It might simply return such an area to its parent (and will always do this if it does not generate areas itself), or alternatively it might arrange the area in the area tree according to the semantics of the formatting object; 次にフォーマット化オブジェクトは,そのフォーマット化オブジェクトの子が返却する領域を処理する。それは,このような領域をその親に対して単に返却するかもしれない(それ自体が領域を生成しない場合には,常にこれを行う)。そうする代わりに,フォーマット化オブジェクトのセマンティクスに従って領域木の中の領域を整えるかもしれない。 this may involve changing its geometric position. これは,その幾何的位置の変更を引き起こしてもよい。 It terminates processing when all its children have terminated processing (if initiated) and it is finished generating areas. フォーマット化オブジェクトが処理を終了するのは,そのすべての子が(開始していた場合には)処理を終了したときとし,領域を生成して終了する。

Some formatting objects do not themselves generate areas; フォーマット化オブジェクトの中には,それ自体で領域を生成しないものもある。 instead these formatting objects simply return the areas returned to them by their children. 代わりに,これらのフォーマット化オブジェクトは,それらの子が返却した領域を単に返却する。 Alternatively, a formatting object may continue to generate (and return) areas based on information discovered while formatting its own children; その一方で,フォーマット化オブジェクトは,それ自体の子をフォーマット化している間に見つけられた情報に基づいて,領域を生成(及び返却)し続けてよい。 for example, the fo:page-sequence formatting object will continue generating pages as long as it contains a flow with unprocessed descendants. 例えば,fo:page-sequenceフォーマット化オブジェクトは,それが未処理の子孫をもつ流し込みを含む限り,ページの生成を続ける。

Areas returned to an fo:root formatting object are page-viewport-areas, and are simply placed as children of the area tree root in the order in which they are returned, with no geometrical implications. fo:rootフォーマット化オブジェクトに対して返却される領域は,ページ表示領域であって,領域木のルートの子として,何の幾何的な関係もなく,それらが返却される順序で単に配置される。

As a general rule, the order of the area tree parallels the order of the formatting object tree. 一般的な規則として,領域木の順序は,フォーマット化オブジェクトの順序に対応する。 That is, if one formatting object precedes another in the depth-first traversal of the formatting object tree, with neither containing the other, then all the areas generated by the first will precede all the areas generated by the second in the depth-first traversal of the area tree, unless otherwise specified. すなわち,一つのフォーマット化オブジェクトが,フォーマット化オブジェクト木の深さ優先たどりにおいて,もう一つのフォーマット化オブジェクトに優先し,いずれもその他のフォーマット化オブジェクトを含まない場合,特に指定がなければ,領域木の深さ優先たどりにおいて,第1優先によって生成される領域のすべては,第2優先によって生成される領域のすべてに優先する。 Typical exceptions to this rule would be things like side floats, before floats, and footnotes. この規則の典型的な例外には,側浮動体,前浮動体及び脚注に類似するものが考えられる。

At the end of the procedure, the areas and their traits have been constructed, and they are required to satisfy constraints described in the definitions of their associated formatting objects, and in the area model section. 手続きの最後においては,領域及びその特色は構築済みであって,それらは,関連するフォーマット化オブジェクトの定義と領域モデルの箇条とにおいて記述された制約を満たすことが要求される。 In particular, size and position of the areas will be subject to the placement and spacing constraints described in the area model, unless the formatting object definition indicates otherwise. 特に,領域のサイズ及び位置は,フォーマット化オブジェクトの定義が別に指示しない場合は,領域モデルにおいて記述された配置及び間隔制約に従う。

The formatting object definitions, property descriptions, and area model are not algorithms. フォーマット化オブジェクトの定義,特性記述及び領域モデルは,アルゴリズムではない。 Thus, the formatting object semantics do not specify how the line-breaking algorithm must work in collecting characters into words, positioning words within lines, shifting lines within a container, etc. そのため,フォーマット化オブジェクトのセマンティクスは,文字を集めて語にする際,語を行内に配置する際,コンテナ内に行を移す際などに,行分割アルゴリズムがどのように動作しなければならないかを指定しない。 Rather this specification assumes that the formatter has done these things and describes the constraints which the result is supposed to satisfy. むしろこの制約は,フォーマッタがこれらの実行を完了したことを想定して,その結果が満たすことになる制約を記述する。 Thus, the constraints do not specify at what time an implementation makes use of that information; そのため,この制約は,実装がその情報をいつ利用するかを指定しない。 the constraints only specify what must be true after processing has been completed. この制約は,処理が終了した後に,何が真であるかを指定するだけである。 An actual implementation may well make use of some constraints at a time other than when formatting the formatting object for which the constraint applies. この制約が適用されるフォーマット化オブジェクトをフォーマットするときを除いて,実際の実装は,1度に幾つかの制約を利用するかもしれない。 For example, the constraint given by the "hyphenate" property on an fo:character would typically be used during line-building, rather than when progessing the fo:character. 例えば,fo:characterの“hyphenate”特性によって与えられた制約は,通常,行構築の間,fo:characterを処理しながら使用されるであろう。 Other examples include constraints for keeps and breaks. 他の例は,保持と分割の制約を含んでいる。