<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - WRITER: Shows multiple footers and no page breaks for this file, unlike MS Word" href="https://bugs.documentfoundation.org/show_bug.cgi?id=122823#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - WRITER: Shows multiple footers and no page breaks for this file, unlike MS Word" href="https://bugs.documentfoundation.org/show_bug.cgi?id=122823">bug 122823</a> from <a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> Mike Kaganski</a> <pre>(In reply to M. A. Sridhar from <a href="show_bug.cgi?id=122823#c5">comment #5</a>) > I was the one that reported this bug. I generated this document using some > code that we use for document generation using template expansion. I am not > fully aware of the rules around correct placement of sectPr nodes, and I got > to this point by trial-and-error experiments and reverse-engineering with > Word template expansions. In general, my understanding is that there should > be one sectPr node before each page break (w:br type=page) node. Irony. OOXML was the most advertised open specification created by MS, yet the fact that specification exist stays unknown :-) The normative reference is ISO/IEC 29500-1:2016, and it is freely available form ISO site [1]. > I took the > stance of "if it works with Word, it should work with Libre Writer". Sigh. This is what makes us not only struggle with all the standard complexity (which is unavoidable and understandable), but also struggle to implement all Word's *bugs/ that people discover using "trial-and-error experiments and reverse-engineering", and then start producing documents exploiting those bugs... so of course, we also must have those bugs to be "compliant". The other ironic fact is that it's enough to re-save such document from Word, to see the proper syntax. > Please > point me to any documentation I can get that clearly articulates the rules > for correct placement of sectPr nodes, and I will see if I can abide by the > rules. Citing from <a class="bz_bug_link bz_status_VERIFIED bz_closed" title="VERIFIED FIXED - DOCX IMPORT: Extra pages and wrong page sizes in a specific document" href="show_bug.cgi?id=108849">tdf#108849</a> (which was mentioned here twice already, which makes me wonder if it's that difficult to click a link to see what's the origin of the problem!): > According to ISO/IEC 29500-1:2016(E) 17.6.17 sectPr (Document Final > Section Properties), the final <w:sectPr> must be the last child element > of the body element. Also, this is enforced in schema for CT_Body complex > type (Annex A. (normative) Schemas – W3C XML Schema, A.1 WordprocessingML, > page 3866), where sectPr is a part of <xsd:sequence>, and thus *must* stay > at specific place in sequence, namely being the last element, and be at > most one instance. > But more generally, my biggest concern is that any generated files should > be openable by Word, and I have seen cases where, if I don't insert the > sectPr node the way I have done, Word will not open the document. And having > the ability to use LibreOffice Writer to convert to PDF is crucial to us, so > for now, we have fallen back to using version 5 until this issue is resolved. > > If I can provide any more information or help in any way, please let me know. Hope that above helps in clarifying this. [1] <a href="https://www.iso.org/standard/71691.html">https://www.iso.org/standard/71691.html</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>