You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Ian C <ia...@amham.net> on 2015/07/04 06:40:14 UTC
ODF Lenses
FYI
I just pushed a new branch ODFLenses so the world can see what I am doing.
Currently it only works in one direction. ODF -> HTML.
Working on the return path now.
--
Cheers,
Ian C
Re: ODF Lenses
Posted by Ian C <ia...@amham.net>.
Hi Harry,
thanks for that. I processed your file and it is not entirely empty.
It does contain some style definitions.
But the main content has gone.
Your document contains features that are not supported yet , eg images.
Please try a more basic document.
Currently the thing will process basic headers and paragraphs.
Attached is a test document I have which I am adding to as I add features.
At the moment I am looking at getting the framework for the round trip going.
Please feel free to add code and submit patches. We need all the help
we can get.
On Sun, Jul 5, 2015 at 3:38 AM, harry bachmann
<ha...@powerapp.eu> wrote:
> Hi Ian
>
> great work!
> In the att. I made a small test file. By me is the result a empty HTML file.
>
> Regards
>
> Harry
>
>
>> On 04 Jul 2015, at 06:40, Ian C <ia...@amham.net> wrote:
>>
>> FYI
>>
>> I just pushed a new branch ODFLenses so the world can see what I am doing.
>> Currently it only works in one direction. ODF -> HTML.
>>
>> Working on the return path now.
>>
>> --
>> Cheers,
>>
>> Ian C
>
>
--
Cheers,
Ian C
Fwd: ODF Lenses
Posted by Ian C <ia...@amham.net>.
Change pushed to the ODFLenses branch.
---------- Forwarded message ----------
From: Ian C <ia...@amham.net>
Date: Sun, Jul 5, 2015 at 2:55 PM
Subject: Re: ODF Lenses
To: dev <de...@corinthia.incubator.apache.org>
Hi All,
when looking at the return processing I have just discovered that the
html generated is very wrong. Well, it has two html sections and the
metadata in the wrong place.
When open the html file in Chrome is seems to be very forgiving and
displays what I expected.
However, dfconvert put is not so forgiving and generates and error
because it can't find the metadata.
I have fixed this now but not pushed yet.
On Sun, Jul 5, 2015 at 3:38 AM, harry bachmann
<ha...@powerapp.eu> wrote:
> Hi Ian
>
> great work!
> In the att. I made a small test file. By me is the result a empty HTML file.
>
> Regards
>
> Harry
>
>
>> On 04 Jul 2015, at 06:40, Ian C <ia...@amham.net> wrote:
>>
>> FYI
>>
>> I just pushed a new branch ODFLenses so the world can see what I am doing.
>> Currently it only works in one direction. ODF -> HTML.
>>
>> Working on the return path now.
>>
>> --
>> Cheers,
>>
>> Ian C
>
>
--
Cheers,
Ian C
--
Cheers,
Ian C
Re: ODF Lenses
Posted by Ian C <ia...@amham.net>.
Hi All,
when looking at the return processing I have just discovered that the
html generated is very wrong. Well, it has two html sections and the
metadata in the wrong place.
When open the html file in Chrome is seems to be very forgiving and
displays what I expected.
However, dfconvert put is not so forgiving and generates and error
because it can't find the metadata.
I have fixed this now but not pushed yet.
On Sun, Jul 5, 2015 at 3:38 AM, harry bachmann
<ha...@powerapp.eu> wrote:
> Hi Ian
>
> great work!
> In the att. I made a small test file. By me is the result a empty HTML file.
>
> Regards
>
> Harry
>
>
>> On 04 Jul 2015, at 06:40, Ian C <ia...@amham.net> wrote:
>>
>> FYI
>>
>> I just pushed a new branch ODFLenses so the world can see what I am doing.
>> Currently it only works in one direction. ODF -> HTML.
>>
>> Working on the return path now.
>>
>> --
>> Cheers,
>>
>> Ian C
>
>
--
Cheers,
Ian C
Re: ODF Lenses
Posted by harry bachmann <ha...@powerapp.eu>.
Hi Ian
great work!
Re: ODF Lenses
Posted by Peter Kelly <pm...@apache.org>.
> On 6 Jul 2015, at 6:42 pm, jan i <ja...@apache.org> wrote:
>
> On 6 July 2015 at 12:42, Peter Kelly <pm...@apache.org> wrote:
>
>> Hi Ian, looks decent so far. Just a few comments:
>>
>> ODFLenses.h is missing from the CMakeLists.txt file. This won’t affect
>> compilation at all, but it does mean that it will now show up in the file
>> list in IDEs like Xcode and Visual Studio.
>>
>> I got a number of “control reaches end of non-void function” warnings,
>> mostly in functions marked TBD, like ODFPut and ODFCreate. I’d recommend
>> setting a “not implemented” error here using DFErrorFormat, and then
>> returning 0.
>>
> +1, I always get suspicious when I get that warning.
>
> Should we move the code to trunk ? I suggest to do it.
Yes master is fine, given it’s for in-development stuff and we have a separate stable branch.
—
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)
Re: ODF Lenses
Posted by Ian C <ia...@apache.org>.
Ah ha, fun with warnings.
Adding -Wall and -Wextra to the compiler command in CMakeList.txt
generates a bunch of extract information.
Not sure that it is all entirely useful but now I know how to get the
extra level of checking.
On Tue, Jul 7, 2015 at 12:09 AM, Peter Kelly <pm...@apache.org> wrote:
>> On 6 Jul 2015, at 8:04 pm, Ian C <ia...@amham.net> wrote:
>>
>> Thanks for the feedback.
>>
>> Re warnings, I don't see any in the ODF code, I get a couple in minizip.
>>
>> Am I missing some compiler/make switches I wonder.
>>
>> My compiler is gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
>>
>> If I'd seen the warnings I would have addressed them.
>
> I’m using Xcode 6.4, which uses clang as its compiler:
>
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.4.0
> Thread model: posix
>
> I’m fortunate enough to have OS X, Ubuntu, and Window 7 accessible to me (the latter two under VMs) and always test new commits on all three platforms before pushing, but I understand not everyone has such a setup - so don’t feel bad about missing warnings that don’t show up on your system. I’ll be happy to correct any problems I see as they arise if you like.
>
> Jan: Do you know if it would be possible for us to get buildbots set up for the three platforms?
>
> Here are the errors I get:
>
> DocFormats/filters/odf/src/ODF.c:30:19: Unused variable 'conv'
> DocFormats/filters/odf/src/ODF.c:54:1: Control reaches end of non-void function
> DocFormats/filters/odf/src/ODF.c:59:1: Control reaches end of non-void function
> DocFormats/filters/odf/src/formatting/ODFStyles.c
> DocFormats/filters/odf/src/formatting/ODFStyles.c:49:62: Data argument not used by format string
> DocFormats/filters/odf/src/formatting/ODFStyles.c:120:128: Data argument not used by format string
> DocFormats/filters/odf/src/formatting/ODFStyles.c:146:112: Data argument not used by format string
> DocFormats/filters/odf/src/formatting/ODFStyles.c:169:110: Data argument not used by format string
> DocFormats/filters/odf/src/text/ODFText.c
> DocFormats/filters/odf/src/text/ODFText.c:157:1: Control reaches end of non-void function
> DocFormats/filters/odf/src/text/gbg_test.c
> DocFormats/filters/odf/src/text/gbg_test.c:139:21: Unused variable 's'
> DocFormats/filters/odf/src/text/gbg_test.c:318:51: Format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'Tag' (aka 'unsigned int')
> DocFormats/filters/odf/src/text/gbg_test.c:334:28: Unused variable 'attrDecl'
> DocFormats/filters/odf/src/text/gbg_test.c:346:54: Format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'Tag' (aka 'unsigned int')
>
> —
> 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)
>
Re: ODF Lenses
Posted by jan i <ja...@apache.org>.
On 6 July 2015 at 18:09, Peter Kelly <pm...@apache.org> wrote:
> > On 6 Jul 2015, at 8:04 pm, Ian C <ia...@amham.net> wrote:
> >
> > Thanks for the feedback.
> >
> > Re warnings, I don't see any in the ODF code, I get a couple in minizip.
> >
> > Am I missing some compiler/make switches I wonder.
> >
> > My compiler is gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
> >
> > If I'd seen the warnings I would have addressed them.
>
> I’m using Xcode 6.4, which uses clang as its compiler:
>
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.4.0
> Thread model: posix
>
> I’m fortunate enough to have OS X, Ubuntu, and Window 7 accessible to me
> (the latter two under VMs) and always test new commits on all three
> platforms before pushing, but I understand not everyone has such a setup -
> so don’t feel bad about missing warnings that don’t show up on your system.
> I’ll be happy to correct any problems I see as they arise if you like.
>
> Jan: Do you know if it would be possible for us to get buildbots set up
> for the three platforms?
>
it should be possible let me file a JIRA.
OS X 10.x
Ubuntu 12.x
Window 7 (sure we should not go for 8?)
rgds
jan i.
>
> Here are the errors I get:
>
> DocFormats/filters/odf/src/ODF.c:30:19: Unused variable 'conv'
> DocFormats/filters/odf/src/ODF.c:54:1: Control reaches end of non-void
> function
> DocFormats/filters/odf/src/ODF.c:59:1: Control reaches end of non-void
> function
> DocFormats/filters/odf/src/formatting/ODFStyles.c
> DocFormats/filters/odf/src/formatting/ODFStyles.c:49:62: Data argument not
> used by format string
> DocFormats/filters/odf/src/formatting/ODFStyles.c:120:128: Data argument
> not used by format string
> DocFormats/filters/odf/src/formatting/ODFStyles.c:146:112: Data argument
> not used by format string
> DocFormats/filters/odf/src/formatting/ODFStyles.c:169:110: Data argument
> not used by format string
> DocFormats/filters/odf/src/text/ODFText.c
> DocFormats/filters/odf/src/text/ODFText.c:157:1: Control reaches end of
> non-void function
> DocFormats/filters/odf/src/text/gbg_test.c
> DocFormats/filters/odf/src/text/gbg_test.c:139:21: Unused variable 's'
> DocFormats/filters/odf/src/text/gbg_test.c:318:51: Format specifies type
> 'size_t' (aka 'unsigned long') but the argument has type 'Tag' (aka
> 'unsigned int')
> DocFormats/filters/odf/src/text/gbg_test.c:334:28: Unused variable
> 'attrDecl'
> DocFormats/filters/odf/src/text/gbg_test.c:346:54: Format specifies type
> 'size_t' (aka 'unsigned long') but the argument has type 'Tag' (aka
> 'unsigned int')
>
> —
> 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)
>
>
Re: ODF Lenses
Posted by Peter Kelly <pm...@apache.org>.
> On 6 Jul 2015, at 8:04 pm, Ian C <ia...@amham.net> wrote:
>
> Thanks for the feedback.
>
> Re warnings, I don't see any in the ODF code, I get a couple in minizip.
>
> Am I missing some compiler/make switches I wonder.
>
> My compiler is gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
>
> If I'd seen the warnings I would have addressed them.
I’m using Xcode 6.4, which uses clang as its compiler:
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
I’m fortunate enough to have OS X, Ubuntu, and Window 7 accessible to me (the latter two under VMs) and always test new commits on all three platforms before pushing, but I understand not everyone has such a setup - so don’t feel bad about missing warnings that don’t show up on your system. I’ll be happy to correct any problems I see as they arise if you like.
Jan: Do you know if it would be possible for us to get buildbots set up for the three platforms?
Here are the errors I get:
DocFormats/filters/odf/src/ODF.c:30:19: Unused variable 'conv'
DocFormats/filters/odf/src/ODF.c:54:1: Control reaches end of non-void function
DocFormats/filters/odf/src/ODF.c:59:1: Control reaches end of non-void function
DocFormats/filters/odf/src/formatting/ODFStyles.c
DocFormats/filters/odf/src/formatting/ODFStyles.c:49:62: Data argument not used by format string
DocFormats/filters/odf/src/formatting/ODFStyles.c:120:128: Data argument not used by format string
DocFormats/filters/odf/src/formatting/ODFStyles.c:146:112: Data argument not used by format string
DocFormats/filters/odf/src/formatting/ODFStyles.c:169:110: Data argument not used by format string
DocFormats/filters/odf/src/text/ODFText.c
DocFormats/filters/odf/src/text/ODFText.c:157:1: Control reaches end of non-void function
DocFormats/filters/odf/src/text/gbg_test.c
DocFormats/filters/odf/src/text/gbg_test.c:139:21: Unused variable 's'
DocFormats/filters/odf/src/text/gbg_test.c:318:51: Format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'Tag' (aka 'unsigned int')
DocFormats/filters/odf/src/text/gbg_test.c:334:28: Unused variable 'attrDecl'
DocFormats/filters/odf/src/text/gbg_test.c:346:54: Format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'Tag' (aka 'unsigned int')
—
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)
Re: ODF Lenses
Posted by jan i <ja...@apache.org>.
On 6 July 2015 at 15:04, Ian C <ia...@amham.net> wrote:
> Thanks for the feedback.
>
> Re warnings, I don't see any in the ODF code, I get a couple in minizip.
>
minizip is third party code that I work on replacing (when I dont work on
apacheCON).
>
> Am I missing some compiler/make switches I wonder.
>
> My compiler is gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
>
> If I'd seen the warnings I would have addressed them.
>
If peter do not beat me to it, I will copy you the list I have in visual
studio.
rgds
jan i.
>
> On Mon, Jul 6, 2015 at 7:42 PM, jan i <ja...@apache.org> wrote:
> > On 6 July 2015 at 12:42, Peter Kelly <pm...@apache.org> wrote:
> >
> >> Hi Ian, looks decent so far. Just a few comments:
> >>
> >> ODFLenses.h is missing from the CMakeLists.txt file. This won’t affect
> >> compilation at all, but it does mean that it will now show up in the
> file
> >> list in IDEs like Xcode and Visual Studio.
> >>
> >> I got a number of “control reaches end of non-void function” warnings,
> >> mostly in functions marked TBD, like ODFPut and ODFCreate. I’d recommend
> >> setting a “not implemented” error here using DFErrorFormat, and then
> >> returning 0.
> >>
> > +1, I always get suspicious when I get that warning.
> >
> > Should we move the code to trunk ? I suggest to do it.
> >
> > rgds
> > jan i.
> >
> >
> >>
> >> There were also some warnings about incorrect use of format strings in
> >> ODFStyles.c. There’s some places here where color macros like CYAN and
> >> RESET are used where in one instance they’re part of the format string
> >> itself, and in others they’re passed as string parameters, like the
> >> following:
> >>
> >> printf(CYAN "Create CSS Properties for %s\n", styleName, RESET);
> >>
> >> This gives me a warning that not all the format parameters are used.
> >>
> >> ODFContainerGet and ODFConainerPut:
> >>
> >> These functions are only really relevant for "container" elements that
> can
> >> have a variable set of children - that is, where the children can be
> added,
> >> removed, and rearranged. Where this is not the case, it is possible
> >> (better? i'm not sure) to do this without the container logic.
> >>
> >> For example, <office:body> has exactly one child - either a
> <office:text>,
> >> <office:spreadsheet>, or <office:presentation>. This determines the
> type of
> >> document. The code that's currently there calls ODFContainerGet with the
> >> ODFTextLens function table as a parameter, and that in turn calls
> >> ODFTextGet, which calls ODFContainerGet with an ODFTextLevelLens.
> Finally,
> >> this results in ODFTextLevelGet being called. A more direct approach
> would
> >> be to simply call ODFTextGet from ODFBodyGet, since we can deduce that's
> >> what will be called in all cases.
> >>
> >> A case where you *would* need to use the generic container functions is
> >> for ODFTextLevelLens (i.e. a containing element which can have multiple
> >> block-level elements such as paragraphs and tables), and similarly for
> any
> >> element that can contain inline elements, like <text:h>, <text:p>, and
> >> <text:span>.
> >>
> >> On the topic of the latter, this should be handled recursively.
> Currently,
> >> ODFParagraphContentGet only handlines child nodes that are text nodes.
> But
> >> if you have a line with multiple, different formatting in it, e.g. bold
> and
> >> italic, then each of these will be a <text:span>. These can be
> arbitrarily
> >> nested, unlike in Word, but like in HTML.
> >>
> >> —
> >> 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)
> >>
> >> > On 4 Jul 2015, at 11:40 am, Ian C <ia...@amham.net> wrote:
> >> >
> >> > FYI
> >> >
> >> > I just pushed a new branch ODFLenses so the world can see what I am
> >> doing.
> >> > Currently it only works in one direction. ODF -> HTML.
> >> >
> >> > Working on the return path now.
> >> >
> >> > --
> >> > Cheers,
> >> >
> >> > Ian C
> >>
> >>
>
>
>
> --
> Cheers,
>
> Ian C
>
Re: ODF Lenses
Posted by Ian C <ia...@amham.net>.
Thanks for the feedback.
Re warnings, I don't see any in the ODF code, I get a couple in minizip.
Am I missing some compiler/make switches I wonder.
My compiler is gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
If I'd seen the warnings I would have addressed them.
On Mon, Jul 6, 2015 at 7:42 PM, jan i <ja...@apache.org> wrote:
> On 6 July 2015 at 12:42, Peter Kelly <pm...@apache.org> wrote:
>
>> Hi Ian, looks decent so far. Just a few comments:
>>
>> ODFLenses.h is missing from the CMakeLists.txt file. This won’t affect
>> compilation at all, but it does mean that it will now show up in the file
>> list in IDEs like Xcode and Visual Studio.
>>
>> I got a number of “control reaches end of non-void function” warnings,
>> mostly in functions marked TBD, like ODFPut and ODFCreate. I’d recommend
>> setting a “not implemented” error here using DFErrorFormat, and then
>> returning 0.
>>
> +1, I always get suspicious when I get that warning.
>
> Should we move the code to trunk ? I suggest to do it.
>
> rgds
> jan i.
>
>
>>
>> There were also some warnings about incorrect use of format strings in
>> ODFStyles.c. There’s some places here where color macros like CYAN and
>> RESET are used where in one instance they’re part of the format string
>> itself, and in others they’re passed as string parameters, like the
>> following:
>>
>> printf(CYAN "Create CSS Properties for %s\n", styleName, RESET);
>>
>> This gives me a warning that not all the format parameters are used.
>>
>> ODFContainerGet and ODFConainerPut:
>>
>> These functions are only really relevant for "container" elements that can
>> have a variable set of children - that is, where the children can be added,
>> removed, and rearranged. Where this is not the case, it is possible
>> (better? i'm not sure) to do this without the container logic.
>>
>> For example, <office:body> has exactly one child - either a <office:text>,
>> <office:spreadsheet>, or <office:presentation>. This determines the type of
>> document. The code that's currently there calls ODFContainerGet with the
>> ODFTextLens function table as a parameter, and that in turn calls
>> ODFTextGet, which calls ODFContainerGet with an ODFTextLevelLens. Finally,
>> this results in ODFTextLevelGet being called. A more direct approach would
>> be to simply call ODFTextGet from ODFBodyGet, since we can deduce that's
>> what will be called in all cases.
>>
>> A case where you *would* need to use the generic container functions is
>> for ODFTextLevelLens (i.e. a containing element which can have multiple
>> block-level elements such as paragraphs and tables), and similarly for any
>> element that can contain inline elements, like <text:h>, <text:p>, and
>> <text:span>.
>>
>> On the topic of the latter, this should be handled recursively. Currently,
>> ODFParagraphContentGet only handlines child nodes that are text nodes. But
>> if you have a line with multiple, different formatting in it, e.g. bold and
>> italic, then each of these will be a <text:span>. These can be arbitrarily
>> nested, unlike in Word, but like in HTML.
>>
>> —
>> 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)
>>
>> > On 4 Jul 2015, at 11:40 am, Ian C <ia...@amham.net> wrote:
>> >
>> > FYI
>> >
>> > I just pushed a new branch ODFLenses so the world can see what I am
>> doing.
>> > Currently it only works in one direction. ODF -> HTML.
>> >
>> > Working on the return path now.
>> >
>> > --
>> > Cheers,
>> >
>> > Ian C
>>
>>
--
Cheers,
Ian C
Re: ODF Lenses
Posted by jan i <ja...@apache.org>.
On 6 July 2015 at 12:42, Peter Kelly <pm...@apache.org> wrote:
> Hi Ian, looks decent so far. Just a few comments:
>
> ODFLenses.h is missing from the CMakeLists.txt file. This won’t affect
> compilation at all, but it does mean that it will now show up in the file
> list in IDEs like Xcode and Visual Studio.
>
> I got a number of “control reaches end of non-void function” warnings,
> mostly in functions marked TBD, like ODFPut and ODFCreate. I’d recommend
> setting a “not implemented” error here using DFErrorFormat, and then
> returning 0.
>
+1, I always get suspicious when I get that warning.
Should we move the code to trunk ? I suggest to do it.
rgds
jan i.
>
> There were also some warnings about incorrect use of format strings in
> ODFStyles.c. There’s some places here where color macros like CYAN and
> RESET are used where in one instance they’re part of the format string
> itself, and in others they’re passed as string parameters, like the
> following:
>
> printf(CYAN "Create CSS Properties for %s\n", styleName, RESET);
>
> This gives me a warning that not all the format parameters are used.
>
> ODFContainerGet and ODFConainerPut:
>
> These functions are only really relevant for "container" elements that can
> have a variable set of children - that is, where the children can be added,
> removed, and rearranged. Where this is not the case, it is possible
> (better? i'm not sure) to do this without the container logic.
>
> For example, <office:body> has exactly one child - either a <office:text>,
> <office:spreadsheet>, or <office:presentation>. This determines the type of
> document. The code that's currently there calls ODFContainerGet with the
> ODFTextLens function table as a parameter, and that in turn calls
> ODFTextGet, which calls ODFContainerGet with an ODFTextLevelLens. Finally,
> this results in ODFTextLevelGet being called. A more direct approach would
> be to simply call ODFTextGet from ODFBodyGet, since we can deduce that's
> what will be called in all cases.
>
> A case where you *would* need to use the generic container functions is
> for ODFTextLevelLens (i.e. a containing element which can have multiple
> block-level elements such as paragraphs and tables), and similarly for any
> element that can contain inline elements, like <text:h>, <text:p>, and
> <text:span>.
>
> On the topic of the latter, this should be handled recursively. Currently,
> ODFParagraphContentGet only handlines child nodes that are text nodes. But
> if you have a line with multiple, different formatting in it, e.g. bold and
> italic, then each of these will be a <text:span>. These can be arbitrarily
> nested, unlike in Word, but like in HTML.
>
> —
> 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)
>
> > On 4 Jul 2015, at 11:40 am, Ian C <ia...@amham.net> wrote:
> >
> > FYI
> >
> > I just pushed a new branch ODFLenses so the world can see what I am
> doing.
> > Currently it only works in one direction. ODF -> HTML.
> >
> > Working on the return path now.
> >
> > --
> > Cheers,
> >
> > Ian C
>
>
Re: ODF Lenses
Posted by Peter Kelly <pm...@apache.org>.
Hi Ian, looks decent so far. Just a few comments:
ODFLenses.h is missing from the CMakeLists.txt file. This won’t affect compilation at all, but it does mean that it will now show up in the file list in IDEs like Xcode and Visual Studio.
I got a number of “control reaches end of non-void function” warnings, mostly in functions marked TBD, like ODFPut and ODFCreate. I’d recommend setting a “not implemented” error here using DFErrorFormat, and then returning 0.
There were also some warnings about incorrect use of format strings in ODFStyles.c. There’s some places here where color macros like CYAN and RESET are used where in one instance they’re part of the format string itself, and in others they’re passed as string parameters, like the following:
printf(CYAN "Create CSS Properties for %s\n", styleName, RESET);
This gives me a warning that not all the format parameters are used.
ODFContainerGet and ODFConainerPut:
These functions are only really relevant for "container" elements that can have a variable set of children - that is, where the children can be added, removed, and rearranged. Where this is not the case, it is possible (better? i'm not sure) to do this without the container logic.
For example, <office:body> has exactly one child - either a <office:text>, <office:spreadsheet>, or <office:presentation>. This determines the type of document. The code that's currently there calls ODFContainerGet with the ODFTextLens function table as a parameter, and that in turn calls ODFTextGet, which calls ODFContainerGet with an ODFTextLevelLens. Finally, this results in ODFTextLevelGet being called. A more direct approach would be to simply call ODFTextGet from ODFBodyGet, since we can deduce that's what will be called in all cases.
A case where you *would* need to use the generic container functions is for ODFTextLevelLens (i.e. a containing element which can have multiple block-level elements such as paragraphs and tables), and similarly for any element that can contain inline elements, like <text:h>, <text:p>, and <text:span>.
On the topic of the latter, this should be handled recursively. Currently, ODFParagraphContentGet only handlines child nodes that are text nodes. But if you have a line with multiple, different formatting in it, e.g. bold and italic, then each of these will be a <text:span>. These can be arbitrarily nested, unlike in Word, but like in HTML.
—
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)
> On 4 Jul 2015, at 11:40 am, Ian C <ia...@amham.net> wrote:
>
> FYI
>
> I just pushed a new branch ODFLenses so the world can see what I am doing.
> Currently it only works in one direction. ODF -> HTML.
>
> Working on the return path now.
>
> --
> Cheers,
>
> Ian C