Hi this one opens nicely with microsoft word, something about Paragraph 1 and 2.
have a nice evening. rgds jan i. On 24 April 2015 at 19:35, Gabriela Gibson <gabriela.gib...@gmail.com> wrote: > I made two of those at the same time, here is the second one. > > On Fri, Apr 24, 2015 at 6:30 PM, Gabriela Gibson < > gabriela.gib...@gmail.com> wrote: > >> That was the first ever AOO file I made. so of course it would be strange >> ;-D Newbie luck! >> >> I made it on a friend's windows laptop. >> >> Will ask him to bring it along so I can see if I can duplicate the >> problem. >> >> G >> >> On Fri, Apr 24, 2015 at 6:12 PM, Peter Kelly <pe...@uxproductivity.com> >> wrote: >> >>> Here’s an excerpt from manifest.xml showing the encryption settings: >>> >>> <manifest:file-entry manifest:media-type="text/xml" >>> manifest:full-path="content.xml" manifest:size="3339"> >>> <manifest:encryption-data manifest:checksum-type="SHA1/1K" >>> manifest:checksum="EmZmyZPO3yYOHgp28usjV1l9X4Q="> >>> <manifest:algorithm manifest:algorithm-name="Blowfish CFB" >>> manifest:initialisation-vector="p92yZnQwe+k="/> >>> <manifest:key-derivation manifest:key-derivation-name="PBKDF2" >>> manifest:key-size="16" manifest:iteration-count="1024" >>> manifest:salt="h/xi87L9mzRV2wJhAxPCzQ=="/> >>> <manifest:start-key-generation >>> manifest:start-key-generation-name="SHA1" manifest:key-size="20"/> >>> </manifest:encryption-data> >>> </manifest:file-entry> >>> >>> -- >>> 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 < >>> http://www.kellypmk.net/pgp-key> >>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) >>> >>> > On 25 Apr 2015, at 12:10 am, Peter Kelly <pe...@uxproductivity.com> >>> wrote: >>> > >>> > 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> >>> > >>> > -- >>> > Dr. Peter M. Kelly >>> > Founder, UX Productivity >>> > pe...@uxproductivity.com <mailto:pe...@uxproductivity.com> >>> > http://www.uxproductivity.com/ >>> > http://www.kellypmk.net/ <http://www.kellypmk.net/> >>> > >>> > 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) >>> > >>> >> On 24 Apr 2015, at 11:48 pm, Gabriela Gibson < >>> gabriela.gib...@gmail.com <mailto: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 <mailto:gabriela.gib...@gmail.com>> wrote: >>> >> On Fri, Apr 24, 2015 at 4:42 PM, Peter Kelly <pmke...@apache.org >>> <mailto:pmke...@apache.org>> wrote: >>> >> > On 24 Apr 2015, at 6:27 pm, Gabriela Gibson < >>> gabriela.gib...@gmail.com <mailto: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 <mailto:pmke...@apache.org> >>> >> >>> >> PGP key: http://www.kellypmk.net/pgp-key < >>> http://www.kellypmk.net/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/ < >>> http://gabriela-gibson.blogspot.com/> >>> >> >>> >> >>> >> >>> >> -- >>> >> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ < >>> http://gabriela-gibson.blogspot.com/> >>> >> <testDoc1.odt> >>> > >>> >>> >> >> >> -- >> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ >> > > > > -- > Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ >
