Skip navigation

Category Archives:

Been at the mentor summit for the first time, and it was even exceeding my high expectations. Awe-some. If there’s another event that pulls together so many friendly high-profile FLOSS people, I’d like to know immediately.

Group Photo - everyone including photographers

Many kudos to Google for the event, and warthog9 for the nice group pic!


With the mentor summit coming up, it’s high time to wrap up this year’s Google Summer of Code for ooo-build. We started the term with 6 students, of which one was sadly missing in action right from the beginning (to set the record straight, he returned all funds).

All participants initially had to fight with OOo’s inherent complexity; I can only stress the importance of getting used to build system, installation & debugging peculiarities before the actual coding starts.

Progress until midterm was good to excellent, except for one case, where we had to make the very hard decision whether to continue with a student showing insufficient results – in the end, the agreement was to drop him, pretty much according to all best practices and lessons learned from other organisations. What I find most encouraging, and open-minded, is the fact that he’s now returning to OOo, and even bringing a few other students from his university for a joint project. Welcome back, Jon!

Which leaves us with a total of four completed projects:

  • Cross-building OOo for win32 (Jesus Corrius, the code (basically all crosswin32-prefixed patches))
  • Impress slide layout rework (Dona Hertel, the code)
  • Writer document comparison (Tzvetelina Tzeneva, the code)
  • Writer document navigation buttons (Maja Djordjevic, the code)

For the last two, let me just reference Tzvetelina’s and Maja’s respective blog postings; I couldn’t possibly explain and advertise it better.

The idea for the cross-building stems from the fact that compiling OOo on win32 is dog slow. With OOo consisting of some 90% c++, compilation is highly i/o-intensive, with an access pattern that apparently makes the Linux buffer cache shine, and the Windows one fall flat on its face. Additionally, of course you’d free people from buying and relying on proprietary software. Additionally, having something cross-buildable usually makes a project’s build system cleaner and more orthogonal.

With the Impress slide layout project, the aim was to get rid of the many hard-coded places where slide layout kinds were handled, following the paradigm of having pure data – the general layout – in a data structure, and not implicitely in code. Of course, an extra benefit is that changing or adding layouts now no longer needs re-compilation of OOo. Specifically, Impress now loads an autolayout configuration file on startup, and exposes the necessary data structures via OOo’s component model to the lower-level subsystems, for import and export.

This was my second GSoC term as a mentor, and my first one as an organisation admin. I’m more than happy with the results; our students did really well, and I hope we’ll see continued contribution from them over time. I also wish to thank my fellow mentors for their time and enthusiasm, and of course Google for making all of this possible in the first place!


Finally, there’ll be a panel presentation of the GSoC results at the annual conference; we’ll hopefully manage to get most of the students and mentors there. Will keep you posted.

The motivations and actual demographic groups the result’s responders recruited themselves from set aside: 53% pro UI-overhaul seems to be pretty low; at least this would make keeping the old UI optionally available a priority for me (and not an afterthought).

As mentioned by several, last week saw Novell’s HackWeek IV. I had two important vectors along which I wanted to advance, namely bringing slideshow a bit closer to using the new drawinglayer primitives, and improving on the built-in testing facilities in ooo-build.

I started with doing an inventory of things to do for the slideshow upgrade, a pleasant surprise was the fact that Armin already provides a factory for retrieving XPrimitive2D for a given Impress XShape – so technically, the slideshow can retrieve all that’s necessary via pure UNO. Looking at the renderer implementation (that outputs XPrimitive2D on the XCanvas render substrate used in slideshow), I found a bunch of loose ends, and got side-tracked fixing those.

The first thing I actually tackled was the way canvas implements gradients (I seem to develop a knack for those recently). The initial interface for those was rather rigid, and to add insult to injury, extremely tied to ODF’s weird gradient definitions. So I changed the XParametricPolyPolygon2DFactory into a generic XMultiServiceFactory instead, that takes the following parameters:

   Gradients - all gradients need to support two construction
   parameters, "Colors" being a sequence of a sequence of doubles
   and "Stops" being a sequence of doubles. Both must
   have the same length, and at least two elements. See for
   the semantics of gradient stops and colors.
   Required gradient services:

   * "LinearGradient" - the gradient varies linearly between
     the given colors. without coordinate system
     transformation, the color interpolation happens in
     increasing x direction, and is constant in y
     direction. Equivalent to svg linear gradient

   * "EllipticalGradient" - this gradient has zeroth color
     index in the middle, and varies linearly between center
     and final color. The services takes an additional
     parameter named "AspectRatio" of double
     (width divided by height), if this aspect ratio is 1, the
     gradient is circular. If it's not 1, the gradient is
     elliptical, with the special twist that the aspect ratio
     is maintained also for the center color: the gradient will
     not collapse into a single point, but become a line of
     center color. If "AspectRatio" is missing, or equal to 1,
     this gradient yields similar results as the svg radial

   * "RectangularGradient" - this gradient has zeroth color
     index in the middle, and varies linearly between center
     and final color via rectangular boxes
     around the center point. The services takes an additional
     parameter named "AspectRatio" of double
     (width divided by height), if this aspect ratio is 1, the
     gradient is quadratic. If it's not 1, the gradient is
     rectangular, with the special twist that the aspect ratio
     is maintained also for the center color: the gradient will
     not collapse into a single point, but become a line of
     center color.

Further massaging the code to share the same gradient texture transformation setup across drawinglayer, canvas, and cppcanvas module, this not only finally gave a nicely uniform rendering of gradients (especially the canvas had some glitches before, with one or the other canvas implementation even missing a gradient type), but also much cleaner code (in terms of comprehensibility, and in terms of implicit duplication of functionality). Final patch has 1237 insertions(+), 1016 deletions(-), containing new functionality (see below) plus substantial commentary (amounting, in total, to about 150 lines). Which gets me quite close to one of my unstated goals of getting less code with more features, when doing refactoring. 😉

Kudos to Armin btw. for abstracting away the legacy gradients pixel-by-pixel into the usual matrix plus texture function concept!

If you’ve read closely the parameter description for the new gradient factory, you’ve noticed that svg gradients are already fully covered by the canvas now (the little twist is to omit the AspectRatio parameter, and instead scale the gradient anisotrophically via the texture transform, to get the normal svg way of isobare gradient rasterization). Possibly one of the next useful additions would be an optional color transformation function, like the sigmoidal gradient that’s often used in MSO docs – with that, we should get fairly close to implementing the superset of all relevant gradient concepts in office land (well, still missing gdiplus-like path gradient, but that’s rather arcane and seldomly used))

‘Nuff said, in the end, I used most of the week on this gradient rework, but it was time well spent. I used Friday to hack up slideshow to use the primitive renderer for XShapes, which actually works, but of course needs much more changes to e.g. properly support attribute animations (like changing fill color, font size etc.). Full patch is here and here. The more relevant achievement of Friday was the addition of ~convenient convwatch support in ooo-build:

On a known-good version, do this (ooconvwatch is here):

   "cd ooo-build/build/install/program; source ooenv; ooconvwatch -c \
    -d path_to_testdocs"


When ooconvwatch finally returns, rebuild with your dubious patches, then:

   "cd ooo-build/build/install/program; source ooenv; ooconvwatch \
    -d path_to_testdocs"

Check /tmp/allfiles.txt for list of docs processed, check /tmp/_filename_.prn.diff.jpg for the graphical diffs.

Todo: collect sensible set of test docs. Throwing huge amounts of random docs at this is a waste. I’m pretty sure I can put everything that will possibly break on a handful of Impress pages. Times the number of odf/sxi/ppt/pptx format versions, and one still has a smallish number. Explore the database usage of convwatch – someone willing to share a description of that feature?

Update: in case it’s not painstakingly obvious, the set of test docs of course will not be closed; instead, after each regression not found by convwatch, it needs to be updated to henceforth catch the problem (referring to the “I have a good idea about what will possibly break in Impress”). 😉

Part of ooo-build since early June, and now on the way to 3.2 for vanilla. Just a few pictures that should tell the story, starting with the state of affairs up to and including OOo 3.1:


The competition:


After the fix:


The differences are a bit subtle when looked at on this scale, but quite annoying when encountered by someone who designs her presentations with an eye for details. Especially the way sub-shapes were gradient-filled before, like the top end of the can or the eyes of the smiley. Kudos to haui btw. for the very nice hack to make OOo believe a sub-shape actually has the same bounding box as the main shape. Here’s the patch for those interested in the gory details.

While working on the rulers fix, Christian pointed out that, with my fix, using rulers on a numbered list of paragraphs totally kills the numbering – because of the way I have to change the outline-defining entities (I pointed out that their atomicity is a real problem). So, this is what you get when changing the outline control item in the middle of a numbered list of paragraphs:


That is, changing any attribute, even the color of the number, restarts numbering in Impress (notice the double occurence of the colored "a)"). While when changing indentation, this might be acceptable, the behaviour with color is clearly non-intuitive, and also likely a fall-out of the list level fixes. Let’s look at the competition:


Somewhat different – changing outline attributes don’t affect numbering. I initially thought a bit about the indentation issue, as you can find arguments for both ways; ultimately though, deviating from MSO for no extremely good reason is something we usually avoid in OOo-land; and incidentally there’s a good reason for the way PowerPoint is doing it: indentation, font, coloring, numbering scheme, etc. is just formatting. The only thing I would consider content is the outline level, i.e. the depth of the nesting (of the numbered paragraphs), on the document level.

So with the golden rule that content is king and formatting is nothing, I went and boldly changed the way numbering is done in ooo-build, namely that only the outline level determines the counting (of course, unnumbered and bulleted paragraphs inbetween still restart the numbering):


Dear LazyWeb, feedback about which behaviour you find more usable (and less surprising) much appreciated.

With the substantial changes in OOo 3.0 regarding list levels (that have caused a bit of trouble elsewhere), Impress seemed to be going along quite nicely, except for the issues when converting between ODF1.1 and tentative-ODF-1.2 documents.


But then along came someone who was using the rulers in Impress (which are disabled by default – you get them inside the “View” menu), complained about extensive brokenness, and I started to have a deeper look:

blog-sample-1-ooold-indented blog-sample-1-ooo-indented

The left image shows status quo (red line showing position of the ruler controls), note that the cursor is inside the last, most indented paragraph. The right image shows the behaviour as it was before 3.0 (the strong black lines added, to better visualize ruler control position). Moving those ruler controls then gives this:

blog-sample-1-ooold-indented blog-sample-1-ooo-indented

Again, left side new, right side old behaviour. Apparently now, the ruler controls only add an offset to the already existing indentation of the outline, whereas before, they directly controlled bullet position and left margin of the text. What’s more, the lower control does not change text left margin, but first line indent – something just utterly useless in a presentation outline. Not exactly an improvement in usability, in my not so humble opinion. This is now fixed in ooo-build master.

That said, the fix has a tiny little fly in the ointment: changing the bullet/text distance needs to modify the entity that determines the whole bullet/numbering appearance (the SvxNumBulletItem, sadly therefore only atomically modifiable – a decision that might need re-assessment), which in turn leads to an outline format that will no longer adhere to e.g. changes in the master page styles. This is no different when changing said distance in an unfixed vanilla OOo, via the Bullets & Numbering dialog; and clearly a lot less annoying than the ruler behaviour there – but it still warrants mentioning, I guess.

Following the original announcement, more than 70 students applied to the Go OpenOffice project for the Google Summer of Code. I was truely impressed, and want to say “thank you!” to all that took the sometimes considerable effort to write a good application.


Choosing six projects among those many was not easy; but I think the collective mentors did an outstanding job selecting both excellent students and relevant tasks – so I’m happy to announce this year’s Go OpenOffice GSoC participants (in order of their last name):

Andrés Correa Casablanca will work on performance improvements

Jesús Corrius will have Win32 OOo cross-compile under Linux

Maja Djordjevic will add Hyperlink/Reference navigation buttons

Dona Hertel will extend the functionality of the templates in Impress

Tzvetelina Tzeneva will improve OOo Writer’s document comparison

Jonathan Winandy will add an Ocropus OCR integration to OOo

Yay to the successful applicants!

To all those who applied, but have not been selected: the competition was fierce, I can assure you, so don’t be put off, try again next year – and maybe give yourself this extra bit of a head start and continue working on OOo! We’ll always and happily mentor you, if you’re enthusiastic and willing to learn – just come and ask us, you already know where!

That only leaves me to thank Google for sponsoring us; thanks to all who applied, thanks to the mentors – without you folks, all of this just won’t happen! Looking forward to a wonderful summer 2009!

With the recent survey about the community’s favorite distributed software configuration management system completed, the Engineering Steering Committee went into debating the candidate system’s merits. Since there was a draw between mercurial and git (which of course counts double because of extra coolness), the ESC came to this very Solomonian decision: proportional to vote turn-out and coolness coherency, the OOo source tree will be split into four different repositories, each hosted by the respective DSCM prospect, in the following way:

dscm hg (with 49%) gets 48% of code:
 helpcontent2 officecfg binfilter sd ooo_custom_images sysui chart2 
 wizards instsetoo_native framework odk icu writerfilter dmake psprint_config
 redland toolkit scripting xpdf bitstream_vera_fonts libxml2 basctl openssl 
 lotuswordpro libxslt stoc fpicker cppu comphelper accessibility uui basegfx 
 package rsc external rhino xmlhelp ucbhelper cppcanvas crashrep registry soltools
 lingucomponent hwpfilter jvmfwk lpsolve io basebmp sax hyphen embedserv 
 pyuno writerperfect i18nutil xml2cmp libwps remotebridges rdbmaker jut 
 postprocess sccomp twain offuh fileaccess MathMLDTD

dscm none (with 25%) gets 24% of code:
 svx sw dictionaries offapi dbaccess vcl sal xmerge vigra desktop xmloff scaddins 
 cairo scp2 jfreereport solenv readlicense_oo autodoc ucb bridges tools stlport 
 hsqldb canvas setup_native psprint shell saxon reportbuilder jurt cppuhelper dtrans
 swext codemaker curl testtools scsolver xmlscript javaunohelper sot ridljar 
 external_images icc idlc testshl2 hunspell beanshell idl jpeg UnoControls unoil 
 mdbtools epm regexp salhelper libwpg jvmaccess ure animations expat fondu 
 unixODBC x11_extensions eventattacher sane

dscm git (with 23%) gets 22% of code:
 sc qadevOOo default_images svtools boost sfx2 extensions filter i18npool
 connectivity oovbaapi sdext basic python starmath reportdesign configmgr
 oox forms xmlsecurity lucene goodies tomcat slideshow apache-commons 
 udkapi padmin berkeleydb libxmlsec javainstaller2 agg transex3 cli_ure
 config_office automation unotools embeddedobj avmedia libwpd moz linguistic
 store libtextcat unoxml neon bean cppunit cosv Mesa sj2 smoketestoo_native
 sandbox vos unodevtools udm afms cpputools np_sdk zlib o3tl msfontextract
 stax libegg packimages agfa_monotype_fonts

dscm bzr (with 3%) gets 4% of code:

Where the people that did not prefer any DSCM will get what they asked for, namely no DSCM at all: those modules will stay with subversion (the proposal to not even host them in any SCM, but simply hold one version on a file server, did not get a majority vote).

We’ve been selected to be part of this year’s awesome GSoC, so all of you OOo-affine students out there, start thinking about the cool projects you want to do during summer!


Should you be new to OOo and not having any immediate idea what to do, fear not, here’s a list of ideas to pick from (just be aware that many of those are initial vectors to put you into the right direction, and fleshing them out would be part of your task; we’ll of course help with that).

Similarly, if you’re an established OOo hacker, willing to mentor and/or miss your favourite idea, help the project and add your name and idea to the proposals page. GSoC is a wonderful opportunity to get people involved with OOo, don’t miss out to get smart students working on your code!

Student application period starts on March 23rd, we’re looking forward to your applications!