mirrors
/
fop
огледало от https://github.com/apache/fop.git
Наблюдаван 1
Харесван 0
Разклонения 0
Код Задачи 0 Версии 48 Уики Activity
Преглед на файлове

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
tags/fop-0_20_4-doc
Keiron Liddle преди 22 години
родител
d33a5e7a9c
ревизия
b274c52f98
променени са 12 файла, в които са добавени 988 реда и са изтрити 3 реда
Разделен изглед Покажи статистика за разликите
  1. 2
    2
      docs/design/alt.design/alt.properties.xml
  2. 8
    1
      docs/design/alt.design/book.xml
  3. 218
    0
      docs/design/alt.design/compound-properties.xml
  4. Двоични данни
      docs/design/alt.design/coroutines.png
  5. 118
    0
      docs/design/alt.design/coroutines.xml
  6. 137
    0
      docs/design/alt.design/footnotes.xml
  7. Двоични данни
      docs/design/alt.design/galley-preprocessing.png
  8. 210
    0
      docs/design/alt.design/galleys.xml
  9. Двоични данни
      docs/design/alt.design/initial-column-values.png
  10. Двоични данни
      docs/design/alt.design/line-area-5.png
  11. Двоични данни
      docs/design/alt.design/line-area-6.png
  12. 295
    0
      docs/design/alt.design/traits.xml

+ 2
- 2
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

+ 8
- 1
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>

+ 218
- 0
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>&lt;length-range&gt;</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>&lt;length-conditional&gt;</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>&lt;length-bp-ip-direction&gt;</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>&lt;space&gt;</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>&lt;keep&gt;</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>

Двоични данни
docs/design/alt.design/coroutines.png Целия файл


+ 118
- 0
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>

+ 137
- 0
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>

Двоични данни
docs/design/alt.design/galley-preprocessing.png Целия файл


+ 210
- 0
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>

Двоични данни
docs/design/alt.design/initial-column-values.png Целия файл


Двоични данни
docs/design/alt.design/line-area-5.png Целия файл


Двоични данни
docs/design/alt.design/line-area-6.png Целия файл


+ 295
- 0
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>

Write Preview
Loading…
Отказ
Запис