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 above linked blog post already described the rich text and checkbox types. In this post, we’ll focus on the new dropdown, picture and date content controls.

You might wonder why content controls are useful, since Writer already has form controls and fieldmarks, which provide something similar. Here are some benefits:

The feature consists of menu items to insert dropdown/picture/date content controls, and then you can interact with the inserted content controls or with their properties:

Drop-down content controls show a dropdown button when you’re inside the content control:

This is similar to dropdown fields, just allows display-text and value pairs, not limited to just values.

Picture content controls contain a single as-character image, but you can interact with them: clicking on the content control opens the file open dialog to provide a replacement for the placeholder:

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

There is also a content control properties dialog, which allows setting if the content controls are in placeholder mode or not:

It has additional widgets for dropdowns. There is UI to create, update or delete these list items:

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 more interesting, Rashesh Padia of Collabora continued exposing this in Collabora Online, see the PR at https://github.com/CollaboraOnline/online/pull/4803.

You can get a snapshot / demo of Collabora Office 22.05 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 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).