MHonArc v2.5.2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC