Category Archives: LibreOffice

Document Freedom Day 2014 recap

Posted on by
1

You already know I took part in the celebration of the Document Freedom Day speaking in an event in the University of Coruña. The nice people from GPUL had recorded the talks and now they are ready for everyone to enjoy, distribute or reuse under the terms of the Attribution-ShareAlike 4.0 International license.

Here are the talks:

Estándares abertos, a situación dende o punto de legal

Estándares abertos, a situación dende o punto de legal

LibreOffice, o proxecto de referencia para a edición de documentos libres

LibreOffice, o proxecto de referencia para a edición de documentos libres

Sobre a importancia dos estándares e formatos libres

Sobre a importancia dos estándares e formatos libres

Tales of LibreOffice interoperability: theme fonts

Posted on by
1

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

Posted on by
3

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

Posted on by
Reply

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!