Index ¦ Archives ¦ RSS

Content controls in Writer

Estimated read time: 4 minutes

Writer now has the start of content controls: a new way to set properties on a piece of text, primarily for form filling purposes. This feature improves compatibility with the DOCX format: inline content control types "rich text" and "checkbox" are the first two types we can now import.

https://share.vmiklos.hu/blog/sw-content-controls/feature.png
Figure 1. Word-style inline content controls in Writer.

First, thanks to NGI DAPSI who made this work by Collabora possible.

https://share.vmiklos.hu/blog/sw-content-controls/eu.png
Figure 2. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871498

Motivation

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:

  • inline content controls can’t span over multiple paragraphs, while this is allowed for fieldmarks (bookmark-based fields)

  • content controls must be well-formed XML elements, this allows nesting (while Writer fields can’t be nested), but does not allow the start/end position to be a random place in the document (while this is allowed for fieldmarks, which have separate XML elements for start and end)

  • content controls just have a set of properties, while fieldmarks are supposed to have a field command and a result (with a separator between the two)

  • content controls can contain rich text (full set of character formatting), while Writer fields can only have one character formatting (e.g. half of the field can’t be bold)

Results

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

https://share.vmiklos.hu/blog/sw-content-controls/menu.png
Figure 3. Menu items to insert rich text and checkbox content controls.

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

https://share.vmiklos.hu/blog/sw-content-controls/rich-text.png
Figure 4. A rich text 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:

https://share.vmiklos.hu/blog/sw-content-controls/checkbox.png
Figure 5. Checkbox content controls.

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

How is this implemented?

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.

Want to start using this?

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).


Clearing breaks in Writer

Estimated read time: 4 minutes

Writer now supports what we call clearing breaks: a new property on line breaks which controls where to put the next line in case the line break is at the end of a line which intersects with an anchored object. This feature improves compatibility with the DOCX and HTML formats.

https://share.vmiklos.hu/blog/sw-clearing-break/all-new.png
Figure 1. Word-style "all" clearing in Writer, new result.

First, thanks to NGI DAPSI who made this work by Collabora possible.

https://share.vmiklos.hu/blog/sw-clearing-break/eu.png
Figure 2. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871498

Motivation

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.)

Results

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

https://share.vmiklos.hu/blog/sw-clearing-break/none-new.png
Figure 3. Word-style not clearing break, new result.

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

https://share.vmiklos.hu/blog/sw-clearing-break/none-old.png
Figure 4. Word-style not clearing break, old result.

And both match the reference rendering:

https://share.vmiklos.hu/blog/sw-clearing-break/none-ref.png
Figure 5. Word-style not clearing break, reference.

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:

https://share.vmiklos.hu/blog/sw-clearing-break/all-old.png
Figure 6. Word-style "all" clearing break, old result.

Finally you can compare that with the reference:

https://share.vmiklos.hu/blog/sw-clearing-break/all-ref.png
Figure 7. Word-style "all" clearing break, 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:

https://share.vmiklos.hu/blog/sw-clearing-break/left-new.png
Figure 8. Word-style "left" clearing break, new result

And this is how it used to look like:

https://share.vmiklos.hu/blog/sw-clearing-break/left-old.png
Figure 9. Word-style "left" clearing break, old result

Finally you can compare that with the reference:

https://share.vmiklos.hu/blog/sw-clearing-break/left-ref.png
Figure 10. Word-style "left" clearing break, 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:

https://share.vmiklos.hu/blog/sw-clearing-break/right-new.png
Figure 11. Word-style "right" clearing break, new result

And this is how it used to look like:

https://share.vmiklos.hu/blog/sw-clearing-break/right-old.png
Figure 12. Word-style "right" clearing break, old result

Finally you can compare that with the reference:

https://share.vmiklos.hu/blog/sw-clearing-break/right-ref.png
Figure 13. Word-style "right" clearing break, reference

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

https://share.vmiklos.hu/blog/sw-clearing-break/ui.png
Figure 14. Insert break dialog in Collabora Online, with a new option for clearing breaks

How is this implemented?

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:

Want to start using this?

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-style border fixes in Writer: pages, tables and paragraphs

Estimated read time: 3 minutes

Writer now has a set of improvements to better render Word-style borders around pages, tables and paragaphs. This required adjusting how we perform automatic mirroring and also to make sure that clipping is done the Word way.

First, thanks Docmosis and TUBITAK who made this work by Collabora possible.

Motivation

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.

Results

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

https://share.vmiklos.hu/blog/sw-page-table-para-border/page-border-new.png
Figure 1. Word-style page borders, new result

And this is how it used to look like:

https://share.vmiklos.hu/blog/sw-page-table-para-border/page-border-old.png
Figure 2. Word-style page borders, old result

Finally you can compare that with the reference:

https://share.vmiklos.hu/blog/sw-page-table-para-border/page-border-ref.png
Figure 3. Word-style page borders, 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:

https://share.vmiklos.hu/blog/sw-page-table-para-border/table-border-new.png
Figure 4. Word-style table borders, new result

And this is how it used to look like:

https://share.vmiklos.hu/blog/sw-page-table-para-border/table-border-old.png
Figure 5. Word-style table borders, old result

Finally you can compare that with the reference:

https://share.vmiklos.hu/blog/sw-page-table-para-border/table-border-ref.png
Figure 6. Word-style table borders, reference

You can notice a number of problems here:

  • the inner horizontal line at the top table was overrunning, it was even painted between the two lines of the outer double border

  • the middle table shows how the vertical thick and thin lines of the outer double border was reversed

  • the bottom table shows how the horizontal tick inner border was not consistent

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:

https://share.vmiklos.hu/blog/sw-page-table-para-border/para-border-new.png
Figure 7. Word-style paragraph borders, new result

And this is how it used to look like:

https://share.vmiklos.hu/blog/sw-page-table-para-border/para-border-old.png
Figure 8. Word-style paragraph borders, old result

Finally you can compare that with the reference:

https://share.vmiklos.hu/blog/sw-page-table-para-border/para-border-ref.png
Figure 9. Word-style paragraph borders, 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.

How is this implemented?

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:

Want to start using this?

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).


Improved PDF export options in the command-line and in Online

Estimated read time: 3 minutes

The LibreOffice Technology now has much better support for creating custom PDF exports of documents: options available in the interactive PDF export options dialog are now also possible to set from the command-line, and also when using the document conversion feature of Collabora Online.

Motivation

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.

https://share.vmiklos.hu/blog/pdf-convert-to/pdf-export-partial.png
Figure 1. UI to specify a partial export to PDF

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.

Results so far

Here are a few examples to show the possibilities:

  • Skip the first page of a Draw document:

soffice --convert-to 'pdf:draw_pdf_Export:{"PageRange":{"type":"string","value":"2-"}}' test.odg
  • Add watermark:

soffice --convert-to 'pdf:draw_pdf_Export:{"TiledWatermark":{"type":"string","value":"draft"}}' test.odg
  • Encrypt the output:

soffice --convert-to 'pdf:draw_pdf_Export:{"EncryptFile":{"type":"boolean","value":"true"},"DocumentOpenPassword":{"type":"string","value":"secret"}}' test.odg
  • We default to PDF 1.6, perhaps you want to write PDF 1.5:

soffice --convert-to 'pdf:draw_pdf_Export:{"SelectPdfVersion":{"type":"long","value":"15"}}' test.odg
  • Sign the PDF:

soffice --convert-to 'pdf:draw_pdf_Export:{"SignPDF":{"type":"boolean","value":"true"},"SignCertificateSubjectName":{"type":"string","value":"CN=..."}}' test.odg

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

curl -k -F "data=@3page.odg" -F "format=pdf" -F "options={\"PageRange\":{\"type\":\"string\",\"value\":\"2-\"}}" https://localhost:9980/cool/convert-to > out.pdf

How is this implemented?

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

Want to start using this?

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).


Start of document themes in Impress: shape text

Estimated read time: 5 minutes

Impress now has the start of document theme support: it is possible to define a document theme on master pages and you can refer to the theme colors from shape text (including effects).

First, thanks to our partner SUSE for working with Collabora to make this possible.

Motivation

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.

Results so far

Here is a demo that shows how it works:

Figure 1. Demo of theme support in Impress shape text

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

  • You can define theme colors once you click on "Master View" in Impress, and then select the Slide → Slide properties menu item, and there choosing the new Theme tab. You can e.g. make "accent1" blue, "accent2" orange, and so on.

  • Then you can refer to these theme colors. Select some shape text, and then either use Format → Character → Font effects → Font color → Theme colors or use the sidebar to set the font color.

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.

How is this implemented?

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:

Want to start using this?

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).


Writer embedded objects: reliably update object previews

Estimated read time: 2 minutes

Embedded objects in Writer consist of a native data part and a preview part. Until now, there was no way to force the update of the preview part in case it was empty.

Now the Tools → Update → Update all menu item updates such previews as well. This is especially useful if you manipulate the ZIP/XML document directly to insert native data, then load it into Writer to generate a preview.

First, thanks Vector who made this work by Collabora possible.

Motivation

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.

Results so far

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

https://share.vmiklos.hu/blog/sw-ole-update/old.png
Figure 1. Writer embedded object with no preview

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

https://share.vmiklos.hu/blog/sw-ole-update/new.png
Figure 2. Writer embedded object with a preview

How is this implemented?

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:

  • Iterating over the frame formats ("special" formats) of the document

  • Filter out shapes

  • Filter out objects which are only reachable from the undo stack

  • Filter out objects which are not embedded ("OLE") objects

  • Once we have access to the OLE node, jump to its SwOLEObj, then to its svt::EmbeddedObjectRef, which knows how to re-calculate the preview bitmap

  • Finally notify the OLE node that the preview was updated, so the necessary repaint can happen

Want to start using this?

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).


Start of linked paragraph and character styles in Writer

Estimated read time: 2 minutes

Writer now has the start of linked character and paragraph styles. This improves DOCX compatibility, extends ODT and it’ll improve the style previews and the UI in the future, hopefully.

First, thanks Docmosis who made this work by Collabora possible.

Motivation

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.

Results so far

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:

https://share.vmiklos.hu/blog/sw-linked-styles/new.png
Figure 1. Word’s style picker, new output: no unwanted additional character styles

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

https://share.vmiklos.hu/blog/sw-linked-styles/old.png
Figure 2. Word’s style picker, old output: unwanted additional character styles

And here is how the input document looks like:

https://share.vmiklos.hu/blog/sw-linked-styles/ref.png
Figure 3. Word’s style picker, reference output: no unwanted additional character styles

How is this implemented?

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.

Want to start using this?

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).


Transparent shadow for tables from PPTX in Impress

Estimated read time: 2 minutes

Impress is now able to correctly render shadows for table shapes, even if the shadow itself or the fill of the table cells have transparency. The result is now compatible with PowerPoint.

First, thanks to our partner SUSE for working with Collabora to make this possible.

Motivation

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.

Results so far

The table shadow now looks like this:

https://share.vmiklos.hu/blog/sd-table-transparent-shadow/new.png
Figure 1. New render result in Impress

Matching the reference rendering:

https://share.vmiklos.hu/blog/sd-table-transparent-shadow/ref.png
Figure 2. Reference render result

While background was red previously:

https://share.vmiklos.hu/blog/sd-table-transparent-shadow/old.png
Figure 3. Old render result in Impress

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

How is this implemented?

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.

Want to start using this?

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).


Start of list level support in Writer paragraph styles

Estimated read time: 2 minutes

Writer now has the start of list level support in Writer paragraph styles. This improves ODT and DOCX compatibility, and it’ll improve the style previews and the UI in the future.

First, thanks Docmosis who made this work by Collabora possible.

Motivation

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.

Results so far

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:

https://share.vmiklos.hu/blog/sw-parastyle-listlevel/parastyle-listlevel.png
Figure 1. Writer exporting a paragraph style with list level info

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.

How is this implemented?

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

Want to start using this?

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).


Unshare shape properties for the same type before insertion in Impress

Estimated read time: 2 minutes

Shape properties were shared by shape type (e.g. shared between group shapes) before insertion into a document model in Impress. This is now fixed: the property names and types are still shared to help performance, but their values are no longer shared. This helps matching the user expectation that separate opened documents don’t share information with each other.

First, thanks to our partner SUSE for working with Collabora to make this possible.

Motivation

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:

  • the first document is opened

  • the first document is closed

  • the second document is opened

  • the second document is saved

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):

https://share.vmiklos.hu/blog/sd-groupshape-unshare/first.png
Figure 1. First document with a SmartArt

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

https://share.vmiklos.hu/blog/sd-groupshape-unshare/second.png
Figure 2. Second document after loading, no SmartArt

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

https://share.vmiklos.hu/blog/sd-groupshape-unshare/second-saved.png
Figure 3. Second document after reloading, with a SmartArt

Results so far

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.

Want to start using this?

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).

© Miklos Vajna. Built using Pelican. Theme by Giulio Fidente on github.