Subject: Re: Commit: Fix lots of stuff.
From: Randy Kramer (rhkramer@fast.net)
Date: Mon Dec 03 2001 - 10:09:12 CST
Martin Sevior wrote:
> Fix Numbered Headings. These are are nested if it makes sense. Fix Styles.
> Properties defined in spans that clash with style definitions on a block
> are removed from the span. List properties are removed following stop
> list. Stopping a list in a doc with several open views just removes one
> list level.
Martin,
Thanks for all your wonderful work on styles and lists! (And the others
who have contributed.)
Sounds good! I have one (very long) comment. The Word97 behavior with
respect to "Properties defined in spans that clash with style
definitions on a block are removed from the span" varies depending on
several conditions, and, there seem to be a number of exceptions. My
interpretation of the desirable behavior (factoring out what I consider
to be Word97 bugs) is something like the following:
Aside, I was/am writing a document to describe this behavior in Word --
when I lost access to bugzilla I set the effort aside and must leave it
set aside for at least the next few days. Some of the text below is
quoted from that other document without modification which may make it
read a little funny. The description below covers many aspects of
Word97's behavior, but the behavior also varies depending on the
selection -- whether you have no selection but just have the cursor
within a paragraph; or the selection consists of less than a paragraph,
one or more entire paragraphs, or one or more entire paragraphs plus
portions of additional paragraphs. I do not attempt to comprehensively
describe how the behavior changes with the selection in the following (I
will do that in the other document).
I can imagine many people looking at this behavior and thinking it's
ridiculously complicated and unnecessary. Actually, I think it becomes
intuitive very quickly, and is very useful. This behavior is by no
means an urgent requirement, but after finishing the (other) document I
will add some of these behaviors to bugzilla as RFE's. (Well actually,
I think I'll submit the document to the abiword-users list to see if we
can get a consensus.)
* If you apply a new style to a paragraph, I don't think it (Word97)
does what you describe as "Properties defined in spans that clash with
style definitions on a block are removed from the span". For instance,
if you apply a paragraph style that includes bold face type to a
document with (separate) spans of bold, underline, and italic, the
underline and italic spans become bold face italic and bold face
underline, respectively. The bold spans remain bold. If you then apply
a different paragraph style to the same paragraph, without the bold face
paragraph style, the original bold, underline, and italic spans should
appear as bold, underline, and italic.
(Actually, Word has what I consider some bugs here -- when you apply the
first new style, with the bold attribute, spans that were originally in
bold now appear non-bold (as if the bold attribute was toggled). When
you switch to a second new style, the italic and underline spans
reappear as described above, but the bold span is lost, i.e., it appears
non-bold.)
* If you reapply the current style to a paragraph or portion of a
paragraph, usually a special dialog box appears with these controls:
<quoted from other document>
1. A pair of radio buttons:
* Update the style to reflect recent changes? (the default)
* Reapply the formatting of the style to the selection?
2. A checkbox:
* Automatically update the style from now on?
3. OK and Cancel buttons
For me, updating the style to reflect recent changes, either one time or
automatically from now on, is evil, so I prefer not to see this
behavior duplicated in AbiWord -- if it is it should certainly not be
the default. (I like to create styles and then maintain them unchanged
unless I explicitly decide to change them. The default behavior here,
and some options like the Format --> Style --> Modify --> Automatically
Update option caused me a lot of problems with Word97 until I realized
some of this stuff existed and turned it off.)
I like the behavior under the option "Reapply the formatting of the
style to the selection?" and that is what I primarily discuss in the
following sections. It should be the default if we offer the choice.
When you accept this option the character level attributes like bold,
underline, and italic of spans within the paragraph are changed to match
the character attributes of the applied style. (So, if you had a
paragraph with some spans of bold, italic, and underline, and the
current style had none of these attributes, if you reapply the style,
those spans will lose their bold, italic, and or underline attributes,
but see below for specific actions depending on the selection.)
</quoted from other document>
Selecting:
* Reapply the formatting of the style to the selection?
usually has the effect of removing special character properties on spans
within the paragraph and replacing them with the "default" special
character properties (bold, underline, italic) of the (current)
paragraph style.
There are a number of exceptions or special cases to this behavior, some
I agree with, some I don't, and some I'm not sure.
The first exception is that this doesn't work if you reapply the Normal
style. I suspect (but don't know) that this was intentional by
Microsoft after too many users reapplied the Normal style by accident
(without thinking) and lost the bold, underline, and italic properties
on spans within the paragraph. (I think this exception may be
appropriate, but am not fully decided.)
The second exception seems to be that (and I need to dig into this one
deeper), when you reapply the current style to a selection less than a
paragraph, but which includes more than one span with special character
properties, only the first selected span is converted to the default
character properties of the (current) paragraph style. (I think all
selected (or partially selected) spans should be converted.)
Note that I am describing the behavior for what I'm calling the special
character properties, so far including bold, underline, italic. The
basic character properties (font style and size) are handled differently
(and, pending some more testing for confirmation, they are generally
applied the first time and every time a paragraph style is applied to a
selection or paragraph).
You can remove highlighting by reapplying the current paragraph style,
but only if the entire selection is highlighted (you don't have to
select the entire highlighted selection, but the entire selection must
be highlighted). I think this restriction is appropriate, it makes it
less likely to accidentally (unintentionally) remove some highlighting.
Aside: the word "span" in this context is something I'm just learning --
is a span always less than or equal to a paragraph, or can a span
include more than one paragraph? (And, is this the generally accepted
meaning or somewhat specific to AbiWord?)
Finally, after writing this, I realize that we should probably get
additional user input into this, so my current plan, after finishing the
other document, is to submit it to the abiword-users list for comment.
Randy Kramer
>
> So:
>
> 1. If you start anuymbered Heading 2 after a numbered heading 1 the
> the Numbered Heading 2 will be nested.
Wonderful!
>
> 1. First heading <= Numbered Heading 1
> 1.1 Sub Heading <= Numbered Heading 2
> 1.2 Sub Heading <= Numbered Heading 2
> 1.2.1 Sub Sub Heading <= Numbeed Heading 3
> 1.2 Sub Heading <= Numbered Heading 2
> 2 Second Heading <= Numbered Heading 1
>
> I think I will remove Chpater 2 CHapter 3, Section 2 and Section 3 styles.
> These are best used with Numbered heading styles. Otherwise with get
I think this is appropriate.
>
> Chapter1.Chapter1 If we apply CHpter heading 2 to a definition of a
> Chapter Heading.
>
> Next I fix styles so that span with properties defined in parapgraph style
> will have their local span properties removed if they clash with the style
> properties.
>
> This makes it possible to remove a character level properties by applying
> "Norma; or "Normal Clean".
My comments are above -- even if we modify these (two) behaviors
eventually, I think they are fine for the time being.
>
> Next I put in some code to remove unneded properties are a list on a block
> has been removed.
>
> Finally I fixed a bug that caused a stoplist action to remove several
> levels of nested lists if more than one view of document is open.
This archive was generated by hypermail 2b25 : Mon Dec 03 2001 - 10:11:16 CST