Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

Hi Thorsten,

indeed, as you say so far discussion among the projects has been solved informally (actually my mail to Italo was rather informal as well). I think the members of the TC and the people that attend the plugfests do already carry that liaison role, but (like yourself) they are very busy people. And I would much rather have these people spend their time on writing specifications if the issues are already specified but just have implementation issues. That is not to say that I want you or anybody else to stop doing what comes informally and naturally (certainly not), but to have a tenacious bulldog appointed within these projects that makes sure that progress is made even if people are swamped.

From where I stand (and I'm not part of any specific project) there are a number of interoperability issues at your end still open I think, although probably people within TDF are already working on these. Notably this includes the use of (legacy) SVM wrappers instead of native alternative ODF frames and the lack of support for frame alternatives and clarification of the range selection of clipboard content (the issue that was raised by Gnumeric in August, as you may recall). Also probably some other forward looking capabilities which provide answers to common interoperability issues - like RDF and SVG support, as well as font inclusion - deserve some attention as well. Even though ODF as a document format has plenty of traction, some specific parts such as ODF's 3D objects stand less of a chance to make it as the dominant standard in this area (given that there are far better and more widely used standards for 3D). In order to make the experience better for everyone and make at least the content portable/visible to other (less complete) implementations I think that should be made more robust by making sure there are standards based fallbacks (in SVG, PNG) for any such parts. Those are the kinds of things I would envision the liaisons to discuss.

For people outside the project it is often not transparent who is responsible for what in other projects. Rather than asking people to just file a bug report, it would be good to have a named person in the project that is 'responsible' for this and that has regular contact. That is why I proposed to name a liaison - so there is an acknowledged channel to discuss practical areas of improvement. But of course it is just a suggestion.


On 11/07/11 09:57, Thorsten Behrens wrote:
Michiel Leenaars:
Would it be an idea to have a liaison between the Document Foundation
and other projects such as Calligra, AbiWord/Gnumeric, with a named
standards compliance person (and a fallback) within each project, which
take care of monitoring and pushing fixes - given that breaking the
standard is a severe thing that noone wants, and fixing such things is
best done from the inside.

Hi Michiel,

hm - I wonder why we'd need this extra ceremony. From what I can
tell, the problem is not acknowledging the problem, but actually
fixing it.

I've personally addressed a bunch of interop things myself, if and
when my time permitted it (and usually made fixing those a priority
over other equally important tasks). If beyond that there are urgent
issues in LibO that you, or the other ODF-processing FLOSS projects
deem important, I think the most promising avenue to success is to
motivate hackers to come&  fix those.

Or is there a recent example where not having such a role was
causing much trouble?

Of course, talking with you, Jos, Ben&  others from those projects
on how to improve ODF interop should happen nevertheless - but does
take place, works nice&  well, often&  informally. :)


-- Thorsten

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.