Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <2B52CEDA-F12B-4D3E-9861-C124BC26110E@apache.org>
References: 
 <CAKw-CV+5F+ejiCBQiVAiUEMkWAuCvgDd6rV3nX294KFqWC9UTg@mail.gmail.com>
	<2B52CEDA-F12B-4D3E-9861-C124BC26110E@apache.org>
Date: Mon, 8 Jun 2015 16:55:00 +0200
Message-ID: 
 <CAK2iWdT1hQOw8MhtzpqOrPExYOSOeMPOZ2c21naO5Zoh-rLgSQ@mail.gmail.com>
Subject: Re: ODF Restructure
From: jan i <jani@apache.org>
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org>
Content-Type: multipart/alternative; boundary=089e0141a0067b61b2051802d307

--089e0141a0067b61b2051802d307
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8 June 2015 at 14:58, Peter Kelly <pmkelly@apache.org> wrote:

> On ODFGet vs. ODFTextGet - I would suggest we stick with the latter, as i=
f
> & when we add support for spreadsheets and presentations, we=E2=80=99ll n=
eed
> additional, separate methods for those. That is, ODFPresentationGet and
> ODFSheetGet. The same is true of ODFTextConverter - I expect we=E2=80=99d=
 have
> ODFPresentationConverter and ODFSheetConverter as well.
>
> The Word converter is structured the way it is because at the time I wrot=
e
> 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=E2=80=99t address either of these at all, and whe=
ther
> either of these gets implemented will depend on interest & available
> man/woman-power. But I think it would be good to keep this possibility op=
en
> - in that sense ODFGet by itself doesn=E2=80=99t make sense sense it=E2=
=80=99s 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 th=
e
> 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=E2=80=99m not inherently tied to one layout or another, bu=
t 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.

>
> =E2=80=94
> 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 7 Jun 2015, at 7:23 pm, Ian C <ian@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 =3D
> ODFConverterNew(html,abstractStorage,package,idPrefix);
> >
> >     //Get the styles data
> >     //CSSSheetRelease(converter->styleSheet);
> >     converter->styleSheet =3D ODFParseStyles(converter);
> >
> >     //Convert the content.xml to an html beastie
> >     ODFTextGet(converter);
> >
> >     char *cssText =3D 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 wor=
d
> 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>
>
>

--089e0141a0067b61b2051802d307--