Style objects for applications and filters

[Thorsten Zachmann]

On Friday, April 25, 2014 12:50:15 PM Inge Wallin wrote:
> I would like to have the opinion of the community for a certain issue. The
> first version of the docx export filter is now merged and it's time to take
> the next step. But this next step involves a decision which needs the input
> from the rest of the Calligra community.
> 
> The docx filter uses stream reading to parse the odf file, using
> KoXmlStreamReader in filters/libodf2, as opposed to our applications that
> use DOM reading, using the KoXmlReader in libs/odf.

It is not 100% correct. The libs/odf also use stream reader but offers a DOM 
interface to use it.

> One thing that we will need is page layout properties, which has child
> elements for columns among other things and this is where decision lies.
> Page layout properties already has good support in a couple of objects in
> libs/odf, among them KoPageLayout, KoColumns and KoBorder.
> 
> Those objects are designed to be fast and use binary representation of their
> properties. On the other hand many of them are not complete, i.e. they
> don't read, store and write all the properties that are defined in the
> standard. And they don't support stream reading. The style objects in 
> filters/libodf2 are all designed to be complete if not super fast - yet.
> 
> So here is the question: When we move forward with the docx filter, should
> we either:
> 
>  - add stream reading capabilities and maybe storage of properties
> represented as text to the objects in libs/odf
> 
> or:
> 
>  - create new objects like the previous style objects in filters/libodf2

I'm not sure about that. If we don't support the stuff in calligra how would 
you like to support it in the filter. If we have support for the stuff  the 
object  we use should support it do I miss something important here?

> The first one makes more sense to me since we should reduce duplication in
> Calligra at large and this will also mean that the objects will be made
> complete in relation to the attributes defined by the standard.  But it may
> also mean that not all attributes will be available in binary form through
> named class methods.

Do you have an example on how that would look. From the textual description 
I'm not sure if that is what we should do. Using a binary represenation has a 
very big advantage and that is the memory used to store the suff compared to 
e.g. have a map of properties if there are a lot of them.

Maybe you can provide more details so there is something we can discuss about.

A nice weekend,

Thorsten