Subject: Re: commit: piecetable changes
From: Randy Kramer (rhkramer@fast.net)
Date: Sun Nov 11 2001 - 10:02:45 CST
Martin Sevior wrote:
> On Sat, 10 Nov 2001, Tomas Frydrych wrote:
> > I have made two substantial changes to the piectable related to
> > styles:
> >
> > (1) when applying a style to something that already has a style, we
> > first remove all attributes and properties associated with the old
> > style and only then add the attributes and properties of the new
> > style. In the past we simply applied the properties of the new style
> > over all existing properties which meant that the result was not the
> > formating of the new style but a union of all previously used styles.
>
> I guess this is right although one might argue that the previous behaviour
> could be defended. Can Randy Kramer remind us of what MS Word does?
I'm pleased to try, but will probably need to provide more information
later.
As a first cut, I think the changes that Tomas has made (is making) are
a definite step forward in terms of duplicating the behavior of Word97
and thus, in behavior as I would expect it.
AFAICT, Word does not delete all attributes and properties associated
with an old style, but I think a lot of the point I'm trying to make
here is covered in Tomas' item (2), below. Character level attributes
(like bold, italic, etc.) on "spans" within a paragraph are usually
preserved. Actually, as I started to do some testing, things got rather
complex. I plan to do some more testing and then provide some
additional feedback within a few days.
>
> >
> > (2) when applying Paragraph style, we apply it to the Paragraph
> > alone not to the paragraph contents. In the past we did the latter,
> > i.e., applying Normal to a block resulted in all spans having also
> > the attribute style="Normal"; this is wrong. (Note that runs retrieve
> > their formating both from the block and span APs, so that any
> > character properties defined in Normal automatically filter down the
> > runs, without the need to apply Normal directly to the runs). This
> > change greatly simplifies changeStruxFmt, and once we are
> > satisified the new code is working, we can simplify it further (at the
> > moment this has been done so that it would could be easily
> > reverted).
> >
>
> I agree with this. The code should have done this before. It was bug since
> it does not.
>
> > These changes go some way toward fixing major bug 1939; there
> > is one more issue that needs to be resolved, and on which I need
> > Martin's input. Because the list-specific attributes are not part of
> > the style definitions, applying say Normal style to a list style will
> > not remove the numbering, etc. It would seem to me that the best
> > thing would be to add function to the style class bool
> > isNumbered(), which would return true for all the list styles,
> > numbered headings, etc., and which could be used to determine
> > whether to remove the list-specific attributes and related stuff.
> >
>
> Hmmm OK, if we take your present logic as correct Tomas, that applying a
> style to a previously defined style on a paragraph, wipes out the previous
> style definitions, then we just need a few hacks to to finish this off.
>
> I agree with how you suggest it should be done too.
>
> Just check for the present of the list "attributes" listID, parentID and
> "start-value". If these are present in a paragraph, wipe them out for any
> new style that does not have the "list-style" property in the style
> definition.
>
> To implement the "isNumbered()" method just look to see if "list-style" is
> present in the current style (including the basedon() parents of course).
> I would call it "isList()" though since that takes bullet lists into
> account too.
>
> Thanks for clearing this up and making progress Tomas. I left this in the
> too hard basket for a long time. If somone could confirm the behaviour of
> MSWord is as you describe we can finish off this messy interaction between
> lists and styles.
>
> Cheers
>
> Martin
This archive was generated by hypermail 2b25 : Sun Nov 11 2001 - 10:04:42 CST