»Root
»Rejourn root
»LibreOffice Community Blogs
Search:
  • Friday, 04 January 2019
    SmartArt improvements in LibreOffice, part 3

    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.

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

    smartart-accent-process.pptx, baseline

    smartart-accent-process.pptx, current

    smartart-accent-process.pptx, reference

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

    smartart-org-chart.pptx, baseline

    smartart-org-chart.pptx, current

    smartart-org-chart.pptx, reference

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


  • Tuesday, 04 December 2018
    SmartArt improvements in LibreOffice, part 2

    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.

    Results so far

    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:

    smartart-accent-process.pptx, baseline

    smartart-accent-process.pptx, current

    smartart-accent-process.pptx, reference

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


  • Monday, 05 November 2018
    SmartArt improvements in LibreOffice

    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.

    Results so far

    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:

    smartart-vertial-box-list.pptx, baseline

    smartart-vertial-box-list.pptx, current

    smartart-vertial-box-list.pptx, reference

    vertical-bracket-list.pptx, baseline

    vertical-bracket-list.pptx, current

    vertical-bracket-list.pptx, reference

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


  • Monday, 01 October 2018
    Text layout performance in LibreOffice conference lightning talk

    Last Friday I gave a Text layout performance lightning talk at LibreOffice Conference 2018. Click on the image to get the hybrid PDF slides!


  • Friday, 28 September 2018
    ReqIF import/export in LibreOffice Writer conference talk

    Earlier today I gave an Editing ReqIF-XHTML fragments with Writer talk at LibreOffice Conference 2018. The room was well-crowded — perhaps because the previous talk was about OOXML interoperability. ;-)

    I expect quite some other slides will be available on Planet, don’t miss them.


  • Sunday, 23 September 2018
    odfsig: an Open Document Format (ODF) digital signatures tool

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


  • Saturday, 22 September 2018
    mutt/vim offline address book with multiple sources

    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!


  • Friday, 07 September 2018
    Custom user profiles with unoconv

    https://farm2.staticflickr.com/1859/43598513125_55bed46184_o.png

    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.

    So I filed a GitHub pull request on 1st Jun, and finally it was merged on 10th Aug.

    Here is how you can use it for example:

    unoconv --user-profile /tmp/tmpf_yreswi -f pdf --port 2002 test.txt
    Note
    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. :-)


  • Wednesday, 08 August 2018
    API improvements in LibreOffice

    https://farm2.staticflickr.com/1793/43859007612_ca207fed0f_o.png

    I worked on two small features to extend the public (UNO) API of LibreOffice. First, thanks to Vector for funding Collabora to make this possible.

    Aliased paths and text in the PNG export for Draw

    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:

    xExporter = createUnoService("com.sun.star.drawing.GraphicExportFilter")
    xExporter.SetSourceDocument(ThisComponent.DrawPages(0))
    Dim aArgs(1) As new com.sun.star.beans.PropertyValue
    aArgs(0).Name  = "URL"
    aArgs(0).Value = "file:///tmp/debug/aa.png"
    aArgs(1).Name  = "MediaType"
    aArgs(1).Value = "image/png"
    xExporter.filter(aArgs())

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

    https://farm2.staticflickr.com/1832/43859007522_aeb4516f02_o.png

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

    Dim aFilterData(0) As new com.sun.star.beans.PropertyValue
    aFilterData(0).Name = "AntiAliasing"
    aFilterData(0).Value = False
    xExporter = createUnoService("com.sun.star.drawing.GraphicExportFilter")
    xExporter.SetSourceDocument(ThisComponent.DrawPages(0))
    Dim aArgs(2) As new com.sun.star.beans.PropertyValue
    aArgs(0).Name  = "URL"
    aArgs(0).Value = "file:///tmp/debug/non-aa.png"
    aArgs(1).Name  = "FilterData"
    aArgs(1).Value = aFilterData()
    aArgs(2).Name  = "MediaType"
    aArgs(2).Value = "image/png"
    xExporter.filter(aArgs())

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

    Note
    This feature is available for other bitmap formats as well, PNG is only an example.

    Default character style in Writer

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

    xCursorProps->setPropertyValue("CharStyleName", uno::makeAny(OUString("Standard")));

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


  • Thursday, 05 July 2018
    Improved ECDSA handling in LibreOffice

    I wrote about ECDSA handling in LibreOffice last year, back then the target was to be able to verify signatures using the ECDSA algorithm on Linux.

    Lots of things happened since then, this post is meant to summarize those improvements. My personal motivation is that Hungarian eID cards come with a gov-trusted ECDSA (x509) cert, so handling those in LibreOffice would be nice. My goals were:

    • platforms: handling Windows as well, not only Linux/macOS

    • operations: handling signing as well, not only verification

    • formats: cover all of ODF, OOXML and PDF

    Let’s see what has happened:

    • Linux, ODF, sign: we had hardcoded RSA algorithm when generating a signature, now we infer the sign algorithm from the signing cert algorithm (commit)

    • Linux, OOXML, sign: same problem with hardcoded RSA (commit)

    • Windows, PDF, sign: the certificate chooser had to be ported to from CryptoAPI to CNG (commit)

    • Windows, ODF, verify / sign: this was the largest problem, this required a whole new libxmlsec backend (interface, implementation, all in C90) and also required conditionally using that new backend in LibreOffice (commit)

    • Windows, OOXML, sign: this was almost functional, except that the UI recently regressed, now fixed (commit)

    • Finally now that everything is ported on Windows to use CNG, I could enable it by default yesterday.

    I could test hardware-based signing after this, which was fine out of the box on both platforms. Some screenshots:

    • Linux:

    https://farm2.staticflickr.com/1784/29321634078_8818b2d7ba_o.png
    • Windows:

    https://farm1.staticflickr.com/927/42288765505_db72ee48f2_o.png

    (There is no reason why this would not work on macOS, but I did not test that.)

    Thanks Gabor Kelemen who helped me to get a sane card reader that has reasonable driver support on Linux.

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


more »