In from selections to graphic handling, I wrote about how we let the LibreOffice Android app select, resize and move images and shapes. Now that we have all type of selections (at least for Writer) in this TDF-funded project, let’s do some formatting! The example implemented by Jan Holesovsky here is to mark the text bold, but you can imagine that using the same technique a number of other character or paragraph properties could be set the same way with little work.

Here is how it works:

If you are interested how this looks like, here is a demo (click on the image to see the video):

Notice that Calc also gained a number of new features, like cell selection, blinking cursor, text selection with much help from Henry Castro.

Now that Writer is nearly functional for the basic editing features that would be good to see in all four applications, time to look at what’s new in Impress-land!

To bring Impress in line with Writer, we implemented the followings with Tomaž Vajngerl:

Here is a demo to show this in action:

For many of the above features, the core part was already implemented due to Writer shapes, what was missing is to call the same editeng methods from Impress and/or do missing core coordinates → LOK coordinates conversions. The later is twips for both cases in Writer, but Impress works in 100th millimeters internally, so it was necessary to do a number of conversions here and there so that LOK callbacks always emit coordinates in twips.

We also prepared more in-depth technical documentation about the Android editing work, libreofficekit/README and android/README now has much more details about how exactly the editing works.

That’s it for now — as usual the commits are in master (a few of them is only in feature/tiled-editing for now), so you can try this right now, or wait till the next Tuesday and get the Android daily build. :-)

In from input handling to selections, I wrote about how we let LibreOffice Android app draw the selections around text content natively. A next step in this TDF-funded project is to provide selections around more UI elements: images and shapes.

Here are a number of challenges we (Tomaž Vajngerl and me) faced while we implemented this:

If you are interested how this looks like, here is a demo (click on the image to see the video):

Notice how the word selection in a table turns into a table selection, or how a long push inside an empty cell creates a selection containing only the empty cell.

An other direction we’re working towards is to show / hide the soft keyboard of Android as you would expect it. On Linux, it’s easy: the keyboard is always available. However on Android you should track when it makes sense to use the keyboard and when not — and show/hide automatically according to the context. Examples:

Additionally, we need to handle the situation when this automagic goes wrong. The Android soft keyboard has a button to hide itself, but we added a toolbar button to force-show it, too (click on the image to see the video):

Finally, Siqi Liu added a new callback type, allowing to tap on hyperlinks and handle them according to how you configured URL handling on your Android device. Here is a demo to show this in action:

That’s it for now — as usual the commits are in master (a few of them is only in feature/tiled-editing for now), so you can try this right now, or wait till the next Tuesday and get the Android daily build. :-)

Earlier I wrote about my setup to hack libvisio. One missing bit was testing the contributed code. Testing can be performed at various levels, so far DLP libraries were tested by recording the output of the various foo2raw tools and then comparing the current output to some previously known good state. This has a number of benefits:

The same technique was used in LibreOffice for Impress testcases initially, however we saw a drawback there: Being automatically generated, you have no control over what part of the output is important and what part is not — both parts are recorded and when some part changes, you have to carefully evaluate on a case by case basis if the change is OK or not. The upshot is that from time to time you just end up regenerating your reference testsuite and till the maintainer doesn’t do that, everyone can only ignore the test results — so it doesn’t really scale.

In short, both techniques have some benefits, but given that the libvisio test repo is quite empty, I thought it’s a good time to give an other method (what we use quite successfully in LO code) a go, too. This method is easy: instead of recording the whole output of some test tool, output a structured format (in this case XML), and then just assert the interesting part of it using XPath. Additionally, these tests are in libvisio.git, so you can nicely put the code change and the testcase in the same commit. So the hope is that this is a more scalable technique:

Technically this method is implemented using a librevenge::RVNGDrawingInterface implementation that generates XML. For now, this is part of libvisio, so in case you want to re-use it in some other DLP library, you need to copy it to your import library, though if indeed multiple importers start to use it, perhaps it’ll be moved to librevenge. The rest of the test framework is a simple testsuite runner and a cppunit TestFixture subclass that contains the actual test cases.

So in case you are planning how to test your import library, then now you have two options, evaluate them and choose what seems to be the better tool for your purpose.

In from a living document to input handling, I wrote about how we handle touch and on-screen keyboard events in the LibreOffice Android app. A next step in this TDF-funded project is to provide more UI elements which are specific to touch devices: selections is one of them.

Here are the problems we had to solve to get this working:

Long push is reasonable to map to double mouse click, as in both cases e.g. in Writer the user expects to have a select word action. But for the adjustment of selections, we really had to define a new API (lok::Document::setTextSelection()) to allow setting the start or end of the selection to a new logical (in document coordinates, not paragraph / character indexes) point.

If you are interested how this looks like, here is a demo:

An other direction we’re working towards is to have the same features in other applications as well: Impress and Calc. Perhaps not so surprisingly, we hit similar problems in these applications as well that we had to solve in Writer. The typical problems are:

Here is how Impress looks like, with working tile invalidation, touch and keyboard handling:

Calc is lagging a bit behind, but it also has working tile invalidation and keyboard handling:

That’s it for now — as usual the commits of me and Tomaž Vajngerl are in master (a few of them is only in feature/tiled-editing for now), so you can try this right now, or wait till the next Tuesday and get the Android daily build. :-)

In from viewing only to a living document, I wrote about how tile invalidation can handle updates in the Android app in case what should be displayed on the screen changes. A next step in this TDF-funded project is to handle more than blinking text: keyboard and mouse/touch events from the user.

First let me enumerate over the issues we had to face:

As usual the commits of me and Tomaž Vajngerl are in master, so you can try this right now, or wait till tomorrow and get the Android daily build. However, if you are just interested how this looks like, here are some demos:

That’s it for now — next on our list are selections, so you can delete and overwrite more easily. :-)

Today is my last day in Brussels where I gave a TextBoxes: complex shapes with complex content and a LibreOffice on Android talk at FOSDEM 2015, in the Open document editors devroom. The devroom was well-crowded, with about 100 users in the rows of the audience — proof pictures above and below. ;-)

We also had a Hackfest with about 20 hackers attending, (again) kindly hosted by Betacowork on Monday and Tuesday:

There were a few topics I hacked on:

A full list of achievements is available, if you were at the hackfest and you did not contribute to that section, please write a line about what did you hack on. :-)

Quite some other slides are now available on Planet, don’t miss them. Mines are also uploaded.

As it has been announced last week, an Android port of LibreOffice in the form of a viewer app is now available for download. What’s next? Editing, naturally. First, thanks again to The Document Foundation — and all the donors who made this (ongoing) work possible. In this post I would like to explain what did we do with Tomaž Vajngerl at Collabora so far in that direction.

If you ever touched the Android port of LibreOffice, you probably noticed that sadly developing for Android is much harder compared to Linux (desktop). On Linux, if you just touch a single module, it’s possible to rebuild just that module in a few seconds, and then you can run soffice again with your modifications included. On Android, this is much harder:

and only then can you test your changes. To partly sidestep from this problem, we split the "Android editing" into two:

One problem with this approach was that while Android properly rendered small tiles of 256x256 pixels, gtktiledviewer rendered a single huge tile. This means that in case part of the document changes and we need to re-draw it, we always repainted the whole document in gtktiledviewer, while we only repainted the necessary parts on Android. Guess what, if the area to be repainted is wrong, it’ll be visible on Android but not on gtktiledviewer. So the first task we solved was to let gtktiledviewer also render small tiles. For debugging purposes, small red rectangles are painted at the top left corners of each rectangle, so the size and position of the tiles can be seen easily:

The next step was to somehow start work on real editing — but where to start? We identified two critical building blocks:

To avoid solving two problems at the same time, we first went after the second. One use case that only requires the update of the view is blinking text. Even if no touch or key events are available, a blinking text wants to update the view using a timer, so it’s a good testcase. It’s now possible for LibreOfficeKit clients to register a notification callback, and using that, LibreOffice can notify clients if part of the view has to be redrawn. Here is how it looks using gtktiledviewer:

This demonstrates that the LibreOfficeKit implementation in LibreOffice core and also the gtktiledviewer client code handle correctly tile invalidations. Once that was done, we could also implement a similar client code in the Android app — it looks like this:

That’s it for now — next on our list is adding support for input handling, so it’s possible to type in some text. :-)

TL;DR: Import of annotated text ranges from binary DOC format was a problem for quite some time, now it should be as good as it always was in the ODT/DOCX/RTF filter.

Longer version: the import of annotation marks from binary DOC was never perfect. My initial implementation had a somewhat hidden, but important shortcoming, in the form of a "Don’t support ranges affecting multiple SwTxtNode for now." comment. The underlying problem was that annotation marks have a start and end position, and this is described as an offset into the piece table (so the unit was a character position, CP) in the binary DOC format, while in Writer, we work with document model positions (text node and content indexes, SwPosition), and it isn’t trivial to map between these two.

Tamás somewhat improved this homegrown CP → SwPosition mapping code, but was still far from perfect. Here is an example. This is how this demo document looks like now in LibreOffice Writer:

And this is how it looked like before the end of last year:

Notice how "Start" is commented and it wasn’t before. Which one is correct? Here is the reference:

The reason is that the document has fields and tables, and the homegrown CP → SwPosition mapping did not handle this. A much better approach is to handle the mapping as we do it for bookmarks: even if at the end annotation marks and bookmarks are entires in sw::mark::MarkManager, it’s possible to set the start position as a character attribute during import (since mapping the current CP to the current SwPosition is easy) and when we know both the start and end, delete the character attribute and turn it into a mark manager entry. That’s exactly what I’ve done. The first screenshot is the result of 3 changes:

Hopefully this makes LibreOffice not only avoid crashing on such complex annotated contents, but also puts an end to the long story of "annotation marks from binary DOC" problems.

TL;DR: If you touch the ODF and/or OOXML filters in LibreOffice, please use the --with-export-validation configure option after you ran the setup.sh script.

Markus Mohrhard did an excellent job with adding the --with-export-validation build switch to LibreOffice. It does the following:

One remaining problem was that it required setting up both odfvalidator and officeotron, neither of them are standard GNU projects but Java beasts. So even if I and a number of other developers do use this option, it happens from time to time that we need to fix new validation regressions, as others don’t see the problem; and even if we point it out, it’s hard to reproduce for the author of the problematic commit.

This has just changed, all you need is to get export-validation/setup.sh from dev-tools.git, and run it like this:

I.e. the first parameter is a working directory and the second is a directory that’s writable by you and is already in your path. And then wait a bit… ODF validator uses maven as a build system, so how much you have to wait depends on how much of the maven dependencies you already have in your local cache… it’s typically 5 to 15 minutes.

Once it’s done, you can add --with-export-validation to your autogen.input and then toplevel make will invoke odfvalidator and officeotron for the above mentioned documents.

The new year is here, if you don’t have a new year’s resolution yet — or if you hate those, but you’re willing to adopt a new habit from time to time — then please consider --with-export-validation, so that such regressions can be detected before you publish your changes. Thanks! ;-)

TL;DR: see above -- a number of preset shapes are now rendered correctly at any scale factors, where previously rendering problems occurred.

fdo#87448 has a reproducer document that shows rendering errors with the scaled cloud preset shape definition. At first I thought that the OOXML spec has wrong definition for this shape type, but that turned out to be not the case. What was a problem is our implementation of the drawingML arcTo command. This implementation defines how we render such arcs as polygons when the shape is to be painted, and given that LibreOffice has native support for the drawingML arcTo / ODF G command, this implementation is invoked during rendering, it’s not an import/export problem.

The rendering result looked like this before:

The cloud is drawn using a set of moveTo and arcTo commands. MoveTo is easier, as it uses explicit coordinates, but arcTo is more complex. It has 4 parameters: the height and width of a "circle", and the start / end angle of an arc on that circle. (Of course if height and width do not equal, than that’s no longer a circle… ;-) ) The problem is that due to this, the distance vector between the arc’s start and end points is implicit — so if something is miscalculated, errors are nicely added to each other as more and more arcs are drawn. This is especially a problem if you later return to the end of an earlier arc using moveTo: if arcTo has some problem, then it’ll be clearly visible.

After fixing UNO ARCANGLETO to only take care of scaling / translation only after counting the actual arc, we started to produce correct end points for the arcs and shapes started to appear correctly at any scale factor, yay! :-)

One remaining problem was how to test this from cppunit, in the above commit I exported the shape to a metafile, and then I could use Tomaž’s excellent MetafileXmlDump to assert that the end of an arc (implicit location) and the parameters of a moveTo command (explicit location) equal — when they do not, that’s what your eyes call a "rendering problem".