A DOM-like object model has been implemented. It supports layout handlers for images, scalable images, text and link objects.
The basic object model has been extended by logical objects which enable logical grouping of objects, e.g., format grouping.
The flow layout controller has been extended by so-called subcontainers, which enable the automated construction of lines, columns, etc.
Document structure processing is done by a markup script parser (DIL parser), which provides processing for any markup based script file. Thus HTML and XML scripts may serve as input, a matching DCL knowledge base assumed.
Layout knowledge input is parsed by the DCL parser. Multiple DCL scripts can be added to one knowledge base. The knowledge is semi-compiled into memory for an efficient interpretation by the layout generator.
As a further improvement, input is now represented as a W3C DOM (level 1) structure. This allows external software to deliver and to modify input directly without additional parsing efforts.
Static output components for HTML and SMIL are provided:
Additionally, DCL may carry user-defined output methods. This template mechanism allows the specifiction of a new output format using a DCL style sheet. As an example application for this technique, a DCL style sheet for RealText has been realized.
Backtracking-based search for alternative design patterns is provided. To achieve a faster pruning of the search space, conflict-directed backtracking has been implemented [KondrakBeek97], which allows to guide the search process. Depending on the current state of generation, the layout generator automatically tries to determine a guilty object based on simple heuristics and tries to solve the current conflict by creating an alternative layout for this object. Using this mechanism, further heuristics about the construction of frames and other subcontainers have been added.
An event-based control mechanism has been added to the layout generation process. Events can handle additional composition task or modify the control flow, especially the search process.
A first implementation of spatial constraints was based on local propagation and Boolean layout constraints. This approach, taken from the single value solver (SIVAS) of the LayLab system, was adapted for an efficient usage of the DesignComposer's hierarchical object model. A further extension enables to control dynamic values (non-constraint values changing during runtime). This feature is required to realize certain complex spatial constraints, like a dynamic spacing depending on object number or size within a given scope.
Since May 2000, a more flexible interface is included in the DesignComposer package which enables the use of other constraint solvers for the resolution of placement problems. The solver may be selected individual for each design-pattern. Currently, the original solver and an implementation based on the Cassowary package are provided. Please note that constraints for other solvers than the original one have to be specified in Java.
For the constraint assertions on finite domains, a general propagator constraint model has been added. Currently, it is used to specify assertions about the pattern selection and format.
Constraints may be parametrized to enable a more abstract specification.
Automated indexing is supported to enable the construction of a table of contents and similar index structures.
A post-processing component with own constraint model allows a flexible modification of a result produced by the layout generator. Typically, beautification by relocation of objects is done here.
Based on a simple statistic approach, the DC is able to optimize the generation process based on the results of previous runs. This optimization is non-evasive, what means that it does not restrict the search space in any way; instead, priorities used for doing design decisions during a generation run are modified. This is important to prevent the removal of interesting solutions from the search space during the optimization.
MK's TextLayout - second version done.
IBM's XML4J may optionally be used as input parser.
Interface structures enable external software to gain control of some basic processing actions. The generation may be restarted, paused and continued. Furthermore, the messaging system of the DC may be completely redirected; for non-fatal errors, the system feedback (stop/continue) may be completely exchanged.
A context retrieval module has been implemented which automatically extracts data important for layout from a presentation environment. Note that this module is currently not available for free download. If you are interested in it, please contact us directly.