OASIS Open Document Format for Office Applications (OpenDocument) TC

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.

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.



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

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)

On Monday 15 October 2007 17:49:03 Patrick Durusau wrote:
> 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?

Yes, and the 'correct' here is a personal one. OOo choose one, I don't agree 
with it and have already implemented it quite different in KWord various 
months ago.

> 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.

That's right,
and to allow multiple implementations to interoperate we should IMO not have 
some paragraph in the spec stating what should happen with the same tag in 
different parts of the document, but instead we should have an extra property 
that makes it explicit.

This avoids the discussion what is the "correct" behavior by making it 
possible for OOo to store its wanted behavior in a property (probably 'true' 
for a table usecase, and 'false' for others) and at the same time allow other 
implementations do what they think is the best thing for their users.

This is the reason I objected to the change.
So for 1.2 we should either add the property (and if we do, I'd like to 
suggest some extra features like the alignment stuff), or leave the 
current 'no clipping' behavior as written in 1.1

Cheers!
-- 
Thomas Zander

Hi Thomas,


Thomas Zander wrote:
> ...
> I'd like to suggest some extra features like the alignment stuff

What kind of alignments do you have in mind?

The alignments, I've found at 
http://websvn.kde.org/trunk/koffice/libs/kotext/KoTextAnchor.h?revision=HEAD&view=markup 
are already defined in the OpenDocument file format specification - see 
sub chapter 16.27.9 - 16.27.12. What is missing there in table 31 is, 
that for anchor type at-paragraph the vertical relations "page" and 
"page-content" are also allowed, and for anchor type at-character the 
vertical relations "page", "page-content" and "line" are also allowed. 
These vertical relations are already supported by OOo since version 2.0



Regards, Oliver.

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.

On Tue, 2007-16-10 at 11:21 +0200, Oliver-Rainer Wittmann - Software
Engineer - Sun Microsystems wrote:

> 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".

Is "clip to the parent or not" a separate property? Clearly whether to
clip or not is orthogonal to whether to flow with the text or not:

Imagine I have an object attached to the 23 word of text inside a table
cell. I may prefer any one of the following:

1) the object should appear at a certain location relative to the anchor
point inside the cell and clipped to the cell.

2) the object should appear at a certain location relative to the anchor
point inside the cell and possibly overlapping information outside the
cell.

3) the object should appear at a certain location relative to the anchor
point inside the cell with the cell enlarged to encompass the object.

4) the object should appear at a certain absolute location on the same
page as the anchor point. Of course no clipping to the table cell should
happen.

5) the object should appear at a certain location relative to the anchor
point somewhere on the same page as the anchor point.  (This may in fact
effectively be the same as #2.)

Please note I have no idea what OOo or KOffice are in fact doing.

Andreas
> 

-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

Hi Andreas,

see my answers/comments inline.

Andreas J Guelzow wrote:
> On Tue, 2007-16-10 at 11:21 +0200, Oliver-Rainer Wittmann - Software
> Engineer - Sun Microsystems wrote:
> 
>> 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".
> 
> Is "clip to the parent or not" a separate property? 
No, it isn't. It's a property, which Thomas is proposing instead of my 
clarification to existing property style:flow-with-text.

> Clearly whether to
> clip or not is orthogonal to whether to flow with the text or not:
> 
> Imagine I have an object attached to the 23 word of text inside a table
> cell.
Thus, in OOo I would anchor the object at the first character of the 
word with anchor type at-character.

> I may prefer any one of the following:
> 
> 1) the object should appear at a certain location relative to the anchor
> point inside the cell and clipped to the cell.
In OOo:
- choose a horizontal and a vertical position relative to the anchor 
character.
- set style:flow-with-text = "true" -> assures that the object stays 
inside the table cell
- assure that the table cell has a fixed height by setting the height of 
the row to a fixed value -> assures that the table cell *doesn't* 
increase its height in order to achieve that the object fits into the 
table cell.

> 
> 2) the object should appear at a certain location relative to the anchor
> point inside the cell and possibly overlapping information outside the
> cell.
In OOo:
- choose a horizontal and a vertical position relative to the anchor 
character.
- set style:flow-with-text = "false" -> assures that the object can 
leave the table cell.

> 
> 3) the object should appear at a certain location relative to the anchor
> point inside the cell with the cell enlarged to encompass the object.
In OOo:
- choose a horizontal and a vertical position relative to the anchor 
character.
- set style:flow-with-text = "true"
- assure that the table cell fits its size to its content by checking 
the corresponding option the row -> assures that the table cell tries 
increase its height in order to achieve that object fits into the table cell

> 
> 4) the object should appear at a certain absolute location on the same
> page as the anchor point. Of course no clipping to the table cell should
> happen.
In OOo:
- choose a horizontal and a vertical position relative to one of the 
page areas.
- set style:flow-with-text = "false"

> 
> 5) the object should appear at a certain location relative to the anchor
> point somewhere on the same page as the anchor point.  (This may in fact
> effectively be the same as #2.)
Yes, same as #2 in OOo.

Regards, Oliver.

Hi,

please see my inline comments.

On Wed, 2007-17-10 at 10:09 +0200, Oliver-Rainer Wittmann - Software
Engineer - Sun Microsystems wrote:
> Andreas J Guelzow wrote:

> > Imagine I have an object attached to the 23 word of text inside a table
> > cell.
> Thus, in OOo I would anchor the object at the first character of the 
> word with anchor type at-character.

so the exact location of the anchor would be script dependent. IN a
right to left script does that put the anchor on the right side of the
first character?
 
> 
> > I may prefer any one of the following:
> > 
> > 1) the object should appear at a certain location relative to the anchor
> > point inside the cell and clipped to the cell.
> In OOo:
> - choose a horizontal and a vertical position relative to the anchor 
> character.
> - set style:flow-with-text = "true" -> assures that the object stays 
> inside the table cell
> - assure that the table cell has a fixed height by setting the height of 
> the row to a fixed value -> assures that the table cell *doesn't* 
> increase its height in order to achieve that the object fits into the 
> table cell.

That could be a problem: perhaps the table cell needs the ability to
adjust its height for some other object also attached to that cell.

> 
> > 
> > 2) the object should appear at a certain location relative to the anchor
> > point inside the cell and possibly overlapping information outside the
> > cell.
> In OOo:
> - choose a horizontal and a vertical position relative to the anchor 
> character.
> - set style:flow-with-text = "false" -> assures that the object can 
> leave the table cell.

so "flow-with-text" has really nothing to do with movement together with
the text. This seems like a strange naming.
> 
> > 
> > 3) the object should appear at a certain location relative to the anchor
> > point inside the cell with the cell enlarged to encompass the object.
> In OOo:
> - choose a horizontal and a vertical position relative to the anchor 
> character.
> - set style:flow-with-text = "true"
> - assure that the table cell fits its size to its content by checking 
> the corresponding option the row -> assures that the table cell tries 
> increase its height in order to achieve that object fits into the table cell
> 
> > 
> > 4) the object should appear at a certain absolute location on the same
> > page as the anchor point. Of course no clipping to the table cell should
> > happen.
> In OOo:
> - choose a horizontal and a vertical position relative to one of the 
> page areas.
> - set style:flow-with-text = "false"
> 
> > 
> > 5) the object should appear at a certain location relative to the anchor
> > point somewhere on the same page as the anchor point.  (This may in fact
> > effectively be the same as #2.)
> Yes, same as #2 in OOo.

If I may summarize:  style:flow-with-text appears to have nothing to do
with flowing with the text.

I am still not clear how to do the following:
A table cell with two objects anchored at 2 characters. Both should
appear at certain locations relative to the anchor point. The first
object inside the cell with the cell enlarged to encompass the object
and the other inside the cell and clipped to the cell size.

I think that the file format should allow for this.

Andreas 

-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

Andreas, Oliver,

I'm not sure if you use the same definition of "to clip".

Andreas: I think for you it does mean that one those parts of an object 
are painted that are within the bounds of the table cell. That is, the 
object's position is not touched. If the object does not fit into the 
table cell, it is only partially visible, or not visible at all. Is that 
correct?

Oliver: I think for you "to clip" means that the object is forced to 
stay within the table cell, either by enlarging the table cell, or maybe 
(I'm not sure) by adapting its position. Is that correct?

Best regards

Michael

Andreas J Guelzow wrote:
> Hi,
> 
> please see my inline comments.
> 
> On Wed, 2007-17-10 at 10:09 +0200, Oliver-Rainer Wittmann - Software
> Engineer - Sun Microsystems wrote:
>> Andreas J Guelzow wrote:
> 
>>> Imagine I have an object attached to the 23 word of text inside a table
>>> cell.
>> Thus, in OOo I would anchor the object at the first character of the 
>> word with anchor type at-character.
> 
> so the exact location of the anchor would be script dependent. IN a
> right to left script does that put the anchor on the right side of the
> first character?
>  
>>> I may prefer any one of the following:
>>>
>>> 1) the object should appear at a certain location relative to the anchor
>>> point inside the cell and clipped to the cell.
>> In OOo:
>> - choose a horizontal and a vertical position relative to the anchor 
>> character.
>> - set style:flow-with-text = "true" -> assures that the object stays 
>> inside the table cell
>> - assure that the table cell has a fixed height by setting the height of 
>> the row to a fixed value -> assures that the table cell *doesn't* 
>> increase its height in order to achieve that the object fits into the 
>> table cell.
> 
> That could be a problem: perhaps the table cell needs the ability to
> adjust its height for some other object also attached to that cell.
> 
>>> 2) the object should appear at a certain location relative to the anchor
>>> point inside the cell and possibly overlapping information outside the
>>> cell.
>> In OOo:
>> - choose a horizontal and a vertical position relative to the anchor 
>> character.
>> - set style:flow-with-text = "false" -> assures that the object can 
>> leave the table cell.
> 
> so "flow-with-text" has really nothing to do with movement together with
> the text. This seems like a strange naming.
>>> 3) the object should appear at a certain location relative to the anchor
>>> point inside the cell with the cell enlarged to encompass the object.
>> In OOo:
>> - choose a horizontal and a vertical position relative to the anchor 
>> character.
>> - set style:flow-with-text = "true"
>> - assure that the table cell fits its size to its content by checking 
>> the corresponding option the row -> assures that the table cell tries 
>> increase its height in order to achieve that object fits into the table cell
>>
>>> 4) the object should appear at a certain absolute location on the same
>>> page as the anchor point. Of course no clipping to the table cell should
>>> happen.
>> In OOo:
>> - choose a horizontal and a vertical position relative to one of the 
>> page areas.
>> - set style:flow-with-text = "false"
>>
>>> 5) the object should appear at a certain location relative to the anchor
>>> point somewhere on the same page as the anchor point.  (This may in fact
>>> effectively be the same as #2.)
>> Yes, same as #2 in OOo.
> 
> If I may summarize:  style:flow-with-text appears to have nothing to do
> with flowing with the text.
> 
> I am still not clear how to do the following:
> A table cell with two objects anchored at 2 characters. Both should
> appear at certain locations relative to the anchor point. The first
> object inside the cell with the cell enlarged to encompass the object
> and the other inside the cell and clipped to the cell size.
> 
> I think that the file format should allow for this.
> 
> Andreas 
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
        D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

Hi,

Michael Brauer wrote:
> Andreas, Oliver,
> 
> I'm not sure if you use the same definition of "to clip".
> 
> Andreas: I think for you it does mean that one those parts of an object 
> are painted that are within the bounds of the table cell. That is, the 
> object's position is not touched. If the object does not fit into the 
> table cell, it is only partially visible, or not visible at all. Is that 
> correct?
> 
> Oliver: I think for you "to clip" means that the object is forced to 
> stay within the table cell, either by enlarging the table cell, or maybe 
> (I'm not sure) by adapting its position. Is that correct?
Correct.

Regards, Oliver.

Hi again,

Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
> Hi,
> 
> Michael Brauer wrote:
>> Andreas, Oliver,
>>
>> I'm not sure if you use the same definition of "to clip".
>>
>> Andreas: I think for you it does mean that one those parts of an 
>> object are painted that are within the bounds of the table cell. That 
>> is, the object's position is not touched. If the object does not fit 
>> into the table cell, it is only partially visible, or not visible at 
>> all. Is that correct?
>>
>> Oliver: I think for you "to clip" means that the object is forced to 
>> stay within the table cell, either by enlarging the table cell, or 
>> maybe (I'm not sure) by adapting its position. Is that correct?
> Correct.
Thus, in general I call this "to capture an object inside a certain area".

Regards, Oliver.

Hi Andreas,

I want to ask you, if you can give your answer to Michael's question.
As it turned out that the used wording and terms causes confusion, I 
think it would be helpful, if we have your answer here.

Thanks, Oliver.

Michael Brauer wrote:
> Andreas, Oliver,
> 
> I'm not sure if you use the same definition of "to clip".
> 
> Andreas: I think for you it does mean that one those parts of an object 
> are painted that are within the bounds of the table cell. That is, the 
> object's position is not touched. If the object does not fit into the 
> table cell, it is only partially visible, or not visible at all. Is that 
> correct?
> 
> Oliver: I think for you "to clip" means that the object is forced to 
> stay within the table cell, either by enlarging the table cell, or maybe 
> (I'm not sure) by adapting its position. Is that correct?
> 
> Best regards
> 
> Michael
> 

On Fri, 2007-19-10 at 08:30 +0200, Oliver-Rainer Wittmann - Software
Engineer - Sun Microsystems wrote:
> Hi Andreas,
> 
> I want to ask you, if you can give your answer to Michael's question.
> As it turned out that the used wording and terms causes confusion, I 
> think it would be helpful, if we have your answer here.

Hi,

Michael was completely correct with his understanding of my
interpretation of the term clipping. [I think this term has been around
with this meaning at least since I first worked in computer graphics in
the late seventies. So I thought the term had a standard meaning.] 

Andreas

> 
> Michael Brauer wrote:
> > Andreas, Oliver,
> > 
> > I'm not sure if you use the same definition of "to clip".
> > 
> > Andreas: I think for you it does mean that one those parts of an object 
> > are painted that are within the bounds of the table cell. That is, the 
> > object's position is not touched. If the object does not fit into the 
> > table cell, it is only partially visible, or not visible at all. Is that 
> > correct?
> > 
> > Oliver: I think for you "to clip" means that the object is forced to 
> > stay within the table cell, either by enlarging the table cell, or maybe 
> > (I'm not sure) by adapting its position. Is that correct?
> > 
> > Best regards
> > 
> > Michael
> > 
> 
-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

On Friday 19 October 2007 09:13:21 Andreas J Guelzow wrote:
> I think this term has been around
> with this meaning at least since I first worked in computer graphics in
> the late seventies. So I thought the term had a standard meaning.

Yes, that's why I used that term ;)
I agree with your interpretation.

-- 
Thomas Zander

Hi,

Andreas J Guelzow wrote:
> On Fri, 2007-19-10 at 08:30 +0200, Oliver-Rainer Wittmann - Software
> Engineer - Sun Microsystems wrote:
>> Hi Andreas,
>>
>> I want to ask you, if you can give your answer to Michael's question.
>> As it turned out that the used wording and terms causes confusion, I 
>> think it would be helpful, if we have your answer here.
> 
> Hi,
> 
> Michael was completely correct with his understanding of my
> interpretation of the term clipping. [I think this term has been around
> with this meaning at least since I first worked in computer graphics in
> the late seventies. So I thought the term had a standard meaning.] 
> 

I've got also your understanding of term "to clip". But, I was advised 
by Thomas in his first reply to my initial post to use this term instead 
of my term "to capture".

Thus at the end, we solved this wording confusion.

Regards, Oliver.

> 
>> Michael Brauer wrote:
>>> Andreas, Oliver,
>>>
>>> I'm not sure if you use the same definition of "to clip".
>>>
>>> Andreas: I think for you it does mean that one those parts of an object 
>>> are painted that are within the bounds of the table cell. That is, the 
>>> object's position is not touched. If the object does not fit into the 
>>> table cell, it is only partially visible, or not visible at all. Is that 
>>> correct?
>>>
>>> Oliver: I think for you "to clip" means that the object is forced to 
>>> stay within the table cell, either by enlarging the table cell, or maybe 
>>> (I'm not sure) by adapting its position. Is that correct?
>>>
>>> Best regards
>>>
>>> Michael
>>>

Hi Andreas,

please see also my answer to Michael question about my interpretation of 
"to clip".

see my comments inline.

Andreas J Guelzow wrote:
> Hi,
> 
> please see my inline comments.
> 
> On Wed, 2007-17-10 at 10:09 +0200, Oliver-Rainer Wittmann - Software
> Engineer - Sun Microsystems wrote:
>> Andreas J Guelzow wrote:
> 
>>> Imagine I have an object attached to the 23 word of text inside a table
>>> cell.
>> Thus, in OOo I would anchor the object at the first character of the 
>> word with anchor type at-character.
> 
> so the exact location of the anchor would be script dependent. IN a
> right to left script does that put the anchor on the right side of the
> first character?

Yes, that's correct.

>  
>>> I may prefer any one of the following:
>>>
>>> 1) the object should appear at a certain location relative to the anchor
>>> point inside the cell and clipped to the cell.
>> In OOo:
>> - choose a horizontal and a vertical position relative to the anchor 
>> character.
>> - set style:flow-with-text = "true" -> assures that the object stays 
>> inside the table cell
>> - assure that the table cell has a fixed height by setting the height of 
>> the row to a fixed value -> assures that the table cell *doesn't* 
>> increase its height in order to achieve that the object fits into the 
>> table cell.
> 
> That could be a problem: perhaps the table cell needs the ability to
> adjust its height for some other object also attached to that cell.
> 
It can be and it depends on the actual positions and sizes of the two 
objects - see below for my further comments below.

>>> 2) the object should appear at a certain location relative to the anchor
>>> point inside the cell and possibly overlapping information outside the
>>> cell.
>> In OOo:
>> - choose a horizontal and a vertical position relative to the anchor 
>> character.
>> - set style:flow-with-text = "false" -> assures that the object can 
>> leave the table cell.
> 
> so "flow-with-text" has really nothing to do with movement together with
> the text. This seems like a strange naming.
>>> 3) the object should appear at a certain location relative to the anchor
>>> point inside the cell with the cell enlarged to encompass the object.
>> In OOo:
>> - choose a horizontal and a vertical position relative to the anchor 
>> character.
>> - set style:flow-with-text = "true"
>> - assure that the table cell fits its size to its content by checking 
>> the corresponding option the row -> assures that the table cell tries 
>> increase its height in order to achieve that object fits into the table cell
>>
>>> 4) the object should appear at a certain absolute location on the same
>>> page as the anchor point. Of course no clipping to the table cell should
>>> happen.
>> In OOo:
>> - choose a horizontal and a vertical position relative to one of the 
>> page areas.
>> - set style:flow-with-text = "false"
>>
>>> 5) the object should appear at a certain location relative to the anchor
>>> point somewhere on the same page as the anchor point.  (This may in fact
>>> effectively be the same as #2.)
>> Yes, same as #2 in OOo.
> 
> If I may summarize:  style:flow-with-text appears to have nothing to do
> with flowing with the text.
That's not true. It only looks like this in the situations you have 
constructed. But, also in these situations an object can flow with the 
text. Namely in the situation, when the table cell is broken into 
several parts. In this case an object with style:flow-with-text="true" 
will flow into the next part of the table cell, if it doesn't fit into 
the one of its anchor.

The name of this attribute had been chosen from the typical situation. 
This is an object anchored at a paragraph respectively at a character of 
a paragraph, which is inside the normal body text. Here 
style:flow-with-text="true" means "follow the text flow of the body text 
and do not leave its area" and style:flow-with-text="false" means 
"object hasn't to follow the text flow and thus, can be positioned 
somewhere in the page area.

> 
> I am still not clear how to do the following:
> A table cell with two objects anchored at 2 characters. Both should
> appear at certain locations relative to the anchor point. The first
> object inside the cell with the cell enlarged to encompass the object
> and the other inside the cell and clipped to the cell size.
It's a combination of #1 and #3 without setting a fixed height for the 
corresponding row, because you want to enlarge the table cell for object 
of #3. If in this situation object of #1 causes an enlargement of the 
table cell due to its position and size, I think its up to the user to 
adjust its position to solve the situation accordingly. For OOo this 
situation doesn't seem to be problematic, because I didn't get any 
negative feedback from the OOo users so far - and this feature is 
useable since OOo 2.0.

> 
> I think that the file format should allow for this.
It is allowed, but I think our file format can not resolve/define every 
constructed layout situation.

Regards, Oliver.