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.
