corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriela Gibson <gabriela.gib...@gmail.com>
Subject Re: Value of OFFICE_DOCUMENT in DFXMLNames.h
Date Fri, 24 Apr 2015 16:48:58 GMT
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.gibson@gmail.com>
wrote:

> On Fri, Apr 24, 2015 at 4:42 PM, Peter Kelly <pmkelly@apache.org> wrote:
>
>> > On 24 Apr 2015, at 6:27 pm, Gabriela Gibson <gabriela.gibson@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
>> pmkelly@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/

Mime
View raw message