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 , ,
- 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!