Skip navigation

Category Archives: OpenOffice.org

I have been working a bit on improving the ooxml import for Impress recently, focusing on the SmartArt stuff from PowerPoint 2k7. A really nifty feature indeed. Cunningly enough, MS does not store any fallback shapes for SmartArt, thus leaving me with the sole option of implementing a SmartArt layout engine myself. Here’s what it can do already:

quickdiagram0a

And this is how the original thing looks like:

ppt03

But there’s more to it. 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). Having a group shape with four extra custom attributes then gives something like this:

smartart01

So “editing” this shape means tweaking the data xml fragment, i.e. adding or removing text or changing attributes, and then re-triggering the import/layouting engine. I just love it when code reuse is that easy. 😉

What I have now is something working end-to-end, with basic import, basic layouting and basic editing working. What comes next is improving all the details, i.e. supporting all layout types, editing all aspects, not only text etc. Stay tuned!

As usual, FOSDEM was a blast. Sadly I missed the Friday beer event this year, due to my current over-loadedness I went to Brussels (very early) Saturday morning. Gave a little talk about what I considered cool (and felt competent enough to talk about) in OOo’s gsl/graphics area together with Janneke, who really deserves (and actually got) the thunder about this awesomely cool dialog layouting implementation.

fosdem_small

For the curious, the slides are here (but we really talked & demoed a lot in between).

Following the announcements of Eike and Eric, I’m going to FOSDEM ’09 as well. If you’re around: I’ll be talking a bit about OpenOffice.org’s graphics/gui core, and what’s hot there currently. Tentative schedule is Saturday at 17:15 in AW1.126.

While having to work on binary PowerPoint import/export recently, I found the support for “debugging” the actual file format a bit lacking (to say the least). Of course, for those with MSDN access there’s the magic FileViewer.exe, but that’s of limited use on those other platforms I fancy working on, plus one cannot easily extend it.

I was therefore enviously looking at Daniel’s biffdumper and even more at Kohei’s xls-dump.py, and thusly set off ripping the guts out of the latter & hacking up a ppt-dump.py – which was a fun project actually!

Basically, what this gives you is a human-readable (and diffable!) dump of binary ppt files, like this:

====================================================================
[DFF_msofbtClientTextbox]
(type: F00Dh inst: 0000h, vers: 000Fh, start: 2760, size: 127)
====================================================================

 ====================================================================
 [DFF_PST_TextHeaderAtom]
 (type: 0F9Fh inst: 0000h, vers: 0000h, start: 0, size: 4)
 ====================================================================

 0F9Fh: -------------------------------------------------------------
 0F9Fh: 01 00 00 00 
 0F9Fh: -------------------------------------------------------------

 ====================================================================
 [DFF_PST_TextBytesAtom]
 (type: 0FA8h inst: 0000h, vers: 0000h, start: 12, size: 45)
 ====================================================================

 0FA8h: -------------------------------------------------------------
 0FA8h: text: 'Text^MText^MText^MText^MText^MText^MText^MText^MText'
 0FA8h: -------------------------------------------------------------
 0FA8h: 54 65 78 74 0D 54 65 78 74 0D 54 65 78 74 0D 54 
 0FA8h: 65 78 74 0D 54 65 78 74 0D 54 65 78 74 0D 54 65 
 0FA8h: 78 74 0D 54 65 78 74 0D 54 65 78 74 0D 
 0FA8h: -------------------------------------------------------------

 ====================================================================
 [DFF_PST_StyleTextPropAtom]
 (type: 0FA1h inst: 0000h, vers: 0000h, start: 65, size: 22)
 ====================================================================

 0FA1h: -------------------------------------------------------------
 0FA1h: para props for 46 chars, indent: 0
 0FA1h: para prop given: para linespacing 80
 0FA1h: -------------------------------------------------------------
 0FA1h: char props for 46 chars
 0FA1h: char prop given: char font size 30
 0FA1h: -------------------------------------------------------------
 0FA1h: -------------------------------------------------------------
 0FA1h: 2E 00 00 00 00 00 00 10 00 00 50 00 2E 00 00 00 
 0FA1h: 00 00 02 00 1E 00 
 0FA1h: -------------------------------------------------------------

 ====================================================================
 [DFF_PST_TextSpecInfoAtom]
 (type: 0FAAh inst: 0000h, vers: 0000h, start: 95, size: 24)
 ====================================================================

 0FAAh: -------------------------------------------------------------
 0FAAh: 2D 00 00 00 01 00 00 00 00 00 01 00 00 00 07 00 
 0FAAh: 00 00 00 00 09 08 00 00 
 0FAAh: -------------------------------------------------------------

[...]

Kudos to Kohei for his great work on xls_dump, of which I reused the structure and most importantly the biff record parsing. I’m not aware of anything like ppt-dump.py, but would of course be interested if there is.

Other than that, here’s a brief list of other FLOSS tools for MSO binary document handling I’m aware of (besides OOo, of course):

Update: merge with xls_dump done, adapted viewvc links

So, as seemingly the Mac users currently miss all the nice Go-Oo features, I put up 3.0 RC4 Intel builds here. A word of warning, though: in comparison to Linux & Windows, the Mac version of Go-Oo has not yet received broad testing, so please consider this version unstable. Any feedback greatly appreciated – and if you want localized UI, there are language packs alongside the RC4 package (e.g. for the fr or de locale).

Just in case you want to try a build yourself: the wiki has a howto.

The following statement from one of the OpenOffice.org project leads set me off this morning:


It’s clear that the re-usability of OOo code in other projects isn’t in our focus. I hope it’s understandable that our main interest is the success of OOo as an end user application. It may be even a bit short-sighted, I don’t know. But that’s as it is.

When I look at the OOo universe, it’s reminiscent of a ghetto – we live in our own world, with everything different from the rest of the FLOSS town: own build system (even with the luxury of our own make utility), own operating system abstraction (sal, osl, rtl, vcl), own configuration system, own string classes (oh, actually, two of them), own component model (UNO), etc. ad infinitum. There were good reasons to implement those back in the day, with OOo being one of the very few truly cross-platform applications.

But the world has changed, and instead of OOo promoting their libs to the rest of the FLOSS world, investing some amount of time & effort in separating e.g. UNO out of OOo and making it easily usable for others (saying that URE is such an independent package is a joke), that outside FLOSS world set the standards for those portable core libs (glib, cairo, fontconfig, dbus, etc.) – because they did succeed in encouraging other people to use their code. It’s not that other projects will come and invest time to mine for reusable code – developers don’t work that way, they require a decent amount of readiness, comfort, and conformance with de-facto standards (and active lobbying, sometimes), before they use it. With this myopic focus on the shipped product (disregarding the value that lies in OOo’s core libs), we missed quite some chance to firmly embed OOo core technology at the heart of other FLOSS projects (that would, I conjecture, have created win-win situations, in sharing the load of maintenance, and also dragging devs into other parts of OOo – and the project has failed miserably to attract developers outside a very limited set of corporate contributors. When compared to e.g. the Linux kernel).

It’s high time then, to challenge this limited vision of OOo as only an end-user application. In fact, the source tree is a gold-mine of excellent technology, that we can be proud of, and that really deserves to be used outside of the core OOo project. And to actually walk my talk, I’ve just put out an independent copy of the basegfx graphic core library to gitorious.org, that should build & run on anything that has the usual ./configure; make; make install working.

That’s because, if we fail at that – if we don’t get more developers (directly, or indirectly by contributing to spin-off libs) working on the code, what will become of OOo in, say, five or ten years from now (cue vastly different UI concepts here, large software packages running on mobile phones etc.)? Think about what’s the true value of OOo – those parts that set it apart from other, similar text processing/spreadsheet/presentation packages. Is it the dialogs, the toolkit, interactions or the packaging? Or rather the filters, ODF, the application cores, UNO? Personally, I’d love to see those jewels survive the test of time, and the challenge web-based & mobile computing poses.

And no, I don’t believe just taking OOo as-is, and putting it onto a server in headless mode, makes the project appealing to anybody – it’s a stop-gap solution, and as soon as light-weight, stable, threadable alternatives appear, people will flock over to them. Instead, my vision of OOo is more that of a document processing toolkit, with webkit possibly the role model of the kind of “engine” I have in mind – portable, easily pluggable, widely used (both hardware- and software-wise).

Having a video in your Impress slideshow is nice, not being able to control start, stop or pause during your talk is sometimes just an annoyance. I recently got around fixing that, and put up a little screencast (ogg video, see here for a list of players) that should give you an idea what’s possible now (stuff as usual available in recent go-oo builds).

Note: the used video is Big Buck Bunny, copyright Blender Foundation | www.bigbuckbunny.org, and licensed under Creative Commons Attribution 3.0.

Being honoured with having a session at the OpenSuSE Helping Hands, I faced the problem of creating a screencast under Linux. Considering the load of vnc-based solutions inherently un-sexy, I tried istanbul and recordmydesktop – with the latter appealing to my knack for command-line utils (an extra requirement was no-hassles support for the very nice USB headset MMX2, which recordmydesktop’s “-device” option solved quite nicely).

So without further ado, here’s the recordmydesktop v0.3.7.3 cmd line I used:

recordmydesktop -delay 2 -device hw:1,0 --on-the-fly-encoding -s_quality 1 -width 1024 -height 768 --quick-subsampling --overwrite -o "path_to_ogg_file"

Of course the device option can either be ommitted, or needs to be adapted, depending on your local alsa setup. Recording starts after two seconds, when you’re done with your ramblings, press Alt-Ctrl-S. Some results of me doing screencasts can be found here.

Wow. Hub just pointed me at one of the recent GCC developer summit’s talks (also quite interesting: coding rule checking and incremental compilation, which goes along nicely with gold‘s (not-yet-implemented) incremental linking), which presents a static c++ code analysis framework, implemented on top of GCC (I mentioned some previous attempts at that before).

Derivatives:

Hopefully the days of rebuilding all of OOo, just to find all places an overloaded member was called, are finally gone…

With some 7 million lines of code (depending on how you count it), mostly c++, OOo is extremely challenging for everybody starting to hack on it. There’s a set of excellent tutorials on building, debugging & hacking on OOo – alas, and the end of the day, smooth coding requires thorough understanding of the inner workings and functional dependencies – in short, the design of OOo. I guess that’s where our documentation story is still lacking (with some notable exceptions, e.g. the API developer’s guide, or the UNO subsystem documentation). The problem with good (design) documentation is that it’s

  • hard to write
  • tedious to keep up-to-date (in fact, I believe most static source code documentation is always at least partially outdated)

To somewhat fill this gap (and avoid the staleness issue), I’ve setup doxygen-autogenerated source code documentation at go-oo. As of now, this is only a partial set of modules (because of runtime and space constraints) – feel free to drop me a note if your favorite module is missing.

Two examples for auto-generated inheritance graphs: