diff options
| author | Keiron Liddle <keiron@apache.org> | 2002-03-27 07:59:56 +0000 |
|---|---|---|
| committer | Keiron Liddle <keiron@apache.org> | 2002-03-27 07:59:56 +0000 |
| commit | b274c52f988a2952d1fb8656a8f9cacabfd416de (patch) | |
| tree | 7203dda739462dd62b1ddb8bf481eb13fbbb34df /docs/design | |
| parent | d33a5e7a9ce6287e3df1213144758278ad87dfa8 (diff) | |
| download | xmlgraphics-fop-b274c52f988a2952d1fb8656a8f9cacabfd416de.tar.gz xmlgraphics-fop-b274c52f988a2952d1fb8656a8f9cacabfd416de.zip | |
added to alt.design docs
Submitted By: "Peter B. West" <pbwest@powerup.com.au>
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@194720 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/design')
| -rw-r--r-- | docs/design/alt.design/alt.properties.xml | 4 | ||||
| -rw-r--r-- | docs/design/alt.design/book.xml | 9 | ||||
| -rw-r--r-- | docs/design/alt.design/compound-properties.xml | 218 | ||||
| -rw-r--r-- | docs/design/alt.design/coroutines.png | bin | 0 -> 6025 bytes | |||
| -rw-r--r-- | docs/design/alt.design/coroutines.xml | 118 | ||||
| -rw-r--r-- | docs/design/alt.design/footnotes.xml | 137 | ||||
| -rw-r--r-- | docs/design/alt.design/galley-preprocessing.png | bin | 0 -> 20744 bytes | |||
| -rw-r--r-- | docs/design/alt.design/galleys.xml | 210 | ||||
| -rw-r--r-- | docs/design/alt.design/initial-column-values.png | bin | 0 -> 10965 bytes | |||
| -rw-r--r-- | docs/design/alt.design/line-area-5.png | bin | 0 -> 22400 bytes | |||
| -rw-r--r-- | docs/design/alt.design/line-area-6.png | bin | 0 -> 20801 bytes | |||
| -rw-r--r-- | docs/design/alt.design/traits.xml | 295 |
12 files changed, 988 insertions, 3 deletions
diff --git a/docs/design/alt.design/alt.properties.xml b/docs/design/alt.design/alt.properties.xml index a0bb5ef6c..6a3f7be3b 100644 --- a/docs/design/alt.design/alt.properties.xml +++ b/docs/design/alt.design/alt.properties.xml @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="ISO-8859-1"?> <!-- $Id$ --> <!-- -<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd"> +<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> --> <document> <header> @@ -48,7 +48,6 @@ when no value has been assigned. </p> <s2 title="The history problem"> - </s2> <p> The difficulty and expense of handling properties comes from this univeral inheritance possibility. The list of properties @@ -65,6 +64,7 @@ specified on an ancestor of this element, and the initial value of the property. </p> + </s2> <s2 title="Data requirement and structure"> <p> This determines the minimum set of properties and associated diff --git a/docs/design/alt.design/book.xml b/docs/design/alt.design/book.xml index 5ae28c1f9..8c49d5d4d 100644 --- a/docs/design/alt.design/book.xml +++ b/docs/design/alt.design/book.xml @@ -5,7 +5,11 @@ <separator/> <external href="../index.html" label="NEW DESIGN" /> <separator/> - <page id="index" label="alt.properties" source="alt.properties.xml"/> + <page id="index" label="co-routines" source="coroutines.xml"/> + <page id="galleys" label="galleys" source="galleys.xml"/> + <page id="footnotes" label="footnotes" source="footnotes.xml"/> + <separator/> + <page id="alt.properties" label="alt.properties" source="alt.properties.xml"/> <page id="classes-overview" label="Classes overview" source="classes-overview.xml"/> <page id="properties-classes" label="Properties classes" source="properties-classes.xml"/> <page id="Properties" label="Properties" source="Properties.png.xml"/> @@ -18,4 +22,7 @@ <page id="xml-parsing" label="XML parsing" source="xml-parsing.xml"/> <separator/> <page id="property-parsing" label="Property parsing" source="propertyExpressions.xml"/> + <separator/> + <page id="compound-properties" label="Compound properties" source="compound-properties.xml"/> + <page id="traits" label="Traits" source="traits.xml"/> </book> diff --git a/docs/design/alt.design/compound-properties.xml b/docs/design/alt.design/compound-properties.xml new file mode 100644 index 000000000..3b20add15 --- /dev/null +++ b/docs/design/alt.design/compound-properties.xml @@ -0,0 +1,218 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!-- $Id$ --> +<!-- +<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> +--> + +<document> + <header> + <title>Compound properties</title> + <authors> + <person name="Peter B. West" email="pbwest@powerup.com.au"/> + </authors> + </header> + <body> + <s1 title="Compound properties in XSLFO"> + <table> + <tr> + <th>Property type</th> + <th>Section</th> + <th>Inherited</th> + <th>'inherit'</th> + </tr> + <tr> + <th><length-range></th> + </tr> + <tr> + <th>minimum</th> + </tr> + <tr> + <th>optimum</th> + </tr> + <tr> + <th>maximum</th> + </tr> + <tr> + <td>block-progression-dimension</td> + <td>7.14.1</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>inline-progression-dimension</td> + <td>7.14.5</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>leader-length</td> + <td>7.21.4</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <th><length-conditional></th> + </tr> + <tr> + <th>length</th> + </tr> + <tr> + <th>conditionality</th> + </tr> + <tr> + <td>border-after-width</td> + <td>7.7.12</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>border-before-width</td> + <td>7.7.9</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>border-end-width</td> + <td>7.7.18</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>border-start-width</td> + <td>7.7.15</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-after</td> + <td>7.7.32</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-before</td> + <td>7.7.31</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-end</td> + <td>7.7.34</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>padding-start</td> + <td>7.7.33</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <th><length-bp-ip-direction></th> + </tr> + <tr> + <th>block-progression-direction</th> + </tr> + <tr> + <th>inline-progression-direction</th> + </tr> + <tr> + <td>border-separation</td> + <td>7.26.5</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <th><space></th> + </tr> + <tr> + <th>minimum</th> + </tr> + <tr> + <th>optimum</th> + </tr> + <tr> + <th>maximum</th> + </tr> + <tr> + <th>precedence</th> + </tr> + <tr> + <th>conditionality</th> + </tr> + <tr> + <td>letter-spacing</td> + <td>7.16.2</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <td>line-height</td> + <td>7.15.4</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <td>space-after</td> + <td>7.10.6</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>space-before</td> + <td>7.10.5</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>space-end</td> + <td>7.11.1</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>space-start</td> + <td>7.11.2</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>word-spacing</td> + <td>7.16.8</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <th><keep></th> + </tr> + <tr> + <th>within-line</th> + </tr> + <tr> + <th>within-column</th> + </tr> + <tr> + <th>within-page</th> + </tr> + <tr> + <td>keep-together</td> + <td>7.19.3</td> + <td>yes</td> + <td>yes</td> + </tr> + <tr> + <td>keep-with-next</td> + <td>7.19.4</td> + <td>no</td> + <td>yes</td> + </tr> + <tr> + <td>keep-with-previous</td> + <td>7.19.5</td> + <td>no</td> + <td>yes</td> + </tr> + </table> + </s1> + </body> +</document> diff --git a/docs/design/alt.design/coroutines.png b/docs/design/alt.design/coroutines.png Binary files differnew file mode 100644 index 000000000..d00478a6a --- /dev/null +++ b/docs/design/alt.design/coroutines.png diff --git a/docs/design/alt.design/coroutines.xml b/docs/design/alt.design/coroutines.xml new file mode 100644 index 000000000..8d39d1730 --- /dev/null +++ b/docs/design/alt.design/coroutines.xml @@ -0,0 +1,118 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!-- $Id$ --> +<!-- +<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> +--> + +<document> + <header> + <title>Implementing co-routines</title> + <authors> + <person name="Peter B. West" email="pbwest@powerup.com.au"/> + </authors> + </header> + <body> + <!-- one of (anchor s1) --> + <s1 title="Implementing Co-routines in FOP"> + <p> + All general page layout systems have to solve the same + fundamental problem: expressing a flow of text with its own + natural structure as a series of pages corresponding to the + physical and logical structure of the output medium. This + simple description disguises many complexities. Version 1.0 + of the Recommendation, in Section 3, <em>Introduction to + Formatting </em>, includes the following comments. + </p> + <note> + [Formatting] comprises several steps, some of which depend on + others in a non-sequential way.<br/> ...and...<br/> + [R]efinement is not necessarily a straightforward, sequential + procedure, but may involve look-ahead, back-tracking, or + control-splicing with other processes in the formatter. + </note> + <p>Section 3.1, <em>Conceptual Procedure</em>, includes:</p> + <note> + The procedure works by processing formatting objects. Each + object, while being processed, may initiate processing in + 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. + </note> + <s2 title="Application of co-routines"> + <p> + If one looks only at the flow side of the equation, it's + difficult to see what the problem might be. The ordering of + the elements of the flow is preserved in the area tree, and + where elements are in an hierarchical relationship in the + flow, they will generally be in an hierarchical relationship + in the area tree. In such circumstances, the recursive + processing of the flow seems quite natural. + </p> + <p> + The problem becomes more obvious when one thinks about the + imposition of an unrelated page structure over the + hierarchical structure of the document content. Take, e.g., + the processing of a nested flow structure which, at a certain + point, is scanning text and generating line-areas, nested + within other block areas and possibly other line areas. The + page fills in the middle of this process. Processing at the + lowest level in the tree must now suspend, immediately + following the production of the line-area which filled the + page. This same event, however, must also trigger the closing + and flushing to the area tree of every open area of which the last + line-area was a descendant. + </p> + <p> + Once all of these areas have been closed, some dormant process + or processes must wake up, flush the area sub-tree + representing the page, and open a new page sub-tree in the + area tree. Then the whole nested structure of flow objects + and area production must be re-activated, at the point in + processing at which the areas of the previous page were + finalised, but with the new page environment. The most + natural way of expressing the temporal relationship of these + processes is by means of co-routines. + </p> + <p> + Normal sub-routines (methods) display a hierarchical + relationship where process A suspends on invoking process B, + which on termination returns control to A which resumes from + the point of suspension. Co-routines instead have a parallel + relationship. Process A suspends on invoking process B, but + process B also suspends on returning control to process A. To + process B, this return of control appears to be an invocation + of process A. When process A subsequently invokes B and + suspends, B behaves as though its previous invocation of A has + returned, and it resumes from the point of that invocation. + So control bounces between the two, each one resuming where it + left off.<br/><br/> + <strong>Figure 1</strong> + </p> + <figure src="coroutines.png" alt="Co-routine diagram"/> + <p> + For example, think of a page-production method working on a + complex page-sequence-master. + </p> + <source> + void makePages(...) { + ... + while (pageSequence.hasNext()) { + ... + page = generateNextPage(...); + boolean over = flow.fillPage(page); + if (over) return; + } + } + </source> + <p> + The <code>fillPage()</code> method, when it fills a page, will + have unfinished business with the flow, which it will want to + resume at the next call; hence co-routines. One way to + implement them in Java is by threads synchronised on some + common argument-passing object. + </p> + </s2> + </s1> + </body> +</document> diff --git a/docs/design/alt.design/footnotes.xml b/docs/design/alt.design/footnotes.xml new file mode 100644 index 000000000..0e2ce4bba --- /dev/null +++ b/docs/design/alt.design/footnotes.xml @@ -0,0 +1,137 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!-- $Id$ --> +<!-- +<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> +--> + +<document> + <header> + <title>Implementing footnotes</title> + <authors> + <person name="Peter B. West" email="pbwest@powerup.com.au"/> + </authors> + </header> + <body> + <!-- one of (anchor s1) --> + <s1 title="Implementing footnotes in FOP"> + <p> + Footnotes present difficulties for page layout primarily + because their point of invocation in the flow is different + from their point of appearance in the area tree. All of the + content lines of a footnote may appear on the same page as its + invocation point, all may appear on a following page, or the + lines may be split over a page or pages. (This characteristic + leads to another problem when a footnote overflows the last + page of flow content, but that difficulty will not be + discussed here.) This note considers some aspects of the + implementation of footnotes in a galley-based design. + </p> + <s2 title="Footnotes and galleys"> + <p> + In the structure described in the <link href= + "../galleys.html" >introduction to FOP galleys</link>, + footnotes would be pre-processed as galleys themselves, but + they would remain attached as subtrees to their points of + invocation in the main text. Allocation to a + footnote-reference-area would only occur in the resolution + to Area nodes. + </p> + <p> + When footnotes are introduced, the communication between + galleys and layout manager, as mentioned <link href= + "../galleys.html#pre-processing" >above</link>, would be + affected. The returned information would two b-p-d values: + the primary line-area b-p-d impact and the footnote b-p-d + impact. The distinction is necessary for two reasons; to + alert the layout manager to the first footnote of the page, + and because the footnote b-p-d will always impact the + main-reference-area b-p-d, whereas the primary inline-area + may not, e.g. in the case of multiple span-areas. + </p> + </s2> + <s2 title="Multiple columns and footnotes"> + <note> + A possible method for multi-column layout and balancing + with footnotes, using a galley-based approach. + </note> + <p> + This note assumes a galley, as discussed <link href= + "../galleys.html" >elsewhere</link>, flowing text with + footnotes and possibly other blocks into a possibly + multi-column area. The logic of flowing into multiple + columns is trivially applied to a single column. The galley + is manipulated within the context of the <em>layout + tree</em>. + </p> + <p> + Associated with the galley are two sets of data. + One contains the maps of all "natural" break-points and + the of all hyphenation break-points. This set is + constructed at the time of construction of the galley and + is a constant for a given galley. The second contains + dynamic data which represents one possible attempt to lay + out the galley. There may be multiple sets of such data + to reflect varying attempts. The data of this set are, + essentially, representations of line-areas, with the supporting + information necessary to determine these line-areas. + </p> + <p> + The line-area data includes the boundaries within the + galley of each line-area, the boundaries of each column + and the boundaries of the "page", or main area. When a + line-area boundary occurs at a hyphenation point, a + "virtual hyphen" is assumed and accounted for in the + i-p-d. As mentioned, individual footnote galleys will + hang from the parent galley. The associated data of the + footnote galleys is similar: a once-only break-points map, + and one or more line-area maps. No column boundaries are + required, but a page boundary is required at the end of + the last footnote or where a footnote breaks across a page + boundary. + </p> + <p> + A number of b-p-d values are also maintained. For each + line-area, the b-p-d, the main area b-p-d increment, the + footnote b-p-d increment and the footnote's page-related + b-p-d increment are required. The main-area b-p-d + increments for any particular line-area are dependent on + the column position of the line-area. Total b-p-d's are + also kept: total footnote b-p-d, total main area b-p-d, + and totals for each column.<br/><br/> + <strong>Figure 1</strong> Columns before first footnote. + </p> + <figure src="initial-column-values.png" alt="Columns before + first footnote"/> + </s2> + <s2 title="Balancing columns"> + <p> + <strong>Figure 2</strong> Adding a line area with first + footnote. + </p> + <figure src="line-area-5.png" + alt="Columns after adding first footnote"/> + <p> + Columns are balanced dynamically in the galley preliminary + layout. While the galley retains its basic linear + structure, the accompanying data structures accomplish + column distribution and balancing. As each line-area is + added, the columns are re-balanced. <strong>N.B.</strong> + This re-balancing involves only some of the dynamic data + associated with the participating galley(s). The data + structures associating breakpoints with the beginning and + end of individual line areas does not change in + re-balancing; only the association of line-area with column, + and, possibly, the various impact values for each line-area. + <br/><br/> + <strong>Figure 3</strong> Adding a line area with next + footnote. + </p> + <figure src="line-area-6.png" + alt="Columns after adding next footnote"/> + </s2> + <s2 title="Layout managers in the flow of control"> + <note>To be developed.</note> + </s2> + </s1> + </body> +</document> diff --git a/docs/design/alt.design/galley-preprocessing.png b/docs/design/alt.design/galley-preprocessing.png Binary files differnew file mode 100644 index 000000000..3a87d58f3 --- /dev/null +++ b/docs/design/alt.design/galley-preprocessing.png diff --git a/docs/design/alt.design/galleys.xml b/docs/design/alt.design/galleys.xml new file mode 100644 index 000000000..e26f2755d --- /dev/null +++ b/docs/design/alt.design/galleys.xml @@ -0,0 +1,210 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!-- $Id$ --> +<!-- +<!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd"> +--> + +<document> + <header> + <title>Galleys</title> + <authors> + <person name="Peter B. West" email="pbwest@powerup.com.au"/> + </authors> + </header> + <body> + <!-- one of (anchor s1) --> + <s1 title="Layout galleys in FOP"> + <s2 title="Galleys in Lout"> + <p> + Jeffrey H. Kingston, in <link href = + "http://snark.niif.spb.su/~uwe/lout/design.pdf" ><em>The + Design and Implementation of the Lout Document Formatting + Language</em> Section 5</link>, describes the + <strong>galley</strong> abstraction which he implemented in + <em>Lout</em>. A document to be formatted is a stream of + text and symbols, some of which are <strong>receptive + symbols</strong>. The output file is the first receptive + symbol; the formatting document is the first galley. The + archetypical example of a receptive symbol is + <strong>@FootPlace</strong> and its corresponding galley + definition, <strong>@FootNote</strong>. + </p> + <p> + Each galley should be thought of as a concurrent process, and + each is associated with a semaphore (or synchronisation + object.) Galleys are free to "promote" components into + receptive targets as long as</p> + <ul> + <li> + an appropriate target has been encountered in the file, + </li> + <li> + the component being promoted contains no unresolved galley + targets itself, and + </li> + <li> + there is sufficient room for the galley component at the + target. + </li> + </ul> + <p> + If these conditions are not met, the galley blocks on its + semaphore. When conditions change so that further progress + may be possible, the semaphore is signalled. Note that the + galleys are a hierarchy, and that the processing and + promotion of galley contents happens <em>bottom-up</em>. + </p> + </s2> + <s2 title="Some features of galleys"> + <p> + It is essential to note that galleys are self-managing; they + are effectively layout <em>bots</em> which require only a + receptive area. If a galley fills a receptive area (say, at + the completion of a page), the galley will wait on its + semaphore, and will remain stalled until a new receptive + area is uncovered in the continued processing (say, as the + filled page is flushed to output and a new empty page is + generated.) + </p> + <p> + Difficulties with this approach become evident when there + are mutual dependencies between receptive areas which + require negotiation between the respective galleys, and, in + some cases, arbitrary deadlock breaking when there is no + clear-cut resolution to conflicting demands. Footnote + processing and side floats are examples. A thornier example + is table column layout in <em>auto</em> mode, where the + column widths are determined by the contents. In + implementing galleys in FOP, these difficulties must be + taken into account, and some solutions proposed. + </p> + <p> + Galleys model the whole of the process of creating the final + formatted output; the document as a whole is regarded as a + galley which flushes in to the output file. + </p> + </s2> + <s2 title="The layout tree"> + <anchor id="layout-tree"/> + <p> + This proposal for implementing galleys in FOP makes use of a + <strong>layout tree</strong>. As with the <link href= + "../layout.html" >layout managers</link><em></em> already + proposed, the layout tree acts as a bridge between the <link + href= "../fotree.html" >FO Tree</link> and the <link href= + "../areatree.html" >Area Tree</link>. If the elements of + the FO Tree are FO nodes, and the elements of the Area Tree + are Area nodes, representing areas to be drawn on the output + medium, the elements of the layout tree are <strong>galley + nodes</strong> and <strong>area tree fragments</strong>. + The area tree fragments are the final stages of the + resolution of the galleys; the output of the galleys will be + inserted directly into the Area Tree. The tree structure + makes it clear that the whole of the formatting process in + FOP, under this model, is a hierarchical series of galleys. + The dynamic data comes from fo:flow and fo:static-content, + and the higher-level receptive areas are derived from the + <em>layout-master-set</em>. + </p> + </s2> + <s2 title="Processing galleys"> + <p> + Galleys are processed in two basic processing environments: + </p> + <s3 title="Inline- and block-progression dimensions known"> + <p> + The galley at set-up is provided with both an + <em>inline-progression-dimension</em> (<em>i-p-d</em>) and + a <em>block-progression-dimension</em> (<em>b-p-d</em>). + In this case, no further intervention is necessary to lay + out the galley. The galley has the possibility of laying + itself out, creating all necessary area nodes. This does + not preclude the possibility that some children of this + galley will not be able to be so directly laid out, and + will fall into the second category. + </p> + <p> + While the option of "automatic" layout exists, to use + such a method would relinquish the possibility of + monitoring the results of such layout and performing + fine-tuning. + </p> + </s3> + <s3 title="Inline- ior block-progression-dimensions unknown"> + <p> + The galley cannot immediately be provided with an i-p-d + ior a b-p-d. This will occur in some of the difficult + cases mentioned earlier. In these cases, the parent + galley acts as a layout manager, similar to the sense used + in <link href= "../layout.html" >another + discussion</link>. The children, lacking full receptive + area dimensions, will proceed with galley pre-processing, + a procedure which will, of necessity, be followed + recursively by all of its children down to the atomic + elements of the galley. These atomic elements are the + individual <em>fo:character</em> nodes and images of fixed + dimensions. + </p> + </s3> + </s2> + <s2 title="Galley pre-processing"> + <anchor id="pre-processing"/> + <p> + Galley pre-processing involves the spatial resolution of + objects from the flows to the greatest extent possible + without information on the dimensions of the target area. + Line-areas have a block progression dimension which is + determined by their contents. To achieve full generality in + layouts of indeterminate dimensions, the contents of + line-areas should be laid out as though their inline + progression dimension were limited only by their content. + In terms of inline-areas, galleys would process text and + resolve the dimensions of included images. Text would be + collected into runs with the same alignment + characteristics. In the process, all possible "natural" and + hyphenation break-points can be determined. Where a + line-area contains mixed fonts or embedded images, the b-p-d + of the individual line-areas which are eventually stacked + will, in general, depend on the line break points, but the + advantage of this approach is that such actual selections + can be backed out and new break points selected with a + minimum of re-calculation. This can potentially occur + whenever a first attempt at page layout is backed out. + <br/><br/> + <strong>Figure 1</strong> + </p> + <figure src="galley-preprocessing.png" alt="Galley + pre-processing diagram"/> + <p> + Once this pre-processing has been achieved, it is + envisaged that a layout manager might make requests to the + galley of its ability to fill an area of a given + inline-progression-dimension. A positive response would + be accompanied by the block-progression-dimension. The + other possibilities are a partial fill, which would also + require b-p-d data, and a failure due to insufficient + i-p-d, in which case the minimum i-p-d requirement would + be returned. Note that decisions about the + actual dimensions of line-areas to be filled can be + deferred until all options have been tested. + </p> + <p> + The other primary form of information provided by a + pre-processed galley is its minimum and maximum i-p-d, so + that decisions can be made by the parent on the spacing of + table columns. Apart from information requests, + higher-level processes can either make requests of the + galleys for chunks of nominated sizes, or simply provide the + galley with an i-p-d and b-p-d, which will trigger the + flushing of the galley components into Area nodes. Until + they have flushed, the galleys must be able to respond to a + sequence of information requests, more or less in the manner + of a request iterator, and separately manage the flushing of + objects into the area tree. The purpose of the "request + iterator" would be to support "incremental" information + requests like <em>getNextBreakPosition</em>. + </p> + </s2> + </s1> + </body> +</document> diff --git a/docs/design/alt.design/initial-column-values.png b/docs/design/alt.design/initial-column-values.png Binary files differnew file mode 100644 index 000000000..103887e07 --- /dev/null +++ b/docs/design/alt.design/initial-column-values.png diff --git a/docs/design/alt.design/line-area-5.png b/docs/design/alt.design/line-area-5.png Binary files differnew file mode 100644 index 000000000..6c467be24 --- /dev/null +++ b/docs/design/alt.design/line-area-5.png diff --git a/docs/design/alt.design/line-area-6.png b/docs/design/alt.design/line-area-6.png Binary files differnew file mode 100644 index 000000000..0001a0a4b --- /dev/null +++ b/docs/design/alt.design/line-area-6.png diff --git a/docs/design/alt.design/traits.xml b/docs/design/alt.design/traits.xml new file mode 100644 index 000000000..8c9dec377 --- /dev/null +++ b/docs/design/alt.design/traits.xml @@ -0,0 +1,295 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!-- $Id$ --> +<!-- +<!DOCTYPE document SYSTEM "file:///home/pbw/src/xml-fop/docs/xml-docs/dtd/document-v10.dtd"> +--> + +<document> + <header> + <title>Traits</title> + <authors> + <person name="Peter B. West" email="pbwest@powerup.com.au"/> + </authors> + </header> + <body> + <s1 title="Traits"> + <table> + <tr> + <th>Trait</th> + <th>Applies to</th> + <th>Refs</th> + <th>Derived from</th> + </tr> + <tr> + <th>Common Traits</th> + </tr> + <tr> + <td>block-progression-direction</td> + <td>All areas</td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice4.html#area-common" + >4.2.2 Common Traits</link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#reference-orientation" + >7.27.7 reference-orientation</link> + </td> + </tr> + <tr> + <th colspan="2"/> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#writing-mode" + >7.27.7 writing-mode</link> + </td> + </tr> + <tr> + <td>inline-progression-direction</td> + <td>All areas</td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice4.html#area-common" + >4.2.2 Common Traits</link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#reference-orientation" + >7.27.7 reference-orientation</link> + </td> + </tr> + <tr> + <th colspan="2"/> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#writing-mode" + >7.27.7 writing-mode</link> + </td> + </tr> + <tr> + <td>shift-direction</td> + <td>Inline areas</td> + </tr> + <tr> + <td>glyph-orientation</td> + <td></td> + </tr> + <tr> + <td>is-reference-area</td> + <td>All areas</td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#section-N6691-Non-property-Based-Trait-Generation" + >5.6 Non-property Based Trait Generation</link> + </td> + <td>Set "true" on:</td> + </tr> + <tr> + <th colspan="3"/> + <td>simple-page-master</td> + </tr> + <tr> + <th colspan="3"/> + <td>title</td> + </tr> + <tr> + <th colspan="3"/> + <td>region-body</td> + </tr> + <tr> + <th colspan="3"/> + <td>region-before</td> + </tr> + <tr> + <th colspan="3"/> + <td>region-after</td> + </tr> + <tr> + <th colspan="3"/> + <td>region-start</td> + </tr> + <tr> + <th colspan="3"/> + <td>region-end</td> + </tr> + <tr> + <th colspan="3"/> + <td>block-container</td> + </tr> + <tr> + <th colspan="3"/> + <td>inline-container</td> + </tr> + <tr> + <th colspan="3"/> + <td>table</td> + </tr> + <tr> + <th colspan="3"/> + <td>table-caption</td> + </tr> + <tr> + <th colspan="3"/> + <td>table-cell</td> + </tr> + <tr> + <td>is-viewport-area</td> + <td></td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice4.html#area-common" + >4.2.2 Common Traits</link> + </td> + </tr> + <tr> + <td>top-position</td> + </tr> + <tr> + <td>bottom-position</td> + </tr> + <tr> + <td>left-position</td> + </tr> + <tr> + <td>right-position</td> + </tr> + <tr> + <td>left-offset</td> + </tr> + <tr> + <td>top-offset</td> + </tr> + <tr> + <td>is-first</td> + </tr> + <tr> + <td>is-last</td> + </tr> + <tr> + <td>generated-by</td> + </tr> + <tr> + <td>returned-by</td> + </tr> + <tr> + <td>nominal-font</td> + </tr> + <tr> + <td>blink</td> + <td></td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" + >5.5.6 Text-decoration Property + </link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" + >7.16.4 "text-decoration" + </link> + </td> + </tr> + <tr> + <td>underline-score</td> + <td></td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" + >5.5.6 Text-decoration Property + </link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" + >7.16.4 "text-decoration" + </link> + </td> + </tr> + <tr> + <td>underline-score-color</td> + <td></td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" + >5.5.6 Text-decoration Property + </link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" + >7.16.4 "text-decoration" + </link> + </td> + </tr> + <tr> + <td>overline-score</td> + <td></td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" + >5.5.6 Text-decoration Property + </link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" + >7.16.4 "text-decoration" + </link> + </td> + </tr> + <tr> + <td>overline-score-color</td> + <td></td> + + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" + >5.5.6 Text-decoration Property + </link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" + >7.16.4 "text-decoration" + </link> + </td> + </tr> + <tr> + <td>through-score</td> + <td></td> + + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" + >5.5.6 Text-decoration Property + </link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" + >7.16.4 "text-decoration" + </link> + </td> + </tr> + <tr> + <td>through-score-color</td> + <td></td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice5.html#refine-text-decoration" + >5.5.6 Text-decoration Property + </link> + </td> + <td> + <link href= + "file:///home/pbw/doc/web/xsl/spec/slice7.html#text-decoration" + >7.16.4 "text-decoration" + </link> + </td> + </tr> + </table> + </s1> + </body> +</document> |
