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

[Patrick Durusau <patrick@durusau.net>]

Thomas,

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.
>
>   
Ah, ok, now I understand the issue.

To "say it back" the problem is one of defining one correct behavior 
versus allowing some defined range of behaviors. Yes?

Of course, any given application may choose to support only one 
"correct" behavior but other applications may choose to offer a fuller 
range of choices as defined by ODF.
>> 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.
>
> 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.
>
>   
Thanks!

Hope you are having a great day!

Patrick
>
> 1) these are just simple examples to proof a point, and not meant to be a full 
> description of the spec.
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)