FOray: Vision

Contents

• The Big Picture
• Immediate Goals
  • Home for Enhancements
  • Modularization

The Big Picture

FOray’s big-picture goal is to eventually provide a complete XML publishing solution, based on standards. This goal includes a WYSISYG editor for the user that is backed (through several layers) by the semantic XML. In other words, the user will actually be editing the semantic XML, but will be doing so through the AreaTree, which is backed by the FOTree, which is backed by the semantic XML.

There is one gaping hole in the above scenario, and that is getting the FOTree backed by the semantic XML. XSLT is currently a one-way street, so we need to find a creative way for a stylesheet concept to create an FOTree that is a “view” of the semantic XML. We think this is doable, but it is non-trivial, and, at the moment anyway, non-standard.

Immediate Goals

Home for Enhancements

The FOP developers refuse to even consider enhancements to the FOP 0.20.5 version, their most recent release. FOray started with FOP 0.20.5 as its codebase and is glad to consider enhancements to that base so that they can be maintained, used, tested, and improved.

Modularization

The major motivation for FOray’s existence is the modularization of the system design. This goal is important:

• so that changes such as the one that FOP started in 2001 can be better isolated, allowing portions of the code that are not affected by radical rewrites to be maintained and immediately usable
• to allow working code to not be abandoned until a better alternative is complete
• to allow new components (such as layout engines) to be added or removed seamlessly

The FOP developers have repeatedly refused to consider modularization of their codebase, although they may be willing to do so after their new layout system is complete. We believe that modularization is a necessary prerequisite to improving any part of the system. Although it is not technically required as a prerequisite to FOP completing their new layout system, we think it would make (or would have made) that job much easier, and would have prevented many of the project problems that have prevented FOP from releasing code in over three years. Our purpose is to first modularize, then proceed with the necessary changes to layout and other modules. One nice benefit of this approach is that, since we have some subsystems already isolated, improvements can be made to them already in a much easier manner, with or without future isolation and modularization work. Improving the font subsystem, for example, is much, much simpler and more straightforward than it was in the FOP 0.20.5 code.

We are modularizing the system in a straightforward, logical, and methodical manner. The following modules have already been spun out of the codebase:

• FOrayFont
• FOrayGraphic
• FOrayPDF
• FOrayPS

Work on modularizing the FOTree is nearly complete. It is designed to be independent. Although it is technically dependent on Area Tree for grafting and other issues, we think these issues can be abstracted through parameters and interfaces.

Other candidates for FOray modules include (in no particular order):

• hyphenation engine (independent)
• hyphenation patterns (independent)
• Control (dependent on all modules). This is essentially what will be left over after everything else is modularized.
• Area Tree (dependent on FO Tree, at least)
• Output Libraries (all independent)
  • PostScript
  • RTF
  • MIF
  • probably others
• Renderers (dependent on Area Tree and related output library)
• Layout Strategies (dependent on FO Tree, Area Tree, and some Renderer concepts)

Project resources and the needs of FOray developers and users will dictate how and when the above chores are tackled