[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: koffice/libs/kotext
From:       Thomas Zander <zander () kde ! org>
Date:       2009-02-27 12:43:49
Message-ID: 200902271343.49958.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 27. February 2009 10:52:30 Pierre Stirnweiss wrote:
> On Fri, Feb 27, 2009 at 7:14 AM, Thorsten Zachmann 
<t.zachmann@zagge.de>wrote:
> > Hello,
> >
> > On Thursday 26 February 2009, Pierre Stirnweiss wrote:
> > > I quickly had a look and see your point. I actually think that the
> > > styles should nevertheless get the default properties in cstr.
> >
> > I don't think that is a good idea. The styles are created in the way that
> > they
> > only contain the attributes they change. I don't think we should make a
> > difference for some values.
>
> To be honest, I am not too sure any more about what I think about this.

I agree with Thorten on the basis of having styles be as empty as possible.

> There are two sort of conflicting use case which need to be handled, and
> our current implementation works only for the first:
[]
> - the second use case, which is broken currently is: The user has defined a
> named style called "Basic" with properties Sans Serif, 14 and another named
> style called "Basic Highlight" inheriting the "Basic" style and adding the
> property bold. The "Basic Highlight" should not set the font family and
> size, because he wants to have the Basic Highlight follow the parent style,
> just it being bold.
> Now he is typing in DjVu 12 some text and apply the style "basic Highlight"
> for some new text he want to type. His expectation would be that the new
> text he will type will be Sans Serif 14 bold. With our current system, the
> text he will enter will be DjVu 12 bold.

Then thats a bug; and an odd one as I was under the impression we have a 
styles unit test which tests this...

The issue is a bit complicated due to the implementation being slightly 
different from the expected outcome.
see koffice/libs/kotext/tests/TestStyles for expected behavior in code.

In words the behavior is that your "Basic Highlight" will return a font size 
of 14 if requested because the font size is found in the parent.
So applying the style should have applied this property to the text-run even 
though the hightlight style doesn't have this property set.

Similarly I expect that when the user changed the "Basic" to have a fontsize 
of 10 instead of the 14 it had before that all the text with the "Basic 
Highlight" are automatically updated to have this new font size. The reason 
is that the change of the parent style implicitly changes the child style as 
well.

About a month ago I realized that our design of applying styles has a 
fundamental flaw. Though.
We currently apply styles incrementally which can't work. We need to find a 
good way to remember all styles that affect a certain piece of text and 
re-apply them all every time we want to change text due to a style change.

But this is slightly off topic for the issue at hand;  the default properties.

> > > The logic of
> > > inheriting the previous span properties is an ODF logic and should be
> > > handled in the ODF loading mechanism.
>
> Now, this is actually not even true. I had a look at the spec (1.2 draft,
> but I think it didn't change):

Yes, I agree with Pierre here; inheriting the previous span properties is not 
a design that ODF states to be needed.
It doesn't make sense to me either, to be honest. It would require me to add 
a "bold=false" property to any span properties if its preceded by a span 
with "bold=true".  No, having 'bold' unset should end up having no bold, 
which is only possible by starting with an empty set of character-properties 
and then applying the span.

-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]