Home
Features
Modules
- aXSL Common
- aXSL Ps
- aXSL Font
- aXSL Graphic
- aXSL Hyphen
- aXSL Speech
- aXSL Text
- aXSL Pdf
- aXSL FoTree
- aXSL AreaTree
- aXSL Galley
- aXSL Layout
- aXSL Output
Project

aXSL: Modules

Summary of Modules
Area Tree Issues

Summary of Modules

The following table lists the aXSL modules and the dependencies between them. The aXSL jar is small enough that there is no great benefit to building only the module that are needed. (In other words, it is recommended that the entire aXSL jar file be installed by client applications, even if only some of it is used). However, when considering whether to use any part of aXSL, it is important to understand the scope of that commitment. For example, when using the axslPDF module to create PDFs, you have a built-in dependency on the axslFont and axslGraphic packages as well.

aXSL is a work in progress, and some modules are more stable and mature than others. The meanings of the items in the "Maturity" column below are as follows:

"Stable" means that future changes will be backward compatible to clients, subject to a normal deprecation cycle. (Implementors on the other hand, are never assured of backward compatibility, as they may need to add methods to provide new features.) By "normal deprecation cycle" we mean that types or methods will not be removed from release X + 1 unless they have been deprecated in release X.
"Partial" is an intermediate stage between "Experimental" and "Stable". It means that massive changes to the API are not expected and any changes at all that are not backward-compatible will be avoided if possible, but will be made if needed. When moving client code from release X to release X + 1, expect to deal with a limited number of API changes.
"Experimental" means that there are working applications using the API, but that it is possible that substantial changes may need to be made to the API in the future. When moving client code from release X to release X + 1, expect to deal with a substantial number of API changes.

Module Name	Repository module	Description	Dependencies	XSL-FO Specific?	Maturity
Universal components (available globally)
SVG library	lib	Pre-compiled jar for SVG.	None.	No.	Stable.
axslCommon	axsl-common	Common interfaces and enumerations useful in document processing.	None.	No (although enumerations are based on XSL-FO).	Experimental.
Standalone Modules
axslPs	axsl-ps	Interfaces for handling encoding issues.	None.	No.	Partial.
axslFont	axsl-font	Interfaces for handling fonts.	axslCommon, axslPs. Current repository code and releases after 0.2 no longer have a dependency on axslCommon.	No.	Partial.
axslGraphic	axsl-graphic	Interfaces for handling graphics, both bitmapped images and vector drawings.	SVG library, axslPs, axslFont.	No.	Experimental.
axslHyphen	axsl-hyphen	Interfaces for hyphenation words.	axslCommon.	No.	Experimental.
axslSpeech	axsl-speech	Interfaces for handling the integration of documents with speech systems.	None.	No.	Experimental.
axslLinebreak	axsl-linebreak	Interfaces for line-breaking.	axslCommon, axslFont	No.	Experimental.
axslPdf	axsl-pdf	Interfaces for creating PDF files.	SVG Library, axslFont, axslGraphic.	No.	Experimental.
Document Processing Modules
axslFoTree	axsl-fo	Interfaces for making XSL-FO content available.	SVG Library, axslCommon, axslFont, axslGraphic, axslText.	Yes.	Experimental.
axslGalley	axsl-galley	Interfaces useful for making laid-out pages available to renderers.	SVG Library, axslCommon, axslFont, axslGraphic.	No.	Experimental.
axslAreaTree	axsl-area	Interfaces useful for creating an Area Tree.	axslCommon, axslFont, axslGraphic, axslText, axslFoTree, axslGalley.	Yes.	Experimental.
axslLayout	axsl-layout	Interface useful for converting an FoTree to an AreaTree.	axslAreaTree.	No.	Experimental.
axslOutput	axsl-output	Interfaces useful for converting an axslFoTree directly to an output format that handles layout itself (like RTF or MIF), or rendering an axslGalley to a more fixed output medium (like PDF or PostScript).	axslFont, axslGalley.	No.	Experimental.

Area Tree Issues

You may have noticed that the concept of a "laid-out" document is represented twice in the above list of modules, once in axslAreaTree (for its creation) and the other in axslGalley (for its consumption). In practice, many applications will have one module that implements both of these. However, we think it is important to keep them separate within aXSL for two reasons:

It does a better job of separating concerns. For example, a layout system doesn't know or care about the location or background color of an area, but does care about its size and how to create other areas inside of it. On the other hand, a renderer does not need to (and should not be allowed to) create areas, but does need the location and background color.
It allows the axslGalley module to be used by non-XSL-FO applications. These applications can leverage the axslGalley data structures and the renderers that exist to render them to various output formats, but can use a different layout system.

Now, the axslAreaTree module is dependent on the axslFoTree module. Some implementations may have the Area Tree encapsulate the Fo Tree, providing a "view" of the Fo Tree. Others may choose instead to copy the relevant data out of the Fo Tree and embed it in the Area Tree. But both depend on the Fo Tree as the Area Tree is being created, that is they have "Bound Input". However, it is conceivable that a different scheme could be used there as well, that would allow an Area Tree to be independent of axslFoTree specifically and independent of XSL-FO generally, that is, having "Free Input".

There are advantages to each approach. If there is interest in a "Free Input" package, it seems conceivable that an adapter could be created that would adapt "Bound Input" to "Free Input". This would allow XSL-FO systems to always write to the Bound Input API, but be able to use implementations that natively used either API.