Word emitter generates extra paragraph markers in footer and header

[MSDelorme]

Word emitter generates extra paragraph markers in footer and header. Although hidden,it is not necessary.
To put elements in an header you need to add a grid first. When generated in word you can see a hidden paragraph marker in the footer/header before the grid. There are more places that extra paragraph marker are generated but I will make separate issues for that (I mention it here because it could be the sames issue)

[wimjongman]

Thanks for reporting. Can you supply patches?

[MSDelorme]

I'm not in the position to make patches .

[hvbtup]

The extra paragraphs (and extra tables!!) in MS Word output are caused by the fact that BIRT supports things like border, margin, padding at every possible place. These are supported technically by using nested tables (in the Word output) for almost everything.
In the tup_main branch of my fork I am trying to reduce these nested tables. This makes the generated output files more suitable for human post-editing. OTOH this results in reduced control of the layout.
While I am happy with the output my patched version generates (with the help of some user properties), there are other differences to the official BIRT release (in particular regarding Excel output), so you cannot just try the fork and assume that everything works as expected.

From the experience with my fork, I think it might be useful to review and discuss some of the changes I made, and maybe merge them into the master branch after making the behavior change optional (e.g. it would be necessary to explicitly opt-in to the changes by setting a render option or whatever.

However, I don't have enough time to do this myself.
It may be useful if you @MSDelorme and others who are interested would try out the tup_main branch and tell me what you think about the output, as a first steep to see if anyone likes the approach at all.

[MSDelorme]

I was planning to make an other issue that there should be more types that are not generated as a table ( I think so far only a label is not table). For example a list (and also a grid) also has a use case (especially when making word documents) that you just want to use the expression part of the list, but not the table part. A property not generate as table or something , could that be part of the solution?

[hvbtup]

For list items, in my tup_main branch, you can set a UserPropety WordEmitter.LAYOUT_MODE to the string value NONE (not sure about the exact phrasing of the option name). This will cause the List Item to basically work like a for-loop in a programming language: It doesn't provide anything to the output in itself. It just enables you to generate several instances of the content of its detail area. Thus this user options prevents the creation of a word table for a BIRT list item.

For texts inside cells, there is a similar optimization preventing nested Word tables (but at the cost of some layout support).

[wimjongman]

I'm not in the position to make patches .

Ok, then don't get your hopes up to get this resolved. We are not in a position to fix hidden cosmetic things. Transferring this to a discussion

[MSDelorme]

I think a great solution would be that some items can be generated without creating a table . (like a label). That would solve most things as mentioned by hvbtup. In word there is still the option not to show those hidden paragraph markers, but when less things are a table you would have less those anyway.

[hvbtup]

Just for reference: The tup_main branch I mentioned is here: https://github.com/triestram-partner/birt.
You can download the all-in-one designer and birt-runtime (both for Windows only) from the releases link there.
For more info related to this discussion see https://github.com/triestram-partner/birt/wiki/NotableDifferences.

See https://github.com/triestram-partner/birt/blob/tup_main/engine/org.eclipse.birt.report.engine.emitter.wpml/src/org/eclipse/birt/report/engine/emitter/wpml/AbstractEmitterImpl.java for the names of the user properties.

Define a string user property WordEmitter.LayoutMode with a value of "NONE" for a list item to make it a "for-loop".

[speckyspooky]

@MSDelorme Could you provide a small example like report so that somebody who is interested can take a look into it, because it is not easy to understand the topic of your note. So I'm not realy understand your topic. Because in the most cases I'm focused on output of HTML, PDF or XLSX.

[MSDelorme]

I think I could rewrite the issue in. Word emitter generates unnecessary hidden paragraph markers after tables and sometimes in tables.

All paragraph markers in this images are hidden.
The layout of your document than depends on if you have hidden text enabled in word or not.

Second discussion in this thread is that it would be very useful to have a property to control of an birt item is generated as table or not in word output.

[speckyspooky]

I can see your problem and it would be greate to have a reference to your mentioned cases
so that is possible to a master example like a kind of reference to talk about the same structure elements
(and to avoid to asume what you have used).

[speckyspooky]

@MSDelorme
The new handling to avoid layout-grid of header and footer of WordEmitter docx will be available with BIRT 4.18 (#1957).
The handling can be controlled via user property to switch off/on the layout grid (default: off, without layout grid).