Index ¦ Archives ¦ RSS

Content controls in Writer: titles and tags

Posted on: Thu 03 November 2022

Estimated read time: 3 minutes

Writer now supports titles and tags for content controls, which helps providing context for the filled in text even if the placeholder text is replaced already.

This work is primarily for Collabora Online, see the previous post for background.

Motivation

Rendering of a title for a content control

Once several content controls are added to a document, it's easy to forget what was the exact purpose of what content control. Think of a press release for example – those regularly start with a location and a date, but once this information is provided, one no longer knows which content control was for which content.

Titles solve this problem for the user: similar to Writer's header/footer buttons, this button appears when you enter the content control and reminds you what content is expected there, even if the placeholder is already replaced.

Tags serve a similar purpose, but they are unique, machine-readable keys or identifiers, so once the form is filled in, an external consumer can easily extract the information from the document, given a specific tag.

Results so far

Titles (also known as aliases) and tags are now not only preserved, but also we have a UI to create, show, edit and delete them. This is available in the desktop rendering and also in the LOK API.

Somewhat related, in case a content control breaks into multiple lines or has formatting to break into multiple text portions, we now only emit one PDF widget for it, taking the description of the widget from the content control's title.

The last related improvement is that now we handle data binding for date content controls, which means that you can specify a timestamp, a language and a date format, and we'll format that timestamp and update the content control's string value at import time from 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 small changes:

Want to start using this?

You can get a snapshot / demo of Collabora Office 22.05 and try it out yourself right now: try the 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.5).

Content controls in Writer: PDF export and combo box type

Posted on: Mon 03 October 2022

Estimated read time: 3 minutes

Writer now supports exporting content controls to PDF and a 7th content control type: it is possible to differentiate between drop-downs and combo boxes.

This work is primarily for Collabora Online, see the previous post for background.

Motivation

PDF export of Writer content controls into PDF

Writer users can create fillable forms using content controls, but the PDF export only contained the plain text representation of them. PDF can also have fillable widgets for form filling, so it's logical to map content controls to PDF widgets.

A perfect mapping is not possible, since PDF widgets are always a single rectangle and Writer content controls is a list of rectangles (text portions), but this doesn't cause a problem in most cases. The size of the PDF rectangle is determined based on the placeholder's size from Writer.

Benefits includes not having to insert a control shape, manually positioned to look like it's in line with the surrounding text. An other benefit is that this way the widget's style (font name, size, etc) can be specified using Writer styles, not with shape properties. It's also interesting that Word itself doesn't seem to support content controls in its PDF export at the time of writing.

Results so far

PDF export now automatically turns Writer content controls into fillable widgets for the rich text, plain text, checkbox, drop-down, combo box and date types.

Combo box itself is a new type: now combo box content can be either free-form or one of its list items, while drop-down can only be one of its list items.

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:

Want to start using this?

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

Cropped video for media shapes in Impress

Posted on: Thu 01 September 2022

Estimated read time: 3 minutes

Impress now supports cropped videos in slide edit mode and during slideshow for documents imported from PowerPoint.

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

Motivation

PowerPoint-style cropped video in Impress

PowerPoint handles videos by taking a preview bitmap from the video, and then it allows users to apply various effects on that bitmap, like cropping. The complex aspect of this is that such filters are also respected while playing the video as well.

Impress didn't store such properties on the media shape, which lead to distorted aspect ratio when playing some cropped videos from PPTX files. This lead to this preview in Impress before the work:

Video with lost cropping in Impress

Results so far

The first problem was that the Impress preview was picked from the 3rd second of the video (presumably to avoid a black preview in many videos that start with a short black fade-in), while PowerPoint can store an explicit preview from the video (seems to be the first frame), so no matter what effects you apply, the previews were just different as the source bitmap was different. This could be fixed by looking for an explicitly provided bitmap for the video first, and only then asking the various avmedia/ backends to produce a preview.

Once the preview's initial bitmap was OK, it was necessary to take cropping into account. This was first done for the preview bitmap, and then also for the gstreamer backend (the relevant one for Linux, as a start) of avmedia/, which is responsible for the actual video playback. The gstreamer bits were done by first creating a videocrop element and then connecting that to the existing playbin.

With these sorted out, we get rendering which matches the reference:

Cropped video in PowerPoint

The last step was to load/save the explicit preview and the crop from/to ODF as well, not only PPTX. We use a markup like this to store the information:

<style:style style:name="gr1">
  <style:graphic-properties fo:clip="rect(0cm, 1.356cm, 0cm, 1.356cm)"/>
</style:style>

And now that the gr1 automatic style is defined, we can refer to it from a media shape:

<draw:frame draw:name="test" draw:style-name="gr1">
  <draw:plugin xlink:href="..." xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" draw:mime-type="application/vnd.sun.star.media">
    ...
  </draw:plugin>
  <draw:image xlink:href="Pictures/MediaPreview1.png"/>
</draw:frame>

The nice property of this markup is that automatic styles are already used for other shapes and image previews are also used for e.g. table shapes, so this is just using existing markup in a new context, but the ODF spec already allows this markup.

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:

User interface to create such a crop, support for other video effects (e.g. black-and-white) and other backends (Windows, macOS) could be done, but is future work currently.

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

Content controls in Writer: the plain text type

Posted on: Mon 01 August 2022

Estimated read time: 2 minutes

Writer now supports a 6th content control type: it is possible to insert a plain text content control.

This work is primarily for Collabora Online, done as a HackWeek project, but the feature is fully available in desktop Writer as well.

Motivation

Word-style plain text content control, user interface

Writer users can put a content control around a piece of rich text, see Content controls in Writer: dropdown, picture and date types for the first five types.

The next step in this journey is plain text: even if one of the big advantages of content controls over input fields is that they allow rich formatting, sometimes you want to restrict this. For example, if one has to fill in their name, then it makes no sense to mark the family name as bold while leaving the given name as non-bold. This would just lead to inconsistent look.

Results so far

There is now a new Form → Content Controls → Insert Plain Text Content Control menu item to create a plain text content control. If you try to make a selection that is a subset of the text inside the content control and you try to format it, the whole text in the content control is formatted to maintain the invariant that plain text has no formatting itself, just the formatting of the whole content control.

As usual, you can delete this content control later. You can also load/save it to ODT/DOCX and it's preserved.

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:

Want to start using this?

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

Document themes in Impress: shape fill

Posted on: Mon 04 July 2022

Estimated read time: 4 minutes

Impress now has the next step of document theme support: it is possible to refer to the theme colors from shape fill colors (including effects).

This work is primarily for Collabora Online, but the feature is fully available in desktop Impress as well.

Motivation

PowerPoint-style themed shape fill, user interface

PowerPoint users can attach a set of colors (and fonts, etc.) to master pages, and then refer to these in many areas, like shape text or shape fill. It was already possible to define theme colors and refer to them from shape text (see Start of document themes in Impress: shape text for details).

The next step in this journey is shape fill: if your shape is filled with some color, it can be a theme color, as visible on the above screenshot. One interesting aspect of this is that the default shape fill color can now depend on the master page, and it may not be the same for all slides (this is what would happen with styles, when not using theming).

Results so far

Here is a demo that shows how it works:

If one opens the svx/qa/unit/data/theme.pptx test file from core.git, it looks like this:

PowerPoint-style themed shape fill, after opening

The middle row has 3 rounded rectangles: the first is filled with the 'Accent 1' color, the second is the same, but 60% lighter and finally the last one is the same, but 25% darker.

Here is how you can change what the 'Accent 1' color is:

  • Click 'Master View' on the sidebar to go to the master of the current slide.
  • Right click -> 'Slide Properties' opens the 'Slide Properties' dialog.
  • The 'Theme' page has an 'Accent 1' row, with a blue color.
  • Change that to an orange color: click on the 'Accent 1' drop-down, then select 'Theme colors', finally the 6th choice is orange in the first row -- this comes from the document's theme.
  • Click 'OK' to close the dialog, followed by 'Close Master View' on the sidebar.

Here is how your shapes now look like:

PowerPoint-style themed shape fill, after changing the theme

What you can see here is that the color effect (darker, lighter, default) of the rounded rectangles' fill color was preserved, but all the blue colors are replaced with orange.

As a cherry on the cake, now if you insert a new shape, that will also have an orange fill color by default as well.

You can see how this is useful when designing templates: a designer can create something good-looking, and all you have to do is to set the theme to the colors of your organization, and you're done.

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:

Want to start using this?

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

Content controls in Writer: dropdown, picture and date types

Posted on: Wed 01 June 2022

Estimated read time: 5 minutes

Writer already had rich text and checkbox content controls: a new way to set properties on a piece of text, primarily for form filling purposes. This feature now gained 3 additional types: dropdown, picture and date picker types. This improves compatibility with the DOCX format: there are now 5 inline content control types we can now import.

https://share.vmiklos.hu/blog/sw-content-controls2/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 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:

  • Dropdown content controls have a list of dropdown items. Each item is a display-text and value pair, allowing to differentiate between a human-readable string and a machine-readable value. Fieldmarks only handled (machine-readable) values, resulting in document text different from Word.

  • Picture content controls allow the author of a form to pre-format the image before the filler of the form inserts the actual image. Writer already had placeholder fields for images in the past, but that was just text, allowing image format only after insertion of the actual image.

  • Date content controls were emulated with Writer fieldmarks in the past, which created trouble during export, since Word itself doesn’t have a date form-field.

Results

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:

https://share.vmiklos.hu/blog/sw-content-controls2/menu.png
Figure 3. Menu items to insert drop-down, picture and date content controls.

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

https://share.vmiklos.hu/blog/sw-content-controls2/dropdown.png
Figure 4. A drop-down 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:

https://share.vmiklos.hu/blog/sw-content-controls2/picture.png
Figure 5. Picture controls.

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:

https://share.vmiklos.hu/blog/sw-content-controls2/properties.png
Figure 6. Content control properties.

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

https://share.vmiklos.hu/blog/sw-content-controls2/properties-inner.png
Figure 7. Content control properties inner UI for list items.

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

Want to start using this?

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

Content controls in Writer

Posted on: Tue 03 May 2022

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

Posted on: Mon 04 April 2022

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

Posted on: Tue 08 March 2022

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

Posted on: Tue 08 February 2022

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

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