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

List:       koffice-devel
Subject:    Re: Call on wise men for text on shape
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2010-07-01 4:43:56
Message-ID: 201007010643.56510.t.zachmann () zagge ! de
[Download RAW message or body]

On Tuesday 29 June 2010 17:50:39 Thomas Zander wrote:
> On Tuesday 29. June 2010 16.07.49 Thorsten Zachmann wrote:
> > However I see some problems with how saving clipping is done at the
> > moment.
> 
> Maybe you can file a bugreport. Its likely not too hard to fix and clipping
> is not part of the text-on-shape wise men request AFAICT.

Lets try to explain the problem once more as it might be not clear what I 
meant.

At the moment the saving of the clip info is done by the following code:

 if (parent() && parent()->isClipped(this)) {

This works as long as there is the container doing the clipping the parent of 
the KoShape. If there is a hierarchy like the follwoing when using text on 
shape:

KoShapeContainer(clipping)
KoShapeContainer(Text on shape)
KoShape + TextShape

the above code does no longer work as the container doing the clipping is no 
longer the parent of the KoShape. Therefore the saving of clip will no longer 
work when text on shape is done as decoration.

There seams to be a real bug in loading somewhere also in the actual code that 
either loading or saving of the clipped rect is not working. Looks like it is 
saved but not loaded. I did not yet have time to report the bug but will do as 
soon as time permits.

I see problems when using multiple decorations to add features to a shape. The 
result might depend on the order of the decoration is added. This is shown by 
the fact that using both clip and text on shape at the same time is currently 
not possible in kword.

Saving using the functions you added might not work due to there being 
multiple parents with different decorations. The saving code you added has some 
problems. Some of the features need to be saved in different places in odf.

o inside the element tag <element feature="">
o between the element tag <element><feature></element>
o inside the style in the above combinations.

To recap I think using the current approach to use the shape hierarchy adding 
decorations is not what should be done. 

Sure there will be fixes and workaround for the problems I posted. This is 
software and nearly everything can be done one or another way.  The list of 
thinks that need to be worked around/fixed will just create more code which is 
much harder to understand and thus it get much harder to maintain. 

Thorsten
_______________________________________________
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]