[office] Style options

Title: Message

Hi

 

I have some general 
comments on styles and how they are implemented in the current spec. I will try 
to stay away from discussing exactly what properties (bold, left-indent, etc.) 
that styles should hold since that is a much bigger 
discussion.

 

Almost all 
commercial office applications have a number of discrete style types, the most 
common ones being paragraph styles and character styles. Each style type can 
hold only properties (I'm using the OpenOffice nomenclature here) related to 
that type. For example, character styles can hold bold, font name, etc. but not 
indents, margins, tab stops, etc., page styles can hold page orientation, 
header/footer size, etc. but not bold, text color etc. Paragraph styles are 
somewhat of an exception because they can hold all the character style 
properties plus the ones specific to paragraphs like indents, alignment, space 
before/after, etc. The OpenOffice applications themselves follow this paradigm in their user 
interface and behavior.

 

The OpenOffice XML 
format however takes a more generic approach. In OpenOffice the list and 
page styles are broken out into text:list-style and 
style:page-master respectively. The character, paragraph and 
graphics styles however are all implemented using a single style:style element. In addition, properties on all five of these 
style types are set using a single all encompassing style:properties 
element and its children. While this is very flexible it requires 
that the user of the spec (especially someone processing an instance for 
rendering) understand, either intuitively or through documentation, what 
properties apply in what cases. For example, it is acceptable in the current DTD 
to have styles like this...

 

<style:style name="StyleP" 
style:family="paragraph">

    <style:properties 
fo:color="#000000" style:font-name="Thorndale" 
fo:left-margin="3cm"/>

</style:style>

 

<style:style name="StyleC" 
style:family="text">

    <style:properties 
fo:color="#CCCCCC" style:font-name="Arial" 
fo:left-margin="5cm"/>

</style:style>

 

...and content like 
this...

 

<text:p 
text:style-name="StyleP">This is a rather <text:span text:style-name="StyleC">short</text:span>sentence</text:p>

 

This is a simple example and I think most people would agree that 
fo:color and style:font-name in StyleC apply 
to the text "short" but the fo:left-margin does not and should 
probably be ignored. This is how the OpenOffice applications would interpret 
this XML. The problem is that the schema does not itself declare or enforce 
this. As property sets got more and more complex it becomes very 
difficult for a consumer to understand which properties to apply in which 
cases.

 

This problem has two possible solutions.

 

Option 1

Leave the existing OpenOffice styles as they are and commit to detailed 
documentation as to where properties apply.

 

Option 2

Change the schema to explicitly type the styles and property sets. Here 
is how the example above might look after such changes are 
made...

 

<style:para-style name="StyleP">

    <style:para-properties 
fo:left-margin="3cm"/>

    <style:char-properties 
fo:color="#000000" style:font-name="Thorndale" 
/>

</style:style>

 

<style:char-style name="StyleC">

    <style:char-properties 
fo:color="#CCCCCC" style:font-name="Arial" 
/>

</style:style>

 

...and content like 
this...

 

<text:p 
text:style-name="StyleP">This is a rather <text:span text:style-name="StyleC">short</text:span>sentence</text:p>

 

Note that because 
style:char-style can contain only style:char-properties 
(I continue to do schema by example instead of RelaxNG, sorry) there is 
no need for the consumer to understand that fo:left-margin="5cm" 
should be ignored, the schema prevents it from existing in a character 
style.

 

This option would have the 
added benefit (in my view) of increasing the readability of styles. In addition, I would rename 
style:page-master to style:page-style for 
consistency.

 

The actual schema for all this would need 
to be worked out but I hope my point and the general outline of my solution in 
option 2 are clear.

 

Thanks

-Phil 
Boutros
VP, Technology
Stellent