From f7aa56bc54d36ea5654963bdadc48517061e86ca Mon Sep 17 00:00:00 2001 From: Jeremias Maerki Date: Fri, 24 Jun 2005 09:32:20 +0000 Subject: [PATCH] CVS -> SVN. Recreated Clay's changes (hopefully all of them). Removed alt.design stuff. git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@201586 13f79535-47bb-0310-9956-ffa450edef68 --- .../xdocs/design/alt.design/PropNames-png.xml | 36 - .../design/alt.design/alt-properties.xml | 169 ---- .../design/alt.design/compound-properties.xml | 234 ----- .../xdocs/design/alt.design/coroutines.xml | 135 --- .../xdocs/design/alt.design/footnotes.xml | 156 --- .../xdocs/design/alt.design/galleys.xml | 233 ----- .../content/xdocs/design/alt.design/index.xml | 143 --- .../content/xdocs/design/alt.design/keeps.xml | 126 --- .../design/alt.design/properties-classes.xml | 168 ---- .../properties/PropertyConsts-class.ehtml | 103 -- .../properties/classes-overview.ehtml | 371 ------- .../properties/enumerated-values.ehtml | 324 ------ .../properties/getInitialValue.ehtml | 160 --- .../alt.design/properties/introduction.xml | 169 ---- .../properties/propertyExpressions.ehtml | 457 --------- .../properties/simple-properties.ehtml | 260 ----- .../xdocs/design/alt.design/spaces.xml | 195 ---- .../xdocs/design/alt.design/traits.xml | 385 -------- .../design/alt.design/user-agent-refs.xml | 929 ------------------ .../xdocs/design/alt.design/xml-parsing.ehtml | 366 ------- .../content/xdocs/dev/api-doc.xml | 9 +- .../content/xdocs/dev/conventions.xml | 9 +- src/documentation/content/xdocs/dev/doc.xml | 13 +- src/documentation/content/xdocs/dev/index.xml | 44 +- .../content/xdocs/dev/testing.xml | 25 +- src/documentation/content/xdocs/dev/tools.xml | 129 +-- src/documentation/content/xdocs/download.xml | 162 ++- src/documentation/content/xdocs/gethelp.xml | 6 +- src/documentation/content/xdocs/maillist.xml | 7 +- src/documentation/content/xdocs/site.xml | 10 +- src/documentation/content/xdocs/team.xml | 5 +- 31 files changed, 274 insertions(+), 5264 deletions(-) delete mode 100644 src/documentation/content/xdocs/design/alt.design/PropNames-png.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/alt-properties.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/compound-properties.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/coroutines.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/footnotes.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/galleys.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/index.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/keeps.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties-classes.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.ehtml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties/classes-overview.ehtml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties/enumerated-values.ehtml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties/getInitialValue.ehtml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties/introduction.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties/propertyExpressions.ehtml delete mode 100644 src/documentation/content/xdocs/design/alt.design/properties/simple-properties.ehtml delete mode 100644 src/documentation/content/xdocs/design/alt.design/spaces.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/traits.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/user-agent-refs.xml delete mode 100644 src/documentation/content/xdocs/design/alt.design/xml-parsing.ehtml diff --git a/src/documentation/content/xdocs/design/alt.design/PropNames-png.xml b/src/documentation/content/xdocs/design/alt.design/PropNames-png.xml deleted file mode 100644 index 944bb0076..000000000 --- a/src/documentation/content/xdocs/design/alt.design/PropNames-png.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - -
- ..fo.PropNames diagram - - - -
- -
- PropNames.class -
-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/alt-properties.xml b/src/documentation/content/xdocs/design/alt.design/alt-properties.xml deleted file mode 100644 index 82fa4b907..000000000 --- a/src/documentation/content/xdocs/design/alt.design/alt-properties.xml +++ /dev/null @@ -1,169 +0,0 @@ - - - - - - -
- Implementing Properties - - - -
- -
- An alternative properties implementation - - The following discussion focusses on the relationship between - Flow Objects in the Flow Object tree, and properties. There - is no (or only passing) discussion of the relationship between - properties and traits, and by extension, between properties - and the Area tree. - -

- Property handling is complex and expensive. Varying numbers of - properties apply to individual Flow Objects - (FOs) in the FO tree but - any property may effectively be assigned a value on any - element of the tree. If that property is inheritable, its - defined value will then be available to any children of the - defining FO. -

- - (XSL 1.0 Rec) 5.1.4 Inheritance - ...The inheritable properties can be placed on any formatting - object. - -

- Even if the value is not inheritable, it may be accessed by - its children through the inherit keyword or the - from-parent() core function, and potentially by - any of its descendents through the - from-nearest-specified-value() core function. -

-

- In addition to the assigned values of properties, almost every - property has an initial value which is used - when no value has been assigned. -

-
- The history problem -

- The difficulty and expense of handling properties comes from - this univeral inheritance possibility. The list of properties - which are assigned values on any particular FO - element will not generally be large, but a current value is - required for each property which applies to the FO - being processed. -

-

- The environment from which these values may be selected - includes, for each FO, for each applicable - property, the value assigned on this FO, - the value which applied to the parent of this FO, - the nearest value specified on an ancestor of this element, - and the initial value of the property. -

-
-
- The construction hierarchy -

- Properties are resoved in the FO tree in a - strictly hierarchical manner. Nodes are detected in the - input in a pre-order traversal, and are - built in the same order. This imples that there are two - phases, or states, of property resolution and construction. - Any particular FO node is either in a state of constructing - its own subtree, or in a stable state where the subtree - construction is complete. These states have differenct data - requirements. -

-
-
Subtree building
-
- In this state, all properties defined on this node, or any - of its ancestors must be available to the subtree. In - effect, any property defined on this node must be - available to its descendants, as all properties defined on - any ancestor are available to this node. -
-
Stable: subtree building complete
-
- In this state, only the properties applicable to - this node need be available. -
-
-
-
- Representing properties: <property> classes -
- Class vs instance -

- What information is required of <property> objects? - More particularly, what information is particular to the - <property> classes, and what to the instantiated - objects? The answer to this question depend largely on - how the <property> objects are used in the context - of layout and Area tree construction. The approach taken - in this implementation is that properties are simply flags - on certain data values associated with FOs. The semantics - of these flags are determined within the layout engine. -

-

- Certain constant information attaches to individual - <property> classes. This information is detailed in - the descriptions of individual properties in Section - 7 of the specification. Such information is - represented in class fields and data - structures within the classes. -

-

- The "instance" information content of a <property> - is: -

-
    -
  • - explicitly, the PropertyValue datum of - the property, and -
    • -
  • - implicitly, the Flow Object to which - the property is attached. -
    • -
-

- Properties, then, serve essentially to link FO - instances with PropertyValue instances, - attaching certain invariant semantic markers to the - PropertyValues in the process. In this implementation, - these functions can be realised entirely within the - <property> classes themselves, - without the need to instantiate any objects. In practice, - <property> singletons are - instantiated to make access to some invariants simpler. -

-
-
-

- Next: property classes overview. -

-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/compound-properties.xml b/src/documentation/content/xdocs/design/alt.design/compound-properties.xml deleted file mode 100644 index 0409b06a5..000000000 --- a/src/documentation/content/xdocs/design/alt.design/compound-properties.xml +++ /dev/null @@ -1,234 +0,0 @@ - - - - - - -
- Compound properties - - - -
- -
- Compound properties in XSLFO - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Property typeSectionInherited'inherit'
<length-range>
minimum
optimum
maximum
block-progression-dimension7.14.1noyes
inline-progression-dimension7.14.5noyes
leader-length7.21.4yesyes
<length-conditional>
length
conditionality
border-after-width7.7.12noyes
border-before-width7.7.9noyes
border-end-width7.7.18noyes
border-start-width7.7.15noyes
padding-after7.7.32noyes
padding-before7.7.31noyes
padding-end7.7.34noyes
padding-start7.7.33noyes
<length-bp-ip-direction>
block-progression-direction
inline-progression-direction
border-separation7.26.5yesyes
<space>
minimum
optimum
maximum
precedence
conditionality
letter-spacing7.16.2yesyes
line-height7.15.4yesyes
space-after7.10.6noyes
space-before7.10.5noyes
space-end7.11.1noyes
space-start7.11.2noyes
word-spacing7.16.8yesyes
<keep>
within-line
within-column
within-page
keep-together7.19.3yesyes
keep-with-next7.19.4noyes
keep-with-previous7.19.5noyes
-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/coroutines.xml b/src/documentation/content/xdocs/design/alt.design/coroutines.xml deleted file mode 100644 index b21dd6959..000000000 --- a/src/documentation/content/xdocs/design/alt.design/coroutines.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - -
- Implementing co-routines - - - -
- -
- Implementing Co-routines in FOP -

- 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, Introduction to - Formatting , includes the following comments. -

- - [Formatting] comprises several steps, some of which depend on - others in a non-sequential way.
...and...
- [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. - -

Section 3.1, Conceptual Procedure, includes:

- - 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. - -
- Application of co-routines -

- 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. -

-

- 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. -

-

- 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. -

-

- 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.

- Figure 1 -

-
-

- For example, think of a page-production method working on a - complex page-sequence-master. -

- - void makePages(...) { - ... - while (pageSequence.hasNext()) { - ... - page = generateNextPage(...); - boolean over = flow.fillPage(page); - if (over) return; - } - } - -

- The fillPage() 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. -

-
-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/footnotes.xml b/src/documentation/content/xdocs/design/alt.design/footnotes.xml deleted file mode 100644 index ebaee47c4..000000000 --- a/src/documentation/content/xdocs/design/alt.design/footnotes.xml +++ /dev/null @@ -1,156 +0,0 @@ - - - - - - -
- Implementing footnotes - - - -
- -
- Implementing footnotes in FOP -

- 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. -

-
- Footnotes and galleys -

- In the structure described in the introduction to FOP galleys, 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. -

-

- When footnotes are introduced, the communication between - galleys and layout manager, as mentioned above, 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. -

-
-
- Multiple columns and footnotes - - A possible method for multi-column layout and balancing - with footnotes, using a galley-based approach. - -

- This note assumes a galley, as discussed elsewhere, 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 layout - tree. -

-

- 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. -

-

- 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. -

-

- 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.

- Figure 1 Columns before first footnote. -

-
-
-
- Balancing columns -

- Figure 2 Adding a line area with first - footnote. -

-
-

- 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. N.B. - 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. -

- Figure 3 Adding a line area with next - footnote. -

-
-
-
- Layout managers in the flow of control - To be developed. -
-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/galleys.xml b/src/documentation/content/xdocs/design/alt.design/galleys.xml deleted file mode 100644 index 04a1d824d..000000000 --- a/src/documentation/content/xdocs/design/alt.design/galleys.xml +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - -
- Galleys - - - -
- -
- Layout galleys in FOP -
- Galleys in Lout -

- Jeffrey H. Kingston, in The - Design and Implementation of the Lout Document Formatting - Language Section 5, describes the - galley abstraction which he implemented in - Lout. A document to be formatted is a stream of - text and symbols, some of which are receptive - symbols. The output file is the first receptive - symbol; the formatting document is the first galley. The - archetypical example of a receptive symbol is - @FootPlace and its corresponding galley - definition, @FootNote. -

-

- 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

-
    -
  • - an appropriate target has been encountered in the file, -
    • -
  • - the component being promoted contains no unresolved galley - targets itself, and -
    • -
  • - there is sufficient room for the galley component at the - target. -
    • -
-

- 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 bottom-up. -

-
-
- Some features of galleys -

- It is essential to note that galleys are self-managing; they - are effectively layout bots 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.) -

-

- 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 auto 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. -

-

- 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. -

-
-
- The layout tree - -

- This proposal for implementing galleys in FOP makes use of a - layout tree. As with the layout managers already - proposed, the layout tree acts as a bridge between the FO Tree and the Area Tree. 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 galley - nodes and area tree fragments. - 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 - layout-master-set. -

-
-
- Processing galleys -

- Galleys are processed in two basic processing environments: -

-
- Inline- and block-progression dimensions known -

- The galley at set-up is provided with both an - inline-progression-dimension (i-p-d) and - a block-progression-dimension (b-p-d). - 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. -

-

- 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. -

-
-
- Inline- ior block-progression-dimensions unknown -

- 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 another - discussion. 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 fo:character nodes and images of fixed - dimensions. -

-
-
-
- Galley pre-processing - -

- 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. -

- Figure 1 -

-
-

- 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. -

-

- 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 getNextBreakPosition. -

-
-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/index.xml b/src/documentation/content/xdocs/design/alt.design/index.xml deleted file mode 100644 index b728213fd..000000000 --- a/src/documentation/content/xdocs/design/alt.design/index.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - - - -
- FOP Alternative Design - Alternative Design Approach to FOP - $Revision$ $Name$ - - - -
- - -
- Alternative Design -

- This section of the FOP web site contains notes on approaches - to an alternative design for FOP. The individual documents - here are fragmentary, being notes of particular issues, - without an overall framework as yet. -

-

- The main aims of this redesign effort are: -

-
    -
  • full conformance with the Recommendation
    • -
  • no limitation on the size of files
    • -
  • increased performance
    • -
  • reduced memory footprint
    • -
-

- Secondary aims include: -

-
    -
  • increased performance
    • -
  • reduced memory footprint
    • -
-

- In order to achieve these aims, the primary areas - of design interest are: -

-
    -
  • - Representing properties, for most purposes, as integers. -
    • -
  • - Implementing a top-down processing model for each of the - processing components. -
    • -
  • - Distributing FOP processing over a number of threads with - single-point downstream communication and flow control by - means of traditional producer/consumer queues. The threads - so far under consideration are: -
      -
    • XML parser
      • -
    • FO tree builder
      • -
    • layout engine
      • -
    • Area tree builder
      • -
    -
    • -
  • - Redesigning XML parsing and FO tree building using a - pull-parsing methodology with integrated FO - input validation. -
    • -
  • - Representing vital relationships among the elements with - appropriate data structures. These include: -
      -
    • - Representing trees with explicit Tree objects, rather than - as implicit relationships among other objects. -
      • -
    • - Drawing threads through the tree nodes to - represent linear layout relationships for resolving - keeps, breaks and space specifiers. -
      • -
    -
    • -
  • - Caching integrated into the tree node access methods. -
    • -
-
- Status and availability -

- The ALT DESIGN effort is not taking place on the - main line of development, represented by the HEAD - tag on the CVS trunk. The source is available via the - FOP_0-20-0_Alt-Design tag. This code has only a - non-Ant build environment based on some small unix - shell scripts and the jikes compiler. The parser - stage and the FO tree building code is present. The first - example of producer/consumer binding is working, the Tree - class and the Node class with inner iterator - classes are available and working. Property handling is - almost complete, and all FO classes are present and - sufficiently complete to allow for FO tree building. -

-

- Preliminary results and follow-up testing of FO tree building shows memory - reductions of almost 50% compared to the most recently tuned - version of the maintenance version of the code (FOP 0.20.5 - RC). Alt-Design FO tree building was also slightly faster, - in spite of the use of pull parsing implemented on top of - SAX. -

-

- Currently, only Peter - West is working on the ALT DESIGN sub-project. -

-
-
- - - - diff --git a/src/documentation/content/xdocs/design/alt.design/keeps.xml b/src/documentation/content/xdocs/design/alt.design/keeps.xml deleted file mode 100644 index eb26ba8a8..000000000 --- a/src/documentation/content/xdocs/design/alt.design/keeps.xml +++ /dev/null @@ -1,126 +0,0 @@ - - - - - - -
- Keeps and breaks - - - -
- -
- Keeps and breaks in layout galleys -

- The layout galleys and the - layout tree - which is their context have been discussed elsewhere. Here we - discuss a possible method of implementing keeps and breaks - within the context of layout galleys and the layout tree. -

-
- Breaks -

- Breaks may be handled by inserting a column- or page-break - pseudo-object into the galley stream. For break-before, the - object would be inserted before the area in which the flow - object, to which the property is attached, is leading. If - the flow object is leading in no ancestor context, the - pseudo-object is inserted before the object itself. - Corresponding considerations apply for break-after. - Selection of the position for these objects will be further - examined in the discussion on keeps. -

-
-
- Keeps -

- Conceptually, all keeps can be represented by a - keep-together pseudo-area. The keep-together property - itself is expressed during layout by wrapping all of the - generated areas in a keep-together area. Keep-with-previous - on formatting object A becomes a keep-together area spanning - the first non-blank normal area leaf node, L, generated by A - or its offspring, and the last non-blank normal area leaf - node preceding L in the area tree. Likewise, keep-with-next - on formatting object A becomes a keep-together area spanning - the last non-blank normal area leaf node, L, generated by A - or its offspring, and the first non-blank normal area leaf - node following L in the area tree. -
TODO REWORK THIS for block vs inline -

-

- The obvious problem with this arrangement is that the - keep-together area violate the hierarachical arrangement of - the layout tree. They form a concurrent structure focussed - on the leaf nodes. This seems to be the essential problem - of handling keep-with-(previous/next); that it cuts across - the otherwise tree-structured flow of processing. Such - problems are endemic in page layout. -

-

- In any case, it seems that the relationships between areas - that are of interest in keep processing need some form of - direct expression, parallel to the layout tree itself. - Restricting ourselves too block-level elements, and looking - only at the simple block stacking cases, we get a diagram - like the attached PNG. In order to track the relationships - through the tree, we need four sets of links. -

-

- Figure 1 -

-
-

- The three basic links are: -

-
    - -
  • Leading edge to leading edge of first normal child.
    • -
  • Trailing edge to leading edge of next normal - sibling.
    • -
  • Trailing edge to trailing edge of parent.
    • -
-

- Superimposed on the basic links are bridging links which - span adjacent sets of links. These spanning links are the - tree violators, and give direct access to the areas which - are of interest in keep processing. They could be - implemented as double-linked lists, either within the layout - tree nodes or as separate structures. Gaps in the spanning - links are joined by simply reproducing the single links, as - in the diagram. The whole layout tree for a page is - effectively threaded in order of interest, as far as keeps - are concerned. -

-

- The bonus of this structure is that it looks like a superset - of the stacking constraints. It gives direct access to all - sets of adjacent edges and sets of edges whose space - specifiers need to be resolved. Fences can be easily enough - detected during the process of space resolution. -

-
-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/properties-classes.xml b/src/documentation/content/xdocs/design/alt.design/properties-classes.xml deleted file mode 100644 index 7cb8979b9..000000000 --- a/src/documentation/content/xdocs/design/alt.design/properties-classes.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -
- Properties classes - - - -
- -
- The <em>org.apache.fop.fo.properties</em> classes -
- Introduction -

- In respect of their fields and data structures, the - <property> classes have a virtual - instantiation in the arrays of the singleton PropertyConsts object, created during - the static - initialization of the class. The methods of these - classes are accessed through an array of singelton - instances of the individual <property> classes, which - is maintained in PropertyConsts. - - - these classes are intended to - remain as repositories of static data and methods. The name - of each property is entered in the - PropNames.propertyNames array of - Strings, and each has a unique integer constant - defined, corresponding to the offset of the property name in - that array. -

-
- Fields common to all classes -
-
final int dataTypes
-
- This field defines the allowable data types which may be - assigned to the property. The value is chosen from the - data type constants defined in Properties, and - may consist of more than one of those constants, - bit-ORed together. -
-
final int traitMapping
-
- This field defines the mapping of properties to traits - in the Area tree. The value is chosen from the - trait mapping constants defined in Properties, - and may consist of more than one of those constants, - bit-ORed together. -
-
final int initialValueType
-
- This field defines the data type of the initial value - assigned to the property. The value is chosen from the - initial value type constants defined in - Properties. -
-
final int inherited
-
- This field defines the kind of inheritance applicable to - the property. The value is chosen from the inheritance - constants defined in Properties. -
-
-
-
- Datatype dependent fields -
-
Enumeration types
-
- final String[] enums
- This array contains the NCName text - values of the enumeration. In the current - implementation, it always contains a null value at - enum[0].

- - final String[] - enumValues
When the number of - enumeration values is small, - enumValues is a reference to the - enums array.

- - final HashMap - enumValues
When the number of - enumeration values is larger, - enumValues is a - HashMap statically initialized to - contain the integer constant values corresponding to - each text value, indexed by the text - value.

- - final int - enumeration-constants
A - unique integer constant is defined for each of the - possible enumeration values.

-
-
Many types: - final datatype - initialValue
-
- When the initial datatype does not have an implicit - initial value (as, for example, does type - AUTO) the initial value for the property is - assigned to this field. The type of this field will - vary according to the initialValueType - field. -
-
AUTO: PropertyValueList auto(property, - list)>
-
- When AUTO is a legal value type, the - auto() method must be defined in the property - class.
- NOT YET IMPLEMENTED. -
-
COMPLEX: PropertyValueList complex(property, - list)>
-
- COMPLEX is specified as a value type when complex - conditions apply to the selection of a value type, or - when lists of values are acceptable. To process and - validate such a property value assignment, the - complex() method must be defined in the - property class. -
-
-
-
-
- Nested property pseudo-classes -

- The property pseudo-classes are classes, like - ColorCommon which contain values, particularly - enums, which are common to a number of actual - properties. -

-
-

- Previous: property classes overview. -

-
- - - diff --git a/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.ehtml b/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.ehtml deleted file mode 100644 index 3af13c57d..000000000 --- a/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.ehtml +++ /dev/null @@ -1,103 +0,0 @@ - - - - - -