Real Rich-Text support is making it's way into the engine

One of the last commited items out of my infinite bag of things to add to the reporting system was the support for real Rich-Text content. (PRE-166)

Rich-Text basically means: Formatted text. But although formatted text may be nice, our layouting system easily can do a bit more than that. As the current layout-system of the classic-engine is a spin-off of the layout system of the frozen Flow-Engine, we can render full-featured documents at nearly no additional costs. And of course, implementing a minimalistic system that supports little more than <b>, <i>, <ul> is boring. If I wanted an non-challenging job, I would become Banker, or even Central-Banker.

Today, surprisingly after only 6 hours of work, the first RTF document appeared happily in the report-designer's report-preview. And even more surprising to me: There are only two features missing to make it totally complete: Justified text-alignment and line-indentions. Solving the justified-text-alignment problem is a to large to solve within the Citrus timeframe (at least if I want to have it safe and scalable. Text-processing is the stuff that takes ages to compute and eats memory like trolls eat children). But text-indention is easy to bring in (it's yet another "almost there" feature).

Now how does it work?

Rich-Text processing is disabled by default and has to be enabled by setting the "rich-text-type" attribute to the desired document type. This way we preserve backward compatiblity (as old reports have no such setting, so they default to text/plain documents) and performance (as plain-text does not need to go through the Rich-Text parser). If the rich-text-flag is set, any content that could contain a document (CLOB, BLOB, char- and byte-arrays and InputStreams and Readers, and of course javax.swing.text.Document instances) are passed into the layouter as raw-objects. The layout-preprocessor then translates these objects into real Document instances by calling RichTextProcessor implementations. These implemenations are pluggable, so that you can easily bring your own rich-text format into the engine. The built-in RichTextProcessors use the Swing-EditorKit parsers for RTF and HTML to create the Documents and then translate these documents into Bands, Label and Content-(formerly known as Image)-elements.

The original element is then treated as Band and the generated Band/Elements are processed as if they were childs of this artifical band.

Of course, introducing artificial Bands and Elements did have side-effects. Not on the engine's core, which did not required a single change. But we now have a new Element-Type called "external-element-field", which allows to use the same trick outside of the layouter. If the element returns a "org.pentaho.reporting.engine.classic.engine.core.Element" instance, that instance is printed as if the element was a band and the returned instance were the band's only child. So far, the only one real use for it is to load external Sub-Reports from an URL or path, but after Citrus we may weave some more magic in this area.

If you haven't checked out our Citrus-Reporting yet, then you are missing an amazing new world. So don't hesitate and grab the latest build!