corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: ODF Restructure
Date Mon, 08 Jun 2015 12:58:06 GMT
On ODFGet vs. ODFTextGet - I would suggest we stick with the latter, as if & when we add
support for spreadsheets and presentations, we’ll need additional, separate methods for
those. That is, ODFPresentationGet and ODFSheetGet. The same is true of ODFTextConverter -
I expect we’d have ODFPresentationConverter and ODFSheetConverter as well.

The Word converter is structured the way it is because at the time I wrote the code, I was
interested only in word processing documents. It was only when I brought the code to Apache
that it was suggested that Corinthia become something that supports presentations and spreadsheets
as well. In a practical sense, we don’t address either of these at all, and whether either
of these gets implemented will depend on interest & available man/woman-power. But I think
it would be good to keep this possibility open - in that sense ODFGet by itself doesn’t
make sense sense it’s not clear what type of document is being dealt with. This is also
why the Word converter is called as what it is, rather than OOXML (though since coming into
Apache the directory structure has been put in place to cater for the future implementation
of OOXML spreadsheets and presentations).

Also one minor comment on coding style - all the existing code uses an indentation of 4 spaces,
no tabs, and { placed on the same line for if/while/switch statements, and on the following
line for function definitions. I’m not inherently tied to one layout or another, but I think
we should try to remain consistent with the style already in place.

Dr Peter M. Kelly

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

> On 7 Jun 2015, at 7:23 pm, Ian C <> wrote:
> Hi Gabriela,
> attached is a patch that reorganises the ODF world to be more like the way Word documents
are processed.
> I changed to the top level from operations to use an ODFGet. Which in turn uses an ODFConverter.
 The heart of the ODFGet function is
>     ODFConverter *converter = ODFConverterNew(html,abstractStorage,package,idPrefix);
>     //Get the styles data
>     //CSSSheetRelease(converter->styleSheet);
>     converter->styleSheet = ODFParseStyles(converter);
>     //Convert the content.xml to an html beastie
>     ODFTextGet(converter);
>     char *cssText = CSSSheetCopyCSSText(converter->styleSheet);
>     HTMLAddInternalStyleSheet(converter->html, cssText);
>     HTML_safeIndent(converter->html->docNode,0);
> Which parses for styles as I did before ( so still needs some work).
> Then calls an edited ODFTextGet - which is much as it was.
> The code has just been twisted around to match the structure of the word world.
> Which means I can't help thinking that we could/should abstract out the common aspects
of converters. 
> It converts the headers.odt document to an html which shows the headers ok.
> I also attached my version of headers.odt since I changed some of the styles to try and
emphasize their differences.
> I hope it makes sense to you and that your patch tool can digest it.
> -- 
> Cheers,
> Ian C
> <odfpatch.txt><headers.odt>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message