Custom String Format should preserve leading whitespaces when generating PDF

[aremund]

We recently upgraded from BIRT 4.13.0 to BIRT 4.14.0 and found a regression when generating PDF's for a Report with String-fields with a Custom-format.
Having the "Format" of the String-Field set to Unformatted all is well. However, having the "Format" of the String-Field set to Custom with "pattern" set to ^, leading white-spaces in the string-value are trimmed away. This was not the case in BIRT 4.13.0

As an example, I attached the file With_Leading_WhiteSpaces.png which is a screenshot from the report rendered with BIRT 4.13.0

Having the same report rendered with BIRT 4.14.0, the leading whitespaces are trimmed away.

As a reference, I also added the zipped rptdesign-file for the above mentioned report.
WhiteSpaceTestReport.zip

[hvbtup]

This might be a consequence of #1319

Can you use dynamic left padding as a workaround, or replacing the spaces with non-breaking-space unicode symbols?

[speckyspooky]

I investigated a little bit time with debugging and it seems to me that we have in this case no "normal" bug or changed behavior.
In my test case I debugged till the PDF-document will be created and the text with the "leading space" was given all the time (with option ^).

I saw that also the PDF-glyph-creation was included with the spaces (openpfd-library).
And the result is the current output without the spaces but I wasn't able to figure out why the spaces no longer displayed.
It seems to me that we haven't here an BIRT-bug, may be we have a changed behavior of the openpdf-library.

debug screen with test " text" - variable is fine, and glyphs will calculated

debug screen of the fetched glyphs

[merks]

FYI, I just update orbit to a new version of com.github.librepdf.openpdf:

https://repo1.maven.org/maven2/com/github/librepdf/openpdf/1.3.36/

So I expect the next build (and Help -> Perform Setup Tasks) should pick that up.

[hvbtup]

Hmm, one of the things I changed in the source code with #1319 was in nLayout/area/impl/LineArea.java.
There, a method ignoreLeftMostWhiteSpace() is called.

What this method does is (as its name says), it calculates the width (using the current font info) of the white space at the beginning of a text line, with the goal of shifting the output left correspondingly such that at the end the output starts where it should.

Probably this method should not be called if the layout element uses the equivalent to white-space: pre or if it's a data item with the "^" custom format.

[speckyspooky]

Hmm too, if it is only a width topic then the spaces should be displayed on PDF and only the start position of the text would be changed
but there are no blanks given.

I will start a new test with your mentioned method perhaps I can see a difference then.

[hvbtup]

I think what you say is basically what's happening here:

[speckyspooky]

Yes, this is the correct line because at method "ignoreLeftMostWhiteSpace()" the length of the white-spaces will be calculated.
On your marked line 149 it fires directly if a white-space-width given and change the start position of the textarea.

[hvbtup]

This change would solve this issue:

But I think we should also take care of text items with

        <property name="whiteSpace">pre</property>

So this isn't a perfect solution.
I have to stop working for today, though...

[hvbtup]

In the code I posted in the screenshot above, I think it must be getComputedStyle() instead of getStyle().
Besides, I'm not sure if startsWith("^") is the correct test. Can the ^ occur anywhere in the pattern?

Regarding "whitespace pre", I investigated further, and I think fixing this would be more complicated.

As of now, BIRT ignores leading whitespace for dynamic text items regardless of whether it is HTML or plain text.
This is caused by the way BIRT works.
I don't understand really what's going on there in detail, but to me it seems as if BIRT, when it comes to a dynamic text item (at least for plain text), it creates a nested structure of different items. In my test with a report containing just one dynamic text item with plain text, this structure contains a DataContent object - which is the same class as for the data items you would use in a report.
As part of the processing, BIRT then calls the LocalizedContentVisitor.processData method

which calls the format method in turn.
This method now applies formatting patterns to the content.
Now, as this DataContent content was generated by BIRT on the fly, all the patterns are null, include the pattern for string formatting.
Thus the behavior is the same as for a data item without the ^ string format pattern: The leading white space is stripped.

BTW: Why does BIRT generate a DataContent at all? I don't know, but I think I know where this happens: In DynamicTextItemExecutor:

I think a fix for this would have to see if the white-space style of the dynamic text item (or maybe even a span element inside the HTML for HTML text items) says that white-space should be preserved, and if that is the case, set the string format for the newly created DataContent to ^... This would go somewhere here (in LocalizedContentVisitor):

But personally I think changing this would be a bit risky and we should only fix this for actual data items.
I'll create a PR for this.

[hvbtup]

See PR #1539

[speckyspooky]

@merks
In this discussion you wrote that openpdf will be updated on orbit side.
I checked openpdf and there are some good bugfixes like (PDF-table-border-fixes on pagebreak) in the latest version 1.3.39 (17.01.2024).

Do you think it would be possible to add this version?

[merks]

The latest orbit version is

https://repo1.maven.org/maven2/com/github/librepdf/openpdf/1.3.39

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/table.html

[speckyspooky]

Perfect!

[merks]

Orbit versions are updated mostly automatically (whenever I run the analyzers/generators, which is several times per week). So generally you should expect that if there are updates you will have them within a day or two:

🚀

[speckyspooky]

I like the orbit update process.
So we have the latest version available into the BIRT-project.