LibreOffice 5.3 will add one more vector-based format that can be inserted as an image into documents: PDF. First, thanks to PMG who made this work possible. On the user interface you can now select PDF files when you choose e.g. Writer’s Insert → Image option:

The first page of the PDF document will be shown, which is handy if the PDF file is basically used as a vector image format.

Similarly to the SVG feature, the original vector image is stored in the document, but when saving to ODF, a replacement PNG file is also generated to be backwards compatible with older ODF readers. The image context menu → Save menu item allows to extract your original PDF data from the image, too:

And that’s it, as long as you save your document in ODF, your PDF-as-an-image will be kept without loosing any data. As usual, you can try this right now with a 5.3 daily build. :-)

However, if you’re interested in how this is implemented, keep reading…

The PDF image in the document model is really similar to how SVG is handled, next to Graphic::getSvgData(), there is now a Graphic::getPdfData(). This new member function exposes the original PDF data, otherwise the Graphic is just a metafile.

The ReplacementGraphicURL property of the image at an UNO level now exposes the generated metafile for PDF images. This is implemented for both Draw and Writer images, and is used by the ODF export filter.

When the Graphic instance is rendered, the layout knows nothing about the PDF data attached to the object, only parses the generated metafile. This way the display of the PDF image works out of the box.

First I’ve implemented a PDF import-as-graphic filter, then the export equivalent of it. As you can see, the PDF import-as-graphic filter isn’t too complicated, it completely reuses the existing "import PDF into Draw" filter, it simply copies the first page of the resulting document model as a metafile.

Second, once the graphic filters were working, I’ve also improved the ODF import to recognize PDF data — the export side needed no explicit work, once the ReplacementGraphicURL bits were in place.

As mentioned above, the Draw and the Writer image implementation is separate, so first I’ve added tests for ODT files in the testEmbeddedPdf of CppunitTest_sw_odfexport, and then SdExportTest::testEmbeddedPdf() to cover ODP files (and other ODF formats). Second, the PDF part of the graphic swapout/in code has a dedicated test in GraphicObjectTest::testPdf(), and the UI’s "Save original PDF" feature has a new XOutdevTest::testPdfGraphicExport() test.

Oh, and if you intent to test this manually in a self-created build, make sure to avoid --disable-pdfimport, otherwise this feature can’t work. ;-)

My autogen.input looks like this:

Which is a normal clang debug build, except:

My first attempt failed at build time, as even the tools used only during the build are instrumented, and some memory leak was detected there, which means the build aborted before reaching the problem I was interested in. To disable leak detection during build, and disable parallelism (I needed this, as I did the build in the background while using the machine for something else):

This also means that I explicitly disabled running any tests, as I knew which is the single unit test I want to run for the purposes of reproducing and fixing the problem.

Once the build completed, it turns out that the stack-use-after-return detection is disabled at runtime by default, which means I could not see any problem locally. Here is the commandline to run one specific CppunitTest with this detection on:

Again, this is just one possible setup, you can use other -fsanitize=... options, other environment variables during build and during testing — but hopefully it helps in the future to avoid pushing fixes for such problems detected by sanitizers just blindly.

The above described "do it yourself" way doesn’t work with LibreOffice master (towards 6.3) and openSUSE Leap 15.0 anymore. I tried to debug what is the exact problem, but there are many moving parts here:

So it’s much easier to just use the combination used by the Jenkins_Linux_Ubsan tinderbox than something custom. Doing that is reasonably straightforward, but still there are a couple of non-trivial steps. What worked for me is:

This will build a working version of both gcc and clang for you.

The 2019-01-25 setup can be fine-tuned further. Sadly LODE mixes two goals: setting up dependencies / environment and cloning repos. I recently added support for bypassing any cloning, so you can use LODE even if you already built the code and want to keep using your own way. The tricks are:

I believe this setup mostly delegates (envrionment, config switches and toolchain) maintenance to LODE, still allows not running in a chroot and managing your git clones without LODE.

These days it works to use the system clang compiler, so no need to to execute ./setup in lode.git. This means: