LibreOffice 4.3 has been released this week and it has already been noticed quite a lot, judging by the number of articles in the press worldwide. The announcement may be found here, and a thorough, technical description has been written by Michael Meeks on his blog (detailed release notes are here).

I would like to discuss a bit what I think stands out in this new release; as such this is a personal collection of items and topics and not an authoritative list you could find in the release notes.

1. Native look and feel on Mac OS X

Had this been a multi-platform announcement, it would probably have been the most touted feature of the release. The reality is that this only affects OS X users and the technical details are a bit more specific: toolbars background are now rendered natively on Mac OS X, essentially leading to a native-look and feel for LibreOffice on Apple computers. This is significant to me and to OS X users and gives a much welcome UI refresh to LibreOffice. I know we receive many demands – or rather complaints to “change our user interface” but most of these requests come from people who probably have no clue what such a change entails in terms of efforts and resources. LibreOffice’s user interface, as such is not outdated because it is based on menus and not ribbons. These two interfaces metaphores are two concepts that date back to roughly the same time (the eighties) and none of them is supposedly better than the other.  LibreOffice however needs a background refresh at least and to look native or more native on each platform. Such changes happen in an incremental way, and the 4.3 illustrates this. If you have a Mac, just download and install Libreoffice 4.3 and see by yourself what I mean. To me it is something major because it is by definition highly visible to anyone.

2. Printable comments

I don’t think I would have hailed it on my top list just a few years ago but working more in more in a “collaborative fashion within a reasonably close physical distance” (read: in an office) I keep on noticing people printing documents all day long, then taking a pen, writing stuff, highlighting lines with markers… Of course you can add comments to documents with LibreOffice and go print-free. But people do print documents. All the time, all day long. I am planning a post dedicated to the never-ending legacy print as some aspects of this issue fascinates me. Anyway, it is now possible to print the comments you added in the margins with Libreoffice, independently of the file format (ODF or OOXML). This is a much awaited feature (other improvements for comments are also shipped with the 4.3), and it will let people continue to print endless drafts of their documents for many, many years to come. Apparently, we answered a deep and essential human need here – it did require a lot of work from the developers as well.

3. Filters, compatibility, interoperability

LibreOffice 4.3 ships with many improvements in document filters: better PDF support, improved OOXML compatibility, new import filters for – get this- Microsoft Works spreadsheets and databases, alongside a whole series of ClarisWorks and AppleWorks filters, igniting in your desillusioned soul the hope that what’s been on this old computer and floppy disks of yours in your inlaws’ basement shall be retrieved at last. For this you must be forever thankful to the Document Liberation project. But, as good as it gets, the juicy bits here won’t come from the nineties, but rather from 2008. Regular readers of this blog will remember these glorious days, just before the big financial crisis, where Microsoft had created the so-called OpenXML standard that was supposed to be totally not competing against the OpenDocument Format, managed to have pretty much the entire standards community swallow it in the most creative ways possible, then fell short of actually implementing it in its own products. A good summary of the whole -technical- story is available here. The irony of life has the uncanny ability to devise ways to enchant us. Well, sort of. The format called “OOXML – Strict”, by comparison to “OOXML-Transitional” was the readable open part of the ISO 29500 standard, known as OOXML. For years, it was obvious that Microsoft Office implemented either OOXML-Transitional (the heap of the more or less documented parts of the format alongside undocumented blurbs) and nothing else, creating a situation where one standard, OOXML was existing, and another format, OOXML, was fully implemented and spread all around, yet was an undocumented, proprietary specification. That’s the .docx, pptx, and .xlsx you see everywhere, and the one LibreOffice was busy reverse-engineering for all these years.

This unfortunate situation, we were told, was about to change soon, with the full adoption of OOXML-Strict by Microsoft Office. Helas, if you open a purely OOXML-Strict compliant file with Microsoft Office 2013, the file will be declared corrupt. If you open the same one with LibreOffice 4.3, the file will open and you will be able to edit its contents just like with any other format supported by LibreOffice. In other words, LibreOffice can claim to have a better support of OOXML than Microsoft Office, despite years of unfulfilled promises, pledges, and never met expectations by Redmond. I guess that, just like the old saying goes, promises only commit the ones who actually believe them.

4. Spring Water

Not in the announcement, but we did change somewhat the way we name one of the LibreOffice branches. We started with a naming pattern for our releases that had numbers only and confused the hell out of everyone. We then named the most recent branch “Fresh” and the older branch “Stable”. That turned out to be a very good idea, answered a lot of questions, but somewhat reinforced the impression that the Fresh branch is a development branch or a beta version of LibreOffice, which is by definition not the case (if you want to check our beta, release candidates and development versions, follow this link) .

We thus had to come up with another name for the “Stable” branch, knowing we could not satisfy everyone. “Mature” seemed to be the best term as it was conveying exactly what we meant. Mature, however, at least in English, can have some other unfortunate meanings that are as or even more popular than “LibreOffice Mature” on the Internet. After some try-outs, we came up with “Still”, as in “Still or Sparkling water”. It echoes well with Fresh, and manages to convey the notion of something that is less active, even quiet and “in a more stable state” than something which is fresh and new, yet already a finished product. Of course this concept works well in English and it will have to be twisted, if not radically altered in other languages, starting with French.

Last but not least, this release has been a success and I would like to thank the developers, the growing Quality Assurance team, the localizers, the infrastructure team and of course Italo Vignoli for this tremendous job. Being involved in the actual release (publishing pages, handling social media among other things), I know the kind of excitement releasing a software like LibreOffice induces, but also the skills and the talent it requires: the LibreOffice project is lucky to rely on these teams of various contributors who make it happen, day by day. That is also one of the things that truly stands out in LibreOffice.

- Better OOXML interoperability, and support of legacy Mac file formats

- Better comment management, and highly intuitive spreadsheet handling

- 3D models in Impress, and support for “monster” paragraphs

Berlin, July 30, 2014 – The Document Foundation announces LibreOffice 4.3, the 8th major release of the free office suite since the birth of the project in September 2010. The application includes the combined effort of thousands of volunteers and hundreds of developers, and has reached a point of maturity that makes it suitable for every kind of deployment, if backed by value added services by the growing LibreOffice ecosystem.

LibreOffice 4.3 offers a large number of improvements and new features, including:

- Document interoperability: support of OOXML Strict, OOXML graphics improvements (DrawingML, theme fonts, preservation of drawing styles and attributes), embedding OOXML files inside another OOXML file, support of 30 new Excel formulas, support of MS Works spreadsheets and databases, and Mac legacy file formats such as ClarisWorks, ClarisResolve, MacWorks, SuperPaint, and more.

- Comment management: comments can now be printed in the document margin, formatted in a better way, and imported and exported – including nested comments – in ODF, DOC, OOXML and RTF documents, for improved productivity and better collaboration.

- Intuitive spreadsheet handling: Calc now allows the performing of several tasks more intuitively, thanks to the smarter highlighting of formulas in cells, the display of the number of selected rows and columns in the status bar, the ability to start editing a cell with the content of the cell above it, and being able to fully select text conversion models by the user.

- 3D models in Impress: support of animated 3D models in the new open glTF format, plus initial support for Collada and kmz files that are found in Google Warehouse, in order to add a fresh new look and animations to keynotes (support of this feature is currently on Windows and Linux versions only).

LibreOffice 4.3 also support “monster” paragraphs exceeding 65,000 characters (an example of an 11 years old bug solved thanks to the modernization of the OOo source code, which is an exclusive function of LibreOffice). In addition, the accessibility technology on Windows has become a standard feature, thanks to the improvements based on IBM’s IAccessible2 framework.

The entire list of new features and improvements of LibreOffice 4.3 is here: https://wiki.documentfoundation.org/ReleaseNotes/4.3.

“The LibreOffice project shows that a large free software community can live and thrive without the patronage of a software vendor, to liberate PC desktops”, says Thorsten Behrens, Chairman of The Document Foundation. “Today, you can’t own a better office suite than LibreOffice, in term of features, interoperability, support for document standards and independence. After many years, LibreOffice brings the control of the PC desktop back into the hands of the users”.

According to the Coverity Scan service, joined by LibreOffice in October 2012, the quality of LibreOffice source code has improved dramatically during the last two years, with a reduction of the defect density per 1,000 lines of code from an above the average 1.11 to an industry leading 0.08 (for more information: http://softwareintegrity.coverity.com/register-for-libreoffice-scan-report.html).

People interested in technical details about the release can access the change logs here: https://wiki.documentfoundation.org/Releases/4.3.0/RC1 (fixed in RC1), here: https://wiki.documentfoundation.org/Releases/4.3.0/RC2 (fixed in RC2), here: https://wiki.documentfoundation.org/Releases/4.3.0/RC3 (fixed in RC3) and here: https://wiki.documentfoundation.org/Releases/4.3.0/RC4 (fixed in RC4).

Download LibreOffice

LibreOffice 4.3 and LibreOffice 4.2.6 – which will be released on Friday – are available for download from the following link: http://www.libreoffice.org/download/. Extensions and templates to supplement the installation of the software and add specific features can be found here: http://extensions.libreoffice.org/.

LibreOffice users, free software advocates and community members can support The Document Foundation with a donation at http://donate.libreoffice.org. Money collected will be used to enhance the project both at global and local level.

About The Document Foundation (TDF)

The Document Foundation is an independent, self-governing and meritocratic organization, based on Free Software ethos and incorporated in Germany as a not for profit entity. TDF is focused on the development of LibreOffice – the best free office suite ever – chosen by the global community as the legitimate heir of OOo, and as such adopted by a growing number of public administrations, enterprises and SMBs for desktop productivity.

TDF is accessible to individuals and organizations who agree with its core values and contribute to its activities. At the end of June 2014, the foundation has just over 200 members and well over 3,000 volunteer contributors worldwide.

Media Contacts: https://www.documentfoundation.org/contact/.

Today we release LibreOffice 4.3.0, packed with a load of new features for people to enjoy - you can read and enjoy all the great news about the user visible features from so many hardy developers, but there are of course also some contributors whose work is primarily behind the scenes in places that are not so easy to see. These are of course still vitally important to the project. It can be hard to extract those from the over fourteen thousand commits since LibreOffice 4.2 was branched, so let me expand:

User Interface Dialog / Layout

The UI migration to Glade based layout of VCL widgets is finally approaching the home straight; more than two hundred dialogs were converted this release; leaving the final dialogs rather hard to find - help appreciated. Many thanks to Caolán McNamara (Red Hat) - for his incredible work here, and also Szymon Kłos, Michal Siedlaczek, Olivier Hallot (EDX), Andras Timar (Collabora), Jan Holesovsky (Collabora), Katarina Behrens, Thomas Arnhold, Maxim Monastirsky, Manal Alhassoun, Palenik Mihály, and many others ... Thanks also to our translators who helped in the migration of strings.

If you'd like to get involved in driving this to 100%, checkout Caolan's howto and his great blog: 99 to go update (now only 65) illustrated by this:

Build improvements

We've improved a lot this cycle in terms of buildability, and ease of comprehension - important for new contributors.

Visual Studio support

Not only did Jesus Corrius add initial support for Visual Studio 2013, but we had a major win from Honza Havlíček who (building on Bjoern Michaelsen (Canonical)'s similar KDevelop work) implemented building a Visual Studio project file - allowing much improved build / debugging support video or just: make vs2012-ide-integration.

OpenGL as a run-time dependency

In the past when we needed an OpenGL code-path we would link a separate shared library to OpenGL and then dynamically load that component - as for the OpenGL slideshow. In 4.3 we unified all of our OpenGL code to use glew and now have a central VCL API for initializing and linking in OpenGL, making it much easier to use in future. Another benefit of using glew is the ability to check for certain extensions at run-time dynamically to better adapt to your platform's capabilities rather than having to work vs. a baseline.

Pre-compiled-headers / PCH updates

Thomas Arhnold discovered that our pch files (used for accelerating windows building) had bit-rotted, and did a fine cleanup sweep across them. That significantly reduced build time for a number of modules.

Mobile code-size reduction

A lot of work was put into LibreOffice 4.3 to allow us to shrink the code to fit a mobile footprint nicely. Thanks to Matus Kukan (Collabora) for splitting a large number of UNO components into individual factory functions - to allow the linker to garbage collect un-used components. Matus also created a python script solenv/bin/native-code.py to share the building of lists of components to statically link in for various combinations of functionality. Tor Lillqvist (Collabora) did some re-work on ICU to package the rather large data tables as a file instead of code. Vincent Saunders (Collabora) worked away to improve dwarfprofile to identify larger pieces of object file and where they came from. Jan Holesovsky de-coupled lots of accessibility code, and removed lots of static variables dragging in un-needed code. Miklos Vajna turned OOXML custom shape preset definitions (oox::drawingml::CustomShapeProperties::PresetsMap) from generated code to generated data: that allowed removal of 50k lines of code. Thanks to Tsahi Glik / CloudOn for funding this work.

Code quality work

There has been a lot of work on code quality and improving the maintainability and cleanliness of the code. Another 75 or so commits to fix cppcheck errors are thanks to Julien Nabet, along with the huge scad of daily commits to build without any compile warnings -Werror -Wall -Wextra on every platform with thanks primarily to Tor Lillqvist (Collabora), Caolán McNamara (Red Hat), and Thomas Arnhold.

Assert usage

Another tool that developers use to ensure they do not introduce new bugs is assertions; historically the OOo code base has had custom assertion facilities that can easily be ignored, and so most developers did just that; thanks to Stephan Bergmann (Red Hat), we have started to use the standard assert() macros in LibreOffice, which have the important advantage that they actually abort the program: if an assertion fails, developers see a crash that is rather harder to ignore than some text printed on the terminal. Thanks to all who asserted the truth.

Rocking Coverity

We have been chewing through the huge amount of analysis from the Coverity Scan, well - in particular Caolán McNamara (Red Hat) has done an awesome job here; his blog on that is typically modest.

We now have a defect density of 0.08 - meaning 8x bugs in every 100,000 lines of code found by static checking. This compares rather favourably with the average open source project of this size which has 65 per 100,000 lines. Perhaps the most useful thing here is Coverity's report on new issues - many of which are rather more serious than the last few, lowest priority un-triaged reports.

This was achieved by 2679 commits, 88% of them from Caolán, and then Norbert Thiebaud, Miklos Vajna (Collabora), Noel Grandin, Stephan Bergmann (RedHat), Chris Sherlock, David Tardon (RedHat), Thomas Arnhold, Steve Yin (IBM), Kohei Yoshida (Collabora), Jan Holesovsky (Collabora), Eike Rathke (RedHat), Markus Mohrhard (Collabora) and Julien Nabet

Import and now export testing

Markus Mohrhard's great import/export crash testing has been expanded to 55,000+ problem/bug documents, now covering the PDF importer, and our crash and validation problem counts continue to drop. Markus also re-wrote and simplified the test script in python to make it simpler; however we routinely suffer from this test (running for 5 days and consuming a beefy machine) locking up Linux of several distributons, kernel versions, on both virtual and real hardware; which has a negative impact on usefulness.

Re-factoring big objects

In some cases LibreOffice has classes that seem to do 'everything' and include the kitchen sink too. Thanks to Valentin Kettner, Michael Stahl (RedHat) and Bjoern Michaelsen (Canonical) for helping to re-factor these. As an example SwDoc (a writer document) now inherits from only nine classes instead of nineteen, and the header file shrunk by more than three hundred lines.

Valgrind fixes

Valgrind continued to be a wonderful tool for finding and isolating leaks, and poor behavior of various bits of code - although normal code-paths are by now rather valgrind clean. Dave Richards from Largo very kindly donated us some CPU time on his new 80x CPU Linux machine to burn it in. We used that to run Markus' import/export testing under valgrind, and found and fixed a number of issues. valgrind logs here. We would be most happy to help others with their boxes in need of load testing.

Address / Leak Sanitizer

There are some great new ways of doing (compile time) code sanitisation, and thanks to Stephan Bergmann (RedHat) we're using them enthusiastically -fsanitize is available for Clang and gcc 4.9. It lets us do memory checking (like valgrind) but with visibility into stack corruption, and to do that very significantly faster. Some details on -fsanitize for libreoffice are available. Lots of leaks and badness have been fixed using the tool, thanks too to Markus Mohrhard, and Caolan McNamara.

Unit testing

We also built and executed more unit tests with LibreOffice 4.3 to avoid regressions as we change the code. Grepping for CPPUNIT_TEST() and CPPUNIT_ASSERT as last time we continued the trend of growth here:

Our ideal is that every bug that is fixed gets a unit test to stop it ever recurring. With 1100 commits, and over eighty committers to the unit tests in 4.3 it is hard to list everyone involved here, apologies for that; what follows is a sorted list of those with over 20x commits to the qa/ directories: Miklos Vajna (Collabora), Kohei Yoshida (Collabora), Caolán McNamara (RedHat), Stephan Bergmann (RedHat), Jacobo Aragunde Pérez (Igalia), Tomaž Vajngerl (Collabora), Markus Mohrhard (Collabora), Zolnai Tamás (Collabora), Tor Lillqvist (Collabora), Michael Stahl (RedHat), Alexander Wilms

SAL_OVERRIDE and more

Traditionally C++ has allowed significant ambiguity in overriding methods, allowing the 'virtual' keyword to be ommitted in overrides, and also allowing accidentally polymorphic overrides. To prepare for the new C++ standard here we've annotated all of our virtual methods that are overridden in sub-classes with the SAL_OVERRIDE macro, to ensure that we are building our vtables correctly. Many thanks to Noel Grandin, and Stephan Bergmann (RedHat) for building a clang plugin to help to build annotation here with another to verify that the result stays consistent. That fixed several long-standing bugs. As a bonus when you read the code it is much easier to find the base virtual method declaration: it's the one that is not marked with SAL_OVERRIDE.

QA / bugzilla

This release the QA team has grown, and done some amazing work both triaging bugs, and also closing them, getting us back well under the totemic one thousand un-triaged bug barrier. Currently ~750 un-confirmed which is the lowest in over two years. Thanks to everyone for their great work there, sadly it is rather hard to extract credits for confirming bugs, but the respective hero list overlaps with the non-developer / top closers listed below.

We also had one of our best bug-hunting weekends ever around 4.3 see Joel Madero's write-up. The QA team are also doing excellent job with our bibisect git repositories to isolate regressions to small blocks of commits - which makes life significantly easier for developers.

One metric we watch in the ESC call is who is in the top ten in the freedesktop Weekly bug summary. Here is a list of the top twenty people who have appeared most frequently in the weekly list of top ten bug closers in order of frequency of appearance: Jorendc, Kohei Yoshida (Collabora), Maxim Monastirsky, tommy27, Joel Madero, Caolán McNamara (RedHat), Foss, Jay Philips, m.a.riosv, Julien Nabet, Sophie Gautier (TDF), Cor Nouws, Michael Stahl (RedHat), Jean-Baptiste Faure, Andras Timar (Collabora), Adolfo Jayme, ign_christian, Markus Mohrhard (Collabora), Eike Rathke (RedHat), Urmas. And thanks to the many others that helped to close so many bugs for this release.

Bjoern Michaelsen (Canonical) also write up a nice taxonomy of our twenty five thousand reported bugs so far, and provided the data for this nice breakdown:

Code cleanup

Code that is dirty should be cleaned up - so we did a lot of that.

The final death of UniString

While we killed our last tools/ string class in 4.2 and switched to clean, uniform OUStrings everywhere - we were still using some 16bit quantities to describe text offsets elsewhere. Thanks to Caolán McNamara (Red Hat) for finally enabling writer to have >64k paragraphs - a long requested feature by a certain type of user, see the related blogpost.

VCL code / structure cleanup

The Visual Class Libraries - the LibreOffice native toolkit has not been given the love it deserves in recent years. Many thanks to Chris Sherlock for several hundred commits - starting to cleanup VCL. That involves lots of good things - giving the code a more logical structure so it is easy to find methods; systematically writing doxygen documentation for API methods, ensuring that API methods have sensible, descriptive names and starting to unwind some poor legacy design decisions; much appreciated.

Ongoing German Comment redux

We continued to make some progress on translating our last lingering German comments across the codebase to good, crisp technical English. Many thanks to Luc Castermans, Sven Wehner, Christian M. Heller, Philipp Weissenbacher, Stefan Ring, Philipp Riemer, Tobias Mueller, Chris Sherlock, Alexander Wilms and others. We also reduced the number of false positives and accelerated the bin/find-german-comments tool in this cycle.

Automated code re-factoring using Clang

One hero of code cleaning is Noel Grandin who is constantly improving the code in many ways; eg. writing out un-necessary duplicate code to use standard wrappers such as SimpleReferenceObject. Noel has been heavily involved in Clang plugins to re-write a lot of our error prone binary file format / stream overrides pStream >> nVar seems like a great idea until you realise that an unexpected change to the type of nVar far away tweaks the file format. These operators are now all re-written to explicit ReadFloat type methods enhancing the robustness of the code to changes. Noel also created plugins to inline simple member functions, detect inefficient passing of uno::Sequence, and OUString. Stephan Bergmann (RedHat) also wrote a number of advanced linting tools, checks for de-referencing NULL pointers, quickly catching inlining problems on Linux that cause most grief on Windows, and re-writing un-necessary uses of sal_Bool to bool. Stephan also wrote a plugin to find unused functions and unused functions in templates, as well as warning on illicit conversions of literal to bool e.g. if (n == KIND_FOO || KIND_BAR). All of this improves the readability, consistency, reliability and in some cases performance of the code.

Improving lifecycle

Takeshi Abe invested lots of time this cycle in improving our often unhelpful object lifecycle. Using smart pointers not only makes the code more readable and often shorter, but also exception safe which is very useful.

DocTok cleanup

This cleanup saved nearly 80k lines of code and make the codebase much simpler to understand thanks to Miklos Vajna (Collabora) you can see the before & after pictures in his blog.

Holding the line on performance

Performance is one of those hard things to keep solid. It has an alarming habit of bit-rotting when your back is turned. That's why Matus Kukan (Collabora) has built a test machine that routinely builds LibreOffice and runs a suite of document loads, conversions etc. under callgrind. Using callgrind's simulated CPU has the beautiful property of ensuring repeatable behaviour, and thus making any small reduction or improvement in performance noticeable and fixable. It is easy to see that in a graph - admire the crisp flatness of the graph between significant events. The X axis is time (annotating the axis with git hashes is not so photogenic).

Often we only check performance just before a release, its interesting to see here the big orange hump from a performance fragility found and fixed as a direct result of these tests. Raw callgrind data is made available for trivial examination of the latest traces along with a flat ODS of the previous runs.

Getting involved

I hope you get the idea that more developers continue to find a home at LibreOffice and work together to complete some rather significant work both under the hood, and also on the surface. If you want to get involved there are plenty of great people to meet and work alongside. As you can see individuals make a huge impact to the diversity of LibreOffice (the colour legends on the right should be read left to right, top to bottom, which maps to top down in the chart):

And also in terms of diversity of code commits, we love to see the unaffiliated volunteers contribution by volume, though clearly the volume and balance changes with the season, release cycle, and volunteers vacation / business plans:

Naturally we maintain a list of small, bite-sized tasks which you can use to get involved at our Easy Hacks page, with simple build / setup instructions. It is extremely easy to build LibreOffice, each easy-hack should have code pointers and be a nicely self contained task that is easy to solve. In addition some of them are really nice-to-have features or performance improvements. Please do consider getting stuck in with something.

Another thing that really helps is running pre-release builds and reporting bugs just grab and install a pre-release and you're ready to contribute alongside the rest of the development team.

Conclusion

LibreOffice 4.3 is the next in a series of releases that incrementally improve not only the features, but also the foundation of the Free Software office suite. Please be patient, it is just the first in a long series of monthly 4.3.x releases which will bring a stream of bug fixes and quality improvements over the next months as we start working in earnest on LibreOffice 4.4.

I hope you enjoy LibreOffice 4.3.0, thanks for reading, and thank you for supporting LibreOffice.

Raw data for many of the above graphs is available.

<figure class="wp-caption aligncenter" id="attachment_870" style="width: 500px;"><figcaption class="wp-caption-text">Sleep symbols standardized by IEEE 1621, and created by LibreOffice for Wikipedia (see the public domain SVG version in Wikimedia Commons)</figcaption></figure>
<figure class="wp-caption alignright" id="attachment_866" style="width: 150px;"><figcaption class="wp-caption-text">Not a standard sleep symbol</figcaption></figure>
Wikipedia page Power symbol mistakenly showed the astronomical symbol of the moon (see right) instead of the IEEE 1621 standard crescent moon symbol. This standardized symbol, called “Sleep” refers to the Sleep mode (also Stand By or Suspend), the low power mode for electronic devices.
The easily accessible consultant report of the standard is a little bit cryptic about the form and size of the proposed symbol (Appendix VI.3.):

Fortunately, abstract of the referred standard IEC 40630 revealed the size of the square, too: exactly 75 mm. Using this data and a ruler, it was possible to measure the diameter of the outer circle, too: it is 6 cm. The standard specifies the ratio of the outer curve of the moon shape: a half circle; the width of the shape: 1/4 diameter of the circle (1.5 cm); and “tilt” of the moon: just for fun, it is equal to the earth’s angle of inclination (at the time of writing of the standard, it was 23.45 degrees). The only question was the specification of the inner curve of the moon shape. After some investigation it was found that it is arc of a circle, not an ellipse. We can calculate its radius (r₂) and position based on the following illustration:

Radius of the first circle (r₁) is 3 cm. Using the Pythagorean theorem, r₂² = (r₂–r₁/2)²+r₁² = (r₂–1.5)² + 9 = r₂² – 3r₂ + 2.25 + 9, so r₂ = 11.25/3 = 3.75. The following LibreLogo program draws the filled moon using a black, 6 cm circle, and a white, 7.5 cm circle:

PENUP LEFT 23.45° 
FILLCOLOR “BLACK” CIRCLE 6cm
RIGHT 90 FORWARD 2.25cm
FILLCOLOR “WHITE” CIRCLE 7.5cm

For a better cropping in the SVG version, we can draw only a black semicircle, and – using the law of sines for the calculation – only the requested white circular segment of the second circle:

PICTURE “power_sleep_black_cropped.svg” [
PENUP LEFT 23.45°
FILLCOLOR “BLACK” ELLIPSE [6cm, 6cm, 6h, 12h]
RIGHT 90 FORWARD 2.25cm LEFT 90
FILLCOLOR “WHITE”
ELLIPSE [7.5cm, 7.5cm, 6h+36.8°, 12h-36.8°, 2]
]

Apply the following steps to convert the black and white circular segments to a single moon shape:
1. Open the exported SVG file in LibreOffice Draw.
2. Select and remove the bad black background rectangle.
3. Press Ctrl-A to select the black and white circular segments.
4. Select Modify » Shapes » Subtract to subtract the white circular segment from the black semicircle.
5. Export as SVG.

Drawing white (empty) sleep symbols is a little bit trickier. We have to draw the circular segments with the (double of the) requested line width for the inner moon shape (see the screenshot), (moreover, in enlarged version to reduce the rounding errors of the Draw canvas and the following clipboard operation), and subtract this smaller moon shape from the big one. Steps:

1. Change the Writer paper size to 100×100 cm, and run the following LibreLogo code:

TO moon color bgcolor
HOME LEFT 23.45° 
PENCOLOR color PENSIZE 4cm 
FILLCOLOR bgcolor ELLIPSE [60cm, 60cm, 6h, 12h]
PENUP RIGHT 90 FORWARD 22.5cm LEFT 90 PENDOWN
FILLCOLOR “WHITE”
ELLIPSE [75cm, 75cm, 6h+36.8°, 12h-36.8°, 2]
END

PICTURE [
moon “INVISIBLE” “BLACK”
moon “ORANGE” “INVISIBLE”
]

2. Copy the picture to a 100×100 cm Draw canvas, select Modify » Ungroup and Modify » Shapes » Subtract to create the inner moon shape.
3. Press Ctrl-C to copy the inner moon shape to the clipboard, and press Ctrl-Z to restore the image.
4. Remove the two shapes with orange outlines.
8. Press Ctrl-V to insert the inner moon shape (you can change its filling color to check it, see on the attached screenshot).
5. Press Ctrl-A and select Modify » Shapes » Subtract to create the empty moon shape.
6. Resize it with Format » Position and Size…, move it to the left upper corner, resize the canvas (or copy the moon shape to the previous, but empty SVG file), and export it as a new SVG file.

IEC 40630 has got two preferred line widths, 2 mm and 4 mm, also the filled moon is an official version of the symbol, and sometimes it is useful to use not only the fully cropped versions of these symbols, but the versions cropped only to the 6 cm (invisible) circle, that is why Wikimedia Commons has got six new sleep symbols (see the image gallery of one of them).

• Up early; mini team meeting, update, tried to deal with the most urgent E-mail; off to Carls for lunch with Robert. Back, continued to wade through the mail. Built ESC bug stats, sent some mail. Slugged with the family in the evening.

Good news everyone ! The OneDrive connection in libcmis is ready. Due to this new feature users can now create and edit files in their OneDrive storage directly from LibreOffice. As soon as the SharePoint connection is ready and functional and hopefully by the time the GSoC ends, this new useful feature will be available and patched into the new version of libcmis. This means that roughly in a month's time users will be able to benefit of it.

Here is a short demo of how the binding works. It basically implies no more than opening the document from your own machine. It gives the user the security and flexibility of a cloud service, while still running locally.

• Opened up, hacked away - finally unwound my problems with the EditEngine - fields are filled in by an amazing series of app-specific callbacks hidden under Links. Nailed my bug. Helped Algot out with triage - managed to get the number of un-triaged bugs really rather low.
• Dick and Jill arrived; Pizza for lunch. More work; Radek passed through, bid 'bye to Joel & Algot, kindly dropped home by Imanuel & Robinson, relaxed.
• Family returned home, full of bounce & exhaustion after water-park-ing at some length. Lovely to see everyone again.

• Into town early by car with the lads; met up with Algot, bagels for breakfast; very kind of Xamarin to provide such a fine venue. Did some gdb / callgrind training, Jeff showed up & implemented several easy hacks, Martin came too from the Inkscape guys. Interested to see LibreOffice: The Complete Guide as a magazine. Great to have some pre-setup EC2 VM's for LibreOffice hacking, thank to Cloph.
• Worked away at this and that until rather late. Burritos and discussion on Boston Common, back to the office for some more hacking; caught up with a passing Radek; more work, home rather late. Relaxed together; synched with Joel, bed late.

• Off to visit Bob, lovely home, took dogs for a walk, talked technology - into Waltham for a Boston steak & cheese sub, kindly dropped at Alewife. Into the Xamarin office - lovely place for a LibreOffice hack-fest tomorrow - lovely to catch up with Jo Shields, Miguel, Duncan, Jeff, Michael, Aaron and a lot of friendly new people. Very generous of them to host us. Waited for Joel and Robinson.
• Car home with Immanuel, Robinson & Joel, off to Wendy's and back to eat on the balcony.

Converting LibreOffice dialogs to .ui format, 54 conversions remaining

We've now converted all but 54 of LibreOffice’s classic fixed widget size and position .src format elements to the GtkBuilder .ui format. This is due to the much appreciated efforts of Palenik Mihály and Szymon Kłos, two of our GSOC2014 students, who are tackling the last bunch of hard to find or hard to convert ones.

Current conversion stats are:
778 .ui files currently exist
There are 20 unconverted dialogs
There are 34 unconverted tabpages
An estimated additional 54 .ui are required
We are 93% of the way through.

Coverity Defect Density: LibreOffice vs Average

LibreOffice: 9,425,526 line of code and 0.09 defect density

Open Source Defect Density By Project Size

Line of Code (LOC)	Defect Density
Less than 100,000	0.35
100,000 to 499,999	0.5
500,000 to 1 million	0.7
More than 1 million	0.65

Note: Defect density is measured by the number of defects per 1,000 lines of code, identified by the Coverity platform. The numbers shown above are from our 2013 Coverity Scan Report, which analyzed 250 million lines of open source code.

On Tuesday the news that the UK Government had decided to use ODF as its official and default file format started to spread. The full announcement with technical details may be found here; the Document Foundation published its press release on Thursday morning there.

This decision is a landmark for several reasons. First, it is not every day that you see an entire government migrate to a standardized file format. You may hear about government branches using this or that solution, but nothing that is so “abstract” than a file format.  This time the UK Government has made the conscious decision to define a coherent policy in handling its digital documents, from the stage where they are created, edited and circulated all the way to the archival phase. It also comes year after the decision of the State of Massachusetts. As such the decision covers a variety of standards (HTML, PDF and ODF); yet its scope, as Glyn Moody rightly reminds us, also means that the devil will lie in the details of the execution.

Most of the migrations from one office suite to another tend to happen without any coherent document management policy. Many organizations moving from, say, Microsoft Office to LibreOffice do not necessarily adopt ODF as their default format and will carry on supporting whatever version of the MS Office file format internally. This usually leads to frustrations and compatibility problems. This time, the UK Government decision takes a different approach. By deciding about the formats first, the UK creates the conditions necessary to have real choices for its government and its citizens, thus setting a level playing field for everyone. Many people have understood this decision as being a move against Microsoft. It is not or at least it should not be. Microsoft Office implements ODF files and its latest editions, as I’m being told are actually quite good at it. What this move does, however, is to ensure no other solution will be at a competitive disadvantage because of a technical or legal (aka patents) lock-in. Of course, it remains to be seen what concrete actions the UK Government will take in order to ensure a smooth transition between proprietary formats and open standards; and it remains to be seen how well it will ensure a proper change management across all of its departments so that its agents feel comfortable with ODF documents and whatever new office suites that may be adopted as a result of the decision. Much could be lost at that stage, but much could be gained as well. And of course, just like with the Netherlands, the decision itself might end up being toned down or take a somewhat different meaning.

While reading among the tea leaves is not my favourite past time, it is relevant to assume that this decision may change a few things around the IT industry as well. By way of an example, I have always been amazed at Apple’s clean support of ODF inside Mac OS X but its constant absence across the iWork editions. Perhaps Apple will feel compelled to introduce ODF files in iWork now? Only time will tell. Cloud solutions will also have to improve or implement ODF and in some cases PDF support in a proper way.

The decision might also have consequences for other European countries and perhaps for the European institutions themselves, as the UK will now be an actual example of a country that has migrated to ODF, and not just one of the countries that made the choice of Free and Open Source Software. This is rare enough to catch the attention of several member states CIO offices.

This move to open standards by the UK Government is also telling of a deeper change in IT industry. We may reach the stage where finally, the average user starts to realize that the old Windows + Office paradigm starts to get exhausted. What can you do with Office documents aside opening them imperfectly in alternatives and opening them in a more effective way with Microsoft software? Actually, not much. Unless you get SharePoint. But the whole point is that in 2014, trying to extract revenue by creating lock-in on office files is no longer acceptable. That, I think, is what the UK Government decision really means. And if I’m right, it’s only the beginning.

Last but not least, this post would not be over without thanking many people whom I’ve worked with for several years in my position at my former company, Ars Aperta, in my former role at OpenOffice.org, at the OASIS Consortium and even today when contributing to the LibreOffice project. I’m thinking about people at OpenForum Europe, the FFII, the APRIL, the AFUL, the OASIS, the now defunct ODF Initiative and everyone else I am forgetting right now but who should be remembered. It’s nice sometimes, after such successes, to turn back and look at the road behind us. It can only give more confidence to walk on the one ahead.

UK citizens will be the first in Europe to be liberated from proprietary lock-ins

Berlin, July 23, 2014 – The Document Foundation (TDF) congratulates the UK government for the selection of the Open Document Format (ODF), in addition to Portable Document Format (PDF), to meet user needs. LibreOffice, the free office suite developed by TDF, supports both ODF – the native document format – and PDF (including PDF/A).

The original UK government press release is here: https://www.gov.uk/government/news/open-document-formats-selected-to-meet-user-needs. In addition, the UK government has published a policy paper with more details: https://www.gov.uk/government/publications/open-standards-for-government/sharing-or-collaborating-with-government-documents.

“TDF has always been a strong supporter of ODF, and a believer in open document standards”, says Thorsten Behrens, TDF Chairman. “July 22 will be a date to remember, as the culmination of a dream inaugurated when ODF become a ISO standard on November 30, 2006. By standardizing on ODF and PDF, the UK government is showing the world that it is entirely possible to find a way out of proprietary formats to enhance user freedom”.

LibreOffice is a reference implementation of ODF, a document standard which is supported by a growing number of applications (including proprietary ones). ODF is independently managed by OASIS (https://www.oasis-open.org/), a non-profit consortium that drives the development, convergence and adoption of open standards for the global information society.

To leverage the advantages of ODF, you can download LibreOffice from the following link: http://www.libreoffice.org/download/. Extensions and templates to supplement the installation of the software and add specific features can be found here: http://extensions.libreoffice.org/.

Complementing ODF, LibreOffice manages Hybrid PDF files, which combine the advantages of PDF and ODF by embedding a fully editable ODF document into a PDF without breaking any of the standard characteristics of both formats.

Thorsten Behrens, Chairman of the Board at The Document Foundation, has announced the elections for the Membership Committee.

Dear Community,

all members of The Document Foundation are called to vote on a new Membership Committee. Therefore, the Board of Directors hereby announces the elections to the Membership Committee with the following timeline:

1. 2014-07-19: announcement of the elections (this e-mail); and start of the nomination phase
2. 2014-08-27, 24:00 CET/UTC+2: end of the nomination phase
3. 2014-09-04, 00:00 CET/UTC+2: official start of the elections
4. 2014-09-11, 24:00 CET/UTC+2: end of the elections
5. 2014-09-12: announcement of the preliminary results; and start of the challenging phase
6. 2014-09-17, 24:00 CET/UTC+2: end of the challenging phase
7. 2014-09-18: official announcement of the final results
8. 2014-09-19: new Membership Committee officially in charge

Members of The Document Foundation as of 2014-07-01 are eligible to vote in the elections, and any eligible voter can also be elected to the Membership Committee. Members may self-nominate.

To announce your candidacy, send a message to board-discuss@documentfoundation.org with your full name, e-mail, corporate affiliation (if any), and a description of your reasons for
wanting to serve as a committee member. All candidates should also send a summary of their candicacy announcement to elections@documentfoundation.org – a compilation of the summaries will be mailed to all registered voters prior to the elections. Summaries should be no more than 75 words of continuous text (so no bullet lists or multiple paragraphs) and must be received by the nomination deadline given above.

Available slots will be filled by a single transferable vote system, seats filled in decreasing order of preference. This election is according to our statutes, and the term of office is two years.

All discussion related to the elections should be held on board-discuss@documentfoundation.org where members are invited to ask questions to one or all candidates. Instructions explaining how to vote will be sent via e-mail to all eligible voters in time before the election.

The board will announce preliminary results as soon as possible after the elections close, along with instructions on how to access the votes archive and how to independently verify the vote count.

Any eligible voter may challenge the preliminary results by e-mailing elections@documentfoundation.org within the aforementioned deadline. Once any challenges have been resolved, the board shall announce the final results.

Any questions regarding these procedures should be directed to the board by e-mail to elections@documentfoundation.org

We are looking forward to all candidacies, and would like to thank you for your work, engagement and dedication for The Document Foundation!

On behalf of the Board of Directors,
Thorsten Behrens

LibreOffice CMIS server connection feature suffered a severe disease since the begining: it was not able to connect to servers using HTTPS. First a workaround was added for invalid certificates, but the problem also existed for valid ones as described by fdo#72277.

After several months of inactivity, I finally managed to grab enough courage to dive into curl and NSS. From 4.3.1, LibreOffice built with internal curl library, will be able to use the mozilla certificates database to validate CMIS connections.

For those wanting to know the gore details, LibreOffice internal curl library is built with NSS support. To read the certificates database, curl needs to find libnssckbi: so NSSInitializer UNO service was here to do that job. But using that service is not enought: curl doesn't know how to read the PKCS certificates stored in the database... and needs libnsspem to do that. After some digging, I uncovered it on fedorahosted and added it as a patch to LibreOffice internal NSS library.

Thanks Caolan and Michael Stahl for pointing me to the right direction to fix that one.

Thanks to Smoose, we are now able to do some real progress with the Android version of LibreOffice. The idea is to first build a LibreOffice document viewer, which is able to display any type of document that is supported by LibreOffice. Afterwards build on that and provide more features and eventually editing. The application itself should be a Android native application and use LibreOffice (interfacing through LibreOfficeKit) to provide tiles of a rendered documents and other needed pieces.

In the last couple of weeks I have been working on making this plan a reality. The first goal is to prepare the base of the application so I used the Fennec (Firefox for Android) source code. Fennec already solves many of the problems that we would need to solve - especially concerning drawing of tiles, touch handling, scrolling, tools and removed the rest, that will not be needed or needed later in development.

The calls to Gecko (rendering engine in Firefox) were replaced with our own implementation either in Java or a facade to LibreOfficeKit. By using a mock document tiles (tiles of the document that are part of the application's assets)  I was able to make the application work without actually interfacing with LibreOffice yet. With this the application  looked something like this:

At this stage the application was able to show a mock document with working scrolling and touch handling. The next big step was integration of LibreOffice and writing a JNI facade to LibreOfficeKit so that a real document rendered by LibreOffice could be show on a screen. With a big help from kendy we managed to integrate LibreOffice and correctly initialize LibreOfficeKit. After that the a real LibreOffice rendered document appeared:

See application in action video here and here.

Finally some results! There are some issues at the tile borders but this will be eventually resolved. The application uses OpenGL ES 2 for rendering so the user experience is smooth for the most parts (there are still things to optimize). This is the current state of the application but it is still far from complete however a lot of quite difficult technical challenges have been resolved and true development and polishing can now start.

Next steps are cleaning up and refactor a lot of code, integrate useful parts of previous attempt (LibreOffice4Android), tune tile loading and invalidation (when to load or remove which tile), making parts asynchronous to reduce blocking and improve the user experience, text selection and copy/paste, ...

I am really excited with what we have achieved and really looking forward to see where we go from here. By the time of LibreOffice 4.4 we should have a working and polished document viewer application ready. Thanks again to Smoose for funding for the work on this important step!

 Tomaž

To quote the gospel of Luke (12:48) before discussing Free Software is rare, yet not unseen, and this blog will not shy away from creating new rarities every month. Let’s start right away. What do projects such as OpenSSL, LibreSSL & LibreOffice have in common? They are Free Software projects of course; why do I ask the question? Probably because it deserves a better answer… Let’s try to dig deeper.

It is  fashionable these days to show surprise, and then a sorry look, when discussing Free and Open Source Software. Yes, some projects are everywhere, in your browser, embedded into appliances and in places you don’t even imagine they could be. Is it written anywhere? Do appliances, ATMs, cars, airplanes, some proprietary software solutions, phones, televisions, ovens come with a full list of components? They usually don’t. But  if they would, people would realize how prevalent Free and Open Source Software is. The other thing they would be surprised with would also be that most of the time, nobody pays projects or developers for this. I know, you’ve been taught that Free Software costs zero, and that’s good news because it’s better than warez, and on top of this you get to tell their idiotic developers that their software stink -heck, you’re even entitled to do that!

The problem with that, however, is that it is not sustainable. I don’t mean to say that the Free Software model is not sustainable, only that, just like any other working system, it does not  work like a perpetual movement: people’s motivation is important, and sometimes even developers need a roof, some food, a shower, perhaps a car…Some of them might be entrepreneurs. Discovering the sorry state of OpenSSL does not equate to demonstrate that Free and Open Source Software does not work as intended, it only means that there are a whole lot of people benefiting from it -the users- and a few people probably abusing it, while the core  contributors do not get anything in the end. And while no  one suggests there is an obligation to pay core contributors in one way or another, certainly no one actually paid attention to the OpenSSL developers.

Let’s come back to LibreOffice. We often get messages, public and private, in the form of: “this or that feature does not work. How can it not work? You should be ashamed to offer this software. I expect software to work, and if it does,’t, well, I’ll take my business elsewhere!”. Of course we have not received this complaint but we did receive similar emails of what can qualified as digruntled customers. At first they were irritating to me, even though some of them were pointing to actual bugs. Now, they make me smile. Not having my livelihood depend on bug fixing helps too, but it would still make me smile. At the risk of offending a few people, these complaints make me think of people who browse large malls, have no money, will not spend anything of course, but who will call the better business bureau and the shops managers to complain about how the racks are aligned or the weak A/C. Could they be right? Probably yes, why not.
Will it be fixed because they communicated their frustration? Probably yes. Or perhaps no. It will really depends if their complaint is justified and if the mall has enough money to fix these issues.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube-nocookie.com/embed/SRZYUyiQMcU?rel=0" width="420"></iframe>

When it comes to Free Software projects, there’s a profound, deep misunderstanding about who does what and how it’s being done. Using the now overused quote, developers write a code “because they have an itch to scratch”, means that there can be twenty different motivations to contribute to Free Software. No one needs to explain or justify his or her contribution. In the real world, one of the most common motivation is money, be it in the form of a salary, a fee, or a transaction involving the developers to fix whatever bug or develop a new feature. Most of the FOSS projects I know -excluding Firefox- do not pay developers directly for fixing bugs except in very specific circumstances and by definition not on a regular basis. The LibreOffice project is no different. The Document Foundation serves the LibreOffice project by financing its infrastructure, protecting its assets and improving LibreOffice in almost every way except paying for development on a regular basis. What this means, in other terms, is that the Document Foundation does not provide support; nor does it provide service to customers. In this sense, it is not a software vendor like Microsoft or Adobe. This is also one of the reasons why there is no “LTS” version of LibreOffice; because the Document Foundation will not provide a more or less mythical “bug-free version” of LibreOffice without ensuring the developers get paid for this. The healthiest way to do this is to grow an ecosystem of developers and service providers who are certified by the Document Foundation and are able to provide professionals with support, development, training and assistance.

To expect software that’s both Free as in beer and as in speech, without bugs and meeting most of your needs is a dream. Free Software delivers software freedom, digital rights; it greatly improves the collaborative development of software and the nurturing of software commons. It does not deliver you free lunch, and it never will. Or rather, if there is free lunch, it will be somebody’s lunch you share with him or her.

How can you help? There are many ways to contribute: joining the community by actively participating to its workflows, its teams and offering time, manpower, expertise; or with money, if you’re a professional user or donating to the project. You can do all this with LibreOffice (donate here; see how you can join us there). Ultimately, Free Software projects do not sell products, they grow communities. Stop being a consumer, become a contributor!

Recently I’ve been working on Calc and Impress tiled rendering, with some results now becoming visible:

Impress

Impress Tiled Rendering is now integrated into master — there are still some issues, i.e. foreground images are not shown yet (this is a bug that’s shared with calc tiled rendering), and it’s not yet possible to select between rendering only slides, only notes, or both (i.e. we currently default to whatever mode the document was last opened in). However in general it seems to work quite well:

In fact very little work had to be done to get tiled rendering working here — the hardest part was figuring out what part of Impress to plug into: once I’d gotten my head around Impress’s architecture, connecting up the rendering was a matter of a few lines of code.

Calc

The calc work is somewhat more substantial, primarily due to the way that scaling for cell rendering works: calc calculates on-screen pixel based sizings in a number of steps using its own scaling methods, which can sum up to noticeable errors between expected and rendered content (which would result in discrepancies when later compositing tiles). This means that there is a significant amount of work needed in rewriting parts of the scaling: while the tiled rendering itself is beginning to look acceptable, the normal UI for Calc is now partly broken, primarily in that scrolling is rather glitchy (however this is being fixed bit by bit, and it is hoped will be mergeable in a useable state soon). This work is still staying on a branch for now — i.e. until it doesn’t break the usual way of using Calc.

Similarly to Impress, images in the foreground aren’t being rendered yet — this as far as I can tell is the same underlying issue, and is what I’m currently working on fixing.

Other Stuff

In addition to the work on actual tiled rendering, there have been some further additions in the surrounding code and testing tools:

• “Zoom” Controls for the gtk tiled viewer. (Zooming is however quite slow as we’re repainting a huge tile…)
• A part selector for the gtk tiled viewer, i.e. permits switching between tabs in a spreadsheet, or slides in a presentation (writer documents are however rendered all as one huge block).
• Associated zoom and part selection methods for the LokDocView gtk+ widget.
• A quad-tiled widget for testing (nothing to do with real tile composition…): this allows for inspecting tile transitions/borders (and was useful for finding some more glaring issues in the calc implementation).
• Some automated tests that aren’t yet fully enabled due to some further bugs that have been uncovered (which would cause them to fail).

The first release candidates for LibreOffice 4.3.0 are already bouncing around the internet and, besides great new features like the ones I’ve been explaining in my latest posts, they come with a set of fixes to ease the life of screen reader users and developers alike. This is, once again, a part of the accessibility work we do at Igalia.

Back in April, when the Gran Canaria hackfest took place, I started working on the bug #71556. The problem was that typing on a document triggered a lot of unnecessary text-attributes-changed events. These events had a variety of origins, but most of them were caused by modifications in the internal text attribute rsid, used for change tracking and with no relevance per se for the user. The bug is not completely fixed, but addressing the problem with rsid attribute allowed us to get rid of the most annoying part of it; now LibreOffice only sends one unnecessary event when we type the first character in a new paragraph and not with every keystroke.

Bug #71558 is also related with the same kind of events; in this case, text-attributes-changed was not being triggered when a word became marked as misspelled. Actually, the spell-checking status is not internally treated as a text attribute and because of that there were no events indicating its change. The patch explicitly raises the event which lets the accessibility code check the status of the text attributes and find out the spelling mistake. While I was working on this issue, I also detected a weird behavior when checking the text attributes through the Python API; it resulted to be a bug in the bridge between AT-SPI and ATK, which I reported and fixed too.

A triaging session took me to bug #74681; the main issue reported there had already been fixed for a while and only small bits regarding missing accessible names in some buttons were missing. I fixed that allowing toolbar buttons to use their tooltip text as the accessible name if it is not explicitly set, and now the paragraph properties panel is fully accessible.

Finally, I retook the work I had been doing in relation with ATK roles at bug #39944 and detected wrong mappings for LibreOffice EDIT_BAR, EMBEDDED_OBJECT and HYPER_LINK accessible roles. I fixed them and opened a ticket in ATK bugzilla to create ATK roles for the five cases that were still registering custom roles. Once that ticket is managed, hopefully we will be able to close bug #75191 too, which is related with the deprecation of atk_role_register.

These fixes are added on top of the ones coded in February hackfest, making 4.3.0 the most accessible LibreOffice so far… Until the next version arrives, of course!

It has been a while since I have discussed open standards here, even though I have alluded to them in passing. There are currently a number of initiatives and policies ongoing at the European level that are bringing this topic back on the table, especially with regard to public procurement practices. Why does it matter? Because it shows that beyond any kind of advantage, convenience, or the mere ability to have a real choice of IT solutions suppliers, open standards are considered by much of the private and public sectors as some sort of nuisance.

Depending on how you see it, the “battle” for open standards is either won, or it is  still ongoing at the normative level (think about the DRM injection in HTML5 that happened at the W3C). Open Standards, more than ever before, rule the IT industry and the Internet. Cloud technologies rely on open standards to a large extent; purchasing music tracks online lets you increasingly download open file formats that, while they may not be exactly standardized themselves, have open specifications and are unencumbered wiith digital restrictions management (yes, that’s how DRM should really be called).

On the other hand, desktop technologies are still a major issue. One could assume it is because of the stranghold of an entrenched  monopoly, and perhaps it is, to some extent. We are in 2014 however, and both open standards and FOSS desktop offerings (LibreOffice, Firefox, Linux  distributions for the desktop) are legion. These have a real uptake among what is  often referred to as the consumers’ market and that’s great news, but when it comes to what’s going on in the workplace, there seems to be little choice aside the MS Office + Outlook + SharePoint on Windows stack. Why  is that the case? Why is the European Commission still trying to tackle the problem in 2014?

The Desktop is traumatizing

And more exactly, change is traumatizing. Technology changes very quickly, but the more structured the workplace you have, the less adaptative it will be for IT  solutions. If you add the specific culture of the organization that can sometimes be more or less rigid and centered on one vertical industry, you will find long cycles of deployment for any kind of IT technologies and a reluctance to “switch” to a new brand or a new kind of software. This could not be more true on the desktop. I’ve been writing this for years here, but there are reasons for that: the desktop is used by pretty much everyone in the organization. While it  is  somewhat changing with the arrival of tablets and smartphones, desktops are here to stay. The problem is that desktops are very complex systems -offering a graphical interface and tools for pretty much every kind of uses and situations one can imagine- and as such come with more quirks than other devices and other software platforms. These quirks end up being noticed by the users, who most of the time are not computer-savy and will be reluctant to change. Worse,  their  skills will directly or indirectly be challenged by the change. This fear of change ends up being passed on to the CIO level, who has to make the purchase decision, and does not want to be hold liable for having chosen that “weird, so called innovative solution no one gets”.

Just like with any fear, we are not talking about rationality. In 2014, people who use Twitter on a daily basis will shout if their desktop has changed overnight. It is not a good practice to do that kind of brutal change anyway, but the very concept of microblogging was unknown to them 5 years ago. They embraced it with no trouble at all. Their desktop, however, is a holy land, the solitaire game and their office suite their hallowed relics.

Open Standards can sometimes be hard to understand

It is hard enough for people to understand what protocols such as TCP/IP do. These open standards however are invisible to most of them, even if they’re using them on a daily basis. Other open standards, such as OpenDocument Format, are probably not conceivable by some people, who think that an office document is “an extension of Microsoft Office”. I have even heard of teachers, here in France, who refused to even mention ODF because such a thing “could not possibly exist”. The conceptual distinction between a file and an application has not permeated much, even in the twenty first century.

Yet, open standards are the way to go. They may not always be the superior technology, but they offer a level playing field for the industry to build on and innovate with. The Internet has been built on this, so does cloud computing. Desktop solutions are no different. Using open standards brings you back in control of your suppliers and IT infrastructure; it ultimately helps reducing costs and keep your data safe, reusable and sustainable  for dozens of year to come. You can read more about it in the excellent article by Bjorn Lundell published here. Ultimately, the lock-in of the desktop solutions will stop being meaningful as the state of the art will change so much the solutions that are seen as essential today will stop being that important. But the documents, the images, the data, all your content will still be locked in undocumented file formats that need to be reverse-engineered in order to edit them. No one should build such a silo for the future and then throw away the key. That’s what has been happening for more than a decade on the desktop, unfortunately. Where does that lead  us? I think we can already see where: vendor lock-in is here to stay on a more or less large extent; but so are open standards. There will then be people who are stuck with their vendors and constantly handle the legacy; there will be the others, who actually enable information technologies to help them innovate. For them, the story has only started.

The LibreOffice conference sites for 2012 and 2013 are running on Plone. I updated them to version 4.2.7 of Plone, a bugfix release. The LibreOffice extensions- and templates sites are running still version 4.2.6. An update to version 4.2.7 gave an error message that needs some investigation and time to fix.

The ODFAuthors site is running the newest release line, 4.3.x. I updated this one from 4.3.2 to 4.3.3 without any issues yet. It’s always a pleasure to update Plone via buildout.

Ich bin Extremist!

Eigen TOR

XKeyscore-Quellcode: Tor-Nutzer werden von der NSA als Extremisten markiert und überwacht

Dabei sollte ich das besser gar nicht benutzen, denn alleine dadurch mache ich mich schon zum Freiwild. Eigen-Tor: Gefahren der Tor-Nutzung im Alltag

William Binney heute in der Anhörung im NSA-Untersuchungsausschuss: Die Vollüberwachung der Gesellschaft ist die größte Bedrohung der Demokratie seit dem amerikanischen Bürgerkrieg.

Ups, da hab ich doch glatt auf netzpolitik.org verlinkt, jetzt bin ich Doppel-Extremist.

Eigentlich ja Dreifach-Extremist, denn Mails verschlüssel ich schon seit Jahren (falls denn jemand mitmacht) mit GnuPG.

Damit ein für alle Mal klar ist was ich von euch NSA-Arschgeigen & Co halte: Und Du, NSA, brauchst da nichts weiter zu speichern und analysieren.

Yours sincerely,
The Tororist

Coverity Defect Density: LibreOffice vs Average

LibreOffice: 9,500,825 line of code and 0.13 defect density

Open Source Defect Density By Project Size

Line of Code (LOC)	Defect Density
Less than 100,000	0.35
100,000 to 499,999	0.5
500,000 to 1 million	0.7
More than 1 million	0.65

Note: Defect density is measured by the number of defects per 1,000 lines of code, identified by the Coverity platform. The numbers shown above are from our 2013 Coverity Scan Report, which analyzed 250 million lines of open source code.

So any crashes you might experience in 4.3 are either a figment of your imagination or a sad commentary on the limitations of static code analysis.

…because the picture is the illustrated version of the sentence “VAKÁCIÓ!”, the obligate, usually colourful and imaginatively designed text on the blackboards of the Hungarian elementary schools before the long Summer vacation (zoom). The animated SVG version of the picture shows how the text is longer day by day, started with the exclamation mark.

Interestingly, the coloured chalk was invented 200 years ago, according to the resources of Wikipedia (see blackboard): James Pillans Scottish classical scholar and educational reformer created it from ground chalk, dyes and porridge in 1814 for teaching geography.

Friday and Saturday were great days of excitement: The LibreOffice Hackfest in Montreuil, organized by the Document Foundation and Simplon.co, a “startup factory” born in a large struggling -yet charming- urban neighbourhood next to Paris, gathered active developers of the project and members of Simplon Co.  The hackfest was a success and a great opportunity to work together on various tasks.

Developers were able to work on OOXML filters, performance improvements, hacking on the integration of the Firebird as the database behind the Base module…

…. as well as interacting with members of the french community and students from Simplon Co.

Less technical particpants (such as yours truly) had the opportunity to work on the Bern Conference planning, the messaging of the upcoming LibreOffice releases, and explain how the LibreOffice project works to our guests. And of course, food and drinks were not forgotten during the Friday evening…

Thank you everyone who participated, to Simplon Co. for their hospitality, to our dev team, to Collabora, and to the volunteers who made this event possible. Santé!

The sidebar comes with a vertical scrollbar for when content doesn't fit in the available space. But the mouse pointer has to be right over the scrollbar to use your scroll wheel, it doesn't work to hover over the content of the sidebar and move the wheel there.

Which is annoying, but on trying to fix that I realized the snag with allowing the wheel-scroll over the sidebar. If you scroll the sidebar down and a widget contained in it ends up under the mouse pointer then if it is a widget which accepts the wheel-scroll it's very easy to accidentally make a change to the widget that has scrolled under the mouse pointer. Spin Buttons for example.

As an aside, this is the exact same problem that I have in glade where I scroll down the property pane with the scroll-wheel and accidentally end up over the "Ellipsize" listbox and inadvertently change it from None to Middle. So if you find labels in LibreOffice with "..." in the middle of them for no good reason, this is why.

Anyway, I still want to scroll the sidebar, but I don't want to end up with this conflicting target-location widget wheel-scroll conflict, so my solution is to continue to send the wheel-scroll events to the previous target so long as the position of the mouse pointer is at the same place as the last wheel event and the time between events is <= the default timeout for raising help tips, i.e. 1/2 a second.

Seems to work well for me, scrolling the sidebars "just works" on master (LibreOffice 4.4) with the scroll wheel without random changes to any scroll-wheel sensitive contents but you can still use the scroll-wheel to modify those widgets on moving to them or when the little timeout completes.

We continue introducing features that will be part of the 4.3.0 release of LibreOffice, which is coming soon. After having worked in the preservation of color in shapes, we worked on the different effects that can be applied to shapes and bitmaps.

There are three types of effects that are managed separately in the DrawingML specification.

General shape effects

Examples of these effects are inner or outer shadows, reflections, glow… They can be applied both to vectorial shapes or bitmaps, and several of them can be applied at the same time.

These effects are indicated with the a:effectLst tag inside the shape properties tag spPr. I won’t explain their specification in detail because you can find a very good description in this website, but you can get an idea by taking a look at the following example where three effects are applied: glow, inner shadow and reflection:

<a:effectLst>
  <a:glow rad="63500">
    <a:schemeClr val="accent2">
      <a:satMod val="175000" />
      <a:alpha val="40000" />
    </a:schemeClr>
  </a:glow>
  <a:innerShdw blurRad="63500" dist="50800"
  dir="2700000">
    <a:prstClr val="black">
      <a:alpha val="50000" />
    </a:prstClr>
  </a:innerShdw>
  <a:reflection blurRad="6350" stA="52000"
  endA="300" endPos="35000" dir="5400000"
  sy="-100000" algn="bl"
  rotWithShape="0" />
</a:effectLst>

Notice that some effects only have some attributes while others contain color specifications as child elements like the ones explained in the previous post.

3D effects

Shapes and bitmaps can be transformed into 3D objects and get lighting and camera modifications applied to them.

These effects are basically controlled by two children tags of spPr. One of them is a:scene3d and controls the camera and lighting, and the other one is a:sp3d which controls the transformation of the shape in a 3D object adding extrusion, bevels and a material effect to the surface. In the same website I linked before, you can read a description of scene3d and sp3d tags and their children. Find an example of their combined use below:

<a:scene3d>
  <a:camera prst="perspectiveRelaxedModerately"
  zoom="150000">
    <a:rot lat="19490639" lon="0"
    rev="12900001" />
  </a:camera>
  <a:lightRig rig="threePt" dir="t">
    <a:rot lat="0" lon="0" rev="4800000" />
  </a:lightRig>
</a:scene3d>
<a:sp3d z="488950" extrusionH="63500"
prstMaterial="metal">
  <a:bevelT w="165100" prst="coolSlant" />
  <a:extrusionClr>
    <a:schemeClr val="tx2" />
  </a:extrusionClr>
</a:sp3d>

Artistic effects

Effects from the last category act like the filters found in image manipulation programs (blur, grain or background removal among others) and that’s why they only can be applied to bitmaps. This is actually not a part of DrawingML spec but an extension over it.

There is an important difference with other filters; these ones come pre-calculated in the document. The bitmap linked by the DrawingML shape already comes with the effect, and the effect specification links a second bitmap that contains the original picture so the effect can be undone. This second bitmap is saved in the relatively new loss-less Windows Media Photo format.

Check the following example of a blip-filled shape; the actual filling comes from the file linked as rId6, while the effect definition is linked to rId7 which is a copy of the original image before the filter was applied:

<a:blip r:embed="rId6" cstate="print">
  <a:extLst>
    <a:ext uri="{BEBA8EAE-BF5A-486C-A8C5-ECC9F3942E4B}">
      <a14:imgProps xmlns:a14="http://schemas.microsoft.com/office/drawing/2010/main">
        <a14:imgLayer r:embed="rId7">
          <a14:imgEffect>
            <a14:artisticLightScreen trans="10000" gridSize="6" />
          </a14:imgEffect>
        </a14:imgLayer>
      </a14:imgProps>
    </a:ext>
  </a:extLst>
</a:blip>

These are the relations between the ids and the files contained in the document, as specified at document.xml.rels:

<Relationship Id="rId6"
  Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
  Target="media/image2.png" />
<Relationship Id="rId7"
  Type="http://schemas.microsoft.com/office/2007/relationships/hdphoto"
  Target="media/hdphoto1.wdp" />

The funny thing of this approach is that LO was able to render these effects with no effort, although the program was not aware of the effect parameters or the original bitmap and these were being lost on save.

Preservation

We use again the grab bag technique to save all the tags and attributes related with the effects as a hidden property that will be used later in the export phase to re-build the effect definitions. In the case of artistic effects, we additionally need to make sure that the original bitmap is preserved; LibreOffice doesn’t support the Windows Media Photo format yet, but we can keep the raw stream of data and output it to a properly named file in the exported document. A small cache table is maintained by the exporter code to prevent that the same original file is saved more than once when two or more pictures apply effects to the same image.

We have finished with the improvements related to shapes and pictures, but there are a few interoperability features not yet mentioned which will be covered in a future post. Like the current and previous ones, they were developed by Igalia and sponsored by CloudOn.

Happy hacking!

The Documentation Team has published the LibreOffice 4.2 Getting Started Guide.

Free PDFs of individual chapters and the full book can be downloaded from The Document Foundation’s wiki.

Printed copies can be purchased here. (Published by Friends of OpenDocument Inc.)

The Documentation Team has published the LibreOffice 4.2 Getting Started Guide. Free PDFs of individual chapters and the full book can be downloaded from The Document Foundation’s wiki. Printed copies can be purchased here. (Published by Friends of OpenDocument Inc.)

Since we announced the Document Liberation Project and its accompanying framework library, librevenge, there has been several requests for EPUB generator. (librevenge itself contains generators to CVS, HTML, SVG and plain text. There is also a separate library for generating ODF called libodfgen.) I had an idle moment two weeks ago and did not feel like working on any of my existing projects, so I decided to look at this. I started a new library, libepubgen (predictable, eh?) The core of it was the HTML generation code from librevenge, modified to produce its output to an abstract output interface instead of into librevenge::RVNGString and also to create XHTML 1.0 instead of HTML 4.01.

Since then, in more idle moments, I added support for images and simple splitting of the HTML output to multiple files. I also integrated the new library into writerperfect, so there are now command line tools to convert various text formats supported by writerperfect to EPUB (for every foo2odt, there is now foo2epub as well). What is still missing is handling of foreign binary objects, the drawing parts of librevenge::RVNGTextInterface (I think I will convert these to SVG images), smarter splitting of HTML files (provided there is enough information from the input) and probably more things I cannot think of right now. It would also be nice to allow conversion of presentations (in other words, to implement librevenge::RVNGPresentationInterface), as they tend to contain lots of text.

The interface is probably not going to change much at this point (except adding functions for registering binary object handlers and possibly some configuration to libepubgen::EPUBTextGenerator). One thing to highlight is that, like libodfgen, libepubgen does not create the output file directly. Instead, it provides an interface (libepubgen::EPUBPackage), which the caller has to implement. All internal files are then generated using this interface. The only exception is mimetype, which must always be created by the caller (only if it creates Zip container, of course. mimetype is not needed for filesystem container).

I will continue to work (on and off) on this, but I have no estimate when the first release is going to happen. If anyone is interested and wants to help, patches are welcome. Bug reports too, but remember this is a new project, so bugs are expected.

Berlin, June 20, 2014 – The Document Foundation announces LibreOffice 4.2.5 “Fresh”, the fifth minor release of the most feature rich version of the software, ready for enterprise deployments. For more conservative users, The Document Foundation suggests LibreOffice 4.1.6 “Stable”.

LibreOffice 4.2.5, as well as LibreOffice 4.1.6, have been developed by over 800 contributors, who have joined the project since the launch in late September 2010 (source: http://www.ohloh.net). “This is a wonderful achievement”, said Thorsten Behrens, Chairman of The Document Foundation. “We have managed to attract at least three new contributors per month, for 46 months in a row, with an average of more than 200 new contributors per year”.

People interested in technical details about the release can access the change logs here: https://wiki.documentfoundation.org/Releases/4.2.5/RC1 (fixed in RC1) and here: https://wiki.documentfoundation.org/Releases/4.2.5/RC2 (fixed in RC2). In total, over 150 bugs or regressions have been solved.

Download LibreOffice

LibreOffice 4.2.5 and LibreOffice 4.1.6 are both available for download from the following link: http://www.libreoffice.org/download/. Extensions and templates to complement the installation of the software and add specific features are available here: http://extensions.libreoffice.org/.

LibreOffice users, free software advocates and community members can support The Document Foundation with a donation at http://donate.libreoffice.org. Money collected will be used to grow the project both at global and local level.

I don't know about the flying abilities of time, but it does pass quickly when you love what you are doing! Such is the case with my Google Summer of Code. It's time for mid-term evaluations already!

For those who do not know what I'm talking about, check out my previous post. I have been working a lot in the last month and have achieved quite a lot. Obviously, none of that was possible without continuous support and help from my mentor, Jan Holesovsky.

So, what have I achieved till now? Let's take a look at the screenshot of the Select Persona Dialog the way it looks now:

The users can enter their favorite terms to search for related themes. What happens then?

1. The Mozilla's AMO API is used to get the search results. If anyone is interested in the data that is retrieved, click this.
2. The retrieved XML is parsed and the learnmore tag's value is used to get the HTML content of the theme from which, the various attributes of the persona, such as it's name, preview file URL, header file URL. text color etc are retrieved and saved.
3. The preview URLs are used to get the images and these are displayed in the dialog. All this parsing and fetching is done in a separate thread. So no hanging of the UI :-)

I know, it's too geeeky! Let's see how it looks:

Yes, I'm a South Park fan, if you haven't guessed till now ;-)

Now, when the user clicks OK after selecting a theme, the header and footer files for the theme are downloaded and applied (this too in a separate thread), and voila!

Presently, I am working on the functionality of using the default themes that are provided with the LibreOffice suite. After this, the main task of the GSoC will be over (pretty cool, huh?), and I'll be looking towards Jan for more work ;-). Hoping to get my code merged in the core repo soon!

Keep watching this space for more. Cheers!

 Converting LibreOffice dialogs to .ui format, 99 conversions remaining

We've now converted all but 99 of LibreOffice’s classic fixed widget size and position .src format elements to the GtkBuilder .ui format. This is due to the much appreciated efforts of Palenik Mihály and Szymon Kłos, two of our GSOC2014 students, who are tackling the last bunch of hard to find or hard to convert ones.


Current conversion stats are:
741 .ui files currently exist
There are 46 unconverted dialogs
There are 53 unconverted tabpages
An estimated additional 99 .ui are required
We are 88% of the way through.

Berlin, June 17, 2014 – The Document Foundation (TDF) announces the second LibreOffice 4.3 bug hunting session, from June 20 to June 22. The community has already made a large collective effort to make LibreOffice 4.3 the best ever, based on automated stress tests and structured tests by Quality Assurance volunteers.

Enterprise and individual LibreOffice users can now contribute to the quality of the best free office suite ever by testing the release candidate to identify issues in their preferred user scenario.

Participating is easy. Details of the bug hunting session are on TDF wiki (https://wiki.documentfoundation.org/BugHunting_Session_4.3.0_RC1). The list of LibreOffice 4.3 new features, which have to be tested for bugs and regressions, is also on the wiki: https://wiki.documentfoundation.org/ReleaseNotes/4.3.

To participate, it will be necessary to have a PC with Windows, MacOS or Linux, and LibreOffice 4.3 RC1 (available at http://www.libreoffice.org/pre-releases). A previous Quality Assurance experience is not mandatory.

Filing bugs is also easy, thanks to the help of the experienced volunteers who will be around on the QA mailing list (libreoffice-qa@lists.freedesktop.org) and IRC channel (irc://irc.freenode.net/#libreoffice-qa).

How I got into GSoC
I learned about this super awesome opportunity for students some time ago and I kept telling myself that I should start searching for a project as soon as possible. But as the starting date drew near I hadn’t done anything and I found myself one week before the accepted organizations publishing nervous and desperate to find something.

Choosing LibreOffice
I had 2 criteria in my choosing: the project had to be written in C++ and it had to be interesting. So it happened that I came across this interesting LibreOffice proposed idea, “Connection to Microsoft’s Sharepoint and OneDrive” which combined what I was looking for and networking, one of my favourite computer related subjects.

The project
The idea was to extend libcmis (content management interoperability services), which is a library that works inside LibreOffice and allows you to work on remote files directly in LibreOffice without the need to explicitly download the file and reupload it. libcmis already has AtomPub and WebService bindings, and as for 2013’s summer it features a new Google Drive binding. Now my task is to work on the connection with OneDrive and SharePoint. I find this new feature to be of great importance as users that are constrained to work on a SharePoint repository can now choose an open source program for their office suite.

Current status
I firstly chose to work on the OneDrive binding as it was going to be a more “gentler” introduction into libcmis’s code. The connection is almost ready and I race to finish it as the midterm evaluation is around the corner. This feature allows users to create, edit and easily move around documents and folders in their OneDrive cloud storage. More updates will follow and hopefully, if everything goes well, a demonstration.

<figure class="wp-caption aligncenter" id="attachment_790" style="width: 500px;"><figcaption class="wp-caption-text">The most simple perfect squared square (in 750px, Wikipedia and SVG)</figcaption></figure>

The Boy Who Loved Math: The Improbable Life of Paul Erdős is a funny children book about the legendary Hungarian mathematician. Author of the book, Deborah Heiligman has got the help of Erdős’s friends and colleagues, also the illustrator of the book, Le Uyen Pham has traveled to Budapest to create great illustrations about the place of birth and childhood of the world wanderer Paul Erdős. According to the New York Times’s review (Nate Silver: Beautiful Minds), this book “should make excellent reading for nerds of all ages.” It contains also several interesting mathematical problems, including the illustrated one: how can we tile a square using other squares whose sizes are all different and have integer lengths. The squaring on the picture is the simplest one, and it was discovered by A. J. W. Duijvestijn in 1978, see its interesting history on Squaring.net.
The LibreLogo source code of the illustration uses the mapping and grid drawing procedures of the tangram drawing example of the previous post, also the new procedure box for drawing a square with random filling color with 50% transparency (using the new FILLTRANSPARENCY command of LibreOffice 4.3) and a title showing the actual size:

TO place x y
POSITION [50+x*4, 500-y*4]
END

TO line x y x2 y2
PENUP place x y
PENDOWN place x2 y2
END

TO grid x y x2 y2
REPEAT y2-y+1 [
    line x y+REPCOUNT-1 x2 y+REPCOUNT-1
]
REPEAT x2-x+1 [
    line x+REPCOUNT-1 y x+REPCOUNT-1 y2
]
END

TO box x y s
PENUP place x+s/2 y+s/2
HEADING 0 FILLCOLOR ANY FILLTRANSPARENCY 50
PENDOWN SQUARE s*4
FONTSIZE MAX (2*4, s*2.5)
TEXT s
END

PICTURE “squaredsquare.svg” [
PENSIZE 0.5 HIDETURTLE
PENCAP “ROUND”
PENCOLOR “SILVER”
FONTFAMILY “Nimbus Sans L”
grid 0 0 112 112
PENSIZE 1 PENCOLOR “BLACK”
box 0 0 33
box 29 33 4
box 33 0 37
box 0 33 29
box 0 33+29 50
box 29 33+4 25
box 29+25 37 16
box 29+25 37+16 9
box 29+25+9 37+16 7
box 29+25+9 37+16+7 2
box 50 37+25 15
box 50 37+25+15 35
box 33+37 0 42
box 33+37 42 18
box 50+15 37+16+7 17
box 50+15+17 18+42 6
box 50+15+17 18+42+6 11
box 50+35 18+42+17 8
box 29+25+16+18 42 24
box 50+35+8 42+24 19
box 50+35 42+24+19 27
]

Hi,

So one difficult topic now. In his post I will throw around with things like precondition and code, but I really try to keep it simple.

So, let us first introduce the example. A “Linked-List”. What you need to know (just valid for this tiny example):

• No element –> NULL
• “->” is the link between elements
• No element is an element
• A list starts at “head”, so head is just the link to the first element

Let’s have an example. These are valid lists

1. head->null
2. head->1->2->3->null

The length of 1) is ZERO, of 2) THREE. That is most of the coding skills you need ;)

So, what are errors? You find them in LibreOffice as well as in all other software. It does not behave as expected, maybe resulting in a crash. That is quite obvious.  You can have invalid or simply unexpected input. As you can see in the above example, we do not expect to add the element “null” at position 1 [between 1 and 2] Would result in head->1->null->2->3->null (again sorry to all developers, I need easy examples).  So we are not allowed to add the element “null”, as this would result in changing the length of the list from 3 to 1, by adding one element. 3+1=1 okay, I guess that should not be like that…. So the code is a little bit inspired by Java, so sorry for the overhead ;)

public void addElement(int position /*A number from -2147483648 to +214483647*/, IntElement e /*Also a number like in our example, but it can have a link to a different IntElement*/){
assert e != null && LENGTH_OF_LIST >= 0;
if(head == null) //If we have an empty list
INSERTFRONT //We do not need to much detail here
assert LENGTH_OF_LIST == 1; //== means equals
return; //Exit the function here
}
int oLength = LENGTH_OF_LIST;
assert position >= 0 AND position <= LENGTH_OF_LIST;
INSERT_MIDDLE_LAST //Insert at the rest of the list
assert LENGTH_OF_LIST == oLength +1; // If adding succeeded the new length must be 1 greater than the old one
}

You can see some line start with “assert”. This are developer’s magic little helpers.

A function in mathematics and informatics has 3 conditions:

1. Precondition –> How should the input should look like
2. Post-condition –> How should the output / result of the function should look like
3. Invariance–> What should be valid at the beginning and the end

Invariance

What should be at the beginning and at the end?  The length must be >=0.

Precondition

The inserted element must not be NULL and the length of the list must be positive (So this includes the invariance as well)

Post-Condition

If the list is empty –> Length is 1 (this includes the invariance)
If the list is not empty the new length must be by one greater than the old length. (this includes the invariance as well)

So, did you get the need? You can assure yourself that the input and output of a function (and if you want steps inside) are correct. So you cannot get any unexpected result, if assertions are enabled. Assertions are disabled by default, because they slow down a bit, but in LibreOffice Daily build from tinderbox 39  (downloadable @ SI-GUI atm) assertions are enabled.

So finally, an example (I only realized they were enabled because of this message:

 

So at line 1291 of winlayout.cxx an assertion failed (while testing bug # 77248) That’s a starting point for devs. The error might be near there ;) So yes, it makes sence to have assertions enabled and more to write them. If you write down how the output and the input should look like, everyone knows. You are turning implicit to explicit knowledge. And you will save hours to search for the place, where the error did occur. So please, and this is not limited to LibreOffice, have assertions enabled during testing!

And if you see such a dialog and remember the steps you did to come there, check if such a bug exists and comment with the exact version, or create a new bug. The exact version is needed, because this is the only way, that devs know on which version of the file they can find the failing assertion.

Tagged: Assertion, Assertion Error, coding, LibreOffice, QA, regression testing, Tinderbox, Windows

Easily integrating LibreOffice directly into any other application is now a step closer thanks to the new GTK+ lok_docview widget (currently only on the feature/gtkbmptiledviewer2 branch, API and naming liable to change, usual disclaimers, etc.).

It currently sports a very simple api, consisting of the following two methods:

GtkWidget*   lok_docview_new (LibreOfficeKit* pOffice);
gboolean     lok_docview_open_document (LOKDocView* pDocView,
                                        char* pPath);