What is Miklos hacking

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:

btlr-cell.docx, baseline

btlr-cell.docx, current

btlr-cell.docx, reference

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:

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

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.

Continuous Block Process, Accent Process and Organization Chart

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:

Continuous Block Process now reads space width from constraints.

Accent Process now has the missing bullets and fixes an incorrect large
paragraph-level indent.

Organization Chart now has an initial implementation of the hierRoot and
hierChild algorithms.

Organization Chart now handles multiple employees for a manager.

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

I recently dived into the SmartArt
support of LibreOffice, which is the component responsible for displaying
complex diagrams from PPTX. I focused especially on the case when only
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.

Accent Process

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:

Values are not read from constraints (there was a reason for this, they can
be complex, given that depending on the context, the unit is points or
millimeters and the unit is always implicit).

ZOrder offsets were ignored.

Linear algorithm did not take size from constraints when it came to
recursing into child algorithms.

Data point assumed that all text for it is a single "run" (i.e. either all
text is bold or nothing, not half of it).

followSib axis was not implemented for forEach, so when you have arrow
shapes between objects, we created N arrows, not N - 1 ones.

Connectors were created as invisible shapes and had the wrong width/height
aspect.

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

I recently dived into the SmartArt support of LibreOffice, which is the
component responsible for displaying complex diagrams from PPTX, especially in
case only 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.

The problem

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 created a toy project to experiment with a few technologies I wanted to try
out (cmake,
googletest,
xmlsec outside LibreOffice,
libzip and AppVeyor). The
result is a tool with a similar interface as pdfsig from poppler (for PDF
files), just for ODF: a cmdline executable to verify the digital signature(s)
in an ODF document.

The source code now has CI on Linux and
Windows, so perhaps in a shape that is interesting for others to have a look
as well. And if not, then no problem, it was interesting to put together these
building blocks and see them working as expected. :-)

I used to have a hackish setup to trigger address book in the form of code
completion from vim, when mutt starts it. I recently migrated the last part of
it from python2, so it’s now in a relatively consistent state. On a boring
flight trip I finally got around to summarize how it works, perhaps it’s
useful to someone else as well. :-)

By multiple sources, I mean Google Contacts for my private account, and LDAP
for work-related accounts. I have one script for each to have a local backup:

Then comes
mutt/contacts/search,
which can read these backups from $HOME/.mutt/contacts/ (you can create
symlinks to decide which backup should be included in the search results).

The rest is just a short
search.vim
that integrates the search script into vim, so when mutt starts it with
ft=mail, the search script is invoked when you start typing and you press
Ctrl-X Ctrl-O (trigger code completion).

And that’s it, I can start typing mails to friends and customers even without
network connectivity, without manually maintaining an own address book just
for mutt!

Background: I was benchmarking Online vs jodconverter vs unoconv the other day
for Collabora’s document
conversion page. One problem with measuring unoconv performance was that it
provided no ways to run multiple unoconv processes in parallel, while the
underlying soffice binary obviously allows this.

So while unoconv is not capable of launching the soffice process in a chroot
(improves security), nor is capable of forking an already pre-initialized
soffice process (improves performance, both are things Online can do for you),
there is no real reason why you should not be able to run multiple unoconv
processes in parallel. The previously mentioned benchmarking would be quite
unfair if even this kind of multiprocessing would be ignored, but unoconv had
no way to specify a custom user profile, which has to be different for each
soffice process.

It’s your responsibility to give --port a unique value, but that’s not
too hard: if you use a thread pool to launch the unoconv processes, then you
can add the thread index to a base port and that will give you a unique port.

So this is available in unoconv master (towards unoconv 0.8.2+1), you can grab
the sources from git and try it out right now. :-)