data missing from export in PRD 5.1.0

[David We]

I recently downloaded and am using the new stable version of PRD (i.e. 5.1.0). With this new version when I preview a report or export the report to a PDF some pages are missing data. For a test I tried the same report in PRD 5.0 and the preview was not missing any data.

Is this a known issue? Or is there something I am doing wrong?

Thanks.

[Taqua]

No, this is the first time I have heard of that. Can you provide more detail on what is happening? Any chance of giving us a sample report that demonstrates the problem, so that we can dig into it on our end?

[David We]

It is a fairly complicated report design. Basically all the sections except for the footer and header are missing from some pages. This data appears to be skipped. I am attaching the beginning of the report from a pdr 5.0 and a pdr 5.1 version so you can see the differences. Take a look at page 4 and 8 of the two pdf's (not the page number listed in the footer but the actual page number of the pdfs).

Not to add to the confusion but with pdf export vs. the print preview in PDR 5.1 there is another bug. In this case a particular label: × is missing from the pdf but is present in the print preview view as well as the pdf from PDR 5.0. Look on the first page for some examples of this × symbol.

Let me know how I can provide more information.

Thanks

[Taqua]

I created a JIRA case for this so that the error and all related work is correctly reported and tracked. Can you attach a PRPT file to this case to help me replicate the error?

Even without data (which I can auto-generate if needed) this will help me to understand what is going on inside the reporting engine and to replicate the bug on my side. Without it I would not even know where to start, as the PDF no longer contains essential information about the layout definition and elements used.

http://jira.pentaho.com/browse/PRD-5180

[David We]

Thanks for filing the bug report. Attached is a PRPT file of the report that generated the pdfs shown in my last post. Please let me know if you have any questions. Thanks.

[Taqua]

This is probably the largest use of "inline" bands and text I have seen in my reporting years. I am investigating now.

Just to be clear: Is the print preview itself the same between the two versions?
Is the problem limited only to the PDF output?

(from the PDFs it seems that all data is actually there (the positions of the elements that are printed match) - so if the print preview/ print out is actually fine, then that narrows it down to just the PDF output.

And at that point, the bug might be explained by the changes we added to support arabic text - and then the fix would not be as scary as a "argh I dont know whats going on" bug-fix.

[David We]

No. The print preview is not the same between both versions. The print preview in PRD 5.1 looks identical to the pdf version from PRD 5.1 that I attached earlier. So the bug is not restricted to the pdf export although it occurs in that too. Even the × symbol I am using is missing in both the pdf export and print preview versions of the PRD 5.1. If you recall, with PRD 5.0 there was initially some bugs with the pdf view but my version of 5.0 is an updated version where the pdf export bugs were fixed. More questions? please ask.

Now you can see why I am excited to have another bug fixed that you filed a JIRA case for (that bug preventing inline subreports within inline reports). And I still haven't found a way to create a hanging indent for text that fills up more than one line in my report.

Thanks for all the help.

[Taqua]

I am unable to replicate the problem with ordinary auto-generated data. Can you provide me with some sample data so that I can get to the bottom of this case?

The problem with bugs like these - layouting bugs - is that they tend to be rather shy. They are usually triggered by some arcane condition in the layouting code that only happens if the content is processed in exactly the right (well, wrong) way. So word-length and linebreak positions become crucial.

A small database dump to produce the problem would be perfect - and I will only use the data to diagnose the bug and it would stay confidential. Please either attach it to the JIRA case or send me an email via "tmorgner@pentaho.com"

Thank you!

[Taqua]

I just committed the fix to the master branch. CI is building this now. I have no information on whether this fix will be backported to the 5.1 code line.

This bug was triggered by some arcane condition due to the deeply nested structure of the report and the use of orphan styles on each level. Ultimately it was caused by the engine's pagination and cleanup code not agreeing how large elements should be when paginating, and thus the engine thought some groups with orphans were larger than the current page and therefore shifted elements off the visible section of the page.

If you are not using the CI build or cannot build a version of the reporting engine yourself, the workaround is to not use Orphan or Widow styles for now.