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] OpenDocument TC Meeting Minutes 2005-12-05


Hi,

> Text Object position
> http://lists.oasis-open.org/archives/office/200510/msg00018.html
>
> David proposed, that attributes should be added, by which the absolute 
> position of objects on a page can be stored, even when the object is 
> not anchored to the page (e.g. anchored to paragraph). This would help 
> applications that do not implement all the layout features of 
> OpenDocument to position such objects.
> It is clear, that rendering a document in such a way will not always 
> lead to perfect results, and is also clear, that the simpler 
> application will need to change the document in such a way, that the 
> object is anchored in some supported way, if it was to modify and save 
> the document.
> There was a consensus that the idea of layout-hints was useful in 
> general. However, there is more discussion needed as to what the 
> general approach in handling such 'hints' should be in the specification.
> Discussion points:
> - Hints should always be optional
> - Should hints be in a special name space?
> - Should hints be a normative part of the specification?
> - Should hints be stored as meta-data rather than directly in the 
> document?
>
> Action: The discussion should be carried on on the mailing list.

I'm sorry, that I had no chance to participate at the meeting.

I would like to argue against layout-hints in OpenDocument. Please let 
me explain why:
My arguments come from a user perspective and what I'm learned from the 
filter in OpenOffice.org. The thing is, that if an application is 
missing a specific feature the user has applied, then sooner or later 
this misbehavior will become obvious. I really believe this, 'cause I 
learned it the hard way.
With this assumptions there are two cases:
a) The OpenDocument user applied the feature on purpose. Then doing the 
x/y stuff will not help him.
b) The OpenDocument user applied the feature on accident. Then the 
application should help him choosing the right feature for his purpose 
(e.g. interoperability), which leads me to the topic of an "tidy 
OpenDocument".


Hope you can follow my arguments,

Best regards,

Floiran



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