Non-M2Doc fields are replaced by (typically wrong) fixed values during generation

[nheuermann]

Note: I've added my findings already to #377, but they may not have been recognized on that already closed issue.

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please have a look to the support pages of our website : http://m2doc.org/support/

Current behavior

In my template, the field for the filename ({ FILENAME * MERGEFORMAT }) in the footer is replaced during generation by the actual value - by the template filename, not the filename of the generated document.

Expected behavior

Expectation is that the field stays intact without being replaced by a value by M2Doc (it's not starting with "m:", so M2Doc shouldn't alter it).

Minimal reproduction of the problem with instructions

Use the attached template file to generate the file (generated file also attached).
I played a bit around (we are using M2Doc 3.2.0 programmatically, but normal UI does show the same behaviour, below files are from that one) and saw that it very much depends on the template file itself:

• Same fields are handled differently (replaced/not replaced) when copied into a fresh Word document (I've started with a fresh Word 356 document, just adding headers/footers, so it's not an "aged" template file with much stuff deleted).
• The below is the "intermediate" case - my original file had both filename field as well as total number of pages {NUMPAGES * Arabic * MERGEFORMAT} replaced. Copied once into a new file resolved everything. Copied into another ended up with this case. EDIT: the "resolved everything" file now shows the same issues, both fields incorrectly replaced. No idea why
• The filename field is only replaced on the second page, not on the first page (header/footer is different for first page compared to other pages)

Files:
M2Doc_PHA_Landscape.docx
M2Doc_PHA_Landscape.generated.docx

What is the motivation / use case for changing the behavior?

Apart from this example, we also see cases of replaced figure numbers etc. - a big problem, as these figure numbers are then all wrong and would have to be replaced manually by fields again after generation.

Environment

M2Doc version: 3.2.0
Eclipse version: programmatically used on medini 2022R1
Platform version:  Windows 11

[ylussaud]

There are some known issues with fields after generation. Did you try to set the UpdateFields option to true in your .genconf file ? It can be done by using the option tab of the template properties wizard.

Let me know if it helps.

[nheuermann]

I forgot to mention it here again, but as stated in my comment to #377: No, the UpdateFields option does not help.

If I interpret the code in 2027b6e correctly, then the touched fields are marked as "dirty" to notify Word (or Apache POI? To make sure they are interpreted?). But in this case the fields are replaced by static text during generation, they are no fields anymore, so this is something different, isn't it?

[nheuermann]

@ylussaud From experience with further reporting work (longer reports) it seems that only the caption fields of the last for loop survive (i.e. stay as Word fields), the caption fields in the previous loops are all replaced by fixed values.
Maybe that helps in understanding where this may come from. Let me know if I should do any further testing.

[ylussaud]

That will help thank you.

[nheuermann]

Hi @ylussaud,
As this may become a more relevant issue for our users, we are intending to fix this (hopefully) ourselves and contribute the solution. Do you have a tip for us where to start looking in the code for this, any helpful aspects?
Thanks, Nils

[ylussaud]

You can have a look at the following:

• for loop evaluation.
• The code that mark fields as dirty so they should be updated when opening the document. This shows how to get and change fields.
• relation duplicating, I'm not sure if its related but that could explain why only one field survives.

One way to investigate:

• create a small document that would be the expected result with several fields
• create a small template that should produce the first document
• unzip both document
• formal all XML files including refs
• compare both folders

You will get unrelated changes. You can remove them form the expected folder (first document) and zip the folder to check is you still have your fields. At some point you should be left with the important changes and then need to modify M2Doc to produce them.

Also M2Doc rely on the Apache POI API but it can be also useful to get the OOXML API directly some time. For instance with:

XWPFRun.getCTR()

Then the API follows the XML document structure. But first try to use an API at POI level to minimize headaches ;)

If you have any progress let me know. And of course if you have a patch please open a pull request. I will be glade to review it.

[ylussaud]

I tested with the master branch of M2Doc and I'm not reproducing this issue. But I don't see a for loop in the template you attached so maybe your template doesn't show the issue or this issue has been fixed.
I tried to create a simple for loop with the filename field in the body of the document and it produce fields in the generated document.

Let me know if this issue is still relevant and if you have an idea to reproduce it.