OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [office] Style options

Title: Message
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 name="StyleC" style:family="text">
    <style:properties fo:color="#CCCCCC" style:font-name="Arial" fo:left-margin="5cm"/>
...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:char-style name="StyleC">
    <style:char-properties fo:color="#CCCCCC" style:font-name="Arial" />
...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.
-Phil Boutros
VP, Technology

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC