Subject: RE: Styles again.
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sat May 19 2001 - 08:44:27 CDT
On Wed, 16 May 2001, Paul Rohr wrote:
> 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.
>
OK after digging through the piecetable code I discovered that that the
attributes/properties of all fragments are contained in a hashtable
defined in PT_VarSet. Since there is currently no way to remove an entry
from the hastable it is impossible to remove a property/attribute from a
frag once it has been defined. I believe this is at the root of the
problem of not being able to define a single attribute style.
> >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?
>
After a style is changed I scan through all the frags and look to see if
the current style is defined for the frag. If it is I generate a fake
changeRecord without adding it the history and broadcast it out to all the
layouts. This causes them to flush their old attribute/properties and
update from the current style.
Right now I don't check the basedon style for Frags. I'll do that next. It
would be easy enough to recursively check the basedon style to see if the
the current style is defined anywhere in the styles history and update the
layout(s) matching the Frag accordingly.
This appears to work well in the tests I've made so far. Of course I can't
remove a property but I can change their values. It's fun to watch "red"
style areas of a document change to blue throughout the document after a
change to the style in the dialog.
> 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.
Yep. I actually do a changeSpan for character or changeStrux for paragraph
styles. The layout code already knows how to deal with these.
>
> 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.
>
I think I've got this covered.
> 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.)
It wasn't too bad. I think though we've finally found a place where Jeff
cut a corner though. The Hashtable code needs a way to delete entries.
>
> >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.
>
This almost works for character styles. I hope the hashtable fixes will
allow it for the paragraph code.
> >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.
Good, we agree!
>
> 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?
>
I think we should remove an explicit property/attribute if we pass the
name and either null pointer or a pointer to a null string. I'll code this
once the hashtable is fixed. Then we should be able to remove explicit
properties/attributes at will.
Cheers
Martin
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:05 CDT