SmartArt and OpenOffice.oo

By Rick Jelliffe
May 6, 2009 | Comments: 5

A month stale new, but I was happy to see Thorsten Behrens' blog entry SmartArt Import and More. Thorsten works on the graphics engine for OpenOffice's presentation application Impress. SmartArt is the name Microsoft give to a feature in Office 2007 where the user enters various kinds of two or three level lists, and these are converted to some pretty diagrams or graphics: structured data to graphics.

Anyway, what I want to call out is a sequence in Thorsten's blog:

Since I needed a SmartArt layouting engine anyways, it was quite natural to (re)use that for actually editing and relayouting the content in Impress! For that to work, of course either the ooxml input fragments or some derived data structure have to be available at the shape; again the most straight-forward way was to use ooxml directly (in the form of an in-memory representation of the xml tree, aka DOM).
  • He wanted to allow SmartArt import in Impress. —Better interoperability requires feature matching.
  • In order to do this, he found he may as well provide editing too. —The minimal implementation required more functionality than might be minimal, but it in turn meant some new low-hanging fruit. Merely being able to edit the rendered version of some structured data is not much compensation for the convenience of editing (simple) structured data directly.
  • The OOXML was usable and indeed "the most straight-forward way". —I am not surprised.

A requirement for ODF Next Gen?

The kicker is in the comments at the end. A contributor asked:

George:
>So I"m curious, can you save this to ODF format 
>once you have the slides done?

thorstenb:
> George, yeah you can, but it's a hack. ;-)

I suspect ODF Next-Gen will need enhancements to cope.

Thorsten's wasn't the only effort in this. It turned out that there is also another effort for the same thing coming out of the RedOffice team in China: Intelligent Groups. I hope they will all be talking and that we will see a good implementation in due course, because it is a really neat feature.

This is one area where ODF could really have used an alternative content facility like OOXML's MCE. The rendered graphic in standard ODF 1.n could be the default, and the smarter structured data in another part, and there would be backward compatability. It seems to me to be completely topsy-turvy to leave the features that will allow backwards compatability to some later time, when it will be too late for them to be any use. But that is what the ODF 1.2 spec will do. Wasted opportunities like this spring out of an underestimation of the advantages of plurality, in my book. A lack support for plurality makes things that should be a small problem (a smarter version of data which can be rendered using current graphics) into a non-interoperable problem.

The effect is that whatever SmartArt-alike gets incorporated into ODF-Next Gen (which may be finished in 2010, but more likely 2014) will not be compatible with today's OpenOffice applications. But not because of any technical reasons.

Having no MCE-alike in ODF 1.2 also increases the burden on implementers for coping with ODF Next-gen features. With MCE, they could put in code now to always chose the fallback version of any alternative content, only allowing that fallback to be strict ODF 1.2. Then any new ODF Next-Gen features (such as Intelligent Groups) would be gracefully coped with. The developer would be free to incrementally support additional Next-Gen features rather than having to support them all in a big bang. This would help smaller projects in particular.

References

Note: If you look through the OOXML standard IS29500 (publicly available) you won't find any reference to SmartArt. It is the name of a user interface feature that is backed up by some simple...err straightforward markup: the DrawingML vocabulary has an element called dataModel which is a graph of pt elements (data points). The primary reference is of course the ISO standard, IS29500 Part 1, s21.4 - Diagrams. There is a little language including forEach and constraints for different graphical compents too: there are sections for the datapoints list, the connections lists, styles and so on.

Wouter has a good intro 101 and 102, for people interested. See also some older doco here here.


You might also be interested in:

5 Comments

Rick,

indeed, Thorsten and the RedOffice team are in touch with each other, see:
http://graphics.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1523

Best regards,
Peter

Welcome to join us to push the Intelligent Group to ODF.

Xiuzhi: The ODF Next Gen requirements gathering phase is currently on until end of May: I think I have put in more requests than anyone else, including for better support of East Asian text structures.

I have been surprised that Open Office developers are not submitting more items on this themselves.

I don't think they realize that embracing standards means that increasingly innovation in applications needs to have a parallel effort in the standards work: after you have prototypes a feature the next step is to gather other prototypers together and make a submission to OASIS ODF TC. Otherwise the standard can have a deadening effect on innovation: I was reading this week an article on LISP that said that innovation on Common LISP and Scheme stopped after (a couple of rounds of) standardization.

There is definitely an effect where Microsoft developers have little idea of what the open source world is doing (they are often banned from looking at FOSS code for fear of polluting IP or something) and many FOSS developers have never even looked at Office 2007. Open standards must take on the role of providing RAND-z information between the camps, to a certain extent.

I read a lot of what seems to be knee-jerk reactions to the Ribbon for example, which is a really well-thought out and executed innovation. (I have many times commended Kiril Grouchnikov's open source Flamingo/Substance Java/Swing libraries which provides ribbon support.) Some people who deride the idea of always dancing to Microsoft's drum seem terrified of leaving the Office user interface circa 2000.

I hope the May 2009 deadline is an artificial one. We won't be through the issues list for ODF 1.2 by then. It seems wacky to freeze submissions for ODF-next when, as it is chancy that we'll have a fully baked OASIS Standard for ODF 1.2 in 2009.

I'm personally not going to think about ODF-next in any way shape or form until we have a stable ODF 1.2 that can serve as the basis on which ODF-next is grounded.

realize that embracing standards means that increasingly innovation in applications needs to have a parallel effort in the standards work: after you have prototypes a feature the next step is to gather other prototypers together and make a submission to OASIS ODF TC. Otherwise the standard can have a deadening effect on innovation: I was reading this week an article on LISP that said

News Topics

Recommended for You

Got a Question?