Docx additional empty "Paragraph" of element "text" and "dynamic text"

[speckyspooky]

@hvbtup
I start this discussion and write you because I know you are very deep involved into the DOCX-emitter too
and if I remember my correctly I read some notes from you with complain about empty paragraphs on table & header & footer level.

Based on the dicussion #1868 I created a simple word document for some tests. I used for that a text-element (content: HTML).
The result of the generated DOCX-structure confused me and may be you have an idea why this was done in the history of the emitter.

The topic is that both elements "text" and "dynamic text" will be automatically wrapped with a word-table to handle the margin/padding of this elements. But in every case at the end of the cell an empty paragraph will be added.

The topic for the end user is that the paragraph exists and some written text seems to be hidden but exists at the added empty paragraph - my test screens.

Test case, original line height

Test case, with changed line height

Have you any idea why this empty paragraph will be added?
It seems to be a kind of try to improve the margin/padding handling but it make not really sense for my
and in best case I would like to remove it.
The problem is there is no good documentation at code level.
If an empty cell then I need an empty paragraph but for an text element.
The same handling will be used for header and footer container before it will be close (unclear too why it is necessary).

One of the frist changes to create an empty paragraph (instead of an hidden paragraph) are coming from an old change 13 years ago,
I figured out the following change: 46fcacc

Reserach start position of the emitter

Table cell end with added empty paragraph

That the cell need the end-closing-tag is clear but why the empty paragraph...

Header/Footer container end with added empty paragraph

Methods to generate the empty paragraphs:

[hvbtup]

I'm on vacation for two weeks from now, then I'll continue work, and another vacation follows at the end of September.
So probably I won't find any time for BIRT for the next 5 weeks.

Well, I don't really understand the existing code and reasoning behind it.
I just stumbled across some issues and tried to solve them as best as I can.

Maybe you can take a look at my fork in the meantime (the tup_main branch for the code, and the wiki for an explanation).

I tried to improve word output, to make it more editable for humans and avoid lots of nested tables.
But this comes at a price: Some of the layout properties, in particular padding and margin, does not work for some items.
This I why I didn't try to merge the code back to master branch here.

One "optimization" I performed is to not wrap items in (Word) tables when they are inside a cell.
Another one is that I created a "loop-only" version of a list item by using the UserProperty WordEmitter.LAYOUT_MODE (I think).

I guess that the developers tried to create the best-looking output with the emitter, instead of the best-working output, similar to the first Excel emitters.

But from my POV people are going to use PDF for best-looking output, and when the generate Word or Excel output, it is almost always because the output should be editable (nearly) as if it was created by a human.

Some concepts of Word apparently don't work similar enough to HTML, tables being the most prominent example.
If you create a Word document manually, you cannot nest tables. But BIRT-generated documents contain lots of nested tables.
My approach is to reduce nested tables by table items only when I really need multiple columns, and use list items with the aforementioned user-property for outer loops.

But the restrictions of this approach are not really documented, unfortunately.
Maybe it would be good to introduce some emitter options that work similar to my user-properties, to specify how and when one wants to sacrifice margin/padding accuracy for editability.

Don't expect more input from me for the next weeks.

[speckyspooky]

Have a good time and nice vacation :o) !

Thanks for your answer and I will think about the next steps here.

[speckyspooky]

Some additional information to the notes above.
One special thing is Word allows to embed nested tables to a cell. So you can nest lot of tables.

But the reason of the empty paragraphs is the usage of the "margin-tabled".
I commented out the empty paragraphs but if a table is inlcuded in a cell without a paragraph afterwards
then you will get an error message if you open the generated DOCX.

So currently only 2 BIRT-options available to add a full paragraph with full line height or the invisible paragraph with line height size 1.
At the end the empty paragraphs can only be solved if the handling of the text-elements will be changed to an implementation without an additional layout table.

I will take a look into it but I think this is upcoming topic of BIRT 4.18 because the changes will be more like a two-liner.