There has been a recent evaluation of PDF signature verification, which included Draw. While we got a checkmark on their Shadow Hide test, their Shadow Replace test found conditional problems and their Shadow Hide-and-Replace test was not happy, either.

So time to look at what are those corner-cases and how the situation can be improved, so people keep trusting that if Draw says a signature is valid, it’s indeed valid.

There were 4 incremental improvements in this area:

These were enough so that talking to the authors of that evaluation now confirmed that these problems are all gone.

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

PDF signature verification works by using a custom PDF tokenizer. You can read about that code in the PDF tokenizer section of this post. The bottom line is that we now have both PDFium and this custom tokenizer, somewhat duplicating the functionality.

After talking to the PDFium developers (see the relevant mailing list thread), there were open regarding adding all the high level API to allow PDF signature verification based on PDFium, and not via our own tokenizer. See this header file for the set of relevant APIs added. A combinations of those allowed to adapt the code on our side and use PDFium for signature verification, not the own tokanizer.

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

Collabora Online is on GitHub, but core.git is still on Gerrit, so it made sense to spend some time on a small shell script that gives you review and backport experience that is closer to Gerrit than the stock GitHub workflow.

Most Online committers push their code for review directly to online.git, to private namespaced branches, like private/kendy/master, then a pull request can be created to get commits from that branch into master after CI, review, etc. This workflow has the benefit that you don’t have to deal with the complexity of multiple repos.

Next to master, there are distro branches like distro/collabora/co-6-4, we may or may not want to backport the contents of a PR to that stable branch.

It’s important that Gerrit used to have a git review command to just submit your changes for review, without asking anything. That explains why the stock GitHub workflow where you need to name the source branch of your PR feels unnecessary complexity. Creating the PR by visiting a webpage is again something we want to avoid. Not to mention open questions like should you delete your source branch after a PR is merged? Should you delete your source repo?

On the other hand, we’re interested in GitHub’s ability to have multiple commits in a PR: Gerrit forces to have one commit per change. The GitHub way encourages developers to split changes into more commits, now that the review and CI cost won’t increase just due to such splits.

The happy path is when you have one or more local commits and you want to submit it for review. In this case now you can do:

And the script will figure out that you want to push your local branch to a remote branch like private/kendy/master and also create a pull request for you, printing its URL.

In case that branch already exists then you need to specify a name:

So parallel reviews are possible, but only the first gets an inferred name. Both cases need no clicking in a browser, thanks to gh.

The easiest case is when you can assume that the master branch and the distro branch is so close to each other that there won’t be conflicts to be resolved. In that case, you can do:

to pick all commits from PR 790 (which is already merged to master) to a distro branch.

Again, you can have multiple backports in progress, e.g. you can do:

If the default name is already used. The backport syntax is a bit longer, so you can always just type ./g backport and you’ll get the usage.

This second command is a bit more complicated, as gh has no trivial way to expose what is the commit range of a PR. But there is gh api graphql which can do arbitrary GraphQL queries, which provide this information. At this stage it may make sense to just rewrite the whole ./g script in e.g. Python, but till that happens, we parse the output of the query using jq.

Finally, if you do have conflicts or you want a local build test / manual test before submitting, you can always check out the distro branch manually, cherry-pick there and use plain ./g review to submit your backport for review.

You can go to the Collabora Online community website and see how to build the code. Then you may want to solve an easy hack, finally submit your commit for review either by using the above method or whichever way you prefer contributing to GitHub projects.

A Collabora Office customer gave us a DOCX document, which is essentially a calendar for planned IT maintenance windows at some organization. These calendars are tables with fields in it. The document is halfway through towards changing it to a newer year: the formulas are already changed to calculate a newer year, but all the cached field results are still for the old year.

The request was to keep showing these results and not throw them away during save, either. Their primary workflow is to fill the calendar with manual entries, not to tweak the calendar layout itself.

The calendar now looks like this:

Matching the reference rendering:

While it looked like a broken calendar previously:

You can see that the day numbers were broken previously and now they line up properly.

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

With these, it’s now possible to edit these calendars, without breaking the fields which provide the day numbers.

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

We regularly see customers wanting minimal templates, which are language independent and have no content. Such files are handy if your workflow is to first name an empty document (create it) and only then edit it (and not the other way around: first create the document, then save it by giving it a name). This is easy for .txt files: if it’s zero bytes, it’s empty. But then this approach is also expected to work for other file formats as well, where our original approach was more technical: if it’s an empty file, that that can be only plain text, so we (almost) always opened it in Writer, not matching the user expectations.

Instead of explaining the problem to people again and again (that a literally empty PPTX file is not a PPTX template), there is value in just adapting the code instead to "do what I mean".

An empty PPTX file is now handled like this:

You can see this is no longer opening in Writer as plain text but in Impress, which is clearly a less surprising behavior.

Here is what happens if you open an empty DOTX (template):

You can see that it is even recognized that this is a template format, so a new document is created, not the template itself is opened for editing.

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

You can see the code change in this commit. First, we restrict this trick to file URLs, and also to empty files.

Second, we look at the extension of the file and try to match an import filter that usually handles that extension. This helps, because then nominally the correct filter will be used for the import, so save will not ask for a filename (as it happens for new documents), but it will know what target filename and export filter to use.

Finally we need to avoid actually invoking the import filter, because no file content is not something an import filter has to handle if its filter detection would reject the file. (E.g. PPTX is expected to be a valid ZIP file.) This is important, because we want to avoid touching each & every file filter to not fail for empty file content — instead we want to handle this centrally, at a single place.

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

SmartArt allows declaring your content and requirements for a graphic, then the layout will take care of arranging that in a suitable way. It is allowed to ask for an automatic font size, which is small enough so that all the content fits into the shape. At the same time, you can ask that the font size is the same in multiple shapes. Impress lacked the ability to do the latter, leading to different font sizes in different shapes, all automatic inside a single shape.

Here is how the automatic text scaling across multiple shapes works in practice:

You can see how the old output used to have unexpected large text in shape A, but now has the same text size as shape B. This is not applied unconditionally, shape C can request to have an independent, fixed font size.

You can see that the old output laid shapes all over the place, while the new output puts them to a 3 by 2 matrix. The reason this works is because now we parse width requests from constraints correctly. This means we give spacings a smaller width, real shapes a larger width, so the content fits in less rows and the layout looks like a grid, matching the reference rendering.

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

As for the autofit synchronization:

Beyond that, for the snake rows:

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

Users create new documents in various ways. When they do so in Online or via Windows Explorer’s context menu (New → …) then actual templates are not involved in the process, technically. What happens instead is that there is a plain empty Writer (or Calc, Impress) document that gets copied. The reason for this is that by the time the document gets created, the WOPI-like protocol or Windows Explorer doesn’t have a running soffice process to create a document instance from a template: it’ll just copy a file.

With that aside, users expect that when they create new documents, the language of their new document matches the locale of Writer itself. This conflicts with the idea that languages in the documents are explicit, so if a German users writes a piece of German text, the spellcheck passes and the next user is English, then the text should remain German, not introducing new spellcheck errors.

The solution to this problem is what Mike and Ezinne implemented: make these "templates" minimal, so they don’t refer to any language. Then Calc or Impress will fill the language from the locale of the soffice process and it’ll be part of the document on the first save. This solves the problem of multi-language templates while it does not break the spellcheck use-case.

Andras copied the same templates to various Online integrations to have the same problem solved in that use-case as well.

Writer was still problematic, though. sw: default to UI locale when language is missing now fixes this. You can see on the above screenshot that the stock soffice.odt was opened with a Hungarian locale and the status bar shows that the document language is Hungarian, not the confusing "multiple languages", as before.

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.1).

SmartArt allows declaring your content and requirements for a graphic, then the layout will take care of arranging that in a suitable way. It is allowed to declare conflicting requirements, and rules can specify how to resolve those conflicts. The below example document has shape widths defined in a way that multiple child shapes wants to have a width of 100%, but simply scaling down all child shapes does not give a correct result. Rules define what to scale down and what to leave unchanged.

Here is how this works in practice:

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

This declares that an earlier shape in a linear layout is on top of a later shapes, not the opposite. The default is that newer shapes are on top of older shapes. This is not a visible problem usually, but once you start using negative widths in a linear layout, you can have overlapping shapes. The above example has 3 text shapes, which are overlapping with the "background" arrow shape. This is expressed by having 100% width for child shapes (OK to scale down), then a -100% width for a dummy shape (not scaling) and finally a 100% width for the background arrow (not scaling).

All in all, now the background arrow shape has a good position and size, and the text on the arrow is readable.

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.1).

The PDF format allows assigning a shape (a form xobject) to a digital signature in the PDF file, and if you use e.g. Adobe Acrobat, then it fills this shape with some visible information about the digital signature. Draw used to write a placeholder widget there (a 0x0-sized rectangle on the first page, at position 0x0). This is valid, but it’s not close to real-world signatures, where signing has a visual effect as well.

Here is how this works in practice:

You can see how the 2 added signatures are visible and Adobe Acrobat confirms they are valid, too.

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

If you use a HW-based certificate, this second step will ask for your certificate PIN.

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.1).

Users sometimes want to specify the vertical position of their shapes in text documents in a way that is relative from the bottom of the page content area. Also, this improves consistency, specifying a position that is relative from the top of the page content area is already possible.

Alternatively, it is possible to have the same calculated position when positioning from the top of the page content area. The downside of this approach is that the position changes when the page height changes. So if the user intention is to position a shape 2 cm above the bottom of the page content area and the page height changes, the shape has to be manually re-positioned. This manual re-positioning is not needed with the new page-content-bottom vertical relation.

For example, if a shape has a height of 10 cm and a 2 cm spacing is wanted between the bottom of the shape and the bottom of the page content area, the position can be set to -12 cm, and then the 2 cm spacing will be maintained, even after the page height changes.

Here is how this works in practice:

You can see how the distance of the shape from the bottom is 2 cm, even if the page height changes.

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

now the import/export code maps this markup to the new feature.

There is a proposal to promote this from our extension namespace to normal ODF (thanks to Regina for the help there!).

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.1).