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

Hi Thorsten,

thanks for the reply. I understand now that the structure of the LO project renders my suggestion infeasible. So lets drop it. I will answer your questions below.

If you, or someone else, has such a list, would be cool to have it
filed properly in bugzilla&  maybe some meta-issue to track.

I'll try to draw one up with Cor Nouws and the other people from LO that attend the 7th ODF plugfest in Gouda next week (if they have the time for it).

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.

Here seems to be some incoherence in your argument (that was
previously asking LibO to fill ODF consumer bugs by completing the
implementation), and then you also suggest we fix things that are
shortcomings in other applications.

Of course, this is another point - however, coming from the same concern which is the experience of the end user. I think it is fair to acknowledge that features like the 3D objects are unlikely to survive in ODF in the long term - and rightly so, for ODF's sake. From a pragmatic point of view these components seem atavistic and without the historicity of Star Division's long gone past in 3D software components their presence in the specification would be hard to explain - let alone justify.

Since it is unlikely that LO will be able to cover the growing billions of electronic devices out there immediately - though I have a great deal of confidence in its unlimited future ;) - the high cost of support for other incomplete (non-desktop) implementations and the subsequent lack of it will probably negatively impact the end users perception of ODF and its capabilities to store their content reliably. So my point is that for the sake of the users we should at least be storing any such data in a way even the users of a simple implementation with many shortcomings can still at least see the objects. This would benefit everyone in the long run, I think.

drs. M.A.G.J. Leenaars
Director of Strategy
NLnet foundation
Science Park 400
1098 XH Amsterdam
sip/xmpp: michiel [@t]

'If you want the Internet to grow strong, safe and free,
but you don't know how to help, contribute to NLNet:
they do know and care."
                            Giorgio Maone, NoScript

Interested what Richard Stallman, Karsten Nohl, Andy Tanenbaum and
many others have to say about what NLnet helped them do for you?
Feel your wallet tingling already? Check out:


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.