keiron      02/03/26 23:59:57

  Modified:    docs/design/alt.design alt.properties.xml book.xml
  Added:       docs/design/alt.design compound-properties.xml
                        coroutines.png coroutines.xml footnotes.xml
                        galley-preprocessing.png galleys.xml
                        initial-column-values.png line-area-5.png
                        line-area-6.png traits.xml
  Log:
  added to alt.design docs
  Submitted By: "Peter B. West" <[EMAIL PROTECTED]>
  
  Revision  Changes    Path
  1.2       +3 -3      xml-fop/docs/design/alt.design/alt.properties.xml
  
  Index: alt.properties.xml
  ===================================================================
  RCS file: /home/cvs/xml-fop/docs/design/alt.design/alt.properties.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- alt.properties.xml        17 Mar 2002 17:24:10 -0000      1.1
  +++ alt.properties.xml        27 Mar 2002 07:59:56 -0000      1.2
  @@ -1,7 +1,7 @@
   <?xml version="1.0" encoding="ISO-8859-1"?>
  -<!-- $Id: alt.properties.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
  +<!-- $Id: alt.properties.xml,v 1.2 2002/03/27 07:59:56 keiron Exp $ -->
   <!--
  -<!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
  
  
  
  1.2       +8 -1      xml-fop/docs/design/alt.design/book.xml
  
  Index: book.xml
  ===================================================================
  RCS file: /home/cvs/xml-fop/docs/design/alt.design/book.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- book.xml  17 Mar 2002 17:24:10 -0000      1.1
  +++ book.xml  27 Mar 2002 07:59:56 -0000      1.2
  @@ -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>
  
  
  
  1.1                  xml-fop/docs/design/alt.design/compound-properties.xml
  
  Index: compound-properties.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!-- $Id: compound-properties.xml,v 1.1 2002/03/27 07:59:56 keiron Exp $ -->
  <!--
  <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
  -->
  
  <document>
    <header>
      <title>Compound properties</title>
      <authors>
        <person name="Peter B. West" email="[EMAIL PROTECTED]"/>
      </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>
  
  
  
  1.1                  xml-fop/docs/design/alt.design/coroutines.png
  
        <<Binary file>>
  
  
  1.1                  xml-fop/docs/design/alt.design/coroutines.xml
  
  Index: coroutines.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!-- $Id: coroutines.xml,v 1.1 2002/03/27 07:59:56 keiron Exp $ -->
  <!--
  <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
  -->
  
  <document>
    <header>
      <title>Implementing co-routines</title>
      <authors>
        <person name="Peter B. West" email="[EMAIL PROTECTED]"/>
      </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>
  
  
  
  1.1                  xml-fop/docs/design/alt.design/footnotes.xml
  
  Index: footnotes.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!-- $Id: footnotes.xml,v 1.1 2002/03/27 07:59:56 keiron Exp $ -->
  <!--
  <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
  -->
  
  <document>
    <header>
      <title>Implementing footnotes</title>
      <authors>
        <person name="Peter B. West" email="[EMAIL PROTECTED]"/>
      </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>
  
  
  
  1.1                  xml-fop/docs/design/alt.design/galley-preprocessing.png
  
        <<Binary file>>
  
  
  1.1                  xml-fop/docs/design/alt.design/galleys.xml
  
  Index: galleys.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!-- $Id: galleys.xml,v 1.1 2002/03/27 07:59:56 keiron Exp $ -->
  <!--
  <!DOCTYPE document SYSTEM "../../xml-docs/dtd/document-v10.dtd">
  -->
  
  <document>
    <header>
      <title>Galleys</title>
      <authors>
        <person name="Peter B. West" email="[EMAIL PROTECTED]"/>
      </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>
  
  
  
  1.1                  xml-fop/docs/design/alt.design/initial-column-values.png
  
        <<Binary file>>
  
  
  1.1                  xml-fop/docs/design/alt.design/line-area-5.png
  
        <<Binary file>>
  
  
  1.1                  xml-fop/docs/design/alt.design/line-area-6.png
  
        <<Binary file>>
  
  
  1.1                  xml-fop/docs/design/alt.design/traits.xml
  
  Index: traits.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!-- $Id: traits.xml,v 1.1 2002/03/27 07:59:56 keiron Exp $ -->
  <!--
  <!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="[EMAIL PROTECTED]"/>
      </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>
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to