Word users expect to be able to import their document to Writer and experience a matching feature set: form filling is not an exception. Word provides several content control kinds (inline, block, row and cell content controls), this project focuses on inline ("run") content controls.

In the scope of inline content controls, the plan is to support rich text, checkbox, dropdown, picture and date content controls. This blog post presents the already implemented rich text and checkbox types.

You might wonder why content controls are useful, since Writer already has form controls and fieldmarks, which provide something similar. Here are some properties of content controls, which make them incompatible with field-based fillable forms or form controls:

The feature consists of menu items to insert rich text or checkbox content controls, and then you can interact with the inserted content controls:

Rich text content controls simply show an indicator when you’re inside the content control:

This is similar to input fields, just allows rich text content, not limited to plain text.

Checkbox content controls contain a single character, but you can interact with them: clicking on the content control toggles the checked state of the checkbox:

And these content controls can be saved to ODT and DOCX.

If you would like to know a bit more about how this works, continue reading… :-)

As usual, the high-level problem was addressed by a series of incremental commits:

To make this even more interesting, Rashesh Padia of Collabora started exposing this in Collabora Online, see the PR at https://github.com/CollaboraOnline/online/pull/4703.

You can get a snapshot / demo of Collabora Office 2022 and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).

Word users expect to be able to import their documents to Writer and experience high fidelity rendering: this means Writer has to support clearing breaks, which instruct the layout to put the next line after a line break not necessarily at the next available vertical position, but perhaps the next line should "just down" to the next full line, or perhaps just do this partially. (Jump down to the next line, so no anchored object causes an additional indentation on the left or right side.)

The easiest case is the "none" clearing break, i.e. when it’s not actually clearing. This looks like this:

This is just a plain line break, and there are no changes here. It used to look like this in the past as well:

And both match the reference rendering:

Now, what’s more interesting is the "all" clearing break, when the next line is placed in a way that it’s a full line. Figure 1 already shows how it now looks like in Writer. Here is how it used to look like:

Finally you can compare that with the reference:

This is the most interesting case, and Word still provides UI to insert such breaks, so it frequently appears in documents out there. But there are two other cases, still. The "left" clearing break "jumps down", below anchored objects on the left. Here is how it looks now in Writer:

And this is how it used to look like:

Finally you can compare that with the reference:

The last case is the mirror of this, when the "right" clearing break "jumps down", below anchored objects on the right. Here is how it looks now in Writer:

And this is how it used to look like:

Finally you can compare that with the reference:

Other than the layout, there is also user interface for this in both LibreOffice and Collabora Online:

If you would like to know a bit more about how this works, continue reading… :-)

As usual, the high-level problem was addressed by a series of incremental commits:

You can get a snapshot / demo of Collabora Office 2022 and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).

Word users expect to able to import their documents to Writer and experience high fidelity rendering: this means Writer has to support the way page / table / paragraph borders are painted according to the OOXML model as well. This is all done conditionally, so existing ODF documents are left unchanged.

This is a set of 5 bugfixes, requested by multiple of our customers.

First let’s look at the new render result for page borders:

And this is how it used to look like:

Finally you can compare that with the reference:

What you can see here is that the page has a double border: the outer line is thick and the inner line is thin. The right and bottom border was incorrect as our result was the opposite of the reference.

Second, let’s look at the new render result for table borders:

And this is how it used to look like:

Finally you can compare that with the reference:

You can notice a number of problems here:

The new render result properly clips the inner border lines, so they don’t intersect outer borders, and the border mirroring (similar to the page borders) is now correct for table borders as well.

Third, let’s look at the new render result for paragraph borders:

And this is how it used to look like:

Finally you can compare that with the reference:

What’s visible here is that some paragraph inside the table cell had borders defined, but due to how the reference clips these borders, this border was not visible. That unexpected border is now also omitted in Writer.

If you would like to know a bit more about how this works, continue reading… :-)

As usual, the high-level problem was addressed by a series of bugfix changes.

For the page border:

For the table border:

For the paragraph border:

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).

I was working on a regression that only happens if you export the second and third pages of a document to PDF. While investigating, I needed a quick way to trigger the problematic code-path, and clicking through a dialog is not convenient.

The PDF export in LibreOffice has a lot of options, but those are only available from extension code (using the UNO API) or from the UI dialog. The idea was to expose much of this to the soffice --convert-to command as well, and if we’re at it, also to the /cool/convert-to endpoint of Online.

Here are a few examples to show the possibilities:

And the best is that the same also works in Online, e.g.:

If you would like to know a bit more about how this works, continue reading… :-)

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).

For the Online side, see the CODE page, the feature is present in the current release (2021).

PowerPoint users can attach a set of colors (and fonts, formattings) to master pages, and then refer to these in shape text, shape fill, shape geometry. You can even make the original color lighter and darker. These effects are preserved when you change the theme colors.

This is a larger feature, this blog post shows how theme colors can be defined and how to refer to those colors from Impress shape text. The rest of the feature is to be done in follow-up steps.

Here is a demo that shows how it works:

In other words, it consists of 2 parts on the UI:

This later shows a grid of colors: each column is one theme color and then the column offers various lighter and darker variants of the color.

And the important bit: if you later change theme colors, then the color of shape text (using theme colors) is updated, even the effects (lighter or darker variants) are preserved.

To set expectations, this only works for shape text for now, and only in Impress, as a start.

If you would like to know a bit more about how this works, continue reading… :-)

As usual, the high-level problem was addressed by a series of small changes. The first step was to upstream work by Tomaž Vajngerl and Sarper Akdemir from the feature/themesupport2 feature branch:

The rest of the work was to go through the usual stages of document model, UNO API, rendering, ODP/PPTX filter and UI work to complete the work started on the branch:

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).

The Update all menu item already updates all sorts of generated content: fields, table of contents, charts, the document layout, but not the preview of embedded objects. You could work this around by double-clicking on the embedded object to re-generate the preview, but doing this manually for a larger document is not efficient. This is especially useful for hand-crafted documents which have proper native data, but no preview image yet.

Here is how an embedded object without a preview looks like:

Now using the Update all menu item turns a sample document into this preview:

If you would like to know a bit more about how this works, continue reading… :-)

sw: update previews of OLE objects on "update all" is the change implementing this small feature. It works by:

Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release (7.4).

Word allows linking paragraph and character styles together, which means only the paragraph one will be present on the UI. Such a split has benefits if you customize the character properties on the UI and later you want to update the paragraph properties from a template, for example.

This is frequent markup in DOCX files, because Word defaults to splitting out the character properties of a Test paragraph style into a Test Char character style on editing.

Saving the document in Writer and then viewing it in Word lead to loosing these links, so their style pickers started to show unwanted Test Char rows.

We used to preserve such linking information when doing DOCX → DOCX conversion for a while, since about 2013. But such preservation was in-memory, so if you saved the document to ODT, then such information was lost. This approach also lacked a real document model, which is necessary to incrementally build this feature into a complete solution.

Here is how the style picker in Word looks like now, after a DOCX → ODT → DOCX pipeline:

Here is how this used to look like before the new changes (note the Heading 1 Char line between Heading and Index):

And here is how the input document looks like:

If you would like to know a bit more about how this works, continue reading… :-)

Just to set expectations, this is currently an invisible feature, but unlike the old approach from 8 years ago, this one can be extended into a full feature, incrementally. It also survives ODT roundtrips.

Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release (7.3).

We got a PPTX document, which has a table shape with pink background and a blurry shadow. Impress rendered a red background, making the text hard to read.

The request was to improve the shadow rendering to be PowerPoint-compatible and in general correctly support transparency when it comes to table cell fills and table shadows.

The table shadow now looks like this:

Matching the reference rendering:

While background was red previously:

You can see that not only the background in the top center cell is pink now, but the blurry table shadow is still correct.

If you would like to know a bit more about how this works, continue reading… :-)

As usual, the high-level problem was addressed by a series of fixes:

With these, it’s now possible to add transparency to both table cell fills and to table shadows, and the rendering will take both into account, correctly.

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.3).

A paragraph might have an associated list in Writer and that list can have multiple levels. This is direct formatting. When it comes to paragraph styles, referring to a list was already possible, but defining a custom list level was not.

Loosing this information in Word documents was quite annoying, and it turned out that ODF also has markup for this, just LibreOffice didn’t implement it.

This work is currently done for the document model, scripting API and file filters: style previews & UI still needs finishing.

Writer can at the moment preserve list level info from ODT and DOCX files. Here is how a file written by Writer looks like in Word:

You can see that the style preview in Word takes the list level into account. Doing the same and applying the list level as part of applying the paragraph style on the Writer UI is still future work.

Thanks to Justin Luth who did the follow-up work to adapt the DOC filter accordingly, and also doing other related fixes.

If you would like to know a bit more about how this works, continue reading… :-)

Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release (7.3).

I was working on a testcase for tdf#132696 when I noticed that the existing CppunitTest_oox_drawingml testsuite runs fine before my changes, also a newly added testGroupShapeSmartArt testcase runs fine in isolation, but if I run the whole testsuite, then it breaks.

Further investigation revealed that in case testGroupShapeSmartArt is executed first, then testTdf131082 fails. This means:

And at this point information from the first document is leaked to the second document, even if the first document was already closed by the time we performed the save. It turns out the root cause was i#114206 (reported in 2010), i.e. group shapes shared their property values till they got inserted to the document model. The first document import did not consume pending SmartArt properties on a to-be-inserted group shape, the second import was looking for pending properties, found them. And then the second document’s save wrote those pending properties to the file, leading to this unexpected leak.

Here is how the first document looks like, containing the blue rectangles (a SmartArt):

Here is how the second document looks like, without a SmartArt:

And here is how the second document looks, after saving to PPTX and reloading:

The fix is to split out part of SvxItemPropertySet to a separate class, so that we can keep sharing SvxItemPropertySet between multiple instances of the same shape type (describing the name and type of the various properties), while introducing a new SvxItemPropertySetUsrAnys that is specific to each not-yet-inserted shape. This way each pending shape is independent, and in case they are not inserted to the document model later, that results in no side-effects.

Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release (7.3).