Tales of LibreOffice interoperability: theme fonts

This is the first post in a series that explains the work that we’ve been doing lately in LibreOffice at Igalia, which hopefully will be part of the future 4.3 release.

Document themes is one of the features of the Microsoft Office suite that doesn’t have support in LibreOffice yet. While it happens, which is a hard work that includes extending the ODF standard, we are focusing on the preservation of the theme information when a document coming from Office is edited in LibreOffice and saved back to OOXML.

First of all, we needed to preserve the theme files contained in the document, which are stored at /word/theme/ inside the document. LibreOffice was able to read and parse the theme definition file to assign colors and fonts to the document elements, but it was discarded after that and not preserved on export. Miguel and Andrés took care of that part of the job when working in the preservation of Smart-Art information and it’s already present in 4.2 release.

Then it was my turn to identify and preserve the theme-related attributes in the document, starting with font attributes. From the user point of view, there are two types of theme fonts in Word: Heading, named major internally, and Body, named minor. Besides this distinction, there are three types of fonts that users can manage separately: Latin, Asian and Complex Script (for Hebrew, Arabic, etc.). Users can set one specific font, or a major or minor theme font, for each of the three types.

Word 2010 font selector

What actual font this mess translates to depends on several things:

  • Type of characters: the application decides if a portion of text is written in Latin, Asian or CS checking the range of characters it contains, and uses the font that the user set for that type.
  • The document language: the theme file can define one font per language besides a fallback font per type:
    [code language=”xml”]
    <a:minorFont>
    <!– default fonts per type –>
    <a:latin typeface="Trebuchet MS" />
    <a:ea typeface="" />
    <a:cs typeface="" />

    <!– language-specific fonts –>
    <a:font script="Hans" typeface="宋体" />
    <a:font script="Hebr" typeface="Arial" />
    </a:majorFont>
    [/code]

  • The default language: the document settings file can define one default language for each font type:
    [code language=”xml”]
    <w:themeFontLang w:val="en-US" w:eastAsia="zh-CN"
    w:bidi="he-IL" />
    [/code]

How does it work altogether? With the above definition of the language settings, the default language for CS text is Hebrew (he-IL), and the theme defines the minor font Arial for that language. In the case of latin languages, it will be Trebuchet MS. This was a new behaviour in LibreOffice that we had to implement ourselves. Notice the mixed use of different naming conventions for languages and regions, which requires conversions.

LibreOffice font selector

My work on theme attributes comprises the preservation of font and shape colors too, but this post is already long enough; that will be part of the next chapter. Let me finish with a thank you to CloudOn for funding this development, and to Adam Fyne for his work detecting and triaging these theme preservation issues.

LibreOffice UX hackfest: for an accessible user experience

Accessibility is one of the areas of interest for us at Igalia, that’s why I traveled to Brussels some weeks ago to take part in the LibreOffice UX hackfest organized by The Document Foundation and kindly hosted by Betacowork. My colleage Joanmarie Diggs, maintainer of Orca, had identified a set of bugs that will be instrumental in improving the experience with the screen reader; as she keeps saying, “Orca can only provide access to what is made accessible.”

Before diving into the specifics, let me introduce the accessibility layers of LibreOffice first. Due to its multi-platform nature, LibreOffice provides its own Visual Components Library (VCL), with a graphical toolkit in the fashion of GTK+, Qt, etc. It serves as an operating system abstraction, and it is mapped to system-specific libraries whenever possible. When it comes to accessibility, there is a set of internal accessibility APIs that can be translated into ATK objects and functions in the same way it can be translated to IAccessible2 API in Windows.

The first thing I tackled was implementing and improving the accessible roles exposed by LibreOffice. Better role support means smarter client applications: for example, an object registering itself as a spreadsheet document allows the screen reader to make some assumptions about the structure of that document and present its contents more efficiently, and in a more tailored fashion, than it could for a generic document. And navigation by heading only works if headings claim to be headings rather than paragraphs.

Bug #39944 is about adding support for new(ish) ATK roles which LibreOffice wasn’t using yet. Checking the list of existing internal roles we find out that some of the new roles fit properly in the existing API, for example group box and comment internal roles match with ATK’s grouping and comment. But other roles had to be added from scratch. This was the case for the new, specific roles for spreadsheet, text and presentation documents that I added to LibreOffice API and linked to their ATK relatives.

Bug #35105 was a trickier one, because it looked more simple than it was… The problem as reported was that headings in text were not exposed using the proper heading role. But as I dug deeper, I discovered a much more complicated issue: paragraphs that could become headings, and the opposite, as a result of editing the document. LibreOffice lacked support for accessibility objects changing their roles, so I added a new event to the API to notify role changes, and connected that event with atk_object_set_role.

I also spent quite some time working on bug #35107. Again, it looked like a simple role-support bug, but I had learned not to trust the first impression. To debug this one, I first had to learn about the ATK hypertext interface and hyperlink objects. Having done so, I was able to verify that LibreOffice’s existing hypertext implementation was working properly. The same didn’t hold true for the hyperlink; in particular, the implementation of hyper_link_get_object in LibreOffice was wrong. A patch is still pending because it requires involving the third member of the ATK hyper-family, AtkHyperlinkImpl, of which there is no trace in LibreOffice (yet) and thus has to be implemented from scratch. Anyway, it was an interesting debugging and documentation-reading exercise.

In addition to the above, I spent some time triaging  existing accessibility bug reports filed by GNOME developers and users and closing those which had already been fixed. The work of code analysis also led me to think of some additional improvements which can be made in LibreOffice’s ATK support. I’ve filed them for now and will begin working on them soon.

I want to thank The Document Foundation for having invited me to attend this hackfest, and all the other participants. It was great to meet all the people I know from the IRC in person.

Happy hacking!

Flavors from Brussels

Flavors from Brussels

Flying to Brussels for some hacking

Just some lines to say I’ll be flying to Brussels with some of my fellow Igalians to attend FOSDEM 2014 next week. It will be a wonderful opportunity to meet in person the members of the communities we are involved in, learning and, of course, having fun.

FOSDEM 2014 logo

But my main interest is taking part in the LibreOffice UX hackfest that will happen afterwards. My plans there include hacking on LibreOffice accessibility, one of the areas of interest for us in Igalia.

LibreOffice hackfest logo

Hope to see you there!

A somehow late recap on 2013

First of all let me wish you a happy new year, dear reader! These kinds of posts are supposed to be published in the last days of the year, but I needed some holidays before being back at full-steam.

That’s because 2013 has been quite a ride from the professional point of view. I have never touched so many different technologies and frameworks in such a relatively short time period:

  • I started the year Introducing KiCad, one of the best free software EDA software suites. I have been contributing to KiCad for some months and even gave a talk to the students at the Facultade de Informática da Coruña.
  • PhpReport got a new release in the first months of 2013.
  • I was also Playing with HTML5 in my spare time to develop a full, albeit short, arcade game.
  • I have helped my fellow Igalian Juan A. Suárez to debug the XML meta-plugin for Grilo, which will allow the development of simpler Grilo plugins using an XML based language. We hope to release it (and blog about it!) in the months to come.
  • I also took some steps into Android application development.
  • And finally, I joined the LibreOffice community where I have been happily contributing to the support of OOXML standard and helping to detect and correct accessibility problems. I’ve already been granted commit permission on the main repo and invited to join ESC meetings. I feel really honored and grateful about that.

IMG_5171

Another feat of 2013 is that Igalia has turned 12, and we celebrated it as a part of the last Igalia summit. We spent the weekend in a really beautiful location in Galicia where we were able to relax, eat, drink, compete in the first official Igalia gymkhana and we even had time to sit down together to discuss how to face the future, spread our values and keep enjoying what we do.

I am really happy to show how Igalia keeps going forward on its compromise with Free Software. In the last year we joined a number of consortia and associations and sponsored FLOSS-related events all around the world. I would like to highlight our membership to the W3C, with whom we will contribute shaping the Web of the future, our partnership with Adobe to implement new web standards, our sponsorship to multiple Linux Foundation events or our support to The Document Foundation.

2014 is ahead and it bring new challenges for sure; my only wish is having the energy to face them with passion!