Next week I’m flying to FOSDEM to let you know about our work in LibreOffice for Android, which has just been released in the Play Store. In my talk I will focus on the document browser, the new features we are currently working on and my own vision for the future of this component.
You can read more about LibreOffice for Android in this post from The Document Foundation, and some gory technical details in Michael Meeks’ blog.
EDIT: Slides! Find them here.
Last week I went back to the University of A Coruña, this time to stand at the opposite side of the classroom and conduct a workshop about LibreOffice.
I was invited by Juan José Sánchez Penas as part of the subject System Information Design (Deseño de Sistemas de Información) which belongs to the Master in Computer Science Engineering (Mestrado de Enxeñería Informática). The goal was introducing students to a real world project and see how the techniques they learn are applied in practice.
The table of contents:
Find below the slides I prepared for the workshop, with versions both in Galician and English. Files are hybrid PDFs to make them easy to modify and reuse; feel free to do it under the terms of the CC-BY-SA license.
EDIT: you probably want to check an updated version of the talk at: Updated LibreOffice workshop at A Coruña University
I’m borrowing the post title that Tomaž and Andrzej used before to talk about the work that I have lately been doing at Igalia regarding LibreOffice on Android.
You might know there are several projects living under android/experimental in our code tree; it is exciting to see that a new experiment for a document viewer that uses a fresh approach recently arrived to the party, which can be the basis for an Android editor. I was happy to add support to receive view or edit intents to the shiny new viewer, so we could open any document from other Android applications like file browsers.
Besides, android/experimental hid some very interesting work on an Android-centric document browser that could be a good starting point to implement a native Android wrapping UI to LibreOffice, although it had some problems that made it unusable. In particular, thumbnail generation was making the application crash – for that reason I’ve disabled it until we get a proper fix – and the code to open a document was broken. Fixing and working around these issues were the first steps to bring the document browser back to life.
I noticed that the browser was inconveniently dependent of the ActionBarSherlock library, which is not really necessary now we are targetting modern Android versions with out-of-the-box action bar support. I replaced Sherlock ActionBars with Android native ones, and that allowed to remove all the files from ABS library from our source tree.
I also took the freedom to reorganize the application resources (design definitions, bitmaps and so), removing duplicated ones. It was the preparation for the next task…
Finally, I merged the document browser project into the new viewer with this huge patch, so they can be built and installed together. I also did the modifications for the browser to open the documents using the new viewer, so they become one coherent, whole application.
Now both the viewer and the document browser can evolve together to become a true LibreOffice for Android, which I hope to see not too far away in the future.
I’m happy to announce that I will be taking part in the 2014 edition of LibreOffice Conference as a speaker. I’ll overview the status of accessibility in our favorite productivity suite, starting with an introduction to accessibility support and how application are supposed to implement it, we will check the particular case of LibreOffice: which accessibility backends are implemented and how the architecture is designed to support multiple backends while maximizing code reuse.
The conference program looks hot too, and this time I’m particularly interested on hearing from the success cases that will be presented there, looking for ideas and lessons to apply to new deployments.
Igalia is one of the sponsors of the conference, taking our compromise with LibreOffice project a step further. The company will also be sponsoring my flight and stay in Bern.
Last but not least, it will be great to meet the community members again, and get to know those I haven’t met yet in previous conferences or hackfests. Looking forward to seeing you at Bern!
EDIT: get the slides here!
I’m welcoming the release of LibreOffice 4.3.0 in the name of Igalia with the last post in this series. This time we will talk about the preservation of embeddings in OOXML text documents, and devote some lines to the support of Standard Document Tags.
Our goal this time was the preservation of embedded content in OOXML text documents, as a first step towards full support like we did with other features. The insertion of new embeddings in .docx documents or the edition of existing ones will have to come later in the future.
An embedded document usually consists of two files; one of them is a preview picture to be shown in the parent document, and the other one is the actual embedded document. For the case of a spreadsheet embedded in a text document, the most common case, you will find these two files in the document:
[code]
/word/media/image1.emf
/word/embeddings/Microsoft_Excel_Worksheet1.xlsx
[/code]
With the corresponding entries in the relations file:
[code language=”xml”]
<Relationship Id="rId2"
Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/package"
Target="embeddings/oleObject1.xlsx" />
<Relationship Id="rId3"
Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
Target="media/image1.emf" />
[/code]
The relevant bits in the document.xml file are below. Notice a w:object consists of one shape, which is filled with data from an image file, and the OLE object itself, linked to the embedded spreadsheet. Also notice the attribute ProgID, which defines the program, document type and version:
[code language=”xml”]
<w:object>
<v:shape id="ole_rId2"
style="width:362.25pt;height:146.25pt" o:ole="">
<v:imagedata r:id="rId3" o:title="" />
</v:shape>
<o:OLEObject Type="Embed" ProgID="Excel.Sheet.12"
ShapeID="ole_rId2" DrawAspect="Content"
ObjectID="_570182397" r:id="rId2" />
</w:object>
[/code]
There is one more element that allows the embedded file to be properly detected by Word, it’s a content type definition in the content types file:
[code language=”xml”]
<Override PartName="/word/embeddings/oleObject1.xlsx"
ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" />
[/code]
As you can see there are three elements that determine the kind of embedding we are dealing with, and Word requires the right combination of the three of them:
The most convenient way to achieve our goal was using the grab bag technique to store the ProgID attribute of the object, and infer the correct content type and relation type. Some examples:
If you detect a particular type of embedding in your documents that isn’t being preserved, drop us a line in the Bugzilla. A patch to add new relations of this kind should be quick and easy.
Structured Document Tags (SDTs) is a family of document objects that contains form-like controls, citations, contents tables or bibliography tables among many other. This variety of uses means that they can live inside a paragraph or they can be a high-level element that contains several paragraphs and even shapes, which of course is tricky to implement.
For 4.3.0 we have worked on some of these tags, and we can say we properly implemented the import and export of combo, date and check boxes. We also wrote some code to preserve generic SDTs and now most of the tags are preserved but there are formatting issues. The proper way to support every kind of SDT is translating them to the equivalent objects in LibreOffice on import and translate them back to SDTs on export, but that will require time and work. Any volunteers? 😉
Despite the 6-month development cycles, I’m feeling like the development of 4.3 line started a long time ago and I may have forgotten to write about some little feature or fix… Anyway, it’s time to close this batch of blog posts about interoperability features, all of them developed by Igalia and sponsored by CloudOn.
Enjoy our shiny new LibreOffice, and happy hacking!