Hi Thomas,
Thomas Zander wrote:
> Morning Oliver.
> On Wednesday 26 September 2007 09:11:25 Oliver-Rainer Wittmann wrote:
>>> I disagree that this is a good way to extend ODF, as I showed with a
>>> conflicting usecase in my previous mail already. In other words; adding
>>> implied behavior is not acceptable to me.
>>> If you want to specify the behaviors you should create a new attribute,
>>> like I described in my previous mail.
>> Again, I don't want to extend ODF - I only want to clarify things.
>>
>> I don't know, if I get the conflicting use case in your previous mail.
>> Is it, that the user anchored an object inside a table cell and stated
>> that the object should be positioned left-aligned at the page margin and
>> thus, in your opinion, this conflicts with clipping/capturing the object
>> inside the table cell?
>
> Let me try to explain what I think your proposal says, maybe I'm
> misunderstanding.
>
> You state that the behavior of the embedded object is slightly different based
> on where it is embedded. Embedding it in a text in the main page will draw it
> as normal while embedding it in a table cell will make sure that the embedded
> object can not be drawn outside that table cell.
> Your 'usecases' are thus embedded positions with slightly different behavior.
>
> Is that right?
>
That's partly right.
I have to add that an object anchored inside the body text will not
leave the body text area, if style:flow-with-text="true" - it can't be
positioned over the page header or the page footer as it is said in the
current specification text. If style:flow-with-text="false" for an
object, which is anchored inside the body text, it can leave the body
text area.
>> I don't understand your objections.
>
> I don't want different behavior based on position since that is implied
> behavior and if you want different behavior you should not make it implied by
> some slightly-relevant thing like where the text is positioned.
> So I disagree with your 'usecases'[1] actually requiring a different outcome.
>
>> Currently, the specification doesn't define the meaning of the frame
>> formatting property style:flow-with-text, if the object is anchored
>> inside a table cell, the page header, the page footer, a
>> footnote/endnote or inside another object.
>
> Yes it does, it defines the behavior exactly. By not making exceptions the
> behavior written in the spec is for all of those circumstances and thus the
> behavior is defined to be the same for all of them.
> The fact that you want to let OOo as well as KOffice and all the others behave
> differently based on where the embedding is done basically doesn't work for
> me. So I object.
>
I didn't agree to this interpretation.
The current specification text isn't very clear in my eyes. From my
point of view it only make sense to the situation that an object is
anchored inside the body text, probably also for an object that is
anchored inside a table cell, which is inside the body text.
It doesn't make sense for objects anchored inside a footnote/endnote,
page header, page footer or inside a text frame.
But finally, I can only repeat, that the original proposal for this
frame formatting property went into the specification too simplified and
not reviewed regarding the OpenOffice.org feature, which triggers this
frame formatting property.
Some notes on the history of this feature in OpenOffice.org Writer:
Prior to OpenOffice.org 2.0, text frames, embedded object and graphics
are clipped/captured inside its layout environment and flow with the
text flow, if possible. The reason for this was, that the content
structure also determines the layout structure - e.g. a paragraph inside
a page header have to stay inside the page header.
Shapes (drawing objects in OpenOffice.org) unfortunately doesn't follow
this rule.
For OpenOffice.org 2.0, we needed to unify text frames, embedded
objects, graphics and shapes. Thus, this frame formatting property has
been proposed. This need was also influenced by interoperability
requests for the binary Microsoft Word file format and the Microsoft
Word layout.
>> I only want to clarify these use cases. I think I can do this, because I
>> am somehow the original author of this frame formatting property, but
>> somehow in the communication process to the OASIS ODF TC some stuff is
>> lost.
>
> Luckely I spotted this in time then, or else KOffice would not be able to
> express its fuller feature set of embedding in ODF :)
>
> 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.
> I do agree that clipping would be great to have, but that for sure is a
> different feature which we should get into ODF.
>
> I suggested "clip-to-parent" as a new property, would that work for you?
From my point of view this isn't needed.
For me, [style:flow-with-text="true"] <==> [clip-to-parent="true"] and
[style:flow-with-text="false"] <==> [clip-to-parent="false"].
While [style:flow-with-text="true"] has the additional meaning, that the
object flow with the text flow, if it is possible.
I still have the opinion, that my proposed change is a needed
clarification for this frame formatting property.
Regards, Oliver.