[ODFPlugtest] ODF interop at DII event in Brussels tomorrow

Sven Langkamp sven.langkamp at gmail.com
Thu Nov 12 04:33:15 CET 2009


On Thu, Nov 12, 2009 at 1:53 AM, Doug Mahugh <Doug.Mahugh at microsoft.com>wrote:

> Michiel,
>
> Attached are three test documents and two images that summarize the
> behavior of these documents.  I think the results speak for themselves.
>
> As stated on the KOffice wiki (
> http://wiki.koffice.org/index.php?title=KOffice2/ODF_Problems), OOo does
> not support the SVG objects that KOffice writes.  I see that this page is
> dated October 25, eight days prior to the Orvieto Plugfest -- could somebody
> from KOffice please confirm the date on which KOffice's SVG support was
> first available?  That is relevant to this discussion, because Michiel has
> repeatedly claimed that we made a bad decision by failing to allow for
> KOffice's support for SVG.  Based on the date on that change log, it appears
> to me that KOffice may have added SVG support 16 months after we first
> demonstrated our ODF implementation (on July 30, 2008) and six months after
> we released that support (on April 28, 2009).  Is that correct?  If not,
> what was the date that this support was added?
>

Looking at the history of the wiki article I added that note 7 march 2008.
The support was added in the first alpha releases so around september 2007
and officially released with KOffice 2.0 in may 2009.


> A few comments on our approach to this particular issue ...
>
> When we were planning our ODF implementation, we looked at existing ODF
> implementations and found that none of them supported reading or writing of
> SVG gradients.  So in an effort to achieve the best interop we could, we
> chose the <draw:gradient> form and limited the features we save to the ones
> supported by that form.  (i.e. only two stops).
>
> KOffice's decision to always writes SVG gradients, even in situations where
>  the gradient had originally been created and saved using draw:gradient (as
> in the attached two-stop example), has broken gradient interoperability with
> all existing ODF implementations that I'm aware of.  As a result of this
> approach, even a simple two-color gradient created by OpenOffice.org (or any
> ODF implementation) is destroyed by KOffice on a round trip.  This is
> clearly demonstrated in the attached files.
>
> So gradient interoperability between KOffice and OO.o is quite broken.
>  Interop between KOffice and Symphony is also broken.  And yes, interop
> between KOffice and MS Office is broken - because in this case we chose
> better interop with OO.o over a fancier feature set that was not supported
> by any existing implementation that we tested.
>

Now that you have tested it you can add loading support for in the next
version. It should be pretty easy for MS Office considering that these
gradients are already supported. I understand that your decision about
saving simplyfied gradients, but you could have implemented loading of SVG
gradients without harming interop with OOo. All other implementations could
do what MS Office does now and take just the first and the last color. It's
not that much work and no rendering needs to be changed.


> This issue is a good example of why the ODF format sometimes makes it very
> hard to achieve good interoperability. There are two completely different
> and mutually incompatible ways of specifying a shape's gradient:
>  <draw:gradient>,  or <svg:linearGradient> and <svg:radialGradient>.  I
> don't know the history of this situation, but in order to improve ODF
> interoperability we need to fix the problem, and modify the standard so that
> it includes a single consistent and interoperable approach to gradients.
>
> Gradient fills are a pretty minor feature, especially when you look at some
> of the much more important document features that ODF does not support.  And
> gradient interoperability in ODF was just fine, albeit limited to two-stop
> gradients, until KOffice implemented a different and incompatible approach.
>

Well the history is pretty simple: The original gradients predate SVG, so
ODF has an acient version of the gradients and SVG gradients. The ancient
gradients are pretty much underdefinied in the spec. I think the best way
would be to actively deprecate the old gradients and use SVG gradients only
(If ODF wants to use more SVG in the future that needs to be done anyway).
Would be a good case for the new ODF-SVG liaison.


> Michiel, I don't understand why you insist on wasting so much of the
> community's time on this issue.  This is a very trivial issue, affecting a
> small number of users, and I don't believe it's worth spending our time on
> when there are so many larger issues to be addressed.
>
> I am very interested in others' thoughts on this matter.  What do other
> implementers think?  Sun?  IBM?  Gnumeric?  AbiWord?  Are you planning to
> implement support for SVG gradients as KOffice has done?  We are committed
> to providing the best possible user experience in this area, so if the
> community is moving toward SVG gradient support please let me know so that
> we can take that into consideration in our planning, just as took the
> widespread support for the draw:gradient approach into consideration in the
> planning of our original ODF implementation.
>
> Thanks,
> Doug
>
> P.S.  Michiel, as for parking at the event, I don't know the details and
> won't be able to verify until the morning.
>
>
> -----Original Message-----
> From: Michiel Leenaars [mailto:michiel at nlnet.nl]
> Sent: Wednesday, November 11, 2009 2:12 PM
> To: Doug Mahugh
> Subject: Re: [ODFPlugtest] ODF interop at DII event in Brussels tomorrow
>
> Hi Doug,
>
> thanks. Just a question: is there parking space available for the
> attendees?
>
> I singled Microsoft out, because you made a presentation about it at the
> plugfest saying your application had severe information loss in some of the
> more advanced graphical stuff when saving to ODF without SVG - which hinders
> adoption unnecessarily. Most of your competitors are not that heavy on
> graphics. Most render the KOffice SVG with less colors but otherwise
> allright, only MS Office and Abiword (which has little to no native graphics
> editor in the application itself) don't.
>
> But indeed, we should make all applications aware of the possible use of
> SVG in ODF. Some other apps like Softmaker in their native format surely
> support complex gradients, and not yet do so when importing an ODF file with
> an SVG. So, another best practise discovered at a plugfest! Let's do a
> scenario on this. We should discuss tomorrow, because it will greatly
> enhance your customer experience.
>
> Best,
> Michiel
>
> RE: [ODFPlugtest] ODF interop at DII event in Brussels tomorrow
>  From:   Doug Mahugh
>  To:   ODF Plugfest mailinglist <plugtest at opendocsociety.org>, "Michiel
> Leenaars (michiel at nlnet.nl)" <michiel at nlnet.nl>
>
> Hi Michiel,
>
> The event tomorrow will take place at the Microsoft Executive Briefing
> Center at Avenue des Nerviens 85.  You can find more information about the
> facility
> here: http://www.microsoft.com/ebc/brussels.mspx
>
> Since today is a holiday in Belgium, I had to provide the list of attendees
> to the EBC staff as of end of day Tuesday, but I will notify them via email
> that you're planning to attend.  If there's any confusion at the front desk
> when you arrive, please ask for me.
>
> I'm glad you can attend, as I've done some further research on the gradient
> issue and have some findings to report.  I don't understand why you refer to
> Microsoft Office specifically below, though -- all versions of
> OpenOffice.org, as well as all other ODF implementations I've tested, with
> the exception of the recent versions of KOffice, do not support the SVG
> gradient alternative that KOffice has recently implemented.  So your
> statement could just as easily have mentioned any other implementation
> instead of Microsoft Office.  Will you be sending emails to all other ODF
> implementers asking them to support KOffice's alternative approach to
> gradients?
>
> In any event, I'll be doing some demonstrations tomorrow that should help
> clarify what's going on.
>
> Regards,
> Doug
>
>
> -----Original Message-----
> From: plugtest-bounces at opendocsociety.org [mailto:plugtest-
> bounces at opendocsociety.org] On Behalf Of Michiel Leenaars
> Sent: Wednesday, November 11, 2009 1:53 AM
> To: Plugtest at opendocsociety.org
> Subject: [ODFPlugtest] ODF interop at DII event in Brussels tomorrow
>
> Hello all,
>
> (slightly off topic question, but relevant to many members of this list)
>
> Doug Mahugh from Microsoft mentioned in Orvieto that there is an event
> organised by his company which will take place in Brussels tomorrow where he
> is talking about ODF-based interoperability. That will probably be very
> interesting, especially in the light of the outcome of the plugfest - where
> as you will remember one of the outcomes was that probably quite some
> features of Microsoft Office 2007 are unnecessarily broken when saving in
> ODF due to the missed fact that vector graphics in ODF consuming
> applications can use the full W3C SVG specification non-embedded rather than
> just the built-in subset meant for supporting low level graphics. I'm
> hopeful Doug will be able to give an update on that, given the timelines for
> their Office 2010 release.
>
> But now to my actual question: I'm trying to find out where the event
> tomorrow will be, and when. The DII website from Microsoft itself
> unfortunately doesn't yet mention the workshop, and the mail address Doug
> provides on his blog bounces. Doug himself is wandering about Brussels
> taking pictures. So if anyone is attending, can you help me out?
>
> Best,
> Michiel Leenaars
> Director of Strategy
> NLnet foundation
>
>
>
> The original message was received at Wed, 11 Nov 2009 10:05:27 +0100:
>
>   ----- The following addresses had permanent fatal errors ----- <
> diievents at microsoft.com>
>    (reason: 550 5.4.1 diievents at microsoft.com: Recipient address rejected:
> Access Denied)
>
>   ----- Transcript of session follows ----- ... while talking to
> mail.messaging.microsoft.com.:
> >>> DATA
> <<< 550 5.4.1 diievents at microsoft.com: Recipient address rejected: Access
> Denied
> 550 5.1.1 <diievents at microsoft.com>... User unknown <<< 503 5.5.2 Need
> rcpt command Unnamed
>
> _______________________________________________
> Plugtest mailing list
> Plugtest at opendocsociety.org
> http://lists.opendocsociety.org/mailman/listinfo/plugtest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open.nlnet.nl/pipermail/plugtest/attachments/20091112/59437e29/attachment.html>


More information about the Plugtest mailing list