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.

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.

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:

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:

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.

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:

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

In this post I would like to present the progress done last month regarding the above mentioned diagram types — these are used in many documents.

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

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

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 Accent Process looks like:

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

This is not not perfect yet, but it’s clearly a large improvement, all text is now readable from the diagrams and bullets 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. :-)

In this post I would like to present the progress regarding the Accent Process preset, available in PowerPoint — which is used in many documents.

This exposed several shortcomings of the current diagram layout we have in LibreOffice:

With all these fixed, we reach a much better state for handling accent process.

smartart-accent-process.pptx is what I used for testing of this work.

Here is how the baseline, the current and the reference rendering of the test documents look like:

This is not not perfect yet, but it’s clearly a large improvement, all text is now readable from the diagram!

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

There are several ones. :-) If you are just interested in high quality viewing of PPTX files, then your problem started with PowerPoint 2007 not writing a pre-rendered drawingML markup of the diagram to the files, only PowerPoint 2010 started behaving like this. Additionally, if a diagram is not edited, then re-saving with PowerPoint 2010 doesn’t seem to generate the drawingML markup, either. This means that data + constraints cases are quite frequent even today.

Also, one day Impress should be able to actually edit these SmartArts as well, so having the knowledge how to lay out SmartArt (even if it’s import-time-only at the moment) is a good thing.

I always write cppunit tests when I work on filter code (in this case OOXML), so far all fixes were visible in just two test files: smartart-vertial-box-list.pptx and vertical-bracket-list.pptx.

Here is how the baseline, the current and the reference rendering of these test documents look like:

In terms of code commits, the fixes are split into several ones:

Clearly the results are not perfect yet, but in both cases nothing was visible, and now all text is readable, so we’re moving in the right direction!

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

The UNO API of Draw allows you to build quite complex and custom shapes, but you may want to export the rendered result to a bitmap for testing purposes, so you can assert that the actual result matches a reference one.

One problem in this area is anti-aliasing, which can easily differ between machines. Given that normally aliased rendering is ugly, there is now a way to enable AA, but disable it just during a single invocation of the PNG exporter.

The above picture shows how the AA result looks like. You could write a Basic macro like this to trigger the PNG export from Draw:

Let’s see how it looks like if you turn AA off:

You just need to specify a new Antialiasing key under FilterData:

You can imagine which rendering result is easier to debug when the reference and the actual bitmap doesn’t match. ;-)

In most cases you don’t really need a default character style: if you’re fine with a default, then the default paragraph style should be enough for your needs. In general, paragraph styles can contain character properties, so if the default is fine for you, you just don’t set a character style.

However, there is an exception to all rules. If you want to reset the current character style, it makes sense to just set the CharStyleName property to a default value, especially since this works with paragraph styles already.

Now you can write C++ code like this (see SwUnoWriter::testDefaultCharStyle() for a full example):

And it’ll be handled as Default Style in English builds, or their localized versions in a non-English UI.

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