Created attachment 165942 [details] cannot open this file Hi, I cannot open the attached file. However, content.xml and styles.xml do not present an error. File preview works. MS WORD can open it. Thank you in advance for your return.
I recieve the error "Read Error. Format error discovered in the file in sub-document styles.xml at 2,34323(row,col)." If I open document in Word 2016 and save it with a new name. LO is able to open the document. Don't know, if this should be considered as a bug or not. Perhaps a more experienced person can help.
(In reply to Dieter from comment #1) > I recieve the error "Read Error. > Format error discovered in the file in sub-document styles.xml at > 2,34323(row,col)." > > If I open document in Word 2016 and save it with a new name. LO is able to > open the document. > > Don't know, if this should be considered as a bug or not. Perhaps a more > experienced person can help. Thank you. Usually with this kind of error the content.xml or styles.xml file is malformed. But this is not the case !
Vincent, in which software did you create that file?
(In reply to Roman Kuznetsov from comment #3) > Vincent, in which software did you create that file? The file contains merge marks. The code is inserted and the whole is zipped. I've never had a problem with previous versions of ODF (1.2). To be sure, I just tried again with the old file, and after merging, the document opens with no problem.
I didn't understand previous reply, question was in which software it was created. I change title to "ODT with externally inserted code". OO couldn't also open it. I don't see what's wrong in styles.xml at 2,34323(row,col).
(In reply to Timur from comment #5) > I didn't understand previous reply, question was in which software it was > created. I change title to "ODT with externally inserted code". > First document has been created with LO and some text has been added programmatically (C ++) > OO couldn't also open it. > I don't see what's wrong in styles.xml at 2,34323(row,col). Me too. It's my (new) problem. Thanks to all for your interest
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed these logs on console: warn:xmloff.core:26807:26807:xmloff/source/core/xmlimp.cxx:1490: duplicate style name of family 300: "Corps_20_de_20_texte" warn:sax:26807:26807:sax/source/fastparser/fastparser.cxx:613: Unexpected exception from XML parser com.sun.star.io.IOException message: Element does not exist and cannot be created: "10000000000000C600000070752B75350F37D0D7.png" /home/julien/lo/libreoffice/package/source/xstor/xstorage.cxx:2002 warn:sax:26807:26807:sax/source/fastparser/fastparser.cxx:613: Unexpected exception from XML parser com.sun.star.io.IOException message: Element does not exist and cannot be created: "10000000000000530000002DFDA6061671E0309D.png" /home/julien/lo/libreoffice/package/source/xstor/xstorage.cxx:2002 warn:sax:26807:26807:sax/source/fastparser/fastparser.cxx:613: Unexpected exception from XML parser com.sun.star.io.IOException message: Element does not exist and cannot be created: "10000000000000C600000070752B75350F37D0D7.png" /home/julien/lo/libreoffice/package/source/xstor/xstorage.cxx:2002 warn:sax:26807:26807:sax/source/fastparser/fastparser.cxx:613: Unexpected exception from XML parser com.sun.star.io.IOException message: Element does not exist and cannot be created: "10000000000000530000002DFDA6061671E0309D.png" /home/julien/lo/libreoffice/package/source/xstor/xstorage.cxx:2002 warn:sw:26807:26807:sw/source/filter/xml/swxml.cxx:206: SAX parse exception caught while importing: com.sun.star.xml.sax.SAXParseException message: [ line 2]: unknown error /home/julien/lo/libreoffice/sax/source/fastparser/fastparser.cxx:578 wrapped: com.sun.star.io.IOException message: Element does not exist and cannot be created: "10000000000000C600000070752B75350F37D0D7.png" /home/julien/lo/libreoffice/package/source/xstor/xstorage.cxx:2002 PublicId: SystemId: LineNumber: 2 ColumnNumber: 34323 warn:sw:26807:26807:sw/source/filter/xml/xmlimp.cxx:409: endDocument skipped, dropping shapes now to avoid dangling SvTextShapeImportHelper pointing to this
Unzipping the file, I got: ./Pictures/10000000000000530000002D4ED4C0B66E0292FB.png ./Pictures/10000000000000C60000007088EF268545261CB1.png Manifest file (META-INF/manifest.xml) references them: <manifest:file-entry manifest:full-path="Pictures/10000000000000C60000007088EF268545261CB1.png" manifest:media-type="image/png"/> <manifest:file-entry manifest:full-path="Pictures/10000000000000530000002D4ED4C0B66E0292FB.png" manifest:media-type="image/png"/> but: content.xml contains: <draw:image xlink:href="Pictures/10000000000000C600000070752B75350F37D0D7.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" draw:mime-type="image/png" /> <draw:image xlink:href="Pictures/10000000000000530000002DFDA6061671E0309D.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" draw:mime-type="image/png" /> similar pb for styles.xml Does the file open well before the C++ part? If yes, the problem is on your C++ part if not, could you attach this initial file?
Created attachment 166095 [details] Original file before merging
Thanks Julien, I attach the original file, before the data merge
On pc Debian x86-64 with master sources updated today, no problem to open the file before merging. I just noticed these logs on console: warn:xmloff.core:69786:69786:xmloff/source/core/xmlimp.cxx:1490: duplicate style name of family 300: "Corps_20_de_20_texte" warn:sw.core:69786:69786:sw/source/core/unocore/unoframe.cxx:2757: SwXFrame: fixing invalid horizontal RelOrientation for at-page anchor warn:sw.core:69786:69786:sw/source/core/unocore/unoframe.cxx:2757: SwXFrame: fixing invalid horizontal RelOrientation for at-page anchor warn:sw.core:69786:69786:sw/source/core/unocore/unoframe.cxx:2757: SwXFrame: fixing invalid horizontal RelOrientation for at-page anchor warn:sw.core:69786:69786:sw/source/core/unocore/unoframe.cxx:2757: SwXFrame: fixing invalid horizontal RelOrientation for at-page anchor warn:sw.core:69786:69786:sw/source/core/unocore/unoframe.cxx:2757: SwXFrame: fixing invalid horizontal RelOrientation for at-page anchor warn:sw.core:69786:69786:sw/source/core/unocore/unoframe.cxx:2757: SwXFrame: fixing invalid horizontal RelOrientation for at-page anchor warn:sw.core:69786:69786:sw/source/core/unocore/unoframe.cxx:2757: SwXFrame: fixing invalid horizontal RelOrientation for at-page anchor warn:sw.core:69786:69786:sw/source/core/unocore/unodraw.cxx:1243: SwXShape: fixing invalid horizontal RelOrientation for at-page anchor warn:legacy.osl:69786:69786:sw/source/core/doc/doclay.cxx:1600: Found a FlySection but not a Format! warn:legacy.osl:69786:69786:sw/source/core/doc/doclay.cxx:1600: Found a FlySection but not a Format! warn:legacy.osl:69786:69786:sw/source/core/doc/doclay.cxx:1600: Found a FlySection but not a Format! warn:legacy.osl:69786:69786:sw/source/core/doc/doclay.cxx:1600: Found a FlySection but not a Format! warn:sw.core:69786:69786:sw/source/core/view/vdraw.cxx:243: Trying to move anchor from invalid page - fix layouting! warn:sw.core:69786:69786:sw/source/core/view/vdraw.cxx:243: Trying to move anchor from invalid page - fix layouting!
Created attachment 166123 [details] Old version (OK)
Created attachment 166124 [details] actuel version (KO)
To summarize the situation, I have attached the old version LO file and the current version LO file. My adding text works fine with the old version and not with the current one (file won't open). Thanks in advance
Both versions open on LO. I tried ODF Validator 1.3 https://odfvalidator.org/, here are the results: old one: he document is NOT conformant ODF 'Missing ODF version'! Details: declar_old.odt: Fatal: Unexpected record signature: 0X0 new one: 7 errors in styles.xml 21 in content.xml each time in loext (so extension of 1.3) loext:graphic-properties" is not allowed. Possible tag names are: <map>,<paragraph-properties>,<text-properties> unexpected attribute "loext:allow-overlap" unexpected attribute "loext:opacity" You may try to use ODF 1.3 strict to generate the file before the merge to see if it's better but it seems you may need to tune your merge process to adapt to the format of the original file which has indeed changed.
The file "actuel version (KO)" opens fine with LO 7.0 and LO 7.1. And the file is valid "ODF 1.3 extended". The file "cannot open this file" has file format errors. Check it in https://odfvalidator.org/. You need to manually select the ODF Version, "auto-detect" does not work. You need item "OASIS ODF 1.3 (extended conforming)".
Regina, thanks, should this be closed as NOB?
(In reply to Timur from comment #17) > Regina, thanks, should this be closed as NOB? Yes. @Vincent H: If such problem occurs with a valid file, you can reopen the bug (and attach that file). In case you are not sure about the standard itself, you can discuss it on mailing list "opendocument-users", see https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#feedback
(In reply to Regina Henschel from comment #18) > (In reply to Timur from comment #17) > > Regina, thanks, should this be closed as NOB? > > Yes. > > @Vincent H: If such problem occurs with a valid file, you can reopen the bug > (and attach that file). > In case you are not sure about the standard itself, you can discuss it on > mailing list "opendocument-users", see > https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#feedback With the new 7.0.2.2 (x64) version, the problem is solved ! THANK YOU ALL