Subject: Re: Styles (was Re: Upcoming releases)
From: Paul Rohr (paul@abisource.com)
Date: Tue Feb 13 2001 - 13:02:30 CST
Robert, Randy, and Martin,
Thanks for starting to delve deeper into what's required to finish our
styles support. As the author of the existing ultra-simple code, I'm pretty
proud of how much work the current styles engine is already capable of. For
more details, I highly encourage anyone interested to read the following:
abi/test/wp/Styles.abw
Be sure to check it out in your favorite plain-text editor, too. It's a
pretty compact demonstration of the following features, which all Just Work,
AFAIK:
- style definitions: <s name, props, type, basedon>
- style usage: <p style> vs. <c style>, <p style> vs. <p props>, etc.
As described at the bottom of that file, there's not much remaining work
left to do down in the styles engine for full support of Word's style
feature set.
At 11:54 AM 2/13/01 -0500, ROBERT CAMPBELL wrote:
>In fact, because styles are applied by default at the paragraph level,
>it is not necessary to select an entire paragraph to change its style.
>Simply place the cursor in the paragraph and select a new style, by any
>method (the drop list, the Style dialog, etc).
Yep. We do that for all <s type=p> paragraph-level styles (the default).
>>On a slightly different point, within a paragraph with a named style,
>>you can apply extra style attributes, like applying bold or italic to
>a
>>specific word or phrase. This text still has the underlying named
>style
>>that the original paragraph has, so that is the named style that is
>>shown in the drop down menu even if, for example, the entire
>paragraph
>>is selected.
>
>It is even possible to apply a different style to selected text withing
>a paragraph. For example, the Normal style may be applied to a
>paragraph. The user may then select text within that paragraph and
>apply the Emphasis style. This would override only the character
>formatting of the Normal style for the selected text. If the Emphasis
>style had paragraph-level formatting that conflicted with Normal style's
>(for example, Emphasis is right aligned and Normal is left aligned), it
>would have no effect.
These are <s type=c> character-level styles. To minimize confusion, the
styles dialog UI should prevent assigning paragraph-level props to these
styles.
>It is possible to have derived styles. For example, there may be a
>Normal style that defines font, point size, paragraph justification,
>etc. There may also be a Normal Emphasis style derived from Normal,
>which only specifies the differences between the two. For example,
>Normal Emphasis may add the bold attribute; it would not duplicate the
>font and point size attributes of Normal. Therefore, if the font and
>point size of the Normal style is changed, these changes would also
>cascade to any text that was Normal Emphasis.
Yep. This cascading effect is already implemented for any <s basedon=...>
style.
>Styles (in MS Word) can also have a Followed By attribute. For
>example, the Followed By attribute for the Heading 1 style may be Normal
>Paragraph. When the user types a heading (using Heading 1 style) and
>then presses enter, AbiWord would automatically switch to Normal
>Paragraph style. This is just a convenience feature. The user can
>select a different style for the next paragraph, if desired. And the
>automatic reformatting that takes place after a change to a style
>definition does not (or, at least, should not) affect the style of the
>following paragraph, even if the Followed By attribute was what changed.
> There is no (easy or infallible) way to tell whether the user had
>overridden the Followed By attribute in the first place.
>
>In the absence of a non-NULL Followed By attribute, the style should
>not change when the user presses ENTER.
Exactly. This is how <s followedby=...> should work. TODO. (At the time,
Jeff was mucking about with the much-maligned FmtMark code, which is my sole
excuse for not finishing this feature, too.)
Adding support for this will require a few localized changes to the editing
code at block boundaries. AFAIK, the styles engine shouldn't need to be
changed.
>I hope to implement RTF style-import, soon. To me, this is one of the
>most important missing features, because I use styles all the time in my
>legacy documents (resumes, reports, etc). I think you will find that
>most businesses do as well.
Excellent, excellent, excellent.
It's always irked me that we don't preserve existing styles on import (or,
worse, copy/paste), because that code should be quite easy to add. Ditto
for other file formats that support styles.
Paul
This archive was generated by hypermail 2b25 : Tue Feb 13 2001 - 16:35:17 CST