The Document Foundation Planet


February 27, 2015

Miklos Vajna

Tiled editing: from input handling to selections

In from a living document to input handling, I wrote about how we handle touch and on-screen keyboard events in the LibreOffice Android app. A next step in this TDF-funded project is to provide more UI elements which are specific to touch devices: selections is one of them.

Here are the problems we had to solve to get this working:

  • Long push is not an event core would recognize.

  • If you use the mouse and have a selection in Writer, it’s only possible to extend the end of it. If you use the keyboard, then it’s possible to shrink the end of it, but still no adjustment of the start. On touch devices, it’s natural to have selection handles at the start and end of the selection and be able to adjust both, in both directions.

  • Additionally, when the user drags the selection handles, the expected behavior is that the position of the selection and the handle are never the same: the handle is placed below the selection position and when you drag the handle, the new selection position is above the handle… ;-)

Long push is reasonable to map to double mouse click, as in both cases e.g. in Writer the user expects to have a select word action. But for the adjustment of selections, we really had to define a new API (lok::Document::setTextSelection()) to allow setting the start or end of the selection to a new logical (in document coordinates, not paragraph / character indexes) point.

If you are interested how this looks like, here is a demo:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>

An other direction we’re working towards is to have the same features in other applications as well: Impress and Calc. Perhaps not so surprisingly, we hit similar problems in these applications as well that we had to solve in Writer. The typical problems are:

  • LibreOffice assumes a given portion of the document is visible (visual area), but the Android view is independent from what LO thinks is visible. Example: LO thinks a table is not visible, so it doesn’t send the selection events for the text inside the table, even if it’s in fact visible on the Android app.

  • Instead of calling Invalidate() and waiting for a timer to call Paint(), at some places direct Paint() is performed, so the tile invalidation notification triggered by Invalidate() is missing → lack of content on Android.

  • We render each tile into a VirtualDevice — kind of an off-screen rendering  — and at some places LO assumed that certain content like the actively edited shape’s text is not interesting, as it’s not interesting "during printing".

  • LO’s mouse events are in pixels, and then this is translated to mm100 (hunderd of milimeters) or twips in core. So counting in pixels is the common language, while the Android app counts everything in twips, and doesn’t want to care about what would be visible at what pixel on the screen, if LO would run in desktop mode. So we had to make sure that we can pass in event coordinates in twips, and get invalidation coordinates in twips, even if previously it was a mix of mm100, twips and pixels.

Here is how Impress looks like, with working tile invalidation, touch and keyboard handling:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>

Calc is lagging a bit behind, but it also has working tile invalidation and keyboard handling:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>

That’s it for now — as usual the commits of me and Tomaž Vajngerl are in master (a few of them is only in feature/tiled-editing for now), so you can try this right now, or wait till the next Tuesday and get the Android daily build. :-)

February 27, 2015 11:14 AM

February 26, 2015

Official TDF Blog

LibreOffice 4.4.1 “Fresh” is available for download

Berlin, February 26, 2015 – The Document Foundation announces LibreOffice 4.4.1, the first minor release of LibreOffice 4.4 “fresh” family, with over 100 fixes over LibreOffice 4.4.0. The release represents the combined effort of the over 900 developers attracted by the project since September 2010, with at least three new developers joining the project each month for 60 months in a row.

New features introduced by the LibreOffice 4.4 family are listed on this web page:

The Document Foundation suggests to deploy LibreOffice in enterprises and large organizations when backed by professional support by certified people (a list is available at:

People interested in technical details about the release can access the change log here: (fixed in RC1) and (fixed in RC2).

Download LibreOffice

LibreOffice 4.4.1 and LibreOffice 4.3.6 are immediately available for download from the following link: LibreOffice users, free software advocates and community members can support The Document Foundation with a donation at Money collected will be used to grow the infrastructure, and support marketing activities to increase the awareness of the project, both at global and local level.

by italovignoli at February 26, 2015 11:59 AM

Collabora Community

Collabora Productivity awarded Best UK Open Source Organisation

Collabora Productivity has been named Best Organisation at the UK Open Source Awards 2015. The award, presented By Software Freedom Conservancy Executive Director Karen Sandler on Wednesday in Edinburgh, was made for ground-breaking work on LibreOffice in 2014.

“This is a time of unprecedented change for British Open Source companies, and growth that’s long overdue” said Collabora Vice President Michael Meeks in his acceptance speech. “The productivity space in particular is due for a shake up, and Open Source will provide it”.

Collabora was chosen over three other shortlisted entrants. These included IMS MAXIMS, a comprehensive Electronic Health Record system used extensively by the NHS, and non-profit Open Source startup Matrix, a recent competitor to Google’s WebRTC. Organisers announced a record number of candidates this year, with a 40% increase on 2014.

“Recent Government policy changes are stimulating demand for Open Source services and development” said Greg Soper, Event Manager of the Open Source Awards. “Global trends towards service-based business models, combined with increasing pressure for value returns, are providing unparalleled opportunities for Britain’s Open Source businesses”.

Via its flagship product, LibreOffice-From-Collabora, the company last year extended LibreOffice support for Microsoft OOXML format, bringing crucial interoperability improvements; added support for legally valid digital signatures to PDF documents, and introduced OpenCL computation, resulting in hardware acceleration and a major performance boost on modern devices. Engineers also did extensive work on LibreOffice for Android, releasing the first in a series of products, LibreOffice Viewer for Android, early this year.

About Collabora Productivity:
Collabora Productivity delivers LibreOffice products and consulting to the enterprise. With the largest team of certified LibreOffice engineers, it is a leading contributor to the LibreOffice code base and community. LibreOffice-from-Collabora provides a business-hardened office suite with long term multi-platform support. Collabora Productivity is a division of Collabora Ltd., the global software consultancy specializing in providing the benefits of Open Source to the commercial world, specialising in mobile, automotive and consumer electronics industries, counting Samsung, Intel, and Google among its former clients.

by Sam Tuke at February 26, 2015 11:31 AM

February 25, 2015

Michael Meeks

2015-02-25 Wednesday

  • Up early, quick mail chew; set off for Cambridge; into the office to see Tracie; read a great report. Train on to Edinburgh, worked on budgets. Extraordinarily frustrating experience with intermittent connectivity and Evolution on the train for some hours.
  • Enjoyed some of the talks at the Open Source Awards, and a great meal mid-stream.
  • Extraordinarily honoured to recieve from Karen Sandler, on behalf of Collabora Productivity, the UK Open Source Awards 2015 - Best Organisation; gave a small acceptance spiel:
    • It is an honour: in a Cloud obsessed world to have a Commodity Client Software company represented. In a world obsessed by Tablets: to encourage Free Software that makes your PC/Mac keyboard really useful. Naturally, we do have a Tablet & phone version making good progress now (for the paper-haters).
    • LibreOffice 80+ million users: more than the UK's population. A brief correction - Collabora is only the 2nd largest contributor to the code - the 1st is volunteers in whose debt we all are. Everything we produce is Free Software.
    • Collabora - has a mission we believe in: To make Open Source rock (ono). We're betting our Productivity subsidiary on ODF and LibreOffice.
    • We're here to kill the old reasons not to deploy Free Software: with long term maintenance for three to five years; rich support options - backing our partner/resellers with a fast code-fix capability; and finally killing complaints - we can implement any feature, fix any bug, and integrate with any Line Of Business app for you.
    • In the productivity space - innovation is long overdue; Free Software can provide that. Thanks for coming & your support

February 25, 2015 09:00 PM

Charles Schulz

Badges for LibreOffice

The LibreOffice project relies almost entirely on volunteers to work, from running our infrastructure to developing our software suite. It is faire to say we take -or try to take – our community very seriously. If I needed any more proof of this, the first months as a member of the Membership Committee of the Document Foundation offered me the opportunity to review membership applications and try to understand both how people contribute and why they are attracted to LibreOffice, even when they’re not contributors.

Part of what I have noticed along with other people (in and out the membership committee) is that while we always supported fluid and transparent team work inside our community, many people, especially ones with non-code contributions tend to feel confused by what it means to be a member of the Document Foundation, and how we value contributions. Sure, they see their contribubadges_example_fastcompanytions are valued, and they feel they’re part of a great team, but how they are recognized and their work ackowledged, aside credits, seems to be a bit blurry.

I cannot quite recall who coined the idea first, but somehow the possibility of using web badges started to float around. Of course badges are not new; online forums have been using them for years; in the past few years however, projects like the OpenBadges initiative from the Mozilla Foundation have taken the concept of badges much beyond the display of “experience points” of forum members.

Badges may seem a simple concept; perhaps a too simple one. But they may help our contributors who do not contribute by sending several patches a week or a month as these ones do not need better tracking. Badges can help in two ways:

  1. Measuring their online activity: we’re not spying on them of course. But let’s take the case of an active contributor with zero experience in development (and no will to learn), who helps in the many other ways: Yesterday, she helped with translating one of our users’guides. Today she helped users on Ask LibreOffice or on one of our mailing lists dedicated to users support. Tomorrow this same contributor will help cleaning the wiki pages in her native languages. Somehow, all this leaves logs, traces; but we have noticed that this kind of contributions is not felt by the same contributors as something worth reporting, explaining, or even something used to apply for membership to the Document Foundation. But these are very real contributions that should be valued. Badges can automatically keep track of these kind of activities. It creates visibility for the Membership Community, the community itself and just as importantly….
  2. … it creates visibility and a sense of validation for the contributor herself. Badges are carried around for a reason. They convey the achievements of the contributor; they are a way to thank the contributor and at the same time give a rather clear sign of the skills of the person people are engaging with.

There are downsides to these badges of course. They’re not set up that easily: remember that besides basic scenarios (i.e. a badge for every TDF member) one has to ensure the badges are “plugged” into each data source that is necessary and relevant to award a badge. On the other end of that process, different badges must be designed for each kind of category we envisioned: users’ support is one thing, but documentation writer or QA volunteer are very different jobs. Besides that, we need to get these “jobs” right, otherwise we may end up forgetting about some of them. It would involve some design to make them look nice. And of course, we need to make sure the attribution process is both simple and flawless.

In the end, I truly think that badges are a good idea and a net positive for the community; but the execution is much more complex that the term “badge” suggests. We need to mature details on how to deliver a workable system for this, and it may still take some time if we decide to move forward with this idea. You are welcome to continue the conversation on RedMine or on our discuss mailing list. Hopefully, we will improve the way our contributors participate to the LibreOffice project and its overall efficiency with the same tool!

by Charles at February 25, 2015 03:33 PM

Stephan Bergmann

On filling a vector

In C++11, what is the cheapest way to create a std::vector<T> with a bunch of statically known T elements (in terms of the number of special member functions of T invoked)?

In other words, which of the blocks in the below program produces the fewest lines of output:

#include <iostream>
#include <vector>
struct S {
    S() { std::cout << " default ctor\n"; }
    S(int) { std::cout << " int ctor\n"; }
    S(S const &) { std::cout << " copy ctor\n"; }
    S(S &&) { std::cout << " move ctor\n"; }
    ~S() { std::cout << " dtor\n"; }
    void operator =(S const &) { std::cout << " copy assignment\n"; }
    void operator =(S &&) { std::cout << " move assignment\n"; }
int main() {
        std::cout << "A1:\n";
        std::vector<S> s { S(), S(), S() };
        std::cout << "A2:\n";
        std::vector<S> s { {}, {}, {} };
        std::cout << "A3:\n";
        std::vector<S> s { 0, 0, 0 };
        std::cout << "B1:\n";
        std::vector<S> s;
        std::cout << "B2:\n";
        std::vector<S> s;
        std::cout << "B3:\n";
        std::vector<S> s;
        std::cout << "C1:\n";
        std::vector<S> s;
    // {
    //  std::cout << "C2:\n";
    //  std::vector<S> s;
    //  s.reserve(3);
    //  s.emplace_back({});
    //  s.emplace_back({});
    //  s.emplace_back({});
    // }
        std::cout << "C3:\n";
        std::vector<S> s;

(Of course, each block needs at least three “dtor” lines when its s goes out of scope, so keep those out of the count.)

What might come as a surprise is that the A variants using an initializer list, though short and sweet, are rather heavy: Each one needs three constructors for the three elements of the initializer list (“default ctor” for A1 and A2, “int ctor” for A3), three copy constructors to copy the elements from the initializer list into the vector, and three destructors when destroying the initializer list. Nine calls to special member functions overall.

That is just as expensive as the B variants. (The difference being the order in which the special member functions are called for the individual elements.) However, the advantage of all three B variants is that they use the move constructor instead of the copy constructor to pass the temporary S instances into the vector.

(If you had hoped that the A variants would use the move constructors instead of the copy constructors, too: that does not work, as initializer lists only offer const access to their members.)

Variant C1 is not any different from variant B1. Still nine calls overall (employing the move constructor).

Variant C3, finally, is better: Although it looks more expensive to pass “wrong” int arguments that first need to be converted into proper S instances, the big benefit here is that those “int ctor” calls can directly instantiate the vector elements—no construction of temporary S instances, no copy or move constructors, no destruction of temporaries. Just three constructor calls overall.

(And variant C2 is commented out for good reason; there is just no way to tell emplace_back to instantiate an element directly into the vector through a default constructor call. But then again, most of the time what you want to put into the vector are not default-constructed elements, anyway.)

by stbergmann at February 25, 2015 10:58 AM

Kohei Yoshida

Orcus 0.7.1 is out

After more than a year since the release of 0.7.0, I’m once again very happy to announce that the version 0.7.1 of the Orcus library is now available for download. You can download the package from the project’s download page.

This is a maintenance release. It primarily includes bug fixes and build fixes since the 0.7.0 release with no new features. That said, the most notable aspect of this release is that it is buildable with the version 0.9.0 of the Ixion library which was just released a week ago. So, if you are trying to package and distribute the newly-released Ixion library but are unable to do so because of Orcus not being buildable with it, you might be interested in this release.

The next major upgrade will be 0.9.0 whose development is on-going on the current master branch. Hopefully that release won’t be too far away.

by Kohei Yoshida at February 25, 2015 12:56 AM

February 24, 2015

Andreas Mantke

LibreOffice und der Minijob-Rechner

Die Minijob-Zentrale mit Sitz in Bochum (Deutsche Rentenversicherung Knappschaft Bahn See) stellt auf Ihren Seiten einen Minijob-Rechner im Dateiformat xls zur Verfügung. Diese Datei enthält Macros.

Die Datei kann mt LibreOffice 4.4 und 4.3 geöffnet werden. Da sie Makros enthält, wird beim Öffnen eine Warnung angezeigt. Die Standardeinstellung bezüglich Ausführen von Makros ist bei LibreOffice hoch, um den Benutzer vor Gefahren insoweit zu schützen. Dies kann im Menü Extras – Optionen – Sicherheit umgestellt werden, ist allerdings zur Ausführung der in der Datei hinterlegten Rechenfunktionen nicht erforderlich.

Allein die Drucken-Schaltfläche im unteren Bereich der Tabellenformulare funktioniert nicht. Dies ist aber verzichtbar, da die Tabellen über die Druckfunktion von LibreOffice selbst ausgedruckt werden können. Die Minijob-Rechner-Datei im Dateiformat xls lässt sich somit mit der lizenzkostenfreien Bürosoftware  LibreOffice verwenden. Eine proprietäre Bürosoftware, für die nicht unerhebliche  Lizenkosten anfallen, braucht also nicht gekauft zu werden.

by andreasma at February 24, 2015 10:19 PM

Michael Meeks

2015-02-24 Tuesday

  • Mail chew, built ESC stats; mail; lunch. Customer call. Reviewed the LibreOffice 4.4 feature set to write a LXF column, rather encouraged.
  • Booked train tickets to the great Open Source Awards tomorrow in Edinburgh.

February 24, 2015 09:00 PM

User Prompt

Campaign to Better Involve Users

User Centric Development today follows a one way communication. Whenever developers need some information, they ask the users (neglecting the problem of reaching a representative sample of users here).

The other way around is much harder – users willing to contribute to a project have to use the tools that work for us, like IRC, bugtracker, forums or mailing lists. Unfortunately these tools are extremely discouraging for normal users.

We need to change this.

We do Free Software and we want and need users to actively participate in the ongoing development. It is the only way to create great products. We hence need new tools for participation, that are made for the need of normal users.

Help us to get there and sign and share the campaign to respect user rights.

by Björn Balazs at February 24, 2015 02:33 PM

Collabora Community

Latest LibreOffice Viewer for Android brings faster, smoother reading

Collabora’s LibreOffice Viewer for Android brings a major performance update in today’s release.

As part of our ongoing development of the separate LibreOffice editor app, user interface rendering has been overhauled ‘under the hood’, with the focus on faster and more accurate fetching of tiles (images which combine to form the visible Android interface).

Where scrolling complex documents used to lag, browsing is now smooth. Where occasional waiting for document sections was required, tiling now prioritises the most important sections, and renders them faster.

This work by Collabora Engineer Tomaž Vajngerl is critical for responsive editing in the LibreOffice editor project, which shares the same codebase as the Viewer application.

Today’s update is the latest of Collabora’s weekly Android updates.

Sailing image Copyright Roman Boed via Flickr.

by Sam Tuke at February 24, 2015 12:20 PM

Official TDF Blog

Tender to develop and incorporate usability metrics collection for LibreOffice (#201502-02)

The Document Foundation (TDF), the charitable entity behind the world’s leading free office suite LibreOffice, seeks for companies or individuals to

develop and incorporate usability metrics collection for LibreOffice

to start work as soon as possible.

In order to improve the user interface, human interaction and usability of LibreOffice, The Document Foundation is looking for an individual or company to, as a turnkey project, implement a usability metrics collection feature to be incorporated into the Windows, Linux and Mac OS X versions of the free office suite. The project consists of:

  1. planning and conception of features and clicks to track in close contact with our UX team, with preselection and prioritization of the features
  2. installation and configuration of a server part within TDF’s infrastructure, which is based on Mozilla’s UITelemetry (see and for further details) and defines the format for the client part
  3. a client part, that not only counts how often features have been used, but also provides further metrics; some samples of items that need tracking are
    1. the location of the click action in the menu, as sometimes duplicates exist
    2. which context menu was used
    3. whether a certain feature was invoked by a single click, by click and hold, by a drop down click or by a multi click
    4. from which application clicking on the close document/window ‘X’ (.CloseDoc) and close application ‘X’ (.Quit) occurs
    5. whether the user used the enter key, mouse click or an accelerator to open a menu item
    6. how the app was opened (via command line, start menu, start center, or by opening a document)
    7. in which toolbar a button was clicked, as some buttons are in multiple toolbars, and users can add buttons to toolbars individually
    8. which slide transitions and object animations are used most in Impress
    9. the concrete action/command sequence: which action was used by the user, and which was the next action used after that (e.g. inserting an image and then adding a caption)
    10. which menu bar keystroke sequences are used (e.g. Alt+F + O)
    11. which icon theme, font list and theme name the user has active

      Work on the client part also involves storing collected metrics data locally in the user profile with transmission to the server part when connectivity is in place.
  4. an opt-in mechanism for the client part, so users have to actively enable the feature before any data is collected and transferred

With this feature, TDF – amongst other improvements – aims to:

  • improve the menus, toolbars and the sidebar
  • show the most popular inserted special characters for use in a future drop down
  • show the most popular bullet/numbering styles for use in a future drop down

Work is to be carried out in the source code of the current master branch of LibreOffice, as available in our git repository at

Required Skills

Programming Languages

  • C++ for the LibreOffice client part
  • knowledge about Mozilla’s UITelemetry for the server part

Other Skills

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.

We exclusively use free, libre and open source (FLOSS) software for development whereever possible and the resulting work must be licensed under MPLv2.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.

The task offered is a project-based one-off, with no immediate plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Companies and individuals applying can be located anywhere in the world.

Bids on individual work packages (#1-#4) are welcome.

TDF is looking forward to receiving your applications, including your financial expectations (name the final price for the turnkey project), and the earliest date of your availability, via e-mail to Florian Effenberger at no later than April 1, 2015. You can encrypt your message via PGP/GnuPG.

Applicants who have not received feedback by April 30, 2015 should consider that their application, after careful review, could not be considered.

by Florian Effenberger at February 24, 2015 12:03 PM

February 23, 2015

Michael Meeks

2015-02-23 Monday

  • Mail chew, 1:1 calls with people, lunch. Team call, sync with Lubos, mail, hacked a little bit on gtktiledviewer wrt. zoomed in selection overlay rendering. 2nd team call.

February 23, 2015 09:00 PM

Collabora Community

ODF for cloud communication added to Government catalogue

Collabora is making it easier for the UK Public Sector to comply with Governmental Open Document Format (ODF) policy by offering interoperability services through the G-Cloud6 digital marketplace. Public bodies may now directly commission Open Standards-based solutions to incompatible proprietary formats, and gain expert assistance bridging barriers to legacy back office systems as they move documents to and from Cloud based services.

The Open Document Format (ODF) is a vital interchange format for moving documents between Cloud Services. Many Cloud-based office suites appear to have no native file format, as all data is stored remotely, accessed only via a web interface — the software implementation is concealed to end-users. Performing data-migration into and between Cloud services demands detailed understanding of import / export systems and format compatibility. Transfer between incompatible systems necessitates a data medium that includes all of a document’s rich content and formatting. As the most widely accepted Open Standard in the field, ODF is ideally suited to this task.

Open Standards are essential for interoperability and freedom of choice based on the merits of different software products and services. British procurement policy mandates the use of Open Standards to realise independence and cost efficiency and vendor independence.

Increasingly popular mobile and web-based apps have greatly expanded the options available public sector buyers. Compatibility remains a crucial necessity when deploying new and disparate systems. ODF offers sophisticated capabilities together with maximum industry uptake and support. A variety of products from competing vendors provide ODF implementations across all major mobile, workstation, and server platforms.

As contributors to the ODF standard and experts on its implementation, Collabora is delighted to have been accepted to the GCloud programme.

by Tim Eyles at February 23, 2015 02:38 PM

February 22, 2015

Michael Meeks

2015-02-22 Sunday

  • Lie-in, out to NCC - Claire preached well; back for lunch with Dean and Moulouia(?) and their fun-sized girls. Quarter practice with the babes, watched a notably terrible 'Cindy' film; tea, read stories bed.

February 22, 2015 09:00 PM

February 21, 2015

Michael Meeks

2015-02-21 Saturday

  • Up earlyish; counted the area for tiles, into Bury to order just the right kind; to Noughton Park to play with the babes. Back for lunch.
  • Spent much of the afternoon moving more cupboards from wall A (the wrong wall) to wall B (the right wall). Considered the plans to create fitted family lockers for the assorted junk that four babes produce - to match JP's version we admired in Toronto.

February 21, 2015 09:00 PM

Eike Rathke

Lenovo Superfish Komodia — Greed, Stupidity and Idiocy

Meanwhile you should have heard about the Lenovo hardware that had Superfish installed, an adware injecting software that uses an SSL hijacker SDK made by Komodia. If not then duck it.

I'd classify that as a Maximum Credible Accident (MCA) which was only possible due to greed, stupidity and idiocy.

  • Greed – Lenovo was greedy enough to deploy Superfish on its hardware, probably just for a few bugs revenue more per machine.
  • Stupidity – Superfish was stupid enough to use the Komodia SSL hijacker, just to be able to inject ads into https connections. Hopefully without knowing what they were doing, else it would had been double stupid stupidity. However, and of course they are greedy as well, because all ad sellers are.
  • Idiocy – Komodia was idiots enough to implement an SSL hijacker SDK and embed a root CA certificate in the software using it and super idiocy chose "komodia" as all private keys' password, making the certificate available to anyone and grandpa.

Extracting the certificate was fairly easy, see here for Superfish and here for other software developed with the SDK. The hit list is lead by parental control softwares.

Now, as if that wasn't enough, according to Forbes the loser behind founder of Komodia was once a programmer in Israel’s IDF’s Intelligence Core. Really? I'm not impressed.

Or wait, here's room for conspiracy theories! Let Superfish be a venture capital startup, financed by Israelis, which maybe is not that far fetched. What if the whole concept just serves the idea to spread an SSL hijacker to be able to intercept HTTPS connections and inject man-in-the-middle attacks? Sounds like a good plan? Yeah, well done, goal achieved, it couldn't be better ;-)

Lenovo shut down the servers that enable Superfish to function and provides a removal tool and instructions for the software and certificates. The list of affected models is quite extensive:

Superfish may have appeared on these models:
G Series: G410, G510, G710, G40-70, G50-70, G40-30, G50-30, G40-45, G50-45
U Series: U330P, U430P, U330Touch, U430Touch, U530Touch 
Y Series: Y430P, Y40-70, Y50-70
Z Series: Z40-75, Z50-75, Z40-70, Z50-70
S Series: S310, S410, S40-70, S415, S415Touch, S20-30, S20-30Touch
Flex Series: Flex2 14D, Flex2 15D, Flex2 14, Flex2 15, Flex2 14(BTM), Flex2 15(BTM), Flex 10
MIIX Series: MIIX2-8, MIIX2-10, MIIX2-11
YOGA Series: YOGA2Pro-13, YOGA2-13, YOGA2-11BTM, YOGA2-11HSW
E Series: E10-30
Hopefully this incident will teach Lenovo a lesson to not fiddle around with the customer too much..

by erAck (23@ at February 21, 2015 07:21 PM

Andreas Mantke

Theming of the new LibreOffice Extensions Site

I worked during the last weeks a bit on a theming product for the new LibreOffice extensions site. This theme uses the Diazo framework of Plone. It contains a static html-/css-template and a rules-file that connects the static theme with the dynamiic content of the Plone CMS.  The current status of the theme is available on Here is a screenshot of the theme connected with my local Plone development site.

Current mockup of the LibreOffice extension site theme

Current mockup of the LibreOffice extension site theme

by andreasma at February 21, 2015 10:31 AM

February 20, 2015

Official TDF Blog

The Document Foundation announces LibreOffice 4.3.6

Berlin, February 20, 2015 – The Document Foundation announces LibreOffice 4.3.6 “Still”, the sixth minor release of the LibreOffice 4.3 family, which is now the suggested version of the software for large deployments in the enterprise and conservative users. LibreOffice 4.3.6 contains over 110 bug fixes. The Document Foundation suggests to deploy LibreOffice 4.3.6 in enterprises and large organizations when backed by professional support by certified individuals (a list is available at capable of providing value added support.

People interested in technical details can find change logs for LibreOffice 4.3.6 here: (fixed in RC1) and (fixed in RC2).

Download LibreOffice

LibreOffice 4.4 “Fresh” and LibreOffice 4.3.6 “Still” are available for download from the following link: LibreOffice users, free software advocates and community members can support The Document Foundation with a donation at

by italovignoli at February 20, 2015 09:02 AM

February 19, 2015

User Prompt

Tracking changes with Libreoffice


Track changes is an essential feature that separates word processors from simple text editors. While change tracking is rather a collaboration tool, as it allows multiple users to make revisions without losing the context of the original document, it is widely used in business to get consensus on documents.

Libreoffice Writer provides this feature since the dawn of time. Change tracking according the ODF 1.2 specification involves for instance the option to add/delete/move and edit text. It also includes formatting, but not in case of templates. And when it comes to page infrastructure the competitors track much more information. Currently, there is an ongoing discussion for an updated ODF version.

Change Tracking in 4.3

Figure 1: Change tracking in 4.3

Additionally to the missing functionality the current UI has some room for improvement on the navigation part. Figure 1 shows  how the change tracking is managed currently.

Some issues with the change tracking have been accumulated over the last release cycles and have been collected along with requirements and a competitors’ analysis in the wiki. The Libreoffice UX team discussed the issues over the last weeks and wants to present a proposal which is planned to get integrated into release 4.5.


Although we do not have personas for Libreoffice the following user stories are written for the fictive user Martin.

Core functions

  • Martin wants to start and stop the change tracking to activate the functionality.
  • Martin wants to be able to add comments to changes in order to clarify the reason, for instance.
  • Martin wants to accept/reject both individual and multiple changes to deal with revisions.
  • Martin wants to protect the changes in the document from being accepted/rejected without permission.


  • Martin wants to browse through changes in order to find the next/previous item and to get an overview.
  • Martin wants to filter the changes to see only those from a particular date, author, type of action, or comment.
  • Martin wants to be able to sort changes to prioritize the list by date, page, author, or action.

Future enhancements

  • Martin wants to easily identify second level changes (the change of a change) for a threaded review.


Basic assumption of the proposal is to have a comprehensive and good-looking implementation but with the flexibility to add future enhancements. The idea is to show the changes in a listbox at the sidebar,  along with a set of toggle buttons on top to sort the list.

If the threaded review comes true (as quoted in the requirements section) the list box can be transformed into a tree view. But some aspects should be taken into consideration then: What happens to the tree on filtering/sorting? or How to deal with threads where parts are accepted/rejected?.

Mockup of the proposal

Figure 2: Mockup of the proposal

Adaptive Filter

To filter this view we want to introduce an adaptive filter. This pattern consists of a dropdown with the type of filtering (author, date/time, page etc.), the kind of relation that depends on the type (“between” makes only sense for time, “is not” would be appropriate for author, “above” or “below” is useful for pages, and so on), and the effective values which depends on the previous settings as well. You can AND-combine multiple filters per click on the plus button right hand. In case the controls do not fit into the limited space on the sidebar the filter settings need to go into a separate dialog. The combobox above the list, which can be used to store the current settings, would still be available by default. The filter in combination with the Show (tracking) option at the toolbar above allows to hide all filtered items in the document.

Since most users might not benefit from the filter option the checkbox that enables the filtering may hide all controls.


The most important controls should be placed in the sidebar to support the workflow. At the top we provide access to Start (actually it toggle tracking on/off), add change Comment (enabled only when tracking is active), and Show changes. All three buttons can be toggled on or off. Functions that relate to the list of changes are located below. That is Previous/Next and Accept/Reject. The latter applies to the current selection (therefore it makes “accept all” superfluous). As usual you may select multiple items by using ctrl and shift. And in order to support accessibility a context menu offers some options for selection too.

Of course, the familiar workflow would be still available. Removal of the changes toolbar is not a matter of discussion therefore.


Since change comments are very similar to normal comments (ctrl+alt+C) it should be shown in the same way. And that is within the document. We suggest to indicate the change comment by using a different position and place it left to the paragraph, as defined by default for the markers. Both types of comments may come from different users and get colored respectively.


Change tracking is an essential feature of Libreoffice. Based on users’ requirements we presented a mockup in figure 2 with a solution for most problems. First steps for implementation in 4.5 have been done. But we want to make sure that development is being done user centric. “Close, but no cigar” is not an option.

So what do you think? Would you benefit from a threaded review? Please let us know if we missed one of your use case or in case you have something to add.

by Heiko Tietze at February 19, 2015 04:22 PM

February 18, 2015

Eike Rathke

LibreOffice 4.4 should have been called 5.0, because it is that much better

Netrunner MAG did LibreOffice 4.4 review – Finally, it rocks and concludes with I have never quite expected this. In fact, LibreOffice 4.4 should have been called 5.0, because it is that much better.
All the little things I wanted are there. Check. Everything purrs like a kitten engorged on baby seal livers. Check. Awesomeness everything, and I am searching for more fanatic wording to convince you that you should abandon all and everything you’re doing and start testing LibreOffice. This is a monumental release, and I only have absolute praise. Well done.
Enough said. And thank you. Every user and everyone involved with the project. Thank you all for making LibreOffice that much better.

by erAck (23@ at February 18, 2015 12:13 PM

February 17, 2015

Eike Rathke

Happy Birthday TDF!

The Document Foundation: The Third Anniversary reads:
The Document Foundation has been incorporated on February 17, 2012. Today is the third anniversary, and this video is a testimonial of the activity of many members of the fantastic LibreOffice community in representation of thousands of volunteers and hundreds of developers. Thanks everyone for the wonderful journey.
and Italo Vignoli assembled this video of nice LibreOffice community shots:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="344" src="" width="612"></iframe>

Happy Birthday TDF!

by erAck (23@ at February 17, 2015 01:25 PM

Kohei Yoshida

Ixion 0.9.0 is out

After a somewhat long hiatus, I’m very happy to announce that the version 0.9.0 of the Ixion library has just been released. You can download the source package from the project’s download page.

The highlight of this release is the new Python binding. Though still somewhat experimental, Ixion’s Python API is considered equally important to the C++ counterpart, and it is my intention to make both Python and C++ API my priority from this point on.

I have made the documentation for the Python API available here. This documentation is still rough around the edges, but hopefully it will improve over time.

by Kohei Yoshida at February 17, 2015 02:02 AM

Official TDF Blog

The Document Foundation: the third anniversary

The Document Foundation has been incorporated on February 17, 2012. Today is the third anniversary, and this video is a testimonial of the activity of many members of the fantastic LibreOffice community in representation of thousands of volunteers and hundreds of developers. Thanks everyone for the wonderful journey.

<iframe allowfullscreen="true" class="youtube-player" frameborder="0" height="390" src=";rel=1&amp;fs=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;wmode=transparent" type="text/html" width="640"></iframe>

by italovignoli at February 17, 2015 12:00 AM

February 16, 2015

Leif Lodahl

Spelling in Malawi

This weekend I was contacted by my good friend Ove Larsen, from the organization FAIR, that are currently working in Malawi to prepare computers for use in high schools. Computers that are disposed in Denmark, but which can easily be used by students in the third world. The message was about compiling a spellchecker in LibreOffice for the language Chichewa, which is the main language in Malawi.

by Leif Lodahl ( at February 16, 2015 06:14 PM

February 15, 2015

Eike Rathke

Bürgerschaftswahl in Hamburg

Der Wahlkampf war gähnende Langeweile, aber das spannendste sind die Strukturdaten für die Bürgerschaftswahl am 15. Februar 2015 in den Hamburger Wahlkreisen, können dann hinterher mit Wahlbeteiligung und Ergebnissen korreliert werden.

Die sauerste Nachricht ist natürlich der Einzug der Partei mit den drei Buchstaben und dem Kleinbuchstaben in der Mitte, ich bin froh in einem Wahlgebiet zu wohnen in dem sie es nicht geschafft haben.

Zu den Wahlergebnissen und vielleicht weiteren statistischen Details.


by erAck (23@ at February 15, 2015 07:49 PM

February 14, 2015

Tor Lillqvist

Dear lazyweb,

I am now using a very silent MacBook Air (with external monitor, keyboard and trackpad) as my desktop, and connect to remote boxes for (CPU-intensive) software builds. (One of those "remote" boxes is actually a relatively low-noise (i.e. big fan) Dell workstation under my desk.)

Will the noise become unbearable if I get a 27in iMac (SSD-only) and fully load its CPU a significant part of the day right in front of my eyes and ears?

by Tor Lillqvist ( at February 14, 2015 09:21 AM

Eike Rathke

I ♥ Free Software

I especially like this year's I ♥ Free Software contribution from The Document Foundation in the bug tracker they host for LibreOffice.

I ♥ Free Software from TDF
I ♥ Free Software from The Document Foundation

by erAck (23@ at February 14, 2015 12:00 AM

February 12, 2015

Leif Lodahl

Is LibreOffice better than the competitor?

h3 { color: rgb(0, 0, 0); }h3.western { font-family: "Liberation Sans",sans-serif; font-size: 14pt; }h3.cjk { font-family: "WenQuanYi Micro Hei"; font-size: 14pt; }h3.ctl { font-family: "FreeSans"; font-size: 14pt; }h2.western { font-family: "Liberation Sans",sans-serif; font-size: 16pt; }h2.cjk { font-family: "WenQuanYi Micro Hei"; font-size: 16pt; }h2.ctl { font-family: "FreeSans"; font-size:

by Leif Lodahl ( at February 12, 2015 08:52 PM

February 11, 2015

Stephan Bergmann

Win some, lose some

Seeing recent LibreOffice commit static const to avoid re-init all the time + c++11 got me thinking. (What the code does is check whether a given rtl::OUString instance is among a statically known sequence of strings.) Clearly we can do even better. (Even ignoring the question whether std::binary_search on a sorted sequence would do a better job here than std::find on an unordered one.)

For one, a std::initializer_list provides all the functionality requested here, and is more obviously reduced by compilers than a std::vector. (Except when the compiler has a bug, Properly check for Clang with static initializer_list bug.)

For another, a rtl::OUStringLiteral is a trivial wrapper around a string literal and its length. So if we allow for comparison between rtl::OUString and rtl::OUStringLiteral, and make the latter’s constructor constexpr (which is still not available with MSVC&nbps;2013, though), the sequence of strings can be fully built into the data section at compile time. Make OUStringLiteral more useful.

(A remaining question is whether it would be better here to use a variant of rtl::OUStringLiteral that operates on char16_t rather than ordinary string literals. The advantages would be using simpler comparison code and no requirement for the sequence of strings to be ASCII-only. The disadvantages would be a bigger data section and the sad fact that MSVC 2013, while knowing char16_t, still does not understand u"..." syntax.)

However, how much “better” is that, actually? Pointers in compile-time data (as are utilized by rtl::OUStringLiteral) require load-time fixups (in relocatable load-objects). So they would ideally be avoided.

One trick, at least for a sequence of strings of fairly equal length, would be to use a std::initializer_list of fixed-size buffers like

template<std::size_t M> struct FixedSizeLiteral {
    template<std::size_t N> constexpr FixedSizeLiteral(char const (&s)[N]):
        string_(s), length_(N - 1) {}
    char string_[M];
    std::size_t length_;

where M would need to be computed at compile time. But that would require turning the sequence of string literals into a template parameter pack, and string literals are not allowed as template arguments.

Another trick would be to replace the pointer stored in rtl::OUStringLiteral with an offset, but generating that data structure at compile time looks like it would also be beyond the capabilities of today’s C++.

As always, no silver bullet.

by stbergmann at February 11, 2015 11:20 AM

February 10, 2015

User Prompt

Rapid UI development for TrustBridge

Last year we teamed up with Intevation to create interfaces and interactions for TrustBridge. TrustBridge is a secure root certificate installer for Windows and Linux, contracted by the German Federal Office for Information Security (BSI). And it is Free Software.

When we joined the project some interfaces were already done. They were mostly used to communicate with the client about the expected functionality. For this article they can be used for a before and after comparison.

Picture 1: Updates of certificates in an early TrustBridge version.

Picture 1: Updates of certificates in an early TrustBridge version.

Following we describe the steps we went through to create the UIs and interactions. As time and money budgets were tight (as always) on this project, we had to go through the whole process rapidly. Even though the steps suggest a strong hierarchical order, the work actually is an iterative process. So whenever we discovered something to be missing in the steps before, we simply revisited them.

Step 1: Vision

In order to create stunning experiences it is extremely helpful to first focus on the target that should be reached. Usually this is done through a vision. For TrustBridge we came up with:

TrustBridge makes email and https communication safer by making it so easy and comfortable for the user to install and update a basket of relevant communication certificates, that they will actually do it. This way the BSI comes a little closer to its task to strengthen the IT security with and within the federal authorities.

The problem is that it is hard to get communication certificates officially supported by Microsoft or Mozilla. Especially when you manage your own certificates as a federal authority or company it takes some time (and money) to get this official support. Same is true if you want to revoke your certificate, because it got somehow corrupted.

Currently users have to add and revoke these certificates by hand, but this is a frustrating process with the current systems. So TrustBridge wants to help here and make the management of these certificates easy and reliable – and by this help to make communication more save.

Step 2: Users

With the goal defined, it is helpful to create a picture of who the users of the product will be. Here Personas can be helpful. For this project though we decided to take a somewhat lighter approach and just sketched two stereotypical users, that mainly differ on the assumed safety-orientation and IT problem solving skills:

Primary user: Paula

  • regular user of office, mail, internet
  • set, female, rather cumbersome
  • follows regulations
  • more safety-oriented
  • good IT problem solving skills

Secondary user: Jens

  • regular user of office, mail, internet
  • set, male, rather cumbersome
  • follows regulations
  • less safety-oriented
  • little IT problem solving skills

Note that the target audience are people working in federal authorities. The picture we are drawing here is exaggerated. This is not due to us not understanding that reality is far more diverse, but for our purposes it helps to focus on the more ‘complicated’ users. So please do not feel offended if you should work in federal administration. Most people working there will be different.

We assume Paula to be the more important user for TrustBridge, so we make her the primary user in terms of Personas, while Jens is the secondary user.

Step 3: Scenarios

Scenarios help to derive and structure the actual tasks we define in the next step. We found two possible scenarios:

  1. User, managing certificates for themselves – Paula and Jens
  2. Administrator, managing certificates for others – Paula only

Step 4: Tasks

Tasks are what users actually want to achieve with the software. It is helpful to order them by assumed priority. Additionally it should be stated which users actually are confronted with the tasks and how often they are.

We created the list of tasks based on the given requirements from the BSI and a brainstorming session, where we tried to mimic the users in their scenarios. This is quite a successful methodology and makes excellent use of the findings in the steps before.

Table 1: Tasks in TrustBridge.

Prio.Description of TaskFrequencyPaulaJens
1Confirm / allow updates of certificates (Check automatically on start up and manually)OccasionallyXX
2Installation: safeguard communication of users serviced by me; execute regulatory directives for the protection of the communication on my computerOnly onceXX
2Confirm / allow update of TrustBridge (Check automatically on start up and manually)RareXX
3Installation of first Mozilla Client (e.g. Thunderbird)RareXX
3Investigate contents of a storeOccasionallyX
4Select certificatesRareX
4Check certificates that are available in TrustBridgeRareX
5Deinstall TrustBridgeOnly onceX(X)
6Get information & help about TrustBridgeRareXX

Step 5: Sketching

The advantage of such an structured approach in requirement analysis becomes visible when it comes to sketching the UIs. Creating UIs usually is an iterative process and the results so far lead us through these first iterations. The recipe is pretty simple:

  1. Take the most important task for the most important user (Paula) and mock the perfect UI.
  2. Then take the next user (Jens) and see how the UI needs to be changed for him to be able to do the first task, but at the same time to keep it great for Paula.
  3. Now alter the UI to allow Paula to do the second most important task, while keeping the experience great for the previous tasks and users.
  4. Go on like this until the last task for the every user is addressed.

A recommended and simple way to do this is on a whiteboard. You can easily erase, change or add things – and at this stage it is not important to think about screen estate or such – it is about getting the ideas to work.

Picture 2: Whiteboard with early interaction flows of TrustBridge.

Picture 2: Whiteboard with early interaction flows of TrustBridge.

Step 6: Wireframing

The UI sketches need to be transformed into something that designers and programmers can use for picking up the work. We use wireframes for that. Unfortunately the only real Free Software wireframing tool Pencil is not mature enough to do this in a proper and efficient way, so we had to use Balsamiq Mockups. As this project is done in German all mocks are made in German language as well -still we hope you get the picture. You are invited to download the .bmml mockup files and play with them.

Picture 3: Updates of Certificates.

Picture 3: Updates of Certificates.

Picture 4: List of Cerificates in TrustBridge.

Picture 4: List of Cerificates in TrustBridge.

Picture 5: Revoked certificates.

Picture 5: Revoked certificates.

Step 7: Realisation

Now that we have the idea of how TrustBridge should work, making it a piece of software is the next step. Seeing and feeling the interactions, running into technical limitations or even gaining new insights from user feedback on these screens will always make it necessary to slightly adjust the target again. So see what we ended up with (the following screens are again provisional results and are likely to be change until the end of the project).

Picture 6: New Certificates found.

Picture 6: New Certificates found.

Picture 7: Viewing Certificate Details for Update.

Picture 7: Viewing Certificate Details for Update.

Picture 8: List of Trusted Certificates.

Picture 8: List of Trusted Certificates.


As TrustBridge is a software with a limited purpose, we were able to do steps 1 to 5 in a one day workshop. For software with a broader scope you would need much more time on that. Creating the wireframes in Step 6 was the wrap up of the workshop and allowed the programmers to start working. Of course a lot of communication happened during the realization, as things here and there turned out to be different than we thought.

Overall this project is a perfect example of how user centered design works – even on a small budget and even without direct access to actual users.

What do you think about the process and the output? Do you have any ideas how to improve what we did? Did you make similar experiences in your projects? Please share your thoughts with us!

by Björn Balazs at February 10, 2015 06:30 PM

Official TDF Blog

Tender to develop and incorporate multi-language support for UI and test cases within Moztrap (#201502-01)

The Document Foundation (TDF), the charitable entity behind the world’s leading free office suite LibreOffice, seeks for companies or individuals to

develop and incorporate multi-language support for UI and test cases within Moztrap

to start work as soon as possible.

TDF currently plans to invest in expanding the capabilities of its test case management system (Moztrap). TDF’s instance of Moztrap, running MySQL as database backend, is currently only available in one language (English). In order to add more use cases and to incorporate more of our international community in testing, TDF is looking for an individual or company to, as a turnkey project, expand the capabilities of Moztrap to allow its international community to:

  1. ability to switch language of the UI (or make the UI localizable)
  2. ability to manage test cases in several languages (including complex scripts and RTL)
  3. ability to create runs in several languages (including complex scripts and RTL)

Note: TDF is not asking for the translation itself, only to add the ability for others to translate and add to native language instances of Moztrap.

Required Skills

Programming Languages

  1. Python
  2. Django

Other Skills

  1. English (Conversationally fluent in order to coordinate and plan with members of TDF)
  2. Experience with the MozTrap source code ( and its dependencies ( recommended
  3. Connection to the up-stream MozTrap project, to provide a reasonable assurance that the work will be folded-back into the up-stream project

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.

We exclusively use free, libre and open source (FLOSS) software for development whereever possible and the resulting work must be licensed under MPLv2.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.

For more information about TDF’s Moztrap please visit
To visit our current running instance of Moztrap please visit
To see our current Moztrap code, plugins and fixes please visit

The task offered is a project-based one-off, with no immediate plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Individuals and companies applying can be located anywhere in the world.

TDF is looking forward to receiving your applications, including company presentation, your financial expectations (name the final price for the turnkey project), and the earliest date of your availability, via e-mail to Florian Effenberger at no later than March 15, 2015. You can encrypt your message via PGP/GnuPG.

Applicants who have not received feedback by April 15, 2015 should consider that their application, after careful review, was not accepted.

by Florian Effenberger at February 10, 2015 02:15 PM

Jan Holešovský

Stabilising LibreOffice Viewer for Android

At the end of the last week we released the new version of LibreOffice Viewer for Android, and I must say, it is a pretty solid release. The app is still in Beta, and some problems (like occasional crashes) should be anticipated, but overall there have been so many stability improvements that I am confident that it's now very usable for daily work.

New components

How does the Viewer look from the technical point of view?  It is the complete LibreOffice that we use on the desktop, but cross-compiled to Android, stripped down to its bare bones, and accessed from the Java part via LibreOfficeKit to provide rendering of 'tiles' -- 256x256 bitmaps that together compose what the user views as a document.

Spot the problem in the above description? "Stripped down to bare bones".  When we initially released, some hard compromises were made, which led to many documents crashing. Did that document contain a drop down box? Ouch! How about a custom shape? Ouch! You get the idea.

To address that, I used the same approach that Markus Mohrard is using for import and export crash testing.  I have collected over 55,000 documents - not so far from the 75,000 that we test with desktop LibreOffice. I discarded documents that were not applicable to the Android Viewer, stripped down the desktop application the same way we are stripping the LibreOffice core that is on Android, and let the tests run for several days.

Based on the output, I have added all the necessary services for text documents; so crashes due to missing components should now be rare.

Documents that remain difficult

Some documents internally provide bindings to features that are intentionally left out of the Android Viewer; namely functionality relating to databases. These documents are still missing the components described above, and thus unfortunately still crash.

We could theoretically add those services too; the problem is that currently we are hitting the 50M .apk size limit that Google imposes on Play store apps.

But don't worry - we have several tricks still up our sleeves. We'll work on them in the following weeks, and eventually include more of the services that are still missing.

More stability improvements

Intents for documents opened from Gmail:  opening documents directly from GMail now works nicely. This was an important use case that we missed in the initial release, and we caught it thanks to the feedback of the users using the Viewer.

Several smaller things have also been fixed, like presentations used with Notes view now switch to the presenting view. We also added preset shape definitions, so .docx files with preset shapes now display nice images.

And finally, we improved recovery from failure -- previously, when the document failed to open, the subsequent open of a document lead to a crash; not any more.

Overall, while the latest LibreOffice Viewer for Android is still a Beta release (and the usual warnings apply), I'm confident it's a really good Beta. Many thanks to Miklos Vajna and Tomaž Vajngerl for their hard work!

Install LibreOffice Viewer Beta from Google Play and enjoy!

by Jan Holesovsky ( at February 10, 2015 11:57 AM

February 09, 2015

Miklos Vajna

Tiled editing: from a living document to input handling

In from viewing only to a living document, I wrote about how tile invalidation can handle updates in the Android app in case what should be displayed on the screen changes. A next step in this TDF-funded project is to handle more than blinking text: keyboard and mouse/touch events from the user.

First let me enumerate over the issues we had to face:

  • Gtk, Android and LibreOffice’s VCL use different key codes for the same physical keys. We solved this by mapping the special keys manually on the Gtk/Android side (using the C++ and Java UNO binding), and for the rest, we simply use the unicode representation of the keys.

  • Special keys: while "return" was easy to map, getting "backspace" to work was more challenging. It worked fine on the Gtk side, but on Android we had to make sure that the whole sfx2 dispatching framework works properly, only then could map the backspace key to the correct UNO command, which is .uno:SwBackspace in case of Writer.

  • Mouse handling: VCL sends pixel coordinates to the editing windows, they then calculate the offset of the editing area (think about toolbars and menus that have to be excluded), and then converts the pixel values to document coordinates. In case of tiled editing, we always work with document coordinates in logical units (twips), so we had to add the possibility to send the coordinates in document ones. This allows core not knowing where the user exactly is (in case the tiles are already ready, swiping can be handled without any LOK calls), and also allows Android not knowing the implementation details of the desktop app (where menus and toolbars would be).

  • Cursor caret overlay: we wanted to be sure that it’s not necessary to re-render the affected tiles each time the cursor blinks, so we added a LOK API to send the rectangle (its width is nearly zero) of the cursor to Android, and then it can handle the blinking cursor itself in a transparent overlay. This overlay will be useful for presenting selections as well.

As usual the commits of me and Tomaž Vajngerl are in master, so you can try this right now, or wait till tomorrow and get the Android daily build. However, if you are just interested how this looks like, here are some demos:

  • Keyboard handling in gtktiledviewer:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>
  • Same on Android, including newlines and backspace handling:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>
  • Mouse handling in gtktiledviewer:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>
  • Same on Android, including the transparent selection overlay that can efficiently blink the cursor:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="" width="420"></iframe>

That’s it for now — next on our list are selections, so you can delete and overwrite more easily. :-)

February 09, 2015 08:54 AM

February 06, 2015

Kohei Yoshida

mdds 0.12.0 is now out

I’m happy to announce that mdds 0.12.0 is now out. You can download it from the project’s download page

The highlight of this release is mostly with the segment_tree data structure, where its value type previously only supported pointer types. Markus Mohrhard worked on removing that constraint from segment_tree so that you can now store values of arbitrary types just like you would expect from a template container.

Aside from that, there are some minor bug and build fixes. Users of the previous versions are encouraged to update to this version.

by Kohei Yoshida at February 06, 2015 02:49 AM

February 05, 2015

Andras Timar

Exporting custom shapes to DrawingML

On the FOSDEM 2015 LibreOffice Hackfest I tried to improve DrawingML export of custom shapes.

Before my work DrawingML custom shape export handled only custom shapes which were imported from OOXML. In that case the equations of the custom shape are created in a way that the actual modifiers are the same for both the ODF and OOXML equations.

When the original shape is not from OOXML, then taking the adjustments without modification no longer works. Full conversion of all ODF equations back to OOXML would have been more work, not for 2 days of the hackfest, but I improved the export by exporting “non-OOXML shapes with adjustments” as polypolygons. This gave the correct view result in many cases.

Custom shapes in LibreOffice Writer inserted from Draw toolbar

Custom shapes in LibreOffice Writer inserted from Draw toolbar

Saved as .docx from Writer and opened in Word 2010 before the patch

Saved as .docx from Writer and opened in Word 2010 before the patch

Here is the result of my work. Not all shapes are correct, but there are big improvements, for example arrows, stars, and many other shapes look good now in OOXML export. This is good for now, until the real solution – full ODF <-> DrawingML conversion of shape equations – is implemented.

Saved as .docx from Writer and opened in Word 2010 after the patch

Saved as .docx from Writer and opened in Word 2010 after the patch

by timar at February 05, 2015 10:06 PM

February 04, 2015

Miklos Vajna

LibreOffice on Android FOSDEM talk

(via LOfCollabora)

Today is my last day in Brussels where I gave a TextBoxes: complex shapes with complex content and a LibreOffice on Android talk at FOSDEM 2015, in the Open document editors devroom. The devroom was well-crowded, with about 100 users in the rows of the audience — proof pictures above and below. ;-)

(via deneb_alpha)

We also had a Hackfest with about 20 hackers attending, (again) kindly hosted by Betacowork on Monday and Tuesday:

(via floeff)

There were a few topics I hacked on:

  • tdf#88583: a fallout from the Writer fillattributes work introduced in LibreOffice 4.4

  • tdf#68183: a small new feature missing since the RSID GSoC project ended

  • build on HiDPI screens should now no longer fail

  • tdf#88811: an RTF regression fix, so that now the counter is down to zero again

  • we no longer produce invalid ODF output when writing character borders

A full list of achievements is available, if you were at the hackfest and you did not contribute to that section, please write a line about what did you hack on. :-)

Quite some other slides are now available on Planet, don’t miss them. Mines are also uploaded.

February 04, 2015 09:44 AM

February 03, 2015

Charles Schulz

In praise of Evolution and Intelligent Design

Dear readers, I do not claim paternity of this title; in fact I think it was initally the developers of Claws Mail who had coined that line, precisely as a prank on the Evolution hackers. Today however I wanted to review the Evolution client and my experience with it, especially in the light of my extensive use of Claws Mail (and to a lesser extent, Thunderbird). Just before we start, however, I just would like to underline that I’m not forgetting my adventures with email clients on Emacs. Expect a post on this topic later this month.


I recently acquired a new laptop and decided to install my favorite Linux distribution, Arch Linux. Without looking for excuses, I guess I lacked time and I got the partitions wrong . As it turned out, I had a live Fedora 21 that I was trying and decided at least as a temporary solution, to fully install. The install was a breeze but that is not exactly what I wanted to talk about. When the time to choose an email client came up, I did not opt for my beloved Claws-Mail, but went for the default Gnome Mail client, Evolution. What did change and did this choice work for me? Some readers may remember an article I wrote last year about potential choices for email clients and another one about technical considerations to move to an Emacs-based email client. Both will be useful for background. However, some of these requirements and criteria have changed. As it were I have no more need for POP access, and I could go for a full Maildir inbox storage (instead of one based mostly on MH). Besides this I have now started to use shared online calendar on a daily basis.  These three changes are actually broadening both my considerations on emacs client, but do lead me to change my expectations on graphical clients as well.

The thing with Claws

I have been writing it here and elsewhere several times and will do it again: Claws Mail rocks. It seriously does. If you don’t need to use shared calendar, that is. Claws Mail does ship with a calendar 64px-ClawsMailLogoplugin that anyone with a limited use of anything like a Google Calendar or a local calendar can more or less rely on. I have satisfied myself with that, as my previous work and activities were not requiring to share 20 different events or meetings all day long. 21st century families can use several shared calendars, and not all of them are on Google. In 2013, my work with one client demanded that I use a corporate shared calendar with an entire team of co-workers. I had restarted to use Evolution on a limited basis but felt very happy with it as well. I now use our calendars and sync them across devices, but I no longer use Google Calendars: I use the KolabNow (aka My Kolab) online service for my personal email, contacts and calendars. I can use the CalDav and CardDav standards to sync and share calendars across devices. Now, Claws uses the webcal protocol in a rather buggy way, but it certainly does not support CalDav nor CardDav. I would love to reconsider my options should this change.

On the email front, things have changed as well. I no longer use email providers allowing POP access only; either because they are now offering IMAP access or because I no longer use them. Of course Claws Mail supports IMAP really well, but there’s an interesting side note to this: One of the things that makes Claws Mail outshine every other client out there is precisely the blazing speed at which it handles MH inboxes with POP accounts. IMAP accounts are handled differently, albeit not in altogether uncommon way by Claws: these are still MH inboxes you can choose to save on your hard drive periodically. However, the IMAP & SMTP protocols cannot usually be as fast when you’re receiving or sending emails, because of the constant connection to the server. This does not make Claws a slow email client: in fact it is still very fast, but it makes Claws lose its significant edge compared to others, especially Thunderbird.

Time for Evolution

 Evolution has changed compared to its previous lives in the form of the 1.x and 2.x branches. Evolution however is the Swiss Army knife of email: while it is not lightweight like Claws, it is actually less demanding than Thunderbird. Picture this: Evolution takes less memory than Thunderbird when loaded with three IMAP inboxes (one with 4 Gigaoctets-large, the second one 2 Giga, and the third one 250 Mo), one MH-based mail archive of 1 Go; 2 shared calendars and a full address book; Thunderbird takes more space without any plugin (without the calendar for instance) and only these three IMAP accounts evolutionloaded. The difference ends up being between a stable and running system (running Evolution) and a system choking off running Thunderbird. But let’s move on to Evolution proper. IMAP Data migration is a breez with Evolution; calendars were a bit trickier, in that you will get random error messages that actually do not mean what they say; you can access your calendars and yes, your shared calendars are all there. You need to restart Evolution for the calendars to display the first time however. Contacts are also very easy to import. There is even an assistant to run mailings in conjunction with LibreOffice.

One thing I don’t like is that Gnome Themes do not seem to agree well with Evolution. At least not all of them: depending on your GTK+ theme or your Gnome Shell look, certain areas of Evolution may all of a sudden become oversized. One thing that tends to surprise me is that very few people customize the fonts of their email client; any client allows for this and more specifically different fonts for the messages that are read on screen and different fonts for the rest of the interface: messages list, menus and inboxes lists. As such as have found some nice fonts for message reading (Carlito) but not somuch for the message list. Be it as it may, message handling such as reading, editing and sending on Evolution feels very smooth. You even have advanced editing capabilities for html messages (I realize I’m writing this, the guy who talks about Claws all the time) which may be handy for some people.

Another matter of importance is the search and filtering capabilities of each client. Here I must say that Claws “does it better” than Evolution. When it comes to search a similar explanation should be made about Claws: whenever Claws has to search a local inbox, I would go as far as saying that only NotMuch goes faster (but then it’s technically not an email client). Searching IMAP folders will taker more time, but it is nonetheless fast. Evolution is fast as well, but there is somewhat of a difference. Filtering is well made in Claws, while I read every kind of horror stories about filters in Evolution. It may be because people tend to forget that filters may end up having a mutual effect that they don’t always foresee: if one filters performs a specific action, it may filter emails that ought to be filtered in a specific way (i.e put in a different folder) by the second filter so that running the two filters will really mean that the first filter works entirely but not the second one. Evolution’s filters assistant seems less intuitive in that regard. Intuitive menus and assistants are another topic; really I’d say that this is up to each user to decide, but the two clients offer an inordinate number of refinements through their maze of menus and preferences settings that accomodate someone like me who receives probably over 150 emails a day (and much more at times) and is subscribed to about 50 mailing lists across several accounts. Mailing lists management is very well handled by these two. Last but not least GPG keys handling is just as smooth as with Enigmail in Thunderbird.

All in all, I have not dumped Claws, as I use it on my workstation; but there are chances that it will be phased out sometimes this year unless support for CalDav starts to be added. However the question of whether I should rather switch to Emacs has not been answered yet; and I won’t answer it here and now. It’s a developing story for me, but I hope I have been able to share my experiences on these topics. They matter more than we think and the answer cannot only be either Thunderbird or Gmail!

by Charles at February 03, 2015 09:53 PM

Jan Holešovský

Using Icecream to speed up the LibreOffice Android build

Lots of us is using Icecream distributed compiler for the LibreOffice development. It is usually the first thing we set up at a hackfest, to speed up the build for everybody (given that it only seldom occurs that all the people build at the same time).

The LibreOffice FOSDEM HackFest is no exception; Markus even brought a MacMini with a Linux VM to provide even more building power.

The problem was that I decided to hack on Android-related stuff; and the setup for Icecream was something that I had on my TODO, never achieved, and now it became really paiful. There was a small problem that was confusing me for a while, but finally I have a how-to!
  1. Make sure you have a recent enough repo that contains this fix
  2. Create cross-compile package for your environment like this (adapt the paths of course):
    /usr/lib/icecc/icecc-create-env --gcc /local/libreoffice/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc /local/libreoffice/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
  3. icecc-create-env will create a tarball with a hash instead of a readable name, rename it to something sensible, let's say
  4. Find out how exactly is the compiler called. Just do ./ > .log 2>& .log, and search for arm-linux-androideabi-gcc and arm-linux-androideabi-g++. You will need it with all the options that are there, it is quite a long command line!
  5. Modify your autogen.input to start like (we'll:
    CC=icecc [the_command_line_with_options_for_arm-linux-androideabi-gcc]
    CXX=icecc [the_command_line_with_options_for_arm-linux-androideabi-g++]
Now every time you start a new shell, just do:

export ICECC_VERSION=/local/libreoffice/android/arm-linux-androideabi-4.9.tar.gz

start the build:


and enjoy the lightning fast compilation for Android! :-)

Update: Since this commit, it is not necessary to set the ICECC_VERSION in every env any more, the one from the ./ time is preserved - it has to be in sync with CC/CXX setting anyway. In other words, you can just add ICECC_VERSION to autogen.input the same way you have added CC/CXX there:

CC=icecc [the_command_line_with_options_for_arm-linux-androideabi-gcc]
CXX=icecc [the_command_line_with_options_for_arm-linux-androideabi-g++]
...your other options...

by Jan Holesovsky ( at February 03, 2015 03:47 PM

February 02, 2015

Jan Holešovský

LibreOffice Design Team

On Sunday, I had one more talk, this time a general one about the LibreOffice Design Team. It was in the Open Source Design Devroom at FOSDEM.

I think it this was the first year when this devroom took place - but it was really well organized. Thanks so much for accepting my talk, was a pleasure to present there!

Click the slide to see the presentation.

by Jan Holesovsky ( at February 02, 2015 09:50 AM