Re: [office] Clarification for frame formatting propertystyle:flow-with-text

[Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems<Oliver-Rainer.Wittmann@Sun.COM>]

Hi

Thomas Zander wrote:
> On Monday 15 October 2007 16:42:08 you wrote:
>>> Bottom line; your different 'usecases' here should not be expressed
>>> add-ons to the style:flow-with-text property as that will only work for
>>> the model that OOo made up. Its not very flexible and it certainly will
>>> not work for KOffice.
>>>  
>> In what way would the suggestion not work for KOffice? (just a pointer
>> to the relevant part of KOffice documentation is fine if too long to
>> repeat)
> 
> To rehash the point Oliver made;
> Oliver wants to document that when this feature is used in different settings 
> the behavior is slightly different.
> So if you embed an image in a table the behavior would automatically change 
> from when that same tag is used in a main-text.
> Further, there are no options available at all to make sure that the behavior 
> in both cases stay the same.  The suggestion made by Oliver means that 
> applications *have* to follow the behavior that OOo now has implemented, or 
> can they are not able to store that in ODF.
> 
> 
> More technical;
> 
> Image embedded in any text flow can have [1]
>  * horizontal alignment (left, right, 'inline')
>  * vertical alignment (top, bottom, 'inline')
>  * image can be 'clipped' by the parent or not.
> 
> In the proposal that Oliver stated the first two are stored as properties, but 
> the 3th is implied by the position in the text where the image is embedded. 
> There is no way to override the clipping if you don't want the behavior 
> Oliver defined to be the correct one.
> 
> The problem you will face soon is that users and applications will find they 
> don't want the default value and want to change it.  But they can not.
> 

This isn't correct - probably I'm not clear enough in my previous mails:
- style:flow-with-text="true":
This means "stay inside the layout environment of its anchor and if 
possible, flow with the text flow.
E.g., Consider an object anchored at a paragraph, which is inside a 
table cell, which belongs to a table inside the body text. This object 
will not leave the area of the table cell. If the table cell is broken 
into several parts, the object can flow from the first part, which 
contains its anchor to the second part.
- style:flow-with-text="false":
This means "object can leave the layout environment of its anchor and 
can be positioned somewhere in the page area, where its anchor is in.
E.g., Consider an object anchored at a paragraph, which is inside a 
table cell, which belongs to a table inside the body text. This object 
can be positioned somewhere in the page area, for example in the 
left/right page margin or at the bottom of the body text area or at the 
top of the page area.

Thus, the user can decide, if she/he wants to "clip to the parent or not".

>> I am also interested in the "fuller feature set" if you have time to
>> point to it.
> 
> http://www.kdedevelopers.org/node/2759
> 
> And
> http://websvn.kde.org/trunk/koffice/libs/kotext/KoTextAnchor.h?revision=HEAD&view=markup
> See the enums at the top for the alignment options.

That's great, that KOffice2 will support such anchored objects and the 
corresponding positions as OOo already does.

> 
> And last; we have a "clip to parent" feature that is saved per shape.  And the 
> user can decide to turn that on or off, its not based on location.
> 
 From my point of view, this feature can be fully modelled with the 
style:flow-with-text. If a KOffice2 user wants an object to "clip to 
parent", then store style:flow-with-text="true" in the ODF file. If a 
KOffice2 user doesn't want this, then store style:flow-with-text="false" 
in the ODF file.

Regards, Oliver.