Re: [office] Text Object position

[David Faure <faure@kde.org>]

On Wednesday 30 November 2005 19:00, Florian Reuter wrote:
> 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.

I disagree; B will be able to save the document, by converting that feature
to an equivalent-looking one. For instance paragraph-anchored frames
become page-anchored frames when opening the document in KWord,
it just needs to know where to put them. When saving again, the frame is still
there, and still where the user put it in the first place. It's just further editing
of the file (in either application) which will behave slightly differently, but that's a
much smaller problem than losing the frame or having it completely misplaced.
Making it possible to convert to a feature that the receiving application knows
is a great help in interoperability. Just like we provide paragraph numbers
to help numbering-unaware readers of the document, even though this means 
that any use of those numbers will prevent proper renumbering if the document
is further edited. But when converting to e.g. plain text it's obvious to everyone
that renumbering won't happen :).

Including "calculated" information into the file format, like frame position or
paragraph numbers, helps all readers of the file, not just other office suites.
There are many cases of programs which only want to read the file, not edit it,
and those are even more likely to miss some layout mechanisms: readonly 
viewers, converters to other formats, etc.

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

I have mixed feelings about this one. There's nothing "untidy" about
those features, it's just that we never implemented them in KWord.
(Well, ok, I do consider paragraph-anchoring-with-an-offset an abomination, 
but that's a special case). There are many reasonable features in OO.o that we
don't have. But in other applications it's other features that will be missing.
We can be arguing until the end of the world about which features are 'basic' enough
and which ones aren't... And do you really want to annoy the user with "this feature
might not work in other applications" when the user merely used whichever
was the default way of creating a text box, and doesn't plan on opening this
document in another application anyway?
A very small (and arguable) increase in interoperability for a large decrease in usability...

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).