vmiklos.hu
shameless self-promoting website
»Root
»Rejourn root
»LibreOffice Community Blogs
Search:
  • Monday, 29 June 2015
    ctags vs override/SAL_OVERRIDE (Comments)

    https://lh3.googleusercontent.com/-9Hd40EVT8aw/VZBhBTZQdTI/AAAAAAAAFyM/AfymfTqKDFw/s0/

    If you use ctags to help your LibreOffice development, there are already good descriptions for that — e.g. for vim there is one on the TDF wiki.

    What was problematic is that since C++11, override is a valid keyword after a member function declaration, and we have our SAL_OVERRIDE macro that I added to be able to use it before all our supported compilers recognize it. Unsupported parsers include ctags, so if a member function have SAL_OVERRIDE, ctags only indexed the definition, not the declaration.

    I created patches to fix these problems in ctags, the override one is probably interesting for all C++ projects, the SAL_OVERRIDE one is LibreOffice-specific.

    The hope is that the later will go away in the long run, so it won’t really be a problem that ctags do not recognize that macro out of the box. :-)


  • Monday, 08 June 2015
    Cleanup of resourcemodel in LibreOffice (Comments)

    (via jbparrott)

    The libreoffice-5-0 branch is created, and in each release cycle there is at least one topic that was a long overdue cleanup. In this post, I’m describing how and why the writerfilter/inc/resourcemodel/ and writerfilter/source/resourcemodel/ directories disappeared — though probably nobody will miss them. :-)

    The resourcemodel building block of writerfilter (that handles Writer’s DOCX and RTF import in LibreOffice) was basically a bucket of old and unused stuff. After the removal of the unused .DOC tokenizer, it turned out that most of that code was just referring to itself or template code that was used with a single type only (hello TableManager). resourcemodel was about 6000 lines of code at the time LibreOffice was started, and after some manual cleanup and moving the still needed small part to dmapper (the shared part of the RTF / DOCX import), tools like loplugin:unreffun and callcatcher helped to detect what became truly unused — at the end resulting in the complete removal of these directories.

    That means that after folding the last remaining header into dmapper, the relevant documentation can hopefully now describe source contents easier, having just 4 directories: the RTF and the DOCX tokenizer, the shared part and the UNO service implementations. One less cryptic leftover nobody really knows what it is! ;-)


  • Tuesday, 26 May 2015
    LibreOffice Cambridge Hackfest (Comments)

    https://lh3.googleusercontent.com/-dGY38VD7z0M/VWNqvkXDLwI/AAAAAAAAFlE/8yurKsu0NcA/s400/

    The first ever UK LibreOffice Hackfest took place in the city of Cambridge on May 21st to 23rd (Thursday → Saturday), kindly hosted by Collabora.

    My starter idea was to fix tdf#90315, i.e. to support both nested tables and multiple columns with the proper spacing in between them in the RTF import. For comparison, here is how this looked in LibreOffice 3.4:

    https://lh3.googleusercontent.com/-KX9Z8y1ojYc/VWNzgg1gQeI/AAAAAAAAFlk/TRwfvnklEOI/s400/

    The table borders looked OK due to correct column spacing, but the nested table is missing. Then here is the LibreOffice 4.4 state:

    https://lh3.googleusercontent.com/-wz4OZdsYf5I/VWNzgu5OhUI/AAAAAAAAFlg/CG37pRlGggY/s400/

    Nested table is OK, but the table borders are strange due to incorrect column spacing. Finally here is how it looks like now, when the import result is correct:

    https://lh3.googleusercontent.com/-Zul_8xTSOkA/VWNzguGZf-I/AAAAAAAAFlY/L88WkfCpL1E/s400/

    Other than this, here is a list of other topics I hacked on:

    After fixing two more less interesting regressions, now it seems we’re down to 0 for the regressions having RTF in their summary, which is promising. :-)

    I few pictures I took while punting and a panorama is available, too.


  • Monday, 18 May 2015
    Protocols Plugfest Europe 2015 (Comments)

    (via plugfestcon)

    Last week I went to Zaragoza to give a talk on how LibreOffice handles interoperability at Protocols Plugfest Europe 2015 on Tuesday. Although I was told this conference is a successor of the previous Zentyal Summit (and I were not there) the conference seemed well-attended — proof above. :-)

    Jacobo also gave a LibreOffice-related talk on Wednesday.

    On the same day, there were some explicit spare time, so I took the opportunity to walk in the historical parts of the city, see my photos and a panorama if that kind of pictures are of your interest. FWIW, Hotel Sauce has free wifi in the rooms, that’s kind of impressing for a two-star category. ;-)

    As usual, thanks Collabora for sponsoring this travel!


  • Sunday, 03 May 2015
    MathType import in the RTF and DOCX filter (Comments)

    TL;DR: Import of old-style (pre-2010 for RTF, pre-2007 for DOCX) math equations embedded into text documents should be now imported as editable embedded math objects.

    Longer version: if you want to embed math equations into RTF or DOCX files, you have two choices. The older approach is to embed a MathType OLE object into the file, the newer one is a native OOXML markup, which has an RTF markup equivalent as well. Handling of the later has been implemented by Luboš Luňák for DOCX a long time ago, and I contributed the RTF equivalent almost 3 years ago.

    What remains is the handling of the older version, the embedded OLE object. Previously only the replacement graphic was imported, so regardless of the Tools → Options → Load / Save → Microsoft Office → MathType to Math checkbox, the result was never editable.

    Here is how it looks like now:

    https://lh3.googleusercontent.com/-V3SqO3Rz88s/VUZvFcBNMPI/AAAAAAAAFb4/QARDYqQVQGY/s0/

    Given that the RTF and the DOCX importers share lots of code in the writerfilter/ module, I implemented the same for the DOCX import at the same time, too. The interesting challenge was that writerfilter wants an XFilter implementation for the embedded object if it is to be handled internally by LibreOffice, but the MathType filter (originally created to handle math objects inside binary DOC files) didn’t have one. Once I implemented such a filter wrapper, the rest wasn’t too hard.

    Here are test documents if you want to try it yourself. You’ll need a 5.0 daily build for that, though. ;-)

    If I’m at describing features new in LibreOffice Writer 5.0 file filters, here are a few more:

    And a number of bugfixes for the RTF filter:

    • tdf#86182 better RTL paragraph handling

    • tdf#80708 related to the improved old-style Writer table export handling work

    • tdf#90421 hyperlink export tweak

    Do these sound interesting? Look at what others did for LibreOffice 5.0 on the TDF wiki, even if it’s far from complete, as the 5.0 branch is not yet created. :-)


  • Tuesday, 21 April 2015
    Open IT 2015 (Comments)

    https://lh3.googleusercontent.com/-bcwPYUJF04A/VTY_cdBo8bI/AAAAAAAAFac/B5ICyiGoKaY/s0/

    On Saturday I gave a talk at the Open IT 2015 conference about the new features of LibreOffice 4.3 and 4.4. My uploaded slides are available here.

    Thanks Óbuda University for hosting us, it was a great event! Other than talking to the usual suspects like Tamás Zolnai or Gábor Kelemen, I enjoyed two OpenStreetMap talks: it was extermely cool to hear that finally the turistautak.hu community changed their license in February so that all their free maps can be imported to OpenStreetMap — finally one pointless fight ends.


  • Friday, 17 April 2015
    Open Source Budapest 5. meetup (Comments)

    On Tuesday the 5th Open Source Budapest meetup was held, I was one of the invited speakers, and gave a lightning talk about ged2dot, both as a standalone Python script and as a LibreOffice extension.

    My uploaded slides are available here.


  • Thursday, 02 April 2015
    Android editing: from graphic handling to formatting (Comments)

    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:

    • When you click on toolbar buttons on the desktop UI, so-called UNO commands are invoked, bold is .uno:Bold.

    • This command is generated by the native Android UI as well, and passed to the lok::Document::postUnoCommand() LOK API.

    • Then the LOK implementation uses the recently introduced comphelper::dispatchCommand() internal API to actually execute it.

    • In all applications (Writer, Calc, Draw and Impress) this command is then evaluated on the current selection: so if you have a cursor position, then from now on the new characters will be bold — or if you have a selection, then that will be adjusted. The point is that this works exactly how it happens with the desktop UI, reusing the same code.

    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:

    • shape text now has a blinking cursor with a cursor handle that can be dragged

    • long push on a word results in a shape text selection with selection handles that can be dragged

    • it’s now possible to resize shapes

    • Impress table selections can be created in two ways: either by long pushing on an empty Impress table cell, or by long pushing on shape text inside a cell, and then turning that shape text selection into a table one.

    • it’s possible to tap on a selected shape without text to add text to it.

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


  • Thursday, 19 March 2015
    Android editing: from selections to graphic handling (Comments)

    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:

    • On Linux (the desktop), the move and resize operations are really similar: if you click near a resize handle (you "hit it"), then it’ll be a resize, otherwise it’ll be a move. Defining "near" means that you don’t have to click exactly at the center of the handle, but we allow some tolerance. Turns out that the tolerance depended on the pixel size of the handle drawn on the desktop: and because we don’t package the bitmaps of the desktop UI, that tolerance was 0.

    • Writer normally requires a click and a double-click to start editing shape text. One to select the shape and another to actually start the text editing. Instead of literally translating this to a tap and a long push, we wanted to start text editing right away if the user tapped on shape text.

    • Shape text doesn’t use the normal Writer text, but editeng — used by Impress and Calc, too. So we had to instrument the editeng module as well to expose the blinking cursor, so that if you tap inside the editeng text, you have some feedback where you are. Same is true for the cursor handle: once we knew where the cursor is, we could draw the cursor handle, but dragging it did nothing: now the setTextSelection() LOK API handles the case when the cursor is inside editeng text and can adjust the cursor position there, too.

    • On Linux, users got used to the following resize behavior: when images are resized, the aspect ratio is kept, but this is not the case for shapes. We wanted to keep this behavior on Android, too.

    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:

    • When you tap inside text, we show the keyboard.

    • When you finish editing, we hide it.

    • When you start scrolling, we hide it.

    • When you select an image, we hide it.

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


  • Saturday, 14 March 2015
    Document Liberation Project regression testing (Comments)

    https://lh5.googleusercontent.com/-0Qh5cUx4gGA/VQR_RkRe2jI/AAAAAAAAFU8/5KIPToOna4Q/s0/

    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:

    • If you know that the current state is good, then there is no need write testcases, you can just record your state automatically.

    • Any change in the output fill signal instant failure, so it gives pretty good test coverage.

    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:

    • Provided that make distcheck is ran before committing, you can’t forget to clone and run the tests.

    • Writing explicit assertions means that it’s rarely needed to adjust existing tests. Which is a good thing, as there are no tests for the tests, so touching existing tests should be avoided, if possible. ;-)

    • Having testcase + code change in the same commit is one step closer to the dream e.g. the git.git guys do — they usually require documentation, code and test parts in each patchset. :-)

    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.


more »