Writer now has a new "allow overlap" shape property for anchored objects, which can ensure that objects with overlapping positioning properties don't actually overlap.

First, thanks TU Dresden who made this work by Collabora possible.

Here is a video showing how it works:

Under the hood, this is a full new Writer feature, since previously shapes were always allowed to overlap with each other:

• macros get a new AllowOverlap shape property (true by default)
• layout takes this into account if you set the property on the UI
• both DOCX and ODT filters serialize and load this property (ODT proposal)

All this is available in LibreOffice master (towards 6.4), so you can try it out right now, if interested.

Yesterday I gave a Bottom to top, left to right writing direction in Writer talk at the LibreOffice Conference 2019. The room was well-crowded -- perhaps because it was on the first day and in the largest room. ;-)

It contains some details which are not available in previous btLr blog posts, like what natural languages use this direction, how to replace real-world clocks without breaking compatibility and more!

I expect quite some other slides from other Collaborans and the wider community will be available on Planet, don't miss them.

You can get a snapshot / demo of Collabora Office 6.2 and try the presented feature 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 (6.4).

The problem¶

I already wrote about the btLr text direction in the context of Writer table cells as a result of a Collabora hack week (part 1, part 2, part 3). This post is meant to be the final one (for now), given that both table cells and shapes / text frames are now working nicely with all major formats.

The result¶

The first topic is that whenever I looked at supporting the new bottom-to-top, left-to-right direction, I always first checked if the more common top-to-bottom, right-to-left direction is working or not (this is used for e.g. Japanese rotated text). Turns out that Writer text frames were not exported to drawingML (part of DOCX), so I fixed that.

Similarly, there is the older shape markup in DOCX: VML. The tbRl direction from that was broken, too, now working nicely.

Then I could actually look at the btLr import from VML, which is now correct.

One of the motivations for this work was to get rid of the old, miserable hack where we did character-level rotation during import (which falls apart for multi-paragraph text). If the import mapping in itself is not painful enough, we had to undo the effect of this import hack at export time. When I could remove the last usage of this dreaded checkFrameBtlr() function in the export code, I mentally did a little dance. ;-)

Back to btLR fixing, exporting Writer text frames to DOCX is not interesting when you do DOCX editing, but it's very much relevant when you do ODT -> DOCX conversion. And the btLr case was of course not handled, fixed now.

RTF was broken in 4 different ways: import and export was broken for the btLr and the tbRl cases for text frames.

The last thing was the binary DOC export, where btLr text frames were not handled.

With these sorted out, I think the topic of table cells and shapes / text frames are now supported reasonably well. ODF could do the btLr writing direction for sections and pages as well, but I don't see that as a priority. And hey, Word doesn't support them, either. :-)

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 is a major contributor to LibreOffice and all of this work will be available in TDF's next release, too (6.4).

The problem¶

Years ago I posted about work to attach comments to text ranges. This improved compatibility with Word greatly, but it was always a piece of text that was commented, never frames. If you just selected a frame and tried to comment by selecting the menu entry or the Ctrl-Alt-C shortcut, nothing happened, because frame selection did not interpret comment insertion.

Result¶

Examples for frames are images or charts. This needs explicit handling, so at the moment the at-char and as-char anchor types are supported, and you can simply insert the comment to a frame once the frame is selected. This works in both desktop Writer and Online.

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 is a major contributor to LibreOffice and all of this work will be available in TDF's next release too (6.4).

I already wrote about the btLr text direction in the context of Writer table cells as a result of a Collabora hack week (part 1, part 2). The next step in this journey is btLr text direction of Writer Text Frames, and building on top of that: DOCX Text Boxes. Here is a series of screenshots showing the result:

You can see that the bug document is some kind of card you can print and fold in the middle: no matter if you are in front of the card or you are behind it, you always see the name and details of the person. Sure, you can do the same with a table with no borders, but using a Text Frame for this purpose is a sane use-case.

The text from the 3 paragraphs used to have the same horizontal position, and now it's laid out the same way as Word does it.

Technically, this result is just the last commit in a series. I fixed the following problems since the last blog post on this topic:

• tdf#124344 sw btlr writing mode, DOCX import: fix vertical alignment

• tdf#124521 sw btlr writing mode render: fix paint rectangle on scroll

• sw btlr writing mode: implement DOCX shape import for tbrl

• sw btlr writing mode: implement ODF filter for textframes

• sw btlr writing mode: implement layout for fly frames

• sw btlr writing mode: implement UI for fly frames

• sw btlr writing mode: fix btlr <-> tbrl switch for fly frames

• sw btlr writing mode: DOCX drawingML import for fly frames

All this is available in LibreOffice master (towards 6.4), so you can try it out right now, if interested.

Years ago I posted about a large rework to where Collabora helped a customer to make Writer read the drawingML markup for DOCX shapes. You can read the various benefits of this switch in that article -- but similar to other large reworks, this also broke some previously working corner-cases, where test coverage lacked.

One of these is charts in group shapes. This needs explicit handling, as Writer normally handles charts as TextEmbeddedObjects, while code that imports charts from OOXML is not specific to Writer. The fix just tells the generic drawingML import to use a Writer-specific service name for the charts.

This is available in LibreOffice master (towards 6.3).

I already wrote about the btLr text direction in the context of Writer table cells as a result of a Collabora hack week. This is meant to be an update to present what happened in the past 2 months. Here is a video showing the results:

I fixed the following problems since the last blog post on this topic:

• sw btlr writing mode shell: fix up/down cursor travelling

• sw btlr writing mode shell: left/right cursor travelling, fix dest para

• sw btlr writing mode shell: left/right cursor travelling, fix vert pos

• sw btlr writing mode shell: fix cursor selection

• tdf#123943 sw btlr writing mode render: fix text portion background

• sw btlr writing mode: implement DOC filter

• tdf#124261 sw btlr writing mode render: fix invalidation rectangle

• sw btlr writing mode: implement RTF export

All this is available in LibreOffice master (towards 6.3), so you can try it out right now, if interested.

I recently dived into the SmartArt support of LibreOffice, which is the component responsible for displaying complex diagrams from PPTX. I focus on the case when only the document model and the layout constraints are given, not a pre-rendered result.

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

Organization Chart, Cycle Matrix and Picture Strip¶

In this post I would like to present the progress done earlier this year regarding the above mentioned diagram types -- these are used in many documents.

The improvement (as always) come in small incremental steps:

• Organization Chart is the most complex type I dealt with so far. I fixed several issues (font color, vertical ordering, multiple paragraphs in a data node, size of layout nodes, better support for hierBranch conditions, the type of connector shapes). This allows giving readable result for diagrams which are more complex than the simple 3-node one presented in the previous post.

• Cycle Matrix: there were missing child nodes here, the composite algorithm needed improved handling of position / size from constraints and the ordering / fill / line properties of actual content also needed fixing.

• Picture Strip: the biggest problem here was the lack of pictures, but also the existing snake algorithm needed improvements (size, positioning, spacing and margins of the child shapes were not great).

With all these fixed, we reach a much better state for the mentioned diagram types.

Results so far¶

The SmartArt test documents from sd/qa/unit/data/pptx/ is what I used for testing this work.

Here is how the baseline, the current and the reference rendering of Organization Chart looks like:

And here is how the baseline, the current and the reference rendering of Cycle Matrix looks like:

And finally here is how the baseline, the current and the reference rendering of Picture Strip looks like:

This is not not perfect yet, but it's clearly a large improvement, all text is now readable from the diagrams and pictures are no longer missing!

All this is available in master (towards LibreOffice 6.3), so you can grab a daily build and try it out right now. :-)

As mentioned in my previous such report, a hack week is when we are allowed to hack on anything we want in LibreOffice for a few days at Collabora. I used this time to implement core support for the btLr text direction in Writer.

Motivation¶

If you work with tables in Word, it's very easy to create this writing direction: the context menu in a table cell has a menu item to set the direction of the text, where you can rotate the text by 90 degrees counter-clockwise or clockwise. The counter-clockwise btLr direction is the problematic one. Support for tbRl was fine already, since that is needed typically for Chinese/Japanese scripts as well.

Results so far¶

Here is how the baseline, the current and the reference rendering of btLr text looks like:

You can see how the second paragraph in the cell was missing from the rendered result and now we basically pixel-by-pixel match the reference.

How is this implemented?¶

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

The document model and UNO API were reasonably straightforward to implement, but the layout was much more challenging. Writer already supported 3 writing directions:

• typically used for Latin (left to right, top to bottom)
• Chinese/Japanese (top to bottom, right to left)
• Mongolian (top to bottom, left to right) text.

This new one is also a vertical direction, also left to right, but bottom to top. The initial layout contained code to read the new enumerator from doc model, extend the SwFrame class to handle this new bottom to top mode, some handling of switching between horizontal/vertical mode and at the end mapping from Writer layout's direction to VCL's "900" font orientation. There are more things to handle in layout, but this was good enough to look at other areas as well.

The ODF filter required updating, which was a bit challenging as it was necessary to write different attribute names depending on which enumerator is used from an emumeration, and we don't have good support for this. Once the filter code was in place, I could write some layout-level tests as well.

Since we have .ui files for UI descriptions, adding UI support was really easy.

Time came to step away from coding for a moment and write up paperwork to propose this feature to be part of the next ODF version (thanks to Andras for the help there!).

Finally I went back to layout, and improved things a bit more: after fixing baseline offsets, the positioning of the text was exactly matching what Word does. How do I know? I used this little script:

gs -dNOPROMPT -dBATCH -sDEVICE=jpeg -r75 -dNOPAUSE -sOutputFile=btlr.jpg btlr.pdf
gs -dNOPROMPT -dBATCH -sDEVICE=jpeg -r75 -dNOPAUSE -sOutputFile=btlr-word.jpg btlr-word.pdf
composite -compose difference btlr-word.jpg btlr.jpg out.jpg

Which allows seeing the differences between our and Word's PDF output. Additional work was needed to handle multiple paragraphs in a table cell. At this stage I was happy enough with the rendering result, so finally pulled the trigger and replaced the old DOCX filter hack (using character-level rotation) with simple DOCX filter mapping from OOXML's btLr direction to Writer's btLr direction -- i.e. what was already done for the tbRl case.

Future work¶

The feature works good enough already so that this new core feature can be used by the DOCX filter by default, but there are still a few rough edges:

• the shell code (cursor travelling, selection painting, etc) only has partial support for this new direction

• RTF and DOC filters are not yet updated

• the ODF proposal has a list of contexts other than table cells where the new writing direction could be used, which lack UI/filter support/etc at the moment.

All this is available in master (towards LibreOffice 6.3), so you can grab a daily build and try it out right now. :-)

The next step in the recent SmartArt story is my Improving SmartArt import in Impress talk at FOSDEM 2019, in the Open Document Editors devroom. The room was a bit far away from the popular places, but the livestream worked out nicely.

There was also a hackfest before the conference, I looked at RTF export of rotated Writer pictures.