Two DOCX emitter page header issues

[hvbtup]

I noticed some issues when I compared the DOCX output of my old customized DOCX emitter with the output of the DOCX emitter from master:

If showHeaderOnFirst is not set to true for the master page, then the DOCX emitter does not show the page header at all.

If I set this property to true for testing purpose, then the page header is created, but a second issue occurs:

In my test report, the content of the page header is a single dynamic text item with a border-bottom line (not a grid or whatever).
But the DOCX emitter does not create this line.

My customized emitter supported showHeaderOnFirst, see triestram-partner@403e3af

Fixing this is not a top priority ATM. Maybe I can try to carefully create a PR from this once I find the time.

[hvbtup]

I don't have any idea what I could do regarding the missing line issue, however...

[speckyspooky]

The changed behavior was added from my DOCX changes with BIRT 4.18 and the try to remove the additional formatter-grids.

This cause the effects and there are 2 effects:
1.) The bottom-line is unprinted because the layout-grid was avoid because it exists not really such style-element for docx
2.) The header-footer-height is unset because an empty grid was used to produce the correct height. This is not the right way but the solution to avoid the grid is only the first step. The docx-property of header-height/footer height must be set (currently not implemented)

Solution to get the old behavior since 4.18 & 4.19 (current version/nightly build):

• set 2 properties on report level on the "advanced property register"

With your ticket it would be better to switch the configuration from disabled (grid-usage=false) to enabled (grud-usage=true).
Please let me know.

[hvbtup]

For the missing line, I did not follow your suggestion, but your suggestion gave me the idea to use a 1x1 grid, put the dynamic text item into that cell and set the border bottom property at the cell level.

I think this is a reasonable workaround: My test report is special int that it uses just a dynamic text item in the page header.
In production, the reports usually contain a grid in the page header and footer anyway.

Following your suggestion is not an option for me, if this can be only set at report level, because as you said yourself, the whole point of most of the optimizations it to avoid unneccessary nested 1x1 tables. I tried setting the UserProperty WordEmitter.WrappedTableForMarginPadding directly for the dynamic text item and the other setting at report level, but that did not work.

So I consider this second issue solved in a way good enought from my POV.

So only the issue regarding showHeaderOnFirst remains, for which a solution approach is shown in the old commit I mentioned.

[speckyspooky]

I have added a short optimization for the header calculation to have better section range.

The option WordEmitter.WrappedTableForMarginPadding is an option at report-level. You can find it under "Advanced -> Emitter Word configuration". This is a global configuration for al elements.

I tested the showHeaderOnFirst and I see the correct handling. The header will be avoid only at page 1, here ist my small test case, not beautiful but it shows the DOCX-output with showHeaderOnFirst = false. May be you have additional conditions to get your effect.

[hvbtup]

The option WordEmitter.WrappedTableForMarginPadding is an option at report-level. You can find it under "Advanced -> Emitter Word configuration". This is a global configuration for al elements.

That's why I did not even consider to use it.

[hvbtup]

I tested the showHeaderOnFirst and I see the correct handling.

Strange...
I changed table.rptdesign slightly (set the content type of the HTMLDESCRIPTION dynamic text item to plain text instead of HTML and this is what the DOCX emitter gives me:

Note that the page header is missing on the second page.

Show Header on First is unchecked (see image below) and this prevents the header to be printed on any page.

[hvbtup]

This line in AbstractEmitterImpl looks suspicious: Note the negation:

[hvbtup]

IIRC from what I changed years ago in my commit, I noticed that the argument/variable naming and their meaning did not really match, and that we also need to take showHeaderOnFirst into account when generating the page footer.
Besides, I noticed that the getHeaderID() and getFooterID method names were misleading, because they change state and thus should not better be named next... instead of get...

$ git status
HEAD detached at speckyspooky/optimize_header_footer_margin_wo_grid_2026
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   build/org.eclipse.birt.target/BIRT all-in-one.launch

no changes added to commit (use "git add" and/or "git commit -a")

The *.launch file is changed just because I had to manually set the JavaSE to 21 instead of 11.

[speckyspooky]

I have done some further investigation. If a separated Run- and afterwards Render-task ist started then all is fine and the flag worls correctly.
I tested it and with the direct creation of docx from the designer your effect is given (= RunAndRender-task).
But the problem appears only if the report includes dynamic elements like a table. The major problem is there that the required pages are not clear on "RunAndRender"-task. I can see it perfectly with my test-report.

The problem is solved with the separated task runs.
With the designer, if I create the HTML-preview and afterwards docx the result is perfect.

Can you confirm this behavior from your side?

[hvbtup]

Yes, I can confirm this behavior: Web Viewer, then export as DOCX: OK, directly generate DOCX: NOT OK.

[speckyspooky]

What is your most used way?
The question behind is do we try to fix the direct run or it is acceptable like it is.

[hvbtup]

We use RunAndRenderTask > 99%, seperate RunTask and RenderTask only in very rare cases.