View Report as PDF never finishes

[fs3514]

Description

We use the report runtime to generate reports from user-provided input.

For some inputs (HTML containing inline images), report generation never finishes. Instead, it produces an ever-growing output file until the disk is full. This issue only occurs when the report is rendered as PDF; rendering the same report as HTML works as expected.

Environment

• OS: Windows
• Browser: Firefox
• BIRT Version: 4.23.0

Additional Context

To improve reproducibility, I simplified the report and replaced the original data source with a scripted data source. As a result, the issue can be reproduced using the BIRT Report Designer All-In-One by viewing the report using "Run → View Report → As PDF".

rptdesign.zip

[merks]

This sounds suspiciously related to the problem I fixed yesterday

#2418

Before I invest too much effort, can you please test with the latest nightly build whether the problem is reproducible in what will soon become the next release?

https://download.eclipse.org/birt/updates/nightly/N202606020849/

[fs3514]

Hello merks,

I retested with birt-report-designer-all-in-one-4.24.0-202606020849-win32.win32.x86_64 but the report (when using PDF as output format) also does not finish.

[merks]

Thanks! I'll have a look soon.

[merks]

We appear to be endlessly creating new pages because of auto page breaking.

Maybe something doesn't fit on a page because there are a lot of pages:

[merks]

I think someone who understands the engine needs to take a look. The method org.eclipse.birt.report.engine.nLayout.area.impl.ContainerArea.checkPageBreak() loops forever.

If I hack it to stop after some counts

this PDF is then produced.

foo(1).pdf

I think something needs to check whether the loop is actually advancing any values used in the guard; the whole purpose/meaning of those values is a mystery to me.

[hvbtup]

The issue is this:

The image is part of the description column, with a width of 1200 and a height of 2400, without a unit specified.
The default unit is pixels (px).
So the height is 2400px.
The report does not specify an imageDPI value. I think the default for this value is 72.
2400 / 72 = 33.33 inch. The A4 page height is 29.7 cm, much less than these 33 inch.

So, the image can never fit as a whole on any page.

The image is part of the group header, and thus is repeated on page break.

All this is a non-sensical combination.

An image cannot be split like text on page-break, so this results in the endless loop.

If you specify eg. imageDPI=600 for the report, then the image is 4 inches high and fits on the page, and the report works.
Note: I tested with layoutPreference=fixed layout instead of layoutPreference=dynamic layout.

I don't say this is not a bug; a potential better BIRT could detect that the page break does not make any progress, and could just abort output generation, which would certainly be better than an endless loop.

But this report can never be generated without losing content, and BIRT cannot know which content is needed or not, so this report can never be generated at all.

[merks]

@hvbtup

I experimented with the following for org.eclipse.birt.report.engine.nLayout.area.impl.ContainerArea.checkPageBreak().

What do you think?

	protected boolean checkPageBreak() throws BirtException {
		boolean ret = false;
		if (!isInInlineStacking && context.isAutoPageBreak()) {
			int aHeight = getAllocatedHeight();
			// When table resolves its bottom border, the total height may exceed the page
			// body height.
			// We add 3pt to avoid unexpected page break.
			int left = aHeight + parent.getAbsoluteBP() - 3000;
			int right = context.getMaxBP();
			while (left > right) {
				if (!parent.autoPageBreak()) {
					return false;
				}
				aHeight = getAllocatedHeight();
				ret = true;

				int newLeft = aHeight + parent.getAbsoluteBP() - 3000;
				int newRight = context.getMaxBP();
				if (newLeft == left && newRight == right) {
					break;
				}
				left = newLeft;
				right = newRight;
			}
		}
		return ret;
	}

The names left and right are not so nice, but I'm not sure actually what these values measure. In any case, it does detect when the loop is no longer making progress via changes to the condition's values...

[hvbtup]

I'll not have time to review this the next days. But regarding the variable names, I can tell you that top and bottom seem more logical, as we're talking about heights and y-values here.
Without extensive testing, we shouId hesitate to merge this into 4.24.

[merks]

Indeed, I don't think merging this so late in the cycle is a good idea! It's just food for thought for the next cycle.