The Document Foundation Planet


March 19, 2018

Official TDF Blog

Italo Vignoli on LibreOffice marketing and the challenges ahead

The free and open source software world is known for being inclusive and open: anyone can get involved, regardless of age, location or background. In the LibreOffice community, we value the input from experienced community members who bring valuable knowledge and ideas to the table. Today we talk to Italo Vignoli, who has been with LibreOffice since day one and is responsible for marketing and public relations. He describes what led him to open source, along with the challenges and opportunities in marketing LibreOffice.

1. Your background is probably a bit unusual in the free software world. Why did you decide to become an advocate for free software and (the predecessor to LibreOffice) at age 50?

In the late nineties, I started to look for Microsoft Office alternatives but I was not happy with “clones” as they were clearly missing a vision. Then, in 2002 I stumbled on, and I was fascinated by the potential of the application (although version 1.0 was still very “young”).

I was completely new to open source software, but I decided to learn. During 2003 I started trying to understand the community, and then – in early 2004 – I sent a message to the leaders of the Italian NLP (Native Language Project) and the marketing project, offering my help to raise the awareness of within the media.

I met the community in September 2004, at the conference in Berlin, and I decided to stay because I loved their ethical values and the passion for innovation. Thirteen years have gone by since that time, and I still have the same enthusiasm and motivation to be part of a community that changes the world of software.

2. What was your background beforehand – and what led you into open source?

I was born in 1954, so I am 63. I have always been extremely curious, and this has helped me in going beyond my background in humanities.

In fact, after my degree in human geography, I started working at the Italian Touring Club as editor-in-chief of the cartographic department. At the same time, I was volunteering as an assistant professor of geography at Milan State University, and a journalist covering metropolitan areas development in Europe.

In late 1981, I moved to Honeywell – at the time a large computer company – to increase the awareness of printers for PCs (the IBM PC had just been launched that year). I soon discovered a passion for information technology which I could not even suspect, given my background and my lack of understanding of mathematics.

Having worked as global marketing director for peripherals and UNIX computers, I realized that communications of high-technologies was my dream job. So, in 1987 I left the company to join a large Italian PR agency, and worked with several agencies throughout my career path. Having founded two own agencies before, these days I work as a freelancer and helped several international companies to set up or grow their operations in Italy.

In 2004, I started to volunteer with, to grow the awareness of the free office suite within the Italian media. In 2010, I was one of the people involved in the birth and development of The Document Foundation (TDF) and LibreOffice, and I have been a member of the Steering Committee and then of the first Board of Directors of TDF.

I am a member of TDF’s paid team since late 2013. I first helped to shape the certification project, and then I have focused on marketing and PR since late 2014.

3. How you spend your time when working for TDF?

I spend most of my time behind a desk, studying products and related topics like standard formats, interacting with journalists, monitoring online articles and comments, drafting documents, creating presentations, managing budgets, dealing with local communities, and handling daily tasks.

Like many who are active in the community, I also deal with a large number of emails and messages, as I am subscribed to most project mailing lists and Telegram groups. This is time consuming, but it is also a very good way of interacting with native language communities, which are often faced by different issues based on local language, culture and legislation.

In addition, I often travel to local events, to speak about The Document Foundation, LibreOffice and Open Document Format. One of my objectives for the next few years is to attend more events, to strengthen the links between the core team and the native language communities.

4. How you spend your free time?

I love travelling with my wife to discover geographies I have never visited, but I love free and open source software, so I also spend lots of my free time attending conferences or local community meetings, to speak about open source software, open standards and – of course – LibreOffice.

5. What is your personal perspective about the LibreOffice project?

LibreOffice is the dream of the community turned into reality: an independent self-sustaining foundation able to push forward the free office suite concept, and to educate users about the advantages of open source software and open document formats.

History forced the community to reconsider the situation and it turned out it was the right time for a paradigm shift: after 10 years under an umbrella, we turned the umbrella upside down into a mixing bowl, where the contribution of every volunteer became a key ingredient for the recipe.

In September 2010, we did not realize that we were writing a new chapter of the open source history. Today, we are fully conscious of the fact that The Document Foundation and LibreOffice are key assets of the open source ecosystem, and as such share a huge responsibility.

LibreOffice is one of the open source “icebreakers”, as it is one of the first open source programs installed on Windows and macOS individual desktops, together with the browser and the email client. It is also the first open source program used to replace the proprietary counterpart in enterprises and public administrations.

6. What do you see as the most important challenges for TDF in 2018 and beyond?

With the publication of the first “alternatives to LibreOffice” articles in the media in early 2017, we have reached the status of recognized leader in the area of free office suites.

So, the first challenge is to keep up with the expectations of stakeholders: journalists, who have silently elected LibreOffice as the main alternative to the market leader; decision makers, who have made a bet on LibreOffice when they have decided to replace proprietary suites; and our millions of users, who are relying on LibreOffice for their daily duties.

The second challenge is to keep the ball rolling, major release after major release. LibreOffice is constantly improving, adding new features and improving the existing ones, and getting rid of some rough corners inherited from

Last, but not least, we have the responsibility of educating public administrations and enterprises, and even individual users, about the advantages of open document formats for interoperability. Unfortunately, this is not an easy task, as the majority of people underestimates the importance of the topic (and has not been educated about interoperability).

7. Where do you see TDF and LibreOffice in 2020? And in 2025?

When we launched the project in late September 2010, we told the media that our dream would have been to reach 200 million users in 2020. After seven years, we are on track. So, let’s avoid any speculations and continue to work on a daily basis to improve the software and grow the community.

8. What is your opinion about TDF achievements? Is there anything we could have achieved if…?

Of course, we could have done even more to grow the community since the first day. Especially during our initial setup phase, though, our resources were limited and we had to balance between bootstrapping the foundation, improving the product and communicating to raise the awareness.

From the results we have been getting during the last couple of years in term of community development, I think that it was the right decision, as we managed to establish the brand and raise the awareness to keep the flow of downloads and donations (which has been key, so far, to support the different activities, including the growth of the community).

9. Are you contributing to other open source projects? If yes, which is your role, and which are your expectations?

I am currently a member of the board of directors at Open Source Initiative (OSI), where I try to bring my marketing and communications experience to grow awareness.

10. Last, but not least, what is your personal hardware/software configuration? Do you have any preferred tool?

I have been a Mac user for a long time, based on the fact that Apple is the system of choice for most public relations agencies. I still own a couple of Macs, but I am now a happy GNU/Linux user. I use a Dell XPS laptop with Ubuntu 16.04, but in the future I will switch to a vendor providing GNU/Linux based laptops, as Dell is no longer selling them in Europe. I also have an Android-based ASUS Zenfone 4, and an Android based Samsung Galaxy Tablet 2.

by Italo Vignoli at March 19, 2018 03:10 PM

March 16, 2018

Official TDF Blog

Prepare for Document Freedom Day on March 28

Document Freedom Day is planned for March 28, 2018. If you are organizing an event to celebrate it, please remember to register it on the website.

by Italo Vignoli at March 16, 2018 04:39 PM

March 14, 2018

Official TDF Blog

LibreOffice Certification @ FSF LibrePlanet

Berlin, March 14, 2018 – The Document Foundation will present LibreOffice Certification to Free Software Foundation Members and free software advocates attending LibrePlanet in Boston. Lothar Becker, co-chair of the Certification Committee, will talk about migration projects and training activities related to LibreOffice, with the objective of helping enterprises to achieve the freedom associated with free software and open document formats.

Lothar Becker will present LibreOffice Certification on Saturday, March 24, during LibrePlanet, and will host a certification focused workshop on Monday, March 26, from 9:30 AM to 1:30 PM.

LibreOffice Certification has been extended to FSF Members in 2017, based on the same professional pre-requisites of TDF Members. The workshop will offer a thorough overview of the skills requested and a summary of TDF’s migration and training protocols. Participation is free but must be booked in advance by sending an email to

In addition, on Sunday, March 25, there will be an international certification review session for applicants for migration and training based in South America and Spain. Reviewers and applicants will join Lothar Becker, chairing the session, using a video conference system based entirely on free software from end to end.

For additional information, please write to

by Italo Vignoli at March 14, 2018 03:25 PM

March 13, 2018

Official TDF Blog

LibreOffice and Google Summer of Code 2018 – get involved!

Google Summer of Code (GSoC) is a yearly programme in which Google funds university students to work on free and open source software projects. LibreOffice has benefited from this – last year 10 students were accepted into GSoC to do various programming jobs, helping to improve the software.

GSoC students are assisted by experienced “mentors” in the LibreOffice community, as 2016 student Jaskaran Veer Singh explains:

For 2018, LibreOffice is again an organisation in the GSoC programme, so if you’re a university student and want to get experience working on a well-known free software project, while also being paid for your efforts, get involved! But don’t delay: the application period runs until March 27, so it’s not far off.

To get started, check out some ideas for projects you can work on. Each project describes what’s involved, the skills required, and the mentor you can contact to get help. If you see something you’d like to work on, contact the mentor as soon as possible! Then you can discuss how to proceed.

After that, read the general GSoC 2018 page on our wiki, which provides more information on the GSoC programme and tells you how to apply. So, check out the ideas, talk to the mentors, and good luck with your projects!

by Mike Saunders at March 13, 2018 01:52 PM

Collabora Community

Recent Mac-specific fixes in LibreOffice


Over the past months, we have been able to make some resources available to look into the most urgent Mac-specific bugs in LibreOffice, thanks to people purchasing LibreOffice Vanilla on the Mac App Store.

We addressed all the high priority Mac regressions

A few bugs were related to use of various 3rd-party fonts on macOS. The system APIs used by LibreOffice to enumerate installed typefaces and their styles indicate the weight of the font as a floating-point number between -1.0 and 1.0, with zero being “regular” weight. That number needs to be converted to an integer (with just ten separate values) used in LibreOffice. The mapping is heuristic, and it turned out that tweaking the mapping just a little bit made it possible to distinguish between some weights of a typeface that had previously mapped to the same weight in LibreOffice.

Another issue was that for some other 3rd-party fonts, the system API claimed that the weight of the “Regular” style was non-zero and positive (0.23 to be exact), i.e., a bit on the bold side. LibreOffice trusted that, which lead to the bold style always being selected for those typefaces, even when asking for a non-bold, regular (medium) weight. The fix for this was to simply handle these special cases separately. If resources allow and more similar problematic fonts are identified, some more generic fix would be needed.

Another set of bugs were related to notifications for screen parameter changes (like when changing the size of the Dock, or attaching or detaching monitors). On some Macs, the system sent these notifications quite eagerly for no obvious reason. LibreOffice was asking to receive such notifications too early before it was prepared to handle them. This lead to a crash. The fix was to request notifications only once being prepared to receive them.

Also, the handler for this notification did not check whether anything had actually changed that LibreOffice would want to know but just went through all the motions of re-calculating layouts of GUI and sizes of text and whatnot, totally in vain. This took a considerable amount of time when you had a lot of document windows open and several of these notifications were received. The fix here was to add a check if anything actually had changed that would be of interest to LibreOffice, and if not, just don’t proceed to do any re-calculations of layouts etc.

Finally, there was a problem with inserting videos in Impress presentations. When doing that LibreOffice (for some reason) copies the video file first into a temporary copy. That copy was given a name without file name extension. The system APIs used to open and display the video did not like that and displaying even an initial grabbed frame from the video failed. The fix was simply to make sure the copy of the video file had the same file name extension as the original one.

We’ll be addressing more Mac issues as when as we sell more LibreOffice Vanilla. Why not get involved to ensure they’re well triaged and prioritized!

Read more details how Collabora started maintaining LibreOffice Vanilla in the Mac app store.

Download now!

The post Recent Mac-specific fixes in LibreOffice appeared first on Collabora Productivity.

by Jona Azizaj at March 13, 2018 11:02 AM

Tomaž Vajngerl

Improving the image handling in LibreOffice - Part 2

It's been some times from my last blog post and in that time I continued with refactoring the code to get rid of use of GraphicObject uniqueID being passed around and stored in the model. The state of the code now is looking fine as we almost don't use the uniqueID anymore, which means that I can start with the next step of Graphic and GraphicObject improvements. 

There is a thing I forgot to clarify in the last blog post and this is that the GraphicObject uniqueID is usually passed around in the form of a URL string. The string has the prefix "" and followed by the GraphicObject uniqueID. Using that URL it is possible to re-create a GraphicObject by passing the unique ID as the construction parameter (see constructor with OUString parameter on GraphicObject or UNO serviceGraphicObject::createWithId).

Usage in filters

The most "heavy" users of the uniqueID were the document format filters (xmloff, oox & writerfilter) which generally use it to read the images from the storage (usually ZIP) and convert the GraphicObject and pass GraphicObject uniqueID around. At writing it does the reverse, get the GraphicObject URL and "resolve" the URL to the package URL. At conversion the GraphicObject is created and the image is stored into the storage. To do this there XGraphicObjectResolver published UNO interface which has only resolveGraphicObjectURL which converts a GraphicObject URL to the Package URL and back. 

Resolving the URL is not the correct approach anymore so I had to do it in a different way. The result of that is XGraphicStorageHandler, which has explicit method to load and save an XGraphic from the package URL, which does everything without the need to use the GraphicObject unique ID.

In addition a graphic can also be external - somewhere on the disk or internet, identified by an external URL. For this case I implemented a GraphicLoader, which is generally just uses XGraphicProvider to load the graphic (in one of the next steps this will be reversed so that XGraphicProvider is just a UNO interface that uses GraphicLoader).

The special case with external URLs is also that we need to remember the URL, which was used to load the graphic, so that we can later just save the URL and not the Graphic into the storage. Previously the URL was always passed along as string so this wasn't a problem, but now we pass XGraphic. So for this I had to extend the Graphic in VCL with an origin URL attribute, to solve this use case. In a next steps the URL loading will be extended even more so the Graphic itself will handle URL completely transparently to the outside.

UNO properties

Usually the filters used the UNO API to set the GraphicObject unique ID into the document model. This was mostly implemented as a properties on various interfaces in UNO. Mostly used name of the properties was GraphicURL (used in different places), but there were also other properties: 
  • BackGraphicURL (for backgrounds)
  • HeaderBackGraphicURL (for backgrounds in header)
  • FooterBackGraphicURL (for backgrounds in footer)
  • ParaBackGraphicURL (for backgrounds in paragraphs)
  • ThumbnailURL (for thumbnail of a graphic - not in IDL)
  • ReplacementGraphicURL (for replacement graphic - not in IDL)
  • FillBitmapURL (BitmapTable)
All these properties are now deprecated and removed and an alternative was added (where needed) that uses the XGraphic or XBitmap types (they use the same implementation so either can be used). This was done as following:
  • GraphicURL -> Graphic (type XGraphic) and GraphicBitmap (type XBitmap) for bullets
  • BackGraphicURL -> BackGraphic (type XGraphic) 
  • HeaderBackGraphicURL -> HeaderBackGraphic (type XGraphic)
  • FooterBackGraphicURL -> FooterBackGraphic (type XGraphic)
  • ParaBackGraphicURL -> ParaBackGraphic (type XGraphic)
  • ThumbnailURL  -> Thumbnail (type XGraphic)
  • ReplacementGraphicURL -> ReplacementGraphic (type XGraphic)
  • FillBitmapURL -> FillBitmap (type XBitmap)
There is also ImageURL which is used in form controls, but this was still left inside as there is already a Graphic property which is an alternative.

As the GraphicObject URL is going away (they won't be created anymore and won't be possible to get the GraphicObject back using the URL), so will the properties, as the content of them won't make much sense anymore.

Next steps

The next step is now to finally work on Graphic itself, which I'm much more excited about. The managing of memory (GraphicManager) will move from the GraphicObject to the Graphic itself.  When a new Graphic is created, the original bit-stream needs to be saved immediately to the temp folder, where the Graphic can always load the image again and is always free to release the memory if needed (this also means it won't need to load the image to the memory until it is actually needed). With this I think that handling of images will finally be a lot more predictable and homogeneous (no different implementations of things through different modules) and we can actually introduce new features in the future much more easily. 

Back to work...


Many thanks to Collabora Productivity, TDF and users that support the foundation by providing donations, to make this work possible.

by Tomaž Vajngerl ( at March 13, 2018 09:30 AM

March 12, 2018

Michael Meeks

2018-03-12 Monday

  • Practice with E. scales decaying over the weekend; hmm. Mail chew, sync with Miklos. Lunch with J. Sync with kendy, call with Jeroen. TDF call. Stories in the evening - Asimov for E. Max Lucado for H.

March 12, 2018 09:00 PM

Andreas Mantke

Helped A Colleague With A Broken Notebook Hard Disk

I worked on a notebook of colleague with a broken hard disk during the weekend. I removed the old disk and added a solid state drive to it. I installed also operating system to the new disk and in addition she got some free software on it, particularly the new LibreOffice 6.

by Andreas Mantke at March 12, 2018 08:59 PM

March 11, 2018

Michael Meeks

2018-03-11 Sunday

  • Up, cooked breakfast in bed for J. with M. - presents, cards, a banner, etc. for the sweetheart. Out to All Saints, played bass; enjoyed Max's sermon. Home for roast lunch.
  • Slugged; digested; played guitar much of the afternoon while babes played lego (a break from minetest), and Smash-Up. Julie over for tea.

March 11, 2018 09:00 PM

March 10, 2018

Michael Meeks

2018-03-10 Saturday

  • Poked mail, took H. to practice the Organ & got a bit of hacking done. Back for lunch. Watched Lost in Space (with not much to recommend it) in the afternoon.

March 10, 2018 09:00 PM

March 09, 2018

Michael Meeks

2018-03-09 Friday

  • Out for a run; mail, customer calls, poked at projections.
  • Poked at EC2 hosting of minetest again in the evening with N.; SLE12 too stale, and/or games not compiled for it; decided to try flatpak having played with snap the other day. Far from ideal for a head-less server use on a remote machine; the app store gives .ini files rather than a simple command-line to install. Installing files demands a server to install from rather than noticing I have just one, and the app is in it. The command-line demands very.long.qualified.names rather than being helpful. I assume this works beautifully from the GUI, and I'm a victim of a corner-case.
    Running a new OS underneath chews enough RAM to require a more expensive instance too - upgraded that, it works; hmm.

March 09, 2018 09:00 PM

Florian Reisinger

SI-GUI statistics


I have not talked mich about SI-GUI statistics lately so here some numbers 😉

Since logging every action (this can be turned off)…

  • 6990 parallel installation have been started (and 6022 of them finished successfully)
  • 6327 downloads have been started with 4833 fining their way in the download statistics [if someone has problem downloading LibreOffice, please tell me]
  • Most people use English (4338), French  (1669), Spanish (1251) and German (1327)

There have been SI-GUI version with bugs in reporting, which could hint to the numbers are not 100% accurate (to low and not to high BTW)

I hope it is still useful for the 33 people, which used this tool in the last week. Do you think it will stay relevant when auto updating nightly builds are implemented?



by Florian Reisinger at March 09, 2018 09:41 AM

March 08, 2018

Michael Meeks

2018-03-08 Thursday

  • Customer call at breakfast; fun. Sync with Miklos. Call with Eloy. ESC call, posted minutes. Out with Richard Wood in the evening for a pleasant drink / catch-up.

March 08, 2018 09:00 PM

Official TDF Blog

Happy Women’s Day

Our inclusive global community celebrates March 8, International Women’s Day, with a tribute to LibreLadies, the group of female volunteers who contribute to the LibreOffice project in different areas. The picture was shot In Rome during the LibreOffice Conference. Marina Latini, first right, has been recently confirmed as TDF Chairwoman (and as such is the longest running BoD Chair since the birth of The Document Foundation in February 2012). Katharina “Bubli” Behrens, first left, is a leading developer. Sophie Gautier, middle (grey hoodie), is a key member of TDF Team, and one of the oldest members of the community. Together with them, a large group of young Albanians who will be involved in the organization of the next LibreOffice Conference in Tirana, and other volunteers from other European countries.

We would like to see more women involved in the LibreOffice and the Document Liberation projects, following the leading example of the Albanian community, where over 50% of volunteers involved in free open source software – including technical roles – are female.

by Italo Vignoli at March 08, 2018 03:09 PM

March 07, 2018

Andreas Mantke

Busy Days And Volunteer Work With WordPress

I’m currently busy with my payed day work and thus have only very small ressources for voluteer work. I met with some friends today to work on a new WordPress site. We finished some tasks and talked about the future steps and the lauch of the site. We also launched a NextCloud instance and I showed a bit of the features to my friends.

Because I’ll on another meeting they will show the site and the NextCloud instance to the whole group of local volunteers during the next weekend.

by Andreas Mantke at March 07, 2018 09:05 PM

March 04, 2018

Caolán McNamara

native GTK3 message dialogs

In LibreOffice 6.1, when the GTK3 backend is in use, the message dialogs are now native GTK3 message dialogs rather than vcl message dialogs using GTK theming.

So they are now true GTK dialogs and they look like...

while before they looked like...

We have 475 message dialogs directly instantiated in LibreOffice and 89 indirectly instantiated via GtkBuilder .ui files.

We've changed the format our dialog, etc. translations are stored in from our own legacy custom format to the more commonplace gettext .mo format. In the case of a message dialog described via a GtkBuilder .ui file, we now use GTK's own GtkBuilder to load the .ui, and GTK's own gettext integration to localize it from our new .mo format translations.

by Caolán McNamara ( at March 04, 2018 04:08 PM

Eike Rathke

Project Gutenberg: Court Order to Block Access in Germany

Die Project Gutenberg Literary Archive Foundation (PGLAF) sperrt jetzt den Zugang zu allen Büchern des Project Gutenberg für IPs die Deutschland zugeordnet sind, aufgrund eines Gerichtsurteils das in Deutschland ergangen ist, weil Werke von Heinrich Mann, Thomas Mann und Alfred Döblin in USA zwar bereits gemeinfrei sind, aber noch dem deutschen Urheberrechtsschutz (Tod + 70 Jahre) unterliegen.

Es lohnt sich, die Q&A im PGLAF statement zu lesen. Money quote:

PGLAF's legal advisors disagree that any foreign Court or entity has jurisdiction over its actions regarding copyright. The Court in Germany has promoted a theory that it has jurisdition, mainly because the site has some content in the German language. The view of PGLAF is that it is up to the rights owner in Germany to identify people there who are infringing on its copyrights, and pursue remediation there.

Q: So the court thinks that the presence of content in German means that courts in Germany have jurisdiction, regardless of the fact that PGLAF is entirely in the US?
A: Yes, that was the original basis of the claim for jurisdiction, which the Court accepted in their judgement. Since then, there some more recent decisions in the European Court of Justice, and other German courts, that support this theory based on a Web site being accessible from a country.

Wenn ich irgendwelche Abos beim S. Fischer Verlag, GmbH oder anderen der Verlagsgruppe Georg Holtzbrinck GmbH (Holtzbrinck Publishing Group, Holtzbrinck Publishers LLC) hätte, würde ich die jetzt kündigen, und zwar mit Angabe genau diesen Grundes. Wer derartigen kulturellen Kahlschlag auslöst verdient es nicht anders. Auf jeden Fall werde ich in Zukunft vermeiden Bücher von angehörigen Verlagen zu kaufen. Obwohl das schwierig werden könnte, denn es sind eine ganze Reihe von Verlagen unter Holtzbrinck: Macmillan Publishers mit den deutschen Publikumsverlagen S. Fischer Verlag, Rowohlt Verlag, Kiepenheuer & Witsch, Droemer Knaur, Argon Verlag, [Quelle Wikipedia]. Leider sind die Dieter von Holtzbrinck Medien (DvH Medien), denen der Zeitverlag gehört, der Georg Holtzbrinck GmbH eng verbunden.

Gerüchtehalber gibt es wohl einige Unstimmigkeiten bei der Geo-Zuordnung von IPs bei verschiedenen deutschen Internet-Providern und ob IPv4 oder IPv6.

by erAck (23@ at March 04, 2018 01:52 PM

March 02, 2018

Miklos Vajna

Optimizing ODT ↔ XHTML conversion performance for simple documents

I worked on improving the ODT ↔ XHTML conversion performance for simple documents in LibreOffice recently. First, thanks to Vector for funding Collabora to make this possible.

ODT → XHTML conversion

The focus here was really simple documents, like just one sentence with minimal formatting. The use-case is to have thousands of these simple documents, only a minority containing complex formatting, the rest is just that simple.

Performance work usually focuses on one specific complex feature, e.g. lots of bookmarks, lots of document-level user-defined metadata, and so on — this way there were room for improvements when it comes to trivial documents.

I managed to reduce the cost of the conversion to the fifth of the original cost in both directions — the chart above shows the impact of my work for the ODT → XHTML direction. The steps that helped:

  • Recognize XHTML as a value for the FilterOptions key in the HTML (StarWriter) export filter, this way avoid the need to go via XSLT, which would be expensive.

  • Add a new NoFileSync flag to the frame::XStorable::storeToURL() API, so that if you know you’ll read the result after the conversion finished, you can avoid an expensive fsync() call for each and every file, which helps HDDs a lot, while means no overhead for SSDs.

  • If you know your input format already, then specifying an explicit FilterName key for the frame::XComponentLoader::loadComponentFromURL() API helps not spending time to detect the file format you already know.

Note that the XHTML mode for the Writer HTML export is still a work in progress, but it already produces valid output for such simple documents.

XHTML → ODT conversion

The chart above shows the results of my work for the XHTML → ODT direction. The steps to get to the final reduced cost were:

  • The new NoFileSync flag, as mentioned previously.

  • A new NoThumbnail flag, which is useful if the ODT will be part of a next step in the pipeline and you know that the thumbnail image won’t be used anyway.

  • The default table autoformat definitions in Writer are now lazy-loaded. (This is my favorite one, you don’t have to opt-in for this, so everyone benefits.)

  • A new HiddenForConversion flag for frame::XComponentLoader::loadComponentFromURL(), which means we don’t lay out the UI elements (toolbars, sidebar, status bar, etc.) when we know the purpose of the document load is only to save the document model in an other format.

All this is available in master (towards LibreOffice 6.1), or you can grab a daily build and try it out right now. :-)

March 02, 2018 08:20 AM

February 28, 2018

Tamás Bunth

DBMS migration in LibreOffice: HSQLDB binary import

Last time I wrote a blog post about the challenges of some Firebird bugs in LibreOffice, and the main concept of implementing the schema import of HyperSQL databases inside a Base document.

Since lately, I continued working on the tender published by TDF with Collabora. Next step was to create a way of importing table rows from a HSQL database. Base creates tables as CACHED tables – meaning in HSQL terminology that data is stored on disk, and pulled up to memory in demand – which implies that the data is stored in a binary file near the schema description.

To interpret the binary file, we get some help from the “script” file, which contains metadata for the database. For each table there is a statement which pairs a set of numbers to them (SET TABLE … INDEX … ). These numbers are file pointers to the root element of AVL trees. Each node of the tree stores a row.

In order to read a row from the table, it is necessary to know the ordered set of its column types, because the row does not contain this information. Fortunately, the column types are known from the schema import.

The next step is to read the data of each column in a row. The data is stored continuously in the file and each type has its own format. For example, the VARCHAR type is stored as follows: The first 4 bytes can be interpreted as an (unsigned) number, which tells us the size – number of unicode characters – of the string. The next array of bytes contains the string itself.

Finally, we have to adopt the data with the new DBMS. For that I use the sdbc layer’s PreparedStatement. By calling the appropriate setXXX method, and executing the statement, the data is finally migrated to the new database.

For those, who were enthusiastic enough to read this post so far, this is the related commit on gerrit:

The job is not done yet. There are some type interpretations which are not implemented yet (e.g. Date/Time, Numeric/Decimal). Also I intend to write unit tests for the whole library, and I expect some upcoming problems while testing it with different databases.

by Bunth Tamás at February 28, 2018 09:48 PM

LibreOffice Design Blog

Easyhacking: All about terminology

Sometimes you may find galimatias in the user interface such as quirky captions, misleading descriptions, too long or to short texts, and strings that are not compliant to the guideline. Why not take this as the perfect start into easyhacking?


As explained in the posting on How to set up your environment, you can always search for unique strings.…

The post Easyhacking: All about terminology appeared first on LibreOffice Design Team.

by The LibreOffice Design Team at February 28, 2018 10:57 AM

February 22, 2018

LibreOffice Design Blog

Easyhacking: How to set up your environment

User-centered development is implicitly steering the development from the top of the cathedral. That means to start with a vision, the context of use, and the primary users etc, granularized later into product requirements with storyboards and use cases, and finally iterating with product design and development.…

The post Easyhacking: How to set up your environment appeared first on LibreOffice Design Team.

by The LibreOffice Design Team at February 22, 2018 11:15 AM

Björn Michaelsen

Invitation to the LibreOffice Hackfest Hamburg 2018 on April 7th and 8th

… for a holiday of working class
She’s a runaway of the establishment incorporated
She won’t cooperate
— Last of the American Girls, 21 Guns, Green Day

Its once again time to meet again in Hamburg for a LibreOffice Hackfest! We will meet with contributors to LibreOffice – old and new – and also welcome those who have not yet contributed to the project, but are interested in doing so. This will also be the first Hackfest TNG.

We will have EasyHacks prepared for anyone wanting to do their first code contribution to the project – and we will have mentors around who may provide guidance to every interested newcomer. An Hackfest is the easiest way to get involved for a curious newcomers to the project: we certainly can offer an interesting C++ codebase!

Not interested in coding? As the local German LibreOffice community joins this Hackfest, non-coding topics like documentation, QA and marketing especially in the German context will be discussed too. This is an opportunity to meet those active in the German community and plan and coordinate how to push the project, the product and the brand of LibreOffice in the German context. Mixing and mingling of the German community with the international developer community is a bonus for both: otherwise this only happens at the frantic and busy meetings at FOSDEM and the LibreOffice conference, where usually time is a very restricted resource for everyone.

Note that as usual support for travel and accommodation for the Hackfest is available from The Document Foundation as per its travel policy, so please feel invited to make use of that offer, especially if you have always been curious about the LibreOffice project and you want to get involved, but are not quite sure how: a Hackfest is a great way to learn that.

So – where will we meet? Here:


This is 6Fwd – a beautiful meeting room at technologies, who are generously hosting us for this event. I am very excited about us being guests at this location and would like to thank for their sponsorship!

Details about the LibreOffice Hackfest Hamburg 2018 are kept on the TDF wiki page and will be continuously updated. If you are interested in joining the event please start adding your name there (especially if you are interested in TDF sponsoring travel and accomodation for you).

(If you are still unsure about joining the event, you can have a look at the wiki pages of previous events to get an idea. But really: the best way to learn about the project is going to a Hackfest, so dont miss this opportunity!)

by bmichaelsen at February 22, 2018 09:00 AM

February 19, 2018

Andreas Mantke

LibreOffice Non-Code Extension Creation – Templates Available

I wrote a first version of a howto about the creation of LibreOffice non-code extensions. This howto is written in German language and the source code is available from my Github repository:

I added some sample templates to this repository, one for each LibreOffice non-code extension, which I described in the howto. You could view them here:

You could check out this code samples and adapt (by editing) them to your own new LibreOffice non-code extension.

I’m keen to see your LibreOffice non-code extension inside the LibreOffice extension repository:

Happy hacking!

by Andreas Mantke at February 19, 2018 08:51 PM

February 18, 2018

LibreOffice Design Blog

Improvements to Font Listing

Font handling is a major topic for office suites and as a result, LibreOffice’s bug tracker has numerous reported issues and suggestions on how to enhance the workflow. In a past blog post, we presented a solution for font substitution and now it is time to talk about font listing.…

The post Improvements to Font Listing appeared first on LibreOffice Design Team.

by The LibreOffice Design Team at February 18, 2018 09:50 PM

Charles Schulz

Running for the board of the Open Source Initiative – a few words

Well, it has been a while I have posted anything on this blog, a little bit over a hear to be precise. I intend to post more in 2018 but I will likely not keep a regular schedule.
Today I would like to explain my reasons for my candidacy at the board of the Open Source Initiative. I can think of two kinds of reason for my decision: one is personal, and the other one is directly related to current state of Open Source and software freedom. Let’s start with the first one: I’m currently helping the Open Information Security Foundation and the Suricata project in my capacity at ANSSI, while contributing in a minor way to the LibreOffice project and the Document Foundation.
I’m also helping an exciting blockchain project called NotaryTrade, which relies both on Free & Open Source Software and Open Hardware. These are my “major” involvements at the time, and what this means is that I’m no longer focused on one community and one project like I was several years ago. The way I work and contribute, while remaining the same in many ways, has changed. What is different as well is my vantage point on the  policies affecting software freedom and I believe I could be useful to one of the most important entities in the field, the Open Source Initiative. This brings me to my second reason:

Free/Open Source Software has won. That’s not exactly new. What has NOT won however is the Free/Open Source Software as a set of principles and ideas. The entire industry is happy to reuse Open Source components but reluctant to admit they’re integrating these same components in their solutions. There’s a large part of the IT industry that does not hire contributors to Open Source projects in their capacity as Open Source projects practitioners. Yet it will gladly reuse components licensed under an OSI-approved license. In other words, a large part of the IT industry handles Open Source Software as an externality it does not have to pay for, yet relies upon for the solutions it sells and distributes.

Another worrying trend is an increase in attacks on the basic legal aspects of Open Source Software (and Open Standards as well): public policy initiatives as well as industry-wide moves aim at weakening the intellectual property tenets of Open Source and we must ensure that these trends be halted and the wider industry educated on Open Source and open standards.

The Open Source Initiative is currently in the right position to improve the standing of Open Source in the industry and defend its principles and licenses against damaging policy projects. I would like to help the OSI tackle these challenges to the best of my abilities.

You can find a short bio and a few key “agenda items” on the my candidate page and I’m of course happy to address or answer any comment posted there or here on this blog. I would also like to specially thank the Open Information Security Foundation(OISF) for its support of my candidacy. If you don’t know what the OISF does visit the Suricata project and you will discover how Open Source plays a major role in cybersecurity. Last but not least, I’m asking for your support and I hope you will help strengthen the OSI board with your vote.

by Charles at February 18, 2018 03:23 PM

February 16, 2018

>Marius Popa Adrian

Some of the few advantages of using Firebird 3.0.x is that performance was greatly improved vs 2.5.x

Here are a few related performance/tunning articles In the first article Vlad does quite a few benchmarks between Firebird 2.5/3.0.0/3.0.2 releases . It's very nice that minor releases brings free speedups. He also shows Firebird 3.0.3 performance related changes and fixes and the future ones that are already in Firebird 4    Firebird Performance, by Vlad Khorsun, Firebird Project  Tuning Linux,

by Adrian Marius Popa ( at February 16, 2018 03:30 PM

February 14, 2018

February 09, 2018

Lera Goncharuk

Variables and data types of LibreOffice Basic

I have promised for a very long time to start writing about the scripting language of programming Basic in LibreOffice and creating macros by this language. This article is devoted to the types of data is used in Basic and, to a greater extent, the rules of description and the possibility of using variables. As always, I will try to provide a maximum of information, and for this reason I hope that this simple topic will be useful not only for novice users. Separately, I would like to thank everyone who commented on the Russian article, gave their recommendations, and helped to deal with difficult questions.
Read more »

by Lera Goncharuk ( at February 09, 2018 09:20 AM

February 08, 2018

February 05, 2018

>Marius Popa Adrian

Firebird 3.0.3 sub-release is available

Firebird Project is happy to announce general availability of Firebird 3.0.3 — the third point release in the Firebird 3.0 series.This sub-release offers many bug fixes (including fix for a recently reported security vulnerability) and also adds a few minor features and improvements, please refer to the Release Notes for the full list of changes. Binary kits for Windows and Linux on both 32-bit

by Adrian Marius Popa ( at February 05, 2018 04:06 PM

Stephan Bergmann

LibreOffice 6 available at

We moved the LibreOffice Flatpak builds to Flathub a while ago, and updating to new versions is normally a pain-free process. (For us as producers of those updates, at least. For you as a user of Flatpak, the process should always be pain-free, anyway.)

However, for LibreOffice 6, building it on Flathub took a bit longer than expected:

Originally, the LibreOffice Flatpak version had lacked a JRE, so some functionality just wasn’t available. There is now a Flatpak extension that allows to bundle Java 9 with an app, so I was finally able to fix this long-standing issue.

In addition, I figured it could be useful to provide debug information for the LibreOffice flatpak (which comes as an extension that you can then optionally install with something like flatpak install flathub org.libreoffice.LibreOffice.Debug).

So I prepared the necessary changes well ahead of the LibreOffice 6.0.0 announcement, tested them locally on my x86_64 machine, and was confident that thinks would just work when I would trigger the Flathub build once the LibreOffice announcement was due. Turned out I was wrong.

First, one little aarch64-specific fix had been missing on the libreoffice-6-0 branch. No problem, just apply the corresponding master fix as a patch to the Flatpak version. Then builds started to fail randomly.

Enabling debug information for an application as large as LibreOffice can increase the size of what gets build, and the time to build it, quite substantially. I do such full-debug-information builds of upstream LibreOffice rather routinely on my (somewhat powerful) local build machine without any problem, so I didn’t even give a thought to this when enabling debug information for the Flathub builds. But it turns out that took some of the Flathub build machines (especially for less powerful platforms, like 32-bit x86) already close to the edge of their capacity. And something as trivial as applying the master-branch patch in the previous step meant that disk-space demand of the LibreOffice builds increased by yet another substantial amount (as Flatpak now needed to install the full LibreOffice git source repository, instead of taking shortcuts). That was apparently enough to move some of the builders over the edge, and into random “disk full” etc. failures.

So I weakened that debug feature again.  There is still unstripped symbol information in the Debug extension that you can download (i.e., you will see meaningful function names in backtraces), just not the whole debug data (e.g., you won’t see source file names and line numbers in backtraces, or be able to print variable values in gdb).

Meanwhile, there had been work going on to finally provide 32-bit arm builds of LibreOffice on Flathub. We had initially disabled that platform because of an issue with the version of GCC 6 that is used to do the builds. That arm-specific issue appears to be fixed with GCC 7, and there is now a Flatpak extension that allows to use GCC 7 instead of 6. And the test branch to do the LibreOffice build with GCC 7 and enable arm worked just fine. When building the old LibreOffice 5.4 version, that is.

When I tried to merge those two efforts that had gone on in parallel, switching to LibreOffice 6 and switching to GCC 7, things started to fail once again.

First off, the Java extension was not available for arm. So building on arm refused to work outright. There is work in progress to make it available, but by now LibreOffice 6 had officially been announced and available for download, and people waiting for the Flatpak version started to get impatient. So I decided to leave 32-bit arm unsupported for just a bit longer and dropped it from the list of supported platforms for the LibreOffice Flathub build again.

But things still didn’t work. The aarch64 build kept failing one of the tests that are executed during the build of LibreOffice. Sometimes these tests are a bit flaky and fail for “random” reasons. So I scheduled multiple builds, just to be sure. But, for sure, aarch64 kept failing, always during the same test.

I had kept using GCC 7 for these builds, even after the original reason for it (to enable 32-bit arm builds) was gone. Looks like there is some issue with building LibreOffice 6.0 with GCC 7, on aarch64 (which I still need to track down in detail). When I switched back to GCC 6, all builds were finally green. And were allowed into the Flathub repo, from where you can install/update them.

(That happened on Friday, just in time to get the LibreOffice 6 Flatpak version battle-tested at FOSDEM. I know at least gicmo’s and my presentations were powered by that version, without a glitch.)

by stbergmann at February 05, 2018 01:43 PM

February 04, 2018

Andreas Mantke

Further Work On Plone AddOns For LibreOffice Extensions/Templates Site

I fixed some internationalization issues within the Plone addons I used to run the LibreOffice extensions and templates website. I added also a function that searches for the latest unstable release of a project. If there is such unstable release it will be shown to the user of the website. I added a new slot to project view for this. The updated code is available in the github repository of The Documenta Foundation yet. It will soon be released and incorporated in Plone instance of the LibreOffice extensions and templates website.

by Andreas Mantke at February 04, 2018 11:50 AM

Miklos Vajna

EPUB export in LibreOffice Writer FOSDEM talk

Yesterday I gave an EPUB export in LibreOffice Writer FOSDEM talk at FOSDEM 2018, in the Open document editors developer room. The room was well-crowded — perhaps because the next talk was about LibreOffice/Collabora Online. ;-)

Quite some other slides will be available on Planet I expect, don’t miss them.

February 04, 2018 09:14 AM

February 01, 2018

>Marius Popa Adrian

In 2017, The Document Foundation (TDF) launched four tenders aimed at improving LibreOffice. Tender four is of interest to the Firebird community

In 2017, The Document Foundation (TDF) launched four tenders aimed at improving LibreOffice. Tender four is of interest to the Firebird community: (4) Tender to implement HSQLDB binary format import in LibreOffice ( Collabora will develop a mechanism to import database files

by Adrian Marius Popa ( at February 01, 2018 11:47 AM

January 31, 2018

Tamás Bunth

DBMS migration in LibreOffice: Firebird and HSQLDB schema import

TDF has published tenders to improve LibreOffice in some areas, including its database management program, Base. The goal here is to implement the import of HSQLDB databases without Java Runtime Environment, in order to facilitate the change-over to
Firebird. In this post I would like to explain what steps are made at Collabora so far to achieve this goal.

Before dealing with the compatibility of the old HSQLDB-based odf files, an improvement had to be made on the Firebird driver. Within this context I implemented those types which could be created with the HSQLDB driver, but not with Firebird. Those Hyper SQL types are:

  • LONGVARCHAR, implemented as a BLOB holding text in Firebird context;
  • BINARY (fix) and VARBINARY. These types can be created as a CHAR/VARCHAR
    field with a special character set called OCTETS. This character set indicates
    that it stores binary format, and it is needed to indicate that no character
    set or collation makes sense here.
  • LONGVARBINARY. This type is responsible for holding images. As images can be
    really big, I implemented this as a subtype of BLOB.

Besides that, to prevent the changing of the DBMS back end being a setback, there were some bugs with high priority to fix. For example the impossibility to copy integer values from Calc to Base (tdf#70425) is fixed by allowing the driver to set numerical values even with the setString method, when it is called on a column with numerical type (int, smallint, etc.).

After that, in order to prepare the removal of the legacy java-based DBMS, it is needed to create a way to import the database schema and the binary data stored in older odf files without Java. Technically it means a new library in module “dbaccess”, which does all the import, and which is used in the dba (core) library when creating connection.

Splitting it to subtasks, I decided to implement the schema import first. The database schema is zipped into the odf file in a text file called “script”. This file consists of DDL statements in a strict format. The new library reads these SQL statements line-by-line, transforms it a little, and then executes them using the sdbc driver. A modification is needed in statements which contain column definitions (since the types typically differ in different systems), and there are some HSQLDB specific keywords too (e.g. CACHED tables).

The migration can be enabled using DBACCESS_HSQL_MIGRATION=1 when starting
LibreOffice. Currently, as the binary import is not ready yet, the result of the migration is some empty tables mostly.

Next step will be to implement the binary import and create unit tests for all.
the changes I have made.

by Bunth Tamás at January 31, 2018 03:48 PM

>Marius Popa Adrian

LibreOffice Firebird driver related changes

There were quite a few bugs fixed in the last two months related to Firebird driver in LibreOffice also interesting commits Tamas Bunth commited : Add HSQLDB schema import.He also fixed Bug 104734 - FIREBIRD: Add those field types that are not available with FB while they are available with Hsqldb.Lionel Elie Mamane fixed Bug 104986 - Firebird: Function EXTRACT doesn't work with WEEKDAY, YEARDAY

by Adrian Marius Popa ( at January 31, 2018 02:58 PM

Tomaž Vajngerl

Improving the image handling in LibreOffice - Part 1


It is known for some time that the image life-cycle in LibreOffice is problematic and can potentially lead to image loss, but to make the life-cycle more robust against loss, a lot of refactoring would need to be done. Another issue is also the mechanism of images swapping in and out of the memory. Keeping images in memory takes a lot of space so when a certain amount is hit, the images get swapped to disk and memory is freed. The problem is that it can happen that the cache handler starts constantly to swap images in and out (especially with with multi-megapixel images that are the norm today) and LibreOffice stalls to halt.

Because of this issues, TDF put up a tender to improve the situation with image handling and Collabora Productivity was selected to implement it, and I will do the development work.

Problems with the image life-cycle - detailed

Currently, when an image is read from a document, a GraphicObject is created for the image and handled over to the GraphicManager which manages the life-cycle. When this happens we usually get back the string based unique ID of the GraphicObject with which we can always get access the image by creating a new GraphicObject with the unique ID (GraphicManager will look for the image with that unique ID). Usually the unique ID is the one that is passed on between layers in LibreOffice (for example from ODF filter when loaded, to the model, where it is manipulated and then to the OOXML filter when saving) but the unique ID itself is just a "reference" to the image and by itself it doesn't have any control over when the image can safely be removed and when not. It could happen that in a certain situation we would still have the unique ID referenced somewhere in the model, but the image would already be removed. This is dangerous and needs to be changed. 
Usually for this kind of object we use reference counting technique, where we pass a objects around that holds a reference to the object resource. When the object is created, the reference count is increased, when destroyed, the reference count is decreased, when the reference count reaches zero, the resource object is destroyed.

The solution for the life-cycle

So instead of passing around of unique ID the idea is to use the usual reference counting technique, that is normally used in this situation. The GraphicObject in mainly a wrapper around Graphic (which then holds a pixel-based image, or animated image, or possibly a vector image), and in addition it keeps additional attributes (gamma, crop, transparency, ...). It also has the implementation of swapping-in and out (but I'll explain this another time). On the other hand Graphic is properly reference-counted already (Graphic objects are reference counting the private ImpGraphic) so the solution to the life-cycle problem is that instead of GraphicObject unique ID we would just pass along the Graphic object instead, or XGraphic, XBitmap which are just UNO wrappers around Graphic. Potentially we could also pass along the GraphicObject or XGraphicObject (UNO wrapper for the GraphicObject) when we would need to take into account the graphic attributes too. This should make the life-cycle much more manageable, but the problem is that there are many many places this needs to be changed.
I will do the work as much incrementally as possible, with ensuring that the test cover the code and if needed add new tests or extend the existing ones. 

Currently almost finished is refactoring of the bitmap table (a list of named bitmaps, mostly used for shape fills or backgrounds) to use XBitmap instead of string based unique ID in the table. For this I needed to change OOXML (oox) and especially the ODF (xmloff) filter, and the document model.


Many thanks to TDF and users that support the foundation by providing donations, to make this work possible. 

To be continued...

by Tomaž Vajngerl ( at January 31, 2018 11:10 AM

January 23, 2018


LibreOffice bitmap pattern

Do you like to use nice bitmap pattern in LibreOffice for area fill. So if you draw a rectangular, a start, … whatever you can use this bitmaps.

With the help of designers from openclipart, pixabay, publicdomainpictures, … I made 42 seamless area bitmap pattern but only 50% are needed. So which one do you like which one can be dropped.


Please comment to the bug reportt tdf#114817 or in the comment section. If you’d like to test them feel free to download the LibreOffice writer dokument.

by kdeonlinux at January 23, 2018 08:27 AM

January 21, 2018

Kohei Yoshida

LibreOffice Development Talk at Triangle C++ Developer’s Group

It was a pleasure to have been given an opportunity to talk about LibreOffice development the other day at the Triangle C++ Developer’s Group. Looking back, what we went through was a mixture of hardship, accomplishments, and learning experience intertwined in such a unique fashion. It was great to be able to talk about it and hopefully it was entertaining enough to those of you who decided to show up to my talk.

Here is a link to the slides I used during my talk.

Thanks again, everyone!

Edit: Here is a PDF version of my slides for those of you who don’t have a program that can open odp files.

by Kohei Yoshida at January 21, 2018 03:30 PM