aXSL

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

aXSL: Modules

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.