Community
Participate
Working Groups
A report which contains a dynamic text element which will be interpreted as HTML fails to properly parse and render some valid HTML style constructs when producing PDF output. The same HTML content works properly for HTML output. This particular case is when a style uses "rgb(x, y, z)" to define a color component of the style, and it is due to having spaces (which are legal HTML syntax) between the three parameters of the rgb call. That is, if the markup is changed to be "rgb(x,y,z)" it will work properly. There is also a non-fatal stack dump produced when the rgb call with spaces is used (see attached file). The attached rptdesign file is a stripped down version which reproduces the problem. Reproducible: Always Steps to Reproduce: 1. Open the rptdesign file in the standalone BIRT report designer 2. Run->View Report->HTML 3. Note that the box surrounding the text is red. 4. Run->View Report->PDF 5. Note that the box surrounding the text is black, not red as specified.
Created attachment 228852 [details] simple rptdesign file that displays the issue
Created attachment 228853 [details] stack dump produces when processing the rptdesign file through the API
You can try "border: 1pt solid red" in the HTML. currently PDf does not support rgb(255, 0, 0) setting.
In our production environment, the dynamic text boxes contain HTML markup from our customer base so we cannot simply change the color description to "red". Also, the rgb setting does work for PDF output but only if there are no spaces in the entry. That is "rgb(255, 0, 0)" fails but "rgb(255,0,0)" works. I looked briefly at the source code and the parser was splitting CSS items by the space character which is what causes the issue in this case because it ends up sending "rgb(255," then "0,", and "0)" down to the CSS processor. If necessary, please consider this an enhancement request. At the very least, it would be nice to avoid the complete stack dump when this error is encountered.
