On 8 June 2015 at 14:58, Peter Kelly <pmke...@apache.org> wrote:
> 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).
>
I agree with peter lets keep the future open.
>
> 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.
>
I too do not really mind what we use, but it must be used consistent in the
source, otherwise it becomes a pain to maintain.
rgds
jan i.
>
> —
> 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)
>
> > On 7 Jun 2015, at 7:23 pm, Ian C <i...@amham.net> 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>
>
>
