I worked on a new EPUB3 export filter in LibreOffice recently. First, thanks to Nou&Off in cooperation with a customer who made this work possible. The current state is that basic features work nicely to the extent that the filter is probably usable for most books (they typically mostly have just text with minimal formatting), so this post aims to explain the architecture, how the various pieces fit together.

The above picture shows the building blocks. The idea is that nominally EPUB is a complete export filter, but instead of doing all the work, we offload various sub-tasks to other modules:

The setup is a bit complicated, but it has a number of advantages:

As a user, here is a list of features you can expect working:

During development I regularly used epubcheck, so hopefully the export result is usually valid.

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

A year in LibreOffice’s PDF support was a talk I gave today at LibreOffice conference 2017. Given that this was one of the last talks at the whole conference, thanks to the ones who still did not go home, but listened. :-)

Today I gave a LibreOffice: Code Structure talk at LibreOffice conference 2017. These are an updated version of Michael Meeks' original slides, it’s actually surprised me how many things changed since April 2016. :-)

I recently fixed tdf#108963, which is a PDF export bug — in case of highlighted and rotated text in e.g. Impress, the highlight rectangle in the PDF export was not rotated.

This is how the export result looked like:

And this is how it now looks like, after fixing:

For a long time the PDF export filter had no tests at all; the current approach I introduced is that we parse the PDF export result with pdfium, which is an excellent PDF rendering library (I covered it in general in an earlier post).

So given that pdfium knows how that rectangle looks like, we should be able to query the details of it from a test as well, correct? It depends. Yes, it’s possible technically, but no, most of the pdfium functionality is actually not exposed at its public API.

The current situation is that one could use FPDF_LoadMemDocument(), FPDF_LoadPage() to get access to a PDF page, then FPDFPage_CountObject() and FPDFPage_GetObject() to iterate over objects on a page. We can filter for the relevant object by using FPDFPageObj_GetType() and FPDFPath_GetFillColor(), that will give us the only path that has a yellow fill color.

But getting more info about the geometry of the path isn’t really possible. As a workaround I went with FPDFPageObj_GetBounds() for the test, but wouldn’t it be nicer to get the individual segments (the objects that are the children of a path) and then get coordinates and other properties of a segment? This is what the recent API I added to pdfium now does. It provides the followings:

This means that after the next pdfium update in LibreOffice, PDF export tests can nicely assert these properties of paths instead of dubious bounding box should be larger after rotation assertions.

Tables and sections in LibreOffice Writer are both containers, and in some cases it makes sense to have sections inside tables or tables inside sections. (For example you can mark a group of paragraphs as read-only by including them in a read-only section.) Tables in sections, split over multiple pages was already working, but now it’s possible to have sections in tables split over multiple pages as well.

First, thanks Escriba who made this work possible.

There were 3 parts of this work, you can read some details about them below.

If you ever used the mail merge wizard with data sources, then you know how it works: it typically needs some kind of data source (e.g. a Calc spreadsheet), a Writer document containing the email or letter (that contains fields), and then mail merge can generate the personalized documents for you.

In case you have an existing document where you already have such data in a Writer table, you had to somehow transfer it to one of the formats for which there was a data source driver, and then you could use it inside mail merge. I’ve now added a dedicated Writer driver in connectivity/, so picking up data directly from Writer tables is now possible.

If you are interested how this looks like, here is a demo (click on the image to see the video):

That’s it for now — as usual the commits are in master, so you can try this right now with a 6.0 daily build. :-)

LibreOffice uses a number of external libraries, and most of them can be configured to use a bundled version or a system version. libxmlsec was an exception previously (only the bundled version was usable), but LibreOffice master (towards 6.0) doesn’t have this limitation anymore.

Using a bundled version is a good choice in case:

Using a system version is a good thing in case:

With that in mind, let’s have a look what blocked using system-xmlsec in the past:

If you are a Linux distro packager then --with-system-libs already implies --with-system-xmlsec, so you probably don’t have to do anything. If you build LO for static analysis (e.g. Coverity) then this should be also useful, so not relevant issues in 3rd-party code don’t have to be ignored manually.

Last weekend I attended the LibreOffice Perugia HackFest 2017, with the primary goal of mentoring students (together with Eike and Christian): provided they manage to contribute at least one non-trivial easy hack, they get university credits for their work.

I worked with Arianna, Claudio, Francesco and Gian, all of them managed to achieve something by the end of the third day.

When I was not helping others, I also fixed a few bugs:

Some photos I took during the event are available.

Thanks the organizers for the great event, also kudos to Collabora, Red Hat and TDF for allowing mentors to come! :-)

This post summarizes the plumbing work around ODF/OOXML digital signatures that I did on LibreOffice master after the 5.3 branch-off up to now. The big thing is the integration of the libxmlsec 1.2.24 release. Among other things, this contains 2 larger changes that I contributed upstream triggered by the needs of LibreOffice:

After the release I also noticed that creating signatures on Windows was broken, this is now fixed on xmlsec master and also backported to LibreOffice.

All this is available in LibreOffice master, towards 5.4.

This is a follow-up to the previous post that described how it is now possible to insert a PDF file as an image in LibreOffice and export that back to PDF, while keeping the original PDF contents. I’ve recently improved this feature so the resulting file is smaller and the vector image can be viewed in more viewers. First, thanks to PMG who made this work possible.

Let’s look at the previously mentioned front page of a magazine sample when it’s viewed in okular. (A KDE pdf viewer, i.e. something that’s not Adobe Acrobat). The previously used reference XObject PDF markup is not handled by it, so the bitmap fallback was displayed:

Compare it with the new result:

Notice the sharp text in the first line.

Also the size of this sample is smaller now, since we don’t write a large bitmap, and the not shown second page of the PDF image: 2 385 984 → 1 605 558 bytes (about one third of the output is avoided).

Both techniques have pros and cons, here is a summary:

Nevertheless, the new approach seems like a much better default, so LibreOffice no longer writes the reference XObject approach unless you explicitly request it in the PDF export dialog.

Some perhaps interesting details:

All this is available in LibreOffice master, towards 5.4.