property overflow = Hidden leads to cut-off decimals with DOCX output

[reiner-killet]

Hi,
since BIRT 4.8 we watch decimals being cut-off at the end of float values in table cells by the BIRT runtime (not RCP designer) with DOCX output.

I first tried to set "Overflow" to "Visible" for the entire table. This had no effect. Next, I examined inheritance of "Overflow" for rows, columns, cells, and data tags. I saw that it is not inherited from outside to inside. All inner elements were still showing "Overflow = Hidden (inherited)" what is wrong. Last, I set "Overflow" to "Visible" for the data tags. This works. Questions:

1. Can you please check if this is a bug which came to existence somewhere between version 4.6 and 4.8.?
2. Can someone explain why "Overflow" is not inherited?
3. Is there a simple way to update a large number of templates to achieve a behaviour like in 4.6?
   Thanks a lot

[hvbtup]

@reiner-killet Can you create a simple report demonstrating the issue?

[reiner-killet]

Eclipse BIRT Designer Version 4.8.0.v201806261756 in /templates/blank_report.gif ltr 120 C:\temp\birt\Test\CSO_ART_PRI_TST_GER.xml NAME dimension NAME PRICE dimension PRICE 1 NAME string 2 PRICE float Data Source 1 NAME NAME string 12 2 PRICE PRICE float 8 2.0 NAME 1 12 -1 -1 Unknown NAME PRICE 2 12 -1 -1 Unknown PRICE ]]> MAX_ROW -1 XML_FILE a4 portrait 2cm 2cm 2cm 2cm 1cm 1cm sans-serif 12pt CUT-OFF DECIMALS SAMPLE html new Date()]]> "Arial"40ptvisiblePRODUCTS NAME NAME dataSetRow["NAME"] string PRICE PRICE dataSetRow["PRICE"] float true left right 2.2cm bold auto Name auto Preisangabe Material auto NAME normal auto Fixed #,##0.00{RoundingMode=HALF_UP} normal PRICE

[hvbtup]

Please attach the rptdesign in a *.zip file.

[hvbtup]

@reiner-killet Did you also test with BIRT 4.9?

[reiner-killet]

Yes. 4.9 release and 4.8 show same behaviour.

[hvbtup]

Regarding your second question:
If a property is inheritable or not is defined in the ROM specification(file rom.def in the sources).
The "overflow" property is defined to not be inherited and this never has changed AFAIK:

<Property canInherit="false" detailType="overflow" displayNameID="Element.Style.overflow" isStyleProperty="true" name="overflow" since="2.5.2" type="choice">
    <Default>hidden</Default>
</Property>

[reiner-killet]

OK, agree. But in this case the designer should not show "Inherited".

[hvbtup]

It is inherited from the default style even though it cannot be inherited from parent layout elements.

[hvbtup]

I digged a bit into the sources.
The handling of overflow: hidden was introduced with 8c4f519 in 2017 with the comment:

Overflow hidden property does not exist on table cell in DOCX

This enhancement is to crop the words that exceed the width of the cell.
If the property is not set, it will wrap around cell and expand the
height of the row and table changing the overall layout

I think that the commit makes sense (though our word reports may be effected just like like yours and we'll probably have to test and change them).

But I can't reproduce the unintended cropping. For example, I took the sample report from #875.
PDF output:

DOCX output:

No cropping - though the overflow property for the data item PRODUCTNAME says

Looking at the source code of AbstractWordXmlWriter.java I would expect the cropping you describe - but I can't reproduce.

[reiner-killet]

the behaviour desribed in [https://github.com//issues/875] is not what we see in 4.8 and 4.9. There is no line break. It deletes 2 digits and the decimal sign:

In my sample template the data type is "Float", tag number format is "Fixed" with grouping characters and 2 decimal places. The cell ist right-aligned.

[hvbtup]

I don't say this is related to #875. I only used the existing report from #875 to test this.

[hvbtup]

BTW you shouldn't use float (in the DB or in BIRT or anywhere) to store prices. It is complicated enough with decimal data and 19% MWSt in Germany 😃, so you don't want additional conversion errors.

[reiner-killet]

Enclosed please find template & XML data. Von: Henning von Bargen ***@***.***> Gesendet: Dienstag, 5. April 2022 15:21 An: eclipse/birt ***@***.***> Cc: Reiner Killet ***@***.***>; Mention ***@***.***> Betreff: Re: [eclipse/birt] property overflow = Hidden leads to cut-off decimals with DOCX output (Discussion #916) Please attach the rptdesign in a *.zip file. — Reply to this email directly, view it on GitHub<#916 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWYBUAUJJD25SNXFSME6DCDVDQ45BANCNFSM5SSCUVQA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[hvbtup]

You can drag a ZIP file directly to the editor control here...

[reiner-killet]

Test.zip

[hvbtup]

I think the problem here is that "380.000.000,00" (meaning 380 millions in German) is considered as one word. And the representation of this word in Arial 10pt is wider than the column width specified. In my test report from #875 the long text consists of several words where each one fits into the column. That explains why it cannot be reproduced with that report.

The behavior is similar to the PDF emitter if the pdfRenderOption.wordBreak option is not set (as can be seen with Run Report As ... PDF).

By setting aforementioned option, the PDF emitter can be configured to break a word if it is too long even if it does not contain spaces.

Maybe the DOCX emitter could use a similar option which would avoid calling the cropping in AbstractWordWriterXml.java if it's set, thus restoring the behavior before the commit 8c4f519). Search for "crop" in the Java source file to see what I mean.

@reiner-killet Can you create a PR for this?

[reiner-killet]

The XML data source does not contain 380.000.000,00
It contains 380000000.17
In my first screenshot you can see that it evem crops numbers although there is a lot of space in the cell.
Let us assume that property "Overflow" was added by 4.8 when opeing a template that was created in an older version.
Unfortunately, the default was "Hidden" and not "Visible".
That's the reason for our misery, correct?
In this case we should simply replace all
<property name="overflow">auto</property> (new remplates)
<property name="overflow">hidden</property> (old templates)
by
<property name="overflow">visible</property>
in the entire rptDesign, maybe using Notepad++.
I guess this will cause an appropriate DOCX output, correct?

[hvbtup]

I think that your assumption about what's going on is wrong. The property has "always" been there, but the Word emitter just ignored it until the commit 8c4f519 in 2017.

As I said, the problem seems to occur only if single words (or numbers) are too long to fit into a single line (not considering the edge case display="inline").

It should suffice to modify only those items (label, data, text, dynamic text) of your reports where this might be a problem.
The tricky part is how to identify those, depending of the amount of your reports.

Unfortunately, I believe that your assumption about what to do in order to avoid the problem is wrong, too.
I bet you won't find the overflow property set explicitly everywhere. So you can't use this as a search condition.
Instead you would have to find items where the overflow is not specified, too.

But you can easily test this yourself, of course.

If I'm right, then Notepad++ won't work. You'd have to write a little program that "understands XML".

But as I said, only really long words or numbers seem to cause the problem. If we assume that cropping a very long word is just an annoyance to the reader but not "bad enough" to render the whole report useless, then you can concentrate on those columns where you output numbers. In that case it may be reasonable to check and edit the reports manually in the designer.

[hvbtup]

In #1013 I proposed a way of setting overflow to visible without changing each and every label and (dynamic) text item. It works by using styles.