Subject: RE: Styles again.
From: Paul Rohr (paul@abisource.com)
Date: Wed May 16 2001 - 16:32:19 CDT
At 10:39 AM 5/14/01 +1000, Martin Sevior wrote:
>Say for example I have a mixture of symbol's and text in a paragraph. I
>want to define a style that will just turn everything a shade of light
>blue and leave all the other properties, like font-family and font-size,
>italics intact.
Yep. That's exactly how I intended it to work.
>Right now setting a style without a defined property puts
>that property to it default value. This screws up using styles to set
>custom colours as needed.
Now that's clearly a bug.
Any time a style definition changes (at edit time), you need an algorithm to
go through the document and make sure that any spans of existing text which
depend on that style get updated and reformatted accordingly. How are you
currently doing this?
At minimum, such an algorithm would need to refresh the appropriate
lookupProperties() caches. Then, depending on what the resulting change is,
you might also need to reflow the block or even higher-level containers. In
theory, this isn't much different than any other edit-driven change.
The tough thing is making sure that you've affected enough of the document,
but done so in an efficient way. The easy brute force solution would be to
reformat the entire document, but it might be more efficient to analyze the
basedon descendents of the changes style to decide which portions of the
document need to be reformatted, and skip anything that's not affected.
Getting a more efficient algorithm right will be real work, I'm afraid. (If
it was easy, I probably would have done it during the initial two-day
implementation.)
>From a UI standpoint this could be implemented by leaving the
>"basedon" property blank. If "basedon" is blank or undefined or "none" the
>style does not reset undefined properties.
Yes, you should definitely allow this in the UI.
>Otherwise the style is a diff from the "basedon" style. Undefined
>properties take on the values in the "basedon" style. This is what is
>currently implemented.
Yeah.
Of course, this raises the question of whether we should allow "redundant"
properties to be set in a "child" style. This is pretty similar to the big
debate we had about the bugs we currently see when property definitions in
styles mirror / hide the explicit properties set (for example, via toggling
the bold button).
Is it time to revive the whole "property pruning" thread, so we can resolve
both issues in a consistent way?
Paul
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:04 CDT