On 24 April 2015 at 18:36, 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). > the cast to (unsigned long) can be from my x64 port, I had to do a small number of casts. rgds jan i > > 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/ >
