However in this case the Version is 11.9.0.0 .net 2.0.
Generating the Document without MailMergeCleanupOptions.RemoveEmptyParagraphs works perfectly fine. the structure of the template used to display the data is the following:
<>
<>
<<b.somefield>>
<<b.someotherfield>>
a
b
c
d
e
f
g
h
<</inner table b>><</table a>>
i need to get rid of the spaces caused by the closing tags.
A swift reply to resolve this issue would be highly appreciated.
Thank you for your request. With high probability your issue has been fixed recently (WORDSNET-7129) and the fix will be available in the new release (11.10) coming very soon. However, in order to make sure, could you please provide your sample template and code snippet used for merge?
I have added the sample files now. It’s not the actual files because it is part of a project we are working on but it resembles the original structure to some extent.
What is the estimated release date on 11.10 if i may ask?
No problem by the way. We do however plan to finish our project by the end of this year. Hopefully 11.10 fixes this issue.
Thanks for your inquiry. While using the latest version of Aspose.Words i.e. 11.9.0, I managed to reproduce this exception on my side. I have logged this issue in our bug tracking system. The issue ID is WORDSNET-7373. Your request has also been linked to this issue and you will be notified as soon as it is resolved. Sorry for the inconvenience.
It is to inform you that your issue has been implemented in the current code base and the fix of WORDSNET-7373 will be included in the next release of Aspose.Words (11.10.0) that is due out at the end of this month. We will inform you as soon as the new release is published.
«TableStart:“Windload xsi:type”» (used to be the same without brackets)
While using the latest version of Aspose.Words i.e. 11.10.0, I managed to reproduce this issue on my side. I have logged this issue in our bug tracking system. The issue ID is WORDSNET-7415. Your request has been linked to this issue and you will be notified as soon as it is resolved. Sorry for the inconvenience.
I would like to apologize for inconvenience too. We are currently analyzing your issue and will update you with the latest progress ASAP. What we have found so far (yet this unlikely has to do with your current issues) is that the simple fields in your template are only enclosed in single brackets (like {field}) while expected to be enclosed in double brackets (like {{field}}). But this is just a remark.
I just checked out the sample file i provided. Turns out my provided sample actually contains errors for the described fields. The behaviour i am describing though was on our Application where the fields are written with double brackets. But good catch there.
I will ask my boss if it’s ok to provide actual production data for you to validate the behaviour. But i can’t make any promises on that yet.
That would be great of course, since we can then make sure that the issue is completely fixed for you this time. You can replace all sensitive data with random text if needed. Currently we are working with your sample template you provided earlier. And the responsible developer has just completed the analysis; we have found the cause of the issue and will proceed to development shortly.
Regarding your problems you’re getting with MailMergeCleanupOptions.RemoveEmptyParagraph option, could you please double check if these are occurring when using your ‘template.docx’? I have also attached output document here for your reference. Could you please create a screenshot that highlights which Paragraphs you would like to remove from your final report? Thanks for your cooperation.
I uploaded another sample with the sections which fail to render as expected after updating to 11.10.0.0
This is only a snippet of the actual production document but i am certain my boss won’t mind me sharing this part.
The reason we iterate through the template using
{{#foreach Windload xsi:type}} is that the full xml contains another property called Windload on the same tree level.
I spent some time trying to figure out what could be the reason as to why this would fail.
- not surrounding with “Silo” foreach first (still works in other areas right now). could it be an “accidental” feature which we abused? and in the latest version it might have been been fixed partially because it wasn’t intended?
- output generates MERGEFIELD “TableStart:Windload xsi:type”. maybe the replace engine expects a pattern like MERGEFIELD TableStart:“Windload xsi:type” ?
Anyways. I hope the provided sample is usefull in finding the problem in some way. I guess to fix the empty paragraph issue the other template will suffice.
I have now checked out the template and the output again and took the screenshots you asked for.
I noticed one behaviour in particular (which i haven’t noticed before because i always checked in a certain area of the output document). For the majority of the document the cleanup option actually seems to work but apparently stops working properly once the given table exceeds a page.
in template.png you will see the table starts top right (page 2) and ends on bottom left (page 3)
The paragraphs are marked (with horribly bad drawn) arrows.
On output.png you can see that removing the first paragraph actually did work, while the paragraph at the end of the table did not get removed
I hope that helps zipping up this issue. I really have to thank both of you for this remarkable support.
Thanks for the additional information. I have tested the scenario and have managed to reproduce the same problem on my side. For the sake of correction, I have logged this problem as WORDSNET-7421 in our issue tracking system. We will further look into the details of this problem and will keep you updated on the status of correction. We apologize for your inconvenience.
I was wondering how long you’d reckon fixing this issue would take and at which point an updated .dll is available. As i’ve mentioned we’re aiming at finishing our project by the end of this year. If you don’t think it’s possible by then it would just be nice to know so i can prepare for that. No pressure intended.