OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.

> I am also interested in the "fuller feature set" if you have time to
> point to it.


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.

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

This is a digitally signed message part.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]