As a small deviation from the usual crosstab and layouter work, I cleaned out the style system of Pentaho Reporting.
It all started not long ago on a stormy night. Creepy rays of moonlight, dark clouds looming over the mountains, wolves howling. On this day, Marius was doing some experiments in getting cascading stylesheet styling into the reporting engine. (I suspect lightning rods and wild laughter was on the menu as well.)
His approach reminded me on the dreadful task I had to go through for the next release. Our style system, a ghoulish monster, has overstayed its welcome. Being ashamed of its nature, we did not expose it to anyone. So this rotten pile of code was sitting around, festering and stinking. I had to kill it. It was an act of mercy for all of us.
With the style crud gone, the reporting engine now has a simplified style system. With the monster, all style definitions on elements always showed a resolved picture of the global style status. For example, each label’s style fully queried all parent elements to compute the effective font information whenever anyone queried it.
In the new world elements no longer maintain that state. Styles are now resolved as part of the report processing after the style and attribute expressions have been evaluated. It not only simplifies cloning (a lot!), it also tunnels style computation through a single code path.
And then there came polly .. ah, well, the release of Suite 4.8, and the customary fun-week, where the daily drill is suspended for exploring the possibilities of the code.
Mix parts of LibCSS – the zombie that wanted to be a CSS-styled better reporting system – with the single code-path of style resolving, and you have CSS3 selector on top of the existing reporting style-system.
Pentaho Reporting now has a fully fledged style system. Any master-report contains a style-definition, which is basically what you know as style-sheet from HTML. Each style-definition consists of style-rules, where each rule has CSS3-selectors attached.
Style-definitions can either be part of the report definition itself or they can be stored as external files so that they can be shared between reports. The external files have the extension “.prptstyle” and are xml-files containing standard element style definitions.
The Pentaho Report Designer allows you to edit both internal and external style definitions. Use ‘Window’->’Style Definition Editor’ to edit standalone files, or use ‘Format’->’Edit Style Definition…’ to edit the internal style definition.
Both editor allow you to load and save ‘prptstyle’ files. Loading a style-file in the internal editor has the effect of importing that external style-definition into the local report, and saving exports it.
So don’t wait, download your own multi-functional report-designer now!
If you download within the next 24 hours, you not only get a style-definition editor, you also get this:
The ‘master-report’ object now has a new attribute called ‘style-sheet-reference’. Set this to a file-name or URL and Pentaho Reporting will load an external stylesheet when the report runs. Put a ‘prptstyle’ file on a public server and all your reports can share the same style definition.
All elements now also have two new attributes called ‘style-class’ and ‘id’ (not to be mixed with ‘xml-id’ for the HTML export) which allow you to match style-rules to elements. Like HTML’s ‘class’ attribute, class is a whitespace separated list of style-class-names that should apply to the element.
And don’t forget: The green-plus means that all of these attributes can be computed via a style-expression.
Very nice! Sometimes it just needs very little to encourage new ambitions 🙂
… but why xml and not css?
CSS allows a lot more settings than what we allow. For starters, they have unity, they have inheritance, functions, combined properties etc. Supporting all of that would take probably 3-4 weeks to implement just on a parser level. And at that point we would still have to throw away large portions of that parsed stuff as the engine simply is not a css compliant renderer.
Using the same XML I already use inside the bundle-files means I just simplified the parsing task to the point of non-existence. And as we intend to not let users see the underlying XML (or CSS or JSON or whatever the raw format of the day is), it makes no practical difference to our users. We have a GUI that is easy to understand, so there is no need to go down to raw formats.
And even web-based systems like Saiku should not have a problem implementing (or even auto-generating) a GUI based on the metadata the reporting engine already provides.
Why Pentaho Reporting 4.0 do not support units edit ? for example:px … Now all css values are default point units.
The reporting engine never supported anything other than points. We also never used CSS as a styling format for reports.
When we *export* to HTML, we use point as unit, as this is what we use internally anyway. But as the exported HTML is auto-generated, it really does not matter what unit is used from a end-user’s point of view. With using points as units, we can at least be sure that the HTML looks as much as possible as the PDF/print output. People never knew the difference between postscript and HTML and educating them on this matter was a fruitless undertaking in the past.
HI,
I tried this style sheet definition concept in Pentaho 5.3 version , I am able to create the style sheet , But even after linking this .prptstyle file to the report and giving style-class property changes are not getting reflected in the report
can some one help me in this .