Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
MIME-Version: 1.0
In-Reply-To: <0A58A1BF-20D4-4BFB-A42F-22D717085DB1@gmail.com>
References: <20140801084237.fd8a9b8ca6261554f2f0b9b0@iol.ie>
	<22A06F0C-16C5-4640-9C75-9CE8CE66AC17@gmail.com>
	<CAMK9kThZ0WerF=wS4am9XSz2sFqp++FY9zS0FFa09CWT1oT0zQ@mail.gmail.com>
	<7F2D7236-9B6D-4F31-B4BF-84934EDFBC98@gmail.com>
	<CAK2iWdQbXPbscZgjFCLh88qheyqoC+zHDZMoDg=AC6XWZ7nPZg@mail.gmail.com>
	<002f01cfae7f$5ce0a6e0$16a1f4a0$@acm.org>
	<CAK2iWdSYD_tUFsROVsk_g2GEtJHKUm_0EiApHiuA2xCrPo=j0A@mail.gmail.com>
	<AA2990A1-ED20-4AA2-8610-0977502125E6@gmail.com>
	<53DE2273.8030503@t-online.de>
	<0A58A1BF-20D4-4BFB-A42F-22D717085DB1@gmail.com>
Date: Sun, 3 Aug 2014 19:16:57 +0200
Message-ID: 
 <CAK2iWdSB+g8ky3P6NhLfPVje7CTdinGq0d4M9DsAtSouKbY+JA@mail.gmail.com>
Subject: Re: OOXML
From: jan i <jani@apache.org>
To: dev <dev@openoffice.apache.org>
Content-Type: multipart/alternative; boundary=001a113433ae29ab8504ffbcca1b

--001a113433ae29ab8504ffbcca1b
Content-Type: text/plain; charset=UTF-8

On 3 August 2014 18:50, Peter Kelly <kellypmk@gmail.com> wrote:

> On 3 Aug 2014, at 6:52 pm, Regina Henschel <rb.henschel@t-online.de>
> wrote:
>
> Peter Kelly schrieb:
>
> There's two ways to view a format: (1) as a way of encoding information
> for storage or transmission, and (2) as an in-memory data structure used
> by the editor at runtime. In some programs these are two different
> things, and in others they are the same. The latter is true of web
> browsers - HTML is both the file format and the runtime data model; the
> W3C DOM APIs can be used to manipulate the HTML structure directly. I
> believe this was also true to a large extent with the binary formats
> used by older versions of MS Office, for purposes of efficiency [1].
>
> I'm not familiar with the internals of OpenOffice - one thing I'd be
> very interested to know is does it use ODF for it's in-memory
> representation of the document? Or are the runtime data structures used
> different to the XML trees that one finds in an ODF package?
>
>
> No, OpenOffice has a very different in-memory representation than the ODF
> format. And the API is a third version of looking at the document.
>
>
> Interesting.
>
> Given this is the case, what would you suggest would be the best strategy
> for supporting OOXML?
>
> 1) Two-way conversion between OOXML and ODF, with OpenOffice then dealing
> solely with the file as ODF (not even being aware it came from OOXML
> originally)
> 2) Two-way conversion between OOXML and OpenOffice's internal
> representation, bypassing ODF altogether
>
> The second option has the advantage that it would be easier to cater for
> features that are supported in OOXML but not ODF, e.g. table styles.
> However the first option has the advantage that it would keep the core
> entirely separate from the OOXML filter, and could potentially be
> constructed as in a general-purpose manner and made usable as a library by
> other software.
>

By painfull experience, I found out that our internal (memory) structure is
a superset of mixed ODF and pre-odf items. I dont think you can have a pure
odf/OOXML memory structure, you need internal pointers as well (like
start/finish of copy buffer)...but of course those 2 parts should have been
well separated.

I wonder, you wrote earlier that UXwrite uses html internally, that seems
for me as the lowest common nominator...I would have thought a real
superset would have been the better choise ?

Some parts of AOO uses the structure directly others go through the API,
that is not very clean, and makes it extremly difficult to test chaanges in
the internal memory layout. An application like this (and many other
similar types), should see the memory as a capsule, with a fixed API around
it.

rgds
jan I

>
> --
> Dr. Peter M. Kelly
> Founder, UX Productivity
> peter@uxproductivity.com
> http://www.uxproductivity.com/
> http://www.kellypmk.net/
>
> PGP key: http://www.kellypmk.net/pgp-key
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>

--001a113433ae29ab8504ffbcca1b--