Subject: RE: The New Styles (LONG)
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 15 2001 - 12:24:06 CST
At 04:27 PM 3/14/01 -0000, Tom Newton wrote:
>I'm normally a bit of a lurker, but I'll put my two cents worth in (from my
>Maxwell WP experience). There are two issues here as you seem to see them:
>
>1. "Normal" style paragraph spacing
>2. General style changes affecting peoples previously saved documents.
Hi Tom!
What can we do to tempt you to de-lurk more often? :-) The community of
folks who've solved WP design problems to make the product Just Work is
pretty small. We'd love to hear more from you about how particular features
can or should work.
>On issue 2 however, either I'm misunderstanding the thread or you've all got
>it slightly wrong. It is my understanding that with most modern word
>processors (certainly in Word) the style definitions are saved with
>documents, and therefore, the fact that the default styles have changed
>shouldn't affect the documents that people have saved. Therefore, _any_
>changes to the default set of styles (even the change to the "normal" style)
>should not affect documents that people have already saved. In Word for
>example, if you change all the default styles, and then receive a document
>from someone who hasn't done so, their document still loads and displays
>correctly. I think Abiword should match this behaviour, and if it's not
>already persisting a set of styles in documents that have been saved, then
>this should be implemented before any changes are made to the default set of
>styles.
Since I wrote the existing styles code, I should clarify what it does and
doesn't do. ;-)
It's really, really simple but it does need a few more tweaks. In
particular, the current logic only persists style definitions that have been
changed from the hardwired defaults.
At the time, my next step was to make the styles mechanism default to the
style definitions from a specific template, instead of the hardwired styles,
and I wanted a way to tell which ones were user-defined so we could get the
dialog right. (Ditto for the hypothetical user-triggered mode which updated
the styles in the current document to reflect changes to the styles in the
underlying template.)
This behavior is currently obscured by the fact that:
- we don't have a working Styles dialog yet, and
- none of our importers (AFAIK) pass along style definitions, either.
Thus, the only way you can see this in effect is to, uh, edit the underlying
files by hand. :-( For details, see:
abi/test/wp/Styles.abw
However, as you point out, this means that we don't currently persist other
style definitions used in the document, which is, in retrospect, a Bad Thing.
As my penance, here's a brain dump on what a complete fix might look like.
At export time, there are conceivably 3 kinds of style definitions to choose
from:
1. user-defined
2. template
3. hardwired defaults
To further complicate matters, not all of those styles are necessarily used
in a particular document.
I'm now thinking that we should probably add another attribute to the <s>
tag to indicate whether a style was user-defined or not, so we can safely go
ahead and persist more style definitions. For example:
- binary choice: user=yes|no
- probably too thorough: source=user|template|default
I can think of two issues here:
A. bloat vs. consistency
-------------------------
Does anyone have any guidance on which of these style definitions, if any,
should *not* persist? I certainly haven't thought this through, but I'm
suspecting that, at minimum, *all* of the following should persist:
- all user-defined styles
- any other styles which were used
Thus, the real question becomes -- is it useful (or bloaty) to also export
unused styles as defined in the template and/or hardwired into the
application?
B. persist more than one style definition of the same name
-----------------------------------------------------------
I haven't seen screen shots or design notes on the new styles dialog, so I'm
not sure whether edited styles will coalesce or cascade.
Say what?
IIRC, we currently look up individual properties in the following order.
The first match found is the one we use.
1. explicit C prop
2. referenced C style
3. other C style that #2 is based on (recursive)
4. explicit P prop
5. referenced P style
6. other P style that #5 is based on (recursive)
7. hardwired default for that property
Note that (for steps 2, 3, 5, & 6) style definitions are looked up by name
in the following order:
i. user-defined
ii. template (not implemented)
iii. hardwired
Off the cuff, I'm guessing that any user-defined style should *explicitly*
include all unmodified props "inherited" from the other sources. That kind
of coalescing means that we'd be able to only persist a single definition
(the top-most one) for each style name.
If we instead wanted to "cascade" the various style definitions at run time,
then we'd have to persist the whole stack. At the moment, I'm not aware of
any use cases where this would be valuable enough to merit the cost.
proposal
--------
I'm very open to suggestions on either of these issues. Off the cuff, my
gut feel is that, at minimum, we should persist:
- one definition per style name (ie, "coalesce" issue B above)
- all user-defined styles
- any other template-defined styles (for consistency)
- any other default styles used
Implications:
- any template style that got redefined would not persist
- unused template styles would
Moreover, the only way a default style would persist would be if:
- it's used
- it's not in the template
- it hasn't been user-defined
Does that make sense? Can anyone think of screw cases where this approach
would get us into trouble?
alternative
-----------
Note that the only space savings in this proposal are the omission of:
- redundant style definitions at various levels
- unused default styles
IMHO, the savings from the former are significant, but the latter are
presumably much less so. Thus, it might just be simpler all around to drop
the "is a default style used" test. (It's certainly easier to implement.)
Then the rule would be to simply emit the topmost definition for each known
style, regardless of whether it's ever been used. Can anyone think of screw
cases where this approach would get us into more trouble than the original
proposal?
Thanks,
Paul
This archive was generated by hypermail 2b25 : Thu Mar 15 2001 - 13:53:29 CST