Re: Value of OFFICE_DOCUMENT in DFXMLNames.h

[Peter Kelly]

I think this file is corrupt… but in a *very* weird way. I unzipped it (using the ‘unzip’ command-line tool), and it seems to be a perfectly valid zip file, however when I look at the XML files they are all binary data. I’ve attached the content.xml I extracted, it’s not in any recognisable format. What program (I’m guessing OO?) and version did you generate this with? Ok - I just checked the META-INF/manifest.xml. Encryption is enabled for the file. OpenOffice opens it without asking for a password for some really odd reason. I tried it in NeoOffice and it asked me for a password, as did LibreOffice. I don’t understand why OO is opening it fine, it seem it would need a password. Even if you have encryption turned on for all new documents in your settings, I shouldn’t be able to open it. Extremely strange!

content.xml
Description: XML document

-- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) On 24 Apr 2015, at 11:48 pm, Gabriela Gibson <gabriela.gib...@gmail.com> wrote: Oops I just realised I forgot to attach the AOO generated file I used. Here is it is. G On Fri, Apr 24, 2015 at 5:36 PM, Gabriela Gibson <gabriela.gib...@gmail.com> wrote: On Fri, Apr 24, 2015 at 4:42 PM, Peter Kelly <pmke...@apache.org> wrote: > On 24 Apr 2015, at 6:27 pm, Gabriela Gibson <gabriela.gib...@gmail.com> wrote: > > In ODFConverterGet in file ODFConverter.c line 700 I check the value of the > first child node: > > DFNode *odfDocument = DFChildWithTag(package->contentDoc->docNode, > OFFICE_DOCUMENT); > > I'm assuming the correct value to be 'OFFICE_DOCUMENT' here, at least the > name suggests that this should be correct. > > However, the value of this is 1468, where as the child node is 1469, which > in the DFXMLNames.h is listed as 'OFFICE_DISPLAY’. This shouldn’t be happening - can you check the document.xml file in the package (perhaps post an excerpt here) and verify that the root node is <office:document>? If you have manually modified DFXMLNames.h or DFXMLNames.c then this would confuse things, and quite possibly cause such a problem to occur. These files were automatically generated from scripts in the ‘schemas’ directory, and aren’t supposed to be manually modified. Nope, I'm innocent (this time). However, I did a diff of my current and an older version, just to be sure. diff /home/g/cor-explore/incubator-corinthia/DocFormats/core/src/xml/DFXML.c /home/g/cor2/incubator-corinthia/DocFormats/core/src/xml/DFXML.c 76c76 <     DFSAXParser *parser = (DFSAXParser *)xcalloc(1,sizeof(DFSAXParser)); --- >     DFSAXParser *parser = (DFSAXParser *)calloc(1,sizeof(DFSAXParser)); 142c142 <         unsigned long attrValueLen = (unsigned long)(attrValueEnd - attrValueStart); --- >         unsigned long attrValueLen = attrValueEnd - attrValueStart; 363c363 <     char *used = (char *)xcalloc(1,count); --- >     char *used = (char *)calloc(1,count); 614c614 <     char *result = xstrdup(buf->data); --- >     char *result = strdup(buf->data); As you can see, strdup was changed and also the (unsigned long) cast has been removed. But that should not really be a problem.   I’ve just realised that those scripts aren’t very easy to run; they rely on phantomjs which at the time I wrote them (> 2 years ago?) worked on my machine but no longer does. phantomjs isn’t very commonly used anyway; perhaps these should be modified to either work in node.js or in python. I tried changing them to node.js but it unfortunately doesn’t include a built-in XML parser, and that lead me into the hell that is the npm package distribution, where the first dom-parsing library I found only works with some fork of node.js called io.js. That’s the point where I go “ok, i’ll just use python instead” but that involves completely rewriting the scripts. We do need to get them running again in an easy-to-use way though, since when the need arises to add more pre-defined elements it will be necessary to run them. They may still run under phantomjs if you have a working installation. I am currently building phantomjs and we'll know in a few hours if that has been a success (the warning about it taking an extra long time are probably correct). I take it I can just run the /schemas/generate.sh script, or do I need to modify anything? G — Dr Peter M. Kelly pmke...@apache.org PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) -- Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ -- Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ <testDoc1.odt>