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] Text Object position


Hi David,

>>>I have a suggestion for an improvement in the way we specify the position of 
>>>text objects (or even drawing objects in general).
>>>What about saving their position (svg:x and svg:y) as redundant information, 
>>>for applications that don't implement all the positioning capabilites of e.g. OOWriter?If the application reading this doesn't implement centering of inline elements
>>>in paragraphs, the text box will be wrongly placed. Can we specify that the
>>>initial application should save the x and y (relative to the page topleft corner),
>>>so that less-advanced applications and conversion filters know where to place it?
>>>      
>>>
First I liked the idea, because its technically very easy to implement
this feature.
But thinking a little about this issue I would like to suggest a
different way to approach the "high sophisticated layout mechanisms" in
OpenDocument.
Speaking from the point of a user we have an application A, which
supports layout feature f and an application B, which doesn't. When
writing the coordinates of f to the file, B could display the position
of f correctly, but B is still not able to e.g. save it, modify it,
recalculating it. In general I think writing the coordinates of f to the
file will only delay the user problems.

What about another approach.
We --- as a TC --- define something like an OpenDocument Tidy or Strict
Subset, which only contains basic features, which can be handled by all
applications, like e.g. readers etc.
In OpenOffice.org or StarOffice or KOffice we could then implement a
warning, which warns the user, when he/she uses a feature, which is not
present in OpenDocument Tidy/Strict. I think this would increase the
interoperability of OpenDocument more than writing the coordinates to
the file.

Awaiting your comments,

Best regards,

Florian

P.S.
I'm still working on the numbering...



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