This is a report of the ODF Plugfest that was held in The Hague on September 15 and 16, 2015. All the presentations can be downloaded from:

http://odfplugfest.org/2015-thehague

This is the web version of the report. You can download the OpenDocument Format version instead.

The eleventh ODF plugfest was hosted by the Netherlands Forum Standaardisatie, Logius and organised by OpenDoc Society.

ODF Plugfest 11 Report

Day 1 Talks and Catch Up

Morning - ODF policy presentations

The 11th ODF Plugfest, hosted by Logius in the Netherlands, was opened by Graham Taylor of Open Forum Europe. The event took place in the Royal Library in the Hague on Prince's Day - the day that the annual budget is presented to the King of the Netherlands. Delegates come from across the globe and represent application vendors, standards bodies, public sector and industry. Several policy officials from the UK and the Netherlands, the nations leading the way with policy and direction for document interoperability, were involved in the activities.

Steven Luitjens

Steven Luitjens (Director Logius, NL) and Interim Director of DIO focused on the benefits of using standards, for instance DigiD has become a widely used standard in the Netherlands, which saves millions of Euros. Open standards, like ODF, are contributing to the goals of the Dutch government. At this moment all devices in Dutch Central Government have ODF applications installed, but use is still minimal. Steven congratulated Jos van den Oever, Logius, who was recently appointed as co-chair of the ODF TC at OASIS. Jos will now work for Logius on the ODF specification.

Jos van den Oever (Co-chair ODF TC, NL)

Jos van den Oever gave insights on the state of ODF . He talked about standards that are already part of societal norms such as language, currency, laws, recipes etc. He explained the difference between data and formats. Documents traveling through space and time may sound out of place, but an open standard is essential to ensure documents can be opened up in the future. With a closed standard, there is no guarantee that the document can be opened up in 100 years time. Imagine if ancient texts were written with an ink that required a special device to decode, and that was not available.
Some of the current key challenges with ODF include high quality implementations and testing, processing of reported issues and organization of information.
Education is important, people need to know what ODF is and why they need it. Documentation and community engagement will enhance ODF and help others benefit from it.
Jos makes a call to other governments, including the UK government present, to be a part of the community and standards process of ODF, and to join the ODF Technical Committee.

Fliss Bennée (Cabinet Office, UK)

"Awake, arise and stop not till the goal is reached - implementing ODF in government"

Fliss explains that the core focus is around user need. It should not matter what software the creator or recipient has when circulating documents, as it is the content that interests them. It is for the tech leaders to ensure that the users have this functionality and that the suppliers deliver tools that comply. Buy-in at the top is essential, and government policy must be robust and have methods to ensure that the policy is adhered to. The team split implementation into phases that are manageable and measurable and makes timetables and plans for government departments to publish the plans online.
The UK Government plan includes ensuring all new documents on gov.uk are in an appropriate Open Document Format. Any documents created will use ODF and line-of-business applications will generate ODF-compliant documents.
The ODF Guidance is released by the UK Government under OGL(the open government license), so can be used by others as long as it complies with the terms.

https://www.gov.uk/guidance/open-document-format-odf-guidance-for-uk-government

Nico Westpalm van Hoorn (Chair Forum Standaardisatie, NL)

Nico Westpalm van Hoorn explained how Dutch policy on comply or explain works. The Dutch Forum for Standardisation selects and qualifies open standards for government use. With the help of stakeholders for that standard. He questions when something like open document formats is such a no-brainer, why is it an uphill battle to change?

Marijke Salters (Forum Standaardisatie, NL) and Dirk Moree (KING, NL)

Marijke and Dirk demonstrated how the control on ODF compliance works for Dutch municipalities, using the Software Catalogus. Dirk demonstrated the software catalog. All municipalities have joined the catalog and introduce their applications on the architecture plate. The suppliers of applications have access and upload their test results on the standards. When asked for the example, Dirk showed 15 Dutch software applications that support ODF. To help municipalities, it also has a library of statements that can be used by the public sector institutions for tendering.

Svante Schubert (OASIS ODF Advanced Collaboration subcommittee, DE)

Svante Schubert presented ideas on collaboration and track changes with the usage of versioning in ODF. His idea on this topic is a breakthrough especially on the part that not a whole document needs to be loaded, reloaded and compared, but to standardize ODF user changes. He describes the challenges of merging saved documents. When we have many people changing the same document and merging it together, the software cannot always determine who did what and when. Further, one user may make changes without seeing the other users changes to the same section and then expect the software to work out which one should be the final version.

Svante proposes that applying a log of changes to a document is the best way to manage this. In its simplest form, the changes just add, modify or delete. This is very similar to the way that collaborative software developments work. As with software, changes should be followed by a test to make sure the change did not damage the original document.

This process also works identically for real-time and on-the-fly collaborative documents through web-based interfaces.

Strict structures are required to enable such a process to work, but as a result, many new features are enabled. This includes security and safety features, with the opportunity of forensic interrogation of the development of a document. Feedback on read-only documents, annotations and comments become simpler to manage and the whole process becomes more efficient.

Barbara Sierman (Open Preservation Foundation/Royal Library, NL)

Barbara introduced the Open Preservation Foundation (OPF). She explained that her mandate is to preserve documents for the long term, from 25 years to eternity. “We struggle with preserving the file formats, preservation can only be done by using open standards and Open Document Standards are essential for this to be effective.”

Digital Preservation has only existed for around 20 years and it still a work in progress so the mission of the foundation is to share knowledge gained and ensure that it is available for future readers. OPF actively engages with projects and partnerships to advocate the tools and processes required to deliver their mission. Validators are important to ensure the integrity of documents in addition to thorough Open Standards. The OPF are working with other organizations to create PDF/A validators. With this, documents can be checked against these standards enabling informed decisions to be made. The OPF care about the long term preservation of of both tools for file formats as well as the formats, and collaborate with a broader digital preservation community.

Hans de Raad (Pleio, NL)

The morning sessions were closed by Hans de Raad, who updated us on Pleio and ODF. He reported that over 100.000 Dutch Civil Servants in the Netherlands use Pleio to interact on governmental issues. Pleio is built on an open software platform, created by civil servants for use by civil servants. Hans introduced Kolabs Roundcube email with WebODF for Pleio, and has received funding from SIDN for the integration after being selected during an IT challenge. Hans raised the question “why documents still matter?”

He suggests that documents must be independent of the application, where email or social media are connected tightly with the communication, not just the content. WebODF is a web application that enables full management of an ODF document without installing any applications and Kolab are are building on the original work created by KO GmbH. Pleio uses the ELGG framework as the base.

Afternoon talks from suppliers

Andras Timar (Collabora, UK)

LibreOffice representatives take part in the work of OASIS ODF TC, the goal is to make LibreOffice's ODF extensions part of the upcoming ODF 1.3 version. File format validation against around 85,000 documents relating to import/export crashes and file format validation. The suite is automatically tested every 3 days and now handles all of the crash tests without failure.

LibreOffice is now available on almost all platforms, even Raspberry Pi. However, the popular demand is now to use it through a web browser as a cloud application.
LibreOfficeKit has been created to expose the LibreOffice internal workings as an API which enables for example LibreOffice on Android and Collabora CloudSuite (LibreOffice Online). For those who want more technical detail: a WebSocket layer which uses LibreOfficeKit acquires tiles of rendered document from the chroot jailed LibreOffice core, and serves them to the client which uses the Leaflet JavaScript library to display the document in the browser. The server part can be run in a virtual machine or Docker container.

A live demonstration was provided running on an AWS instance of Collabora CloudSuite, showing core functions of the application operating. Text files, spreadsheets and presentations were demonstrated, with good performance and rendering of equivalent quality to the desktop installation.

Andras explained additional commercial possibilities offered by Collabora (UK) and CIB (Germany) which provide long-term support, security, maintenance, integration into e.g. Windows security frameworks and custom installers. Custom development and integration services are also offered.

Malte Timmermann, Open-Xchange

Jos van den Oever presented the OX platform on behalf of Malte Timmermann.

The Open-Xchange platform is available as a mixed license, with GPL server side code, and the front-end provided as a Creative Commons license. It is used as a web based text and spreadsheet document editing platform, offering “lossless round-trip” so a document sent between applications and platforms does not loose any data. Many other applications only save their files containing data that they understand, therefore removing any features that they don’t.

The source file is not sent between the server and the client, just the changes, therefore it does not matter which import or export file format is used, the process is the same. OX implements the cloud-based real-time collaborative technique using the “Operations” method.

Kázmér Koleszar (MultiRacio, HU)

MultiRacio is a Hungarian company, they are the creators of EuroOffice. It is now available in 7 languages, covering 85% of the population of Europe. Differences with the Hungarian language and many other European languages mean that many of the tools developed in other similar applications had to be redeveloped to provide reliable Hungarian support.

EuroOffice 2015 is based on LibreOffice 4.3.3. EuroOffice has one release per year. The application is fully Open Source, and external modules are available, some Open Source, others are proprietary. These proprietary modules include barcode/QR code, translators, MapChart, language tools and the free extensions include Sparkline, FormularConverter, EcoPrint.

EuroOffice text, spreadsheet and presentation is now also available in a tablet version. Kázmér has observed the changing demands from the user community. “The document editing community is responding to key market trends including the demand for standardized & open solutions, mobilization, globalization, real-time collaboration.”

Boris Devouge (Microsoft, UK)

Boris Devouge is Microsoft's Open Source Strategy Lead for the UK. He explained that ODF is part of his wider Open Source remit. He talked about some of the issue of blurring the line between marketing and product, and was keen to clarify that Office365 is not a product, but a way of buying Office. A “seat” provides access to Office Online, and a current version of an Office client.

He reported on some of the progress Microsoft has made since the 10th ODF Plugfest in London, back in December 2014. The key updates are implementation of ODF on the Microsoft Office Online application and the “export as ODF”, although documents are OOXML at the back end. He clarified that ODF export can be set as the standard format for 365 commercial customers.

At the event, Boris announced a project within Microsoft to provide the import for every ODF document for Word, Excel and PowerPoint on Mac and iPad as well as the export as ODF for Word, Excel and PowerPoint across Windows and Mac platforms.

Microsoft's interoperability undertakings covers ODF in Primary PC productivity applications and beyond the windows desktop. It is hard to apply this to older versions so this is forward looking. MS have made available licenses for Officeshots so that their latest applications can be tested against the ODF tests.

Friedrich Kossebau (Calligra & Calligra Engine, DE)

Calligra is a suite of office and graphics applications created by a team of people who have different expectations of these applications. The Calligra Engine enables developers to embed the engine to create own apps like custom editors and viewers or to process documents automatically. ODF is used as the default transport and storage format; ODF is the default format and are committed to Open Standards.

Calligra, part of the KDE community, are porting the engine and the applications to a new version of Qt to enable better integration on more operating systems and a better user experience. There is a lot in progress, more updates on this at the next Plugfest.

Dr. Peter Rakyta (MultiRacio, HU)

Merge-enabled Change Tracking (MCT): Implementation on Android platform

Peter has developed MCT extensions for EuroOffice, LibreOffice, Apache OpenOffice. Now he's developing for the Android platform. This is based on the Calligra engine, Qt framework, KDE libraries and Java components, making up the EuroOffice application for Android.

The inner workings of this development is based around generating a changeset that stores the change. The change set stores user data, the type of change required, style changes and characteristics. Operationally, it enables reviewing the changes at a low level, see who and when they were made, and providing the option of reversing them out.

User interface improvements are planned, to make the process easier and is planned to visualize the changes. This process can also be used for tracking spreadsheets.

Svante Schubert (CIB, DE)

Svante presented on behalf of CIB about JSMerge, an extended high-performance version of mail-merge functionality suitable for high document volume.

Using JavaScript V8 to provide the function of merging content to templates in an automated way from enterprise data sources. This process enables a higher level ODF mark-up including dynamic tables and other extended functionality. Role distinction creates an editor role for the manager of the template as a separate role to the data activities. This gives a department of an organization control of formatting without giving access to the data. Outputs of the JSMerge application can be ODF or OOXML.

Aditya Bhatt (Kolab Systems, CH)

Kolab builds groupware tools and solutions, and is working on a new product that leverages WebODF.

Aditya explained that WebODF is a tool that renders ODF documents in the browser, and can be embedded anywhere that understands HTML5. WebODF can save edited documents without information loss because it is round-trip compliant. It uses the powerful rendering capabilities of the web browser. WebODF has a Viewer an an Editor tool with an API.

Kolab Manticore is a realtime concurrent editing tool like Etherpad, but backed by the ODF. Unlike Etherpad, the document spec is already defined in ODF, so adding features are easy. Several users can edit together.

Storage and authentication is modular, with WebDAV and LDAP back ends available, so it is easy to implement into an existing infrastructure either in the cloud or on-premise. Loading existing documents is as easy as pointing the storage application to your existing documents.

A live demo was showcased. Each save creates a new version to prevent data loss by overwrites, and export to multiple formats including PDF is available at any time.
Kolab's future roadmap includes deep integration with Roundcube, seamless integration with email threads, calendar (invitations) and messaging integration.

Introduction to Plugfest interoperability testing

Jos van den Oever

Jos van den Oever explained the procedure of document testing ahead of the second day's technical sessions.

In addition to ODF 1.2, ODF 1.2 Extended allows many other features to be added.

Jos introduced all of the formats. There are 132 variants of the ODF file formats. There are around 600 elements with 1300 attributes. By contrast, HTML4 has around 30 elements, HTML5 has around 40. ODF is a much larger standard, presentations, spreadsheets are complicated standards. However, HTML has CSS which manages other types of elements.

ODF software can be a producer, editor or consumer. To be compliant to ODF 1.2, the packed (compressed) format is required, and at least one format must be used. Lossless round trip is not mandated at this time.

It is possible for ODF applications may not interoperate, for example, an ODF spreadsheet may not work in a word processor. Sometimes, ODF is badly implemented, whrere it damages information in the source files. Therefore, a set of tests must be documented and executed to check for all of these dimensions.

At the last plugfest, ODF Autotest was introduced. Prior to this, a user would have to manually make tests, but autotests allows a test to be created once. The tests will check many things including the specific feature requested, makes sure that the output is saved correctly and that the output style compares well to the input.

A key function of the test is the ability to check that the document is not only technically correct, but the output looks consistent with the input.

The outcome of the Plugfest technical session will be a list of reports with the testing applications which will generate discussions to find out if the issue is the application or format, and have the issue reported to the author.

Reviewing results for some existing 320 tests of ODF functions available prior tot the technical session across 8 applications show that many tests pass, and of the ones that fail, many are caused by minor issues that are easy to fix. The report is thorough, showing exactly which part of the detail of the presentation of any part of text causes any difference between the spruce and the output file. Any ODF feature can be analysed, included tables, graphics and other features.

Announcement from Gijs Hillenius (EU Joinup platform)

The session ended with a n incoming announcement of yet another large migration to ODF: the Italian Ministry of Defense is adopting a strict ODF policy, and will simultaneously with the migration to the standard migrate 150.000 desktops to an ODF centric office solution – in line with the government wide policy to adopt open source software wherever possible:

https://joinup.ec.europa.eu/community/osor/news/italian-military-switch-libreoffice-and-odf.

With ODF policies recently also being installed in France, while Portugal, the UK and The Netherlands already had similar policies in place, the state of ODF adoption is showing a strong trend.

Wrapup

Graham Taylor informed the attendees of a workshop organised by ETSI, on November 19th 2015 in the south of France that might be interesting to both existing open source actors as well as companies that are still doubting whether to open source their technology:

http://www.etsi.org/news-events/events/979-2015-11-summit-standardization-and-open-source

Graham Taylor noted that Open Source Software in general seems to be working with Open Standards by default. “With OSS on its way to becoming ubiquitous, it is great to see the innovation and development being brought to ODF applications and to the marketplace.”

Day 2 – Plugtesting

Steven Pemberton chaired the plugtesting sessions on day 2.

This year we tried a new method where Jos van den Oever ran tests beforehand and the attendees used the time to analyse the test results. Full test results are available here http://autotests.opendocumentformat.org/ if you want the full detail.

A lot of the day was given to discovery of implementation flaws and fruitful discussion, even though not all companies had sent engineers to attend. Engineers from two suppliers, LibreOffice and WebODF, did look into actual code and fixed a few issues during the event itself. The new workflow gave us the opportunity to go through a lot more material than at the previous plugfest.

Software evaluated

• AbiWord 3.0.1 on Linux

• Calligra 2.9.6 on Linux

• LibreOffice 4.3 and 5.0

• Microsoft Office 2013 and 2016 on Windows Server

• WebODF 0.5.9 on Linux

Overall test bugs

Google Docs saves ODF 1.1. It always uses a metadata field <meta:non-whitespace-character-count/>. This is correct, but was reported by as an error because an old version of the ODF 1.1 Relax NG file was used that omitted the namespace on the field.

For many tests it is hard to automatically determine if the rendering is correct. But often it is possible to say that the rendering should be different from another rendering. The test suite could allow specifying reference documents and check if the rendering is the same or different from the rendering of another file.

Overall implementation bugs

AbiWord

AbiWord has the same error twice in each ODF file that it saves. The file manifest.xml starts with a Document Type Definition (DOCTYPE) with URI Manifest.dtd.

	<!DOCTYPE manifest:manifest PUBLIC "-//OpenOffice.org//DTD Manifest 1.0//EN" "Manifest.dtd">

The URI Manifest.dtd is not included in the ODF document, so it cannot be resolved by the XML parser. This problem can be fixed by leaving out the DOCTYPE.

Google Docs

Google Docs is losing the common styles (in our tests it is always called “TestStyle”). The styling information is put in automatic styles instead. This is a problem because the relation between all the parts of the document with the same common style is lost. With common styles, the look of all these parts can be changed in place instead of going through the entire document. The lack of support for common styles also means that the distinction between styles with identical styling but different names is lost.

Because of this issue, Google Docs fails at most tests – while the styling may be retained, the test cannot confirm this because the common style has been lost by Google Docs.

Microsoft Office 2013 and 2016

ODF 1.2 files saved by Microsoft Office lack the attribute manifest:version on the document element of the file manifest.xml. This attribute must be present and must have the value 1.2. In the files content.xml and styles.xml, the attribute office:version must be present and must have the value 1.2. Microsoft Office does save these files properly. The version number only is omitted from manifest.xml.

WebODF

WebODF5.9 often shows a serif font in the rendered document instead of the specified Helvetica. This was not a general bug but a quirk of the factory installation. Opening the same files in a desktop browser showed the right font.

Text testing

A collection of tests on the styling of character text. These tests test the attributes on the element <style:text-properties/> on the character style family (style:family="text").

odt-color

No notable problems.

odt-background-color

Google Docs does not show the background color. The background color attribute is not saved. This is document loading bug.

AbiWord and WebODF are painting the background far too wide. This appears to be because different default settings are in place for justification and paragraph.

odt-country-language

This attribute specifies the language and the preferences that go with that language. Specifically, if long words are written in different languages, the hyphen to break the word up on a line will go in a different place. We can test whether an application keeps the language information after round-tripping - but we aren't yet testing to see if the words split correctly.

Volunteer Action - Make a test for a long word on a short line.

Does it bring in the right spellchecker? Difficult to say because you'd need to know that a language was installed. Svante identified that fo:language does not change text without also specifying fo:country.

odt-font-family

This is checking to see if Helvetica survives the round trip.

Volunteer Action - make the font in this test different from the default (and make the default different from Helvetica and the test font).

What is AbiWord doing here? it appears that if it can't find the font specified, it doesn't round-trip the information - the same goes for MS Word. AbiWord is changing the attribute from fo:font-family to style:font-name. In fact, it appears that AbiWord is correct, because ODF states that style:font-name is preferable, so AbiWord is improving it according to the style guide.

High priority Jos has asked Ben Martin to investigate apparent difference in word size.

odt-font-size

No notable problems.

odf font style oblique

Bug: Calligra has translated oblique style to italic. Oblique is different from italic, but the rules seem to be that oblique should be used if italics aren't available. There is an issue that Helvetica may not have an italic font.

Action Friedrich fix Calligra bug

Bug: Google Docs and AbiWord lose the fo:font-style attribute so oblique text changes to normal text.

odf font style normal

In this test, a common style TestStyle, which sets the font style to normal, is derived from another common style middle, which sets the style to italic. The result should be text in normal style.

Bug: AbiWord loses the attribute fo:font-style with value normal .

odt-font-variant-small-caps

Bug: AbiWord removes the entire style TestStyle.

Bug: Google loses the style attribute fo:font-variant.

Bug: WebODF keeps the style but does not rendered it. FIXED by Aditya at the plugfest. To be included in next release.

odt-font-variant-normal

Bug: AbiWord removes the entire style TestStyle.

Bug: Google loses the style attribute fo:font-variant.

Bug: MSOffice is loses the attribute fo:font-variant with value normal.

odt-font-weight-100

This is the test for thin weight font. There is an error in the test where the font weight in the middle part of the test is not being set.

Bug: AbiWord keeps the attribute fo:font-weight, but sets it to normal.

Bug: Google Docs keeps the attribute fo:font-weight, but sets it to bold, which is the opposite effect.

Bug: MSOffice loses the attribute fo:font-weight.

odt-font-weight-900

This is the test for thick weight font. There is an error in the test where the font weight in the middle part of the test is not being set.

Bug: AbiWord keeps the attribute fo:font-weight, but sets it to normal.

Bug: Google Docs keeps the attribute fo:font-weight, but sets it to bold.

Bug: MS Office substitutes weight to bold.

odt-hyphenate-true (and -false)

Bug: AbiWord removes the entire style TestStyle.

Bug: Google Docs loses the attribute fo:hyphenate.

Volunteer action use the short line length, long word test from the language test also in this test.

odt-hyphenation-push-char-count-10

This attribute refers to the minimum number of letters in a hyphenated word on the next line after the hyphenation.

Bug: AbiWord removes the entire style TestStyle.

Bug: Google Docs loses the attribute fo:hyphenation-push-char-count.

Bug: MS Office loses the attribute fo:hyphenation-push-char-count.

Volunteer Action – There is a need a test for multiple languages too. There should be a test with at least two lines, one with a word that is longer than the criteria, one that is shorter. Visual inspection should be required as well. Also right-to-left languages should be tested.

odt-hyphenation-remain-char-count-10

Bug: AbiWord removes the entire style TestStyle.

Bug: Google Docs loses the attribute fo:hyphenation-remain-char-count.

Bug: MS Office loses the attribute fo:hyphenation-remain-char-count.

odt-letter-spacing-normal

The test sets the spacing to 1 pixel and then back to normal.

Bug: AbiWord removes the entire style TestStyle.

Bug: Google Docs loses the attribute fo:letter-spacing.

Bug: MS Office loses the attribute fo:letter-spacing.

Bug: Calligra is translating pixels to points without changing the number.

Action Friedrich fix

Bug: LibreOffice is dropping the 1 pixel spacing style in the middle style.

Action Andras fix

odt-letter-spacing-1mm and odt-letter-spacing--1mm

Bug: WebODF does not render letter spacing. Aditya fixed this before the notes recorded an action.

Bug: AbiWord removes the entire style TestStyle.

Bug: Google Docs loses the attribute fo:letter-spacing.

Bug: Calligra does not show the letter spacing in the text.

LibreOffice has changed to centimeters, but this is allowed.

odt-script

Bug: Calligra loses the attribute fo:script.

Bug: AbiWord loses the entire style TestStyle.

Bug: Google Docs loses the attribute fo:script and the attribute fo:language.

Bug: LibreOffice loses the attribute fo:script.

Bug: MS Office loses the attribute fo:script.

odt-script-225

The same bugs as in odt-script.

Additional bug: LibreOffice changes to value of fo:language from ar to en.

odt-script-es

Test improvement: what are the expected failures/ what values should be tested by the test case?
Why is it testing two-letter “@fo:script='es'” code? (in the ISO there are four-letter and numeric codes). This test should be better documented.

odt-text-shadow

Bug: Calligra does not render the shadow.

Bug: AbiWord loses the entire style TestStyle.

Bug: Google Docs loses the fo:text-shadow attribute.

Bug: WebODF does not render the shadow.

Bug: LibreOffice seems to support only 1pt shadows and writes out 1pt. The UI has no option to configure size of shadow.

odt-text-transform-none

In this test, the style TestStyle has fo:text-transform set to none. It has a parent style where fo:text-transform is set to uppercase.

Bug: Google Docs loses the fo:text-transform attribute.

Bug: MS Office loses the value none of the attribute. It does retain the value uppercase for the middle style. The rendering is uppercase, which is not correct.

Odt-text-transform-lowercase

Test improvement: the rendering of lowercase is not visible because the text is already lowercase.

Bug: Google Docs loses the fo:text-transform attribute.

Bug: MS Office loses the fo:text-transform attribute.

odt-text-transform-uppercase

Bug: Google Docs loses the fo:text-transform attribute.

odt-text-transform-capitalize

Bug: Google Docs loses the fo:text-transform attribute.

Bug: MS Office loses the fo:text-transform attribute.

odt-text-underline-type-double

Bug: Google Docs loses the style:text-underline-type attribute.

Bug: AbiWord changes the value of the style:text-underline-type attribute to single.

Bug: WebODF: keeps the attribute but does not render it the double underline.

odt-text-underline-width

Bug: Google Docs loses the style:text-underline-width attribute.

Bug: AbiWord loses the style:text-underline-width attribute.

Bug: LibreOffice changes the value of the style:text-underline-width attribute to auto.

Bug: MS Office changes the value of the style:text-underline-width attribute to auto.

odt-use-window-font-color-true

Bug: Google Docs loses the style:use-window-font-color attribute.

Bug: AbiWord loses the entire style TestStyle.

Bug: LibreOffice also adds the attribute and value to the default style for text.

Bug: MS Office also adds the attribute and value to the default style for text.

Test case problem: the test would probably still be black as that is the foreground color in most systems. So the current test does not test the rendering well. This can be solved by using a different value for fo:color.

odt-use-window-font-color-false

Bug: Google Docs loses the style:use-window-font-color attribute.

Bug: AbiWord loses the entire style TestStyle.

Bug: LibreOffice adds the attribute to the default style with inverted value (true) and removes it from the test style.

Bug: LibreOffice adds the attribute to the default style with inverted value (true) and removes it from the test style.

odt-display-true

The text:display attribute specifies whether text is hidden.

Problem with the test: there is no different value specified in a parent style or default style. Since true is the default value for text:display attribute, this test cannot detect if the application would have saved the value.

odt-display-none

Bug: Calligra loses the text:display attribute.

Bug: Google Docs loses the text:display attribute.

Bug: AbiWord loses the text:display attribute.

Bug: WebODF ignores the none value for the text:display attribute.

Paragraph testing

A collection of tests on the styling of paragraphs. These tests test the attributes on the element <style:paragraph-properties/> on the paragraph style family (style:family="paragraph").

odt-background-color

Bug: Google Docs loses the fo:background-color attribute.

odt-border

Bug: Google Docs fails to render left and right borders. Instead of adding a top border, it creates an extra empty paragraph with a bottom border above the original paragraph.

Bug: MS Office loses the fo:border attribute.

Test problem: AbiWord splits the attribute fo:border over separate attributes for top, bottom, left and right. This is not a bug.

Test problem: the border thickness of 0.06pt is much too small. 1pt is more appropriate. The rendering by AbiWord shows no border, but because the border is so thin, it cannot be said if this is a bug.

odt-border-top

Bug: MS Office loses the fo:border-top attribute.

odt-border-left

Bug: Google Docs loses the fo:border-left attribute.

Bug: MS Office loses the fo:border-left attribute.

odt-border-right

Bug: Google Docs loses the fo:border-right attribute.

Bug: MS Office loses the fo:border-right attribute.

odt-border-bottom

Bug: MS Office loses the fo:border-bottom attribute.

odf-break-after

Bug: Google Docs loses the fo:break-after attribute.

Bug: AbiWord loses the fo:break-after attribute.

Bug: MS Office loses the fo:break-after attribute.

Test problem: the test should contain more paragraphs. At the moment it cannot be determined if an page break is inserted in the rendered document.

odt-hyphenation-keep

The attribute fo:hyphenation-keep determines if a word may be split over pages or columns. In this test, the value of the attribute is set to page. This means that a word may only be hyphenated if the two halves remain on the same page.

Bug: Google Docs loses the fo:hyphenation-keep attribute.

Bug: AbiWord removes the entire style TestStyle.

Bug: LibreOffice loses the fo:hyphenation-keep attribute.

Bug: MS Office loses the fo:hyphenation-keep attribute.

Test problem: the test does not contain enough text to determine of the rendering behavior of the attribute is implemented.

odt-margin

Calligra converts margins creates an additional automatic paragraph style where fo:margin-left and fo:margin-right are set needlessly. This is not a bug.

Google Docs converts the margins from inches to centimeters. This is not a bug.

Bug: AbiWord removes the entire style TestStyle and does not render the margin.

Bug: MS Office loses the margin attribute and does not render the margin.

Bug: WebODF does not render the top margin.

LibreOffice splits fo:margin into constituent margins.

Test problem: the margin is small so it is a hard to see if the margin is being applied.

Test problem: the attribute fo:margin may be split over fo:margin-top, fo:margin-left, fo:margin-right and fo:margin-bottom. If an application does this, this should not be marked as a bug.

odt-margin-bottom

Test problem: with only one line of text it is hard to see if the rendering is correct.

odt-margin-left

No bugs.

odt-margin-right

Test problem: with only one line of text it is hard to see if the rendering is correct.

odt-margin-top

Bug: WebODF does not set the top margin.

odt-orphans

Test problem: with only one line of text it is hard to see if the rendering is correct.

Bug: Google Docs changes the value of fo:orphans from 1 to 2.

Bug: MS Office loses the fo:orphans attribute.

odt-padding

Bug: Calligra does not render the top padding.

Bug: Google Docs loses the fo:padding attribute and does not render the padding.

Bug: AbiWord does not render the padding.

AbiWord splits the padding over four attributes when saving.

Bug: LibreOffice does not render the padding. It only renders the padding when a border is defined as well.

Bug: MS Office loses the fo:padding attribute and does not render the padding.

Test problem: the padding is small so it is a hard to see if the padding is being applied.

Test problem: the attribute fo:padding may be split over fo:padding-top, fo:padding-left, fo:padding-right and fo:padding-bottom. If an application does this, this should not be marked as a bug.

odt-padding-left

Bug: Google Docs loses the fo:padding-left attribute and does not render the padding.

Bug: AbiWord does not render the padding.

Bug: LibreOffice does not render the padding. It only renders the padding when a border is defined as well.

Bug: MS Office loses the fo:padding-left attribute and does not render the padding.

odt-padding-top

Bug: Calligra does not render the top padding.

Bug: Google Docs loses the fo:padding-top attribute and does not render the padding.

Bug: AbiWord does not render the padding.

Bug: LibreOffice does not render the padding. It only renders the padding when a border is defined as well.

Bug: MS Office loses the fo:padding-top attribute and does not render the padding.

odt-padding-bottom

Test problem: with only one line of text it is hard to see if the rendering is correct.

Bug: Google Docs loses the fo:padding-bottom attribute.

Bug: AbiWord removes the entire style TestStyle .

Bug: MS Office loses the fo:padding-bottom attribute.

odt-text-align

Everything renders fine!

odt-text-align-last

Bug: Google Docs loses the attribute fo:text-align-last.

Test problem: the test is inadequate, it needs to be accompanied by text-align according to specification.

odt-text-indent

Everything renders fine.

Test problem: there should also be a with negative indents.

odt-widows

The fo:widows attribute specifies the minimum number of lines that shall be displayed at the top of a page to avoid paragraph widows.

Test problem: more text and a page break is needed to know if the attribute is rendered correctly.

Bug: Google Docs changes the value of the fo:widows attribute from 1 to 2.

Bug: MS Office moves the fo:widows attribute to the default style, and changes the value from 0 to 1.

odt-auto-test-indent

The style:auto-text-indent attribute specifies that the first line of a paragraph is indented by a value that is based on the current font size.

Test problem: the name of this test should be odt-auto-text-indent.

Test problem: more text and a page break is needed to know if the attribute is rendered correctly.

Bug: Google Docs loses the style:auto-text-indent attribute.

Bug: AbiWord removes the entire style TestStyle.

Bug: WebODF does not indent the text.

Bug: MS Office loses the style:auto-text-indent attribute.

odt-background-transparency

Test problem: the transparency of a background cannot be checked visually if there is no background color or image. This test should also set fo:background-color.

Bug: Google Docs loses the style:background-transparency attribute.

Bug: AbiWord removes the entire style TestStyle.

Bug: LibreOffice loses the style:background-transparency attribute.

Bug: MS Office loses the style:background-transparency attribute.

odt-border-line-width

Test problem: the attribute style:border-line-width contains three lengths. The lengths can be written back with different units. Calligra and LibreOffice are doing this and this is not bug.

Bug: Calligra has strange rendering where the text is not centered and the distance between borders is different at the top and bottom.

Bug: Google Docs loses the style:border-line-width attribute and does not render the border.

Bug: AbiWord loses the style:border-line-width attribute and does not render the border.

Bug: MS Office loses the style:border-line-width attribute and does not render the border.

odt-line-height-at-least

Bug: Google Docs changes the attribute style:line-height-at-least="10mm" to fo:line-height="236%".

Test problem: with only one line of text it is hard to see if the rendering is correct.

Page layout testing

A collection of tests on the layout of pages. These tests test the attributes on the element <style:page-layout-properties/>.

odt-background-color

This tests sets the attribute fo:background-color. The specification says that this attribute specifies a background color for characters, paragraphs, text sections, frames, page bodies, headers, footers, tables, table rows and tables. Calligra, LibreOffice, and WebODF interpret this to mean that the background color does not apply to the margins. AbiWord does include the page margins. The specification should clarify the description of this attribute.

Bug: Google Docs loses the fo:background-color attribute and does not render the background.

Bug: MS Office loses the fo:background-color attribute and does not render the background.

Bug: WebODF applies the background only to the paragraphs of text. This is because WebODF 0.5.9 does not support paginated rendering.

Test problem: the output file for LibreOffice 5 was missing and the reported results for LibreOffice 5 are wrong.

odt-border

Test problem: the border line is much too thin to accurately determine if a border was painted.

Bug: Google Docs loses the fo:border attribute.

Bug: AbiWord loses the fo:border attribute.

Bug: WebODF renders a border directly around the paragraph instead of around the page.

MS Office changes the unit of the border thickness. This is not a bug.

odt-border-*

The same bugs are found as for odt-border.

odt-margin

Test problem: the margin is small compared to a normal text document. A margin of 1cm in <default-page-layout/> and a test value of 2cm would be more appropriate.

Bug: AbiWord loses the fo:margin attribute.

Test problem: Google Docs, LibreOffice and MS Office split the attribute fo:margin over separate attributes for top, bottom, left and right. This is not a bug and should not be reported as one.

odt-margin-*

Test problem: the margin is small compared to a normal text document and a default value for the margins is missing. A margin of 1cm in <default-page-layout/> and a test value of 2cm is more appropriate.

odt-padding

Test problem: the padding is small compared to a normal text document. A padding of 1cm in <default-page-layout/> and a test value of 2cm would be more appropriate.

Bug: Google Docs splits the padding attribute fo:padding and sets the padding values to 0cm.

Bug: AbiWord loses the fo:padding attribute.

Bug: LibreOffice does not render the padding.

Bug: MS Office loses the fo:padding attribute.

Test problem: Google Docs and LibreOffice split the attribute fo:padding over separate attributes for top, bottom, left and right. This is not a bug and should not be reported as one.

odt-padding-*

Bug: Google Docs sets the value of the padding attribute to 0cm.

Bug: AbiWord loses the fo:padding-* attributes.

Bug: LibreOffice does not render the padding.

Bug: MS Office loses the fo:padding-* attributes.

odt-page-height

This test sets the page height to 20cm. This is 566.9pt.

Bug: AbiWord changes the page height from 20cm to 297.000000mm.

Bug: WebODF renders a page of 297mm instead of 20cm .

odt-page-width

Test problem: the test sets fo:page-height instead of fo:page-width.

odt-page-height-in

Test problem: the test sets fo:page-width instead of fo:page-height.

odt-page-width-in

This test sets the page height to 5in. This is 360pt.

Bug: AbiWord changes the value of fo:page-width from 5in to 210.000000mm.

Bug: WebODF renders a page of 297mm instead of 20cm .

odt-border-line-width

Specification problem: the test sets fo:border and style:border-line-width. fo:border also contains a width for the border lines. The specification does not say what value to use. It is a fair assumption that style:border-line-width takes precedence because it is more specific.

Test problem: no page margins are set, so it is not intuitive to compare the renderings.

Bug: Calligra does not render the page border.

Calligra sets the length in fo:border to the last length in style:border-line-width.

Bug: Google Docs loses the attribute style:border-line-width.

Bug: Google Docs loses the attribute fo:border .

Bug: AbiWord loses the attribute style:border-line-width .

Bug: AbiWord loses the attribute fo:border .

Bug: WebODF renders the border around the paragraph instead of the page.

LibreOffice sets the length in fo:border to the last length in style:border-line-width .

MS Office changes the value of the attribute style:border-line-width from 0.4mm 0.0299in 0.7mm to 0.0208in 0.0208in 0.0208 in . The sum of those numbers is equal to border thickness provided in fo:border .

odt-border-line-*

The results are similar to those for odt-border-line-width.

odt-first-page-number

Test problem: the test should include the page number as a field.

Bug: Calligra loses the attribute style:first-page-number.

Bug: Google Docs loses the attribute style:first-page-number.

Bug: AbiWord loses the attribute style:first-page-number.

Bug: LibreOffice loses the attribute style:first-page-number.

Bug: MS Office loses the attribute style:first-page-number.

odt-footnote-max-height-in

Test problem: this test does not contain a footer, so rendering cannot be evaluated.

Bug: Calligra loses the attribute style:footnote-max-height.

Bug: Google loses the attribute style:footnote-max-height.

Bug: AbiWord loses the attribute style:footnote-max-height.

Bug: MS Office loses the attribute style:footnote-max-height.

odt-footnote-max-height-pt

This tests hows the same issues as odt-footnote-max-height-in.

*-grid-*

Test problem: tests for the grid attributes need to be rewritten by someone with more know-how about Asian layout grids.

odt-num-format

Test problem: there is no page number field in the test. So the rendering of the page number cannot be checked.

Specification issue: the attribute style:num-format is defined twice in the specification. Once at General Attributes 19.500 and once at Formatting Attributes 20.314. The two definitions can be combined.

Bug: Calligra loses the attribute style:num-format.

Bug: Google loses the attribute style:num-format.

Bug: AbiWord loses the attribute style:num-format.

odt-num-letter-sync

Test problem: there is no page number field in the test. So the rendering of the page number cannot be checked. This attribute is best tested with a document with more than 26 pages.

Specification issue: the attribute style:num-letter-sync is defined twice in the specification. Once at General Attributes 19.501 and once at Formatting Attributes 20.315. The two definitions can be combined.

Bug: Calligra loses the attribute style:num-letter-sync.

Bug: Google loses the attribute style:num-letter-sync.

Bug: AbiWord loses the attribute style:num-letter-sync.

Bug: LibreOffice loses the attribute style:num-letter-sync.

Bug: MS Office loses the attribute style:num-letter-sync.

odt-num-prefix

Test problem: there is no page number field in the test. So the rendering of the page number cannot be checked.

Specification issue: the attribute style:num-prefix is defined twice in the specification. Once at General Attributes 19.502 and once at Formatting Attributes 20.316. The two definitions can be combined.

Bug: Calligra loses the attribute style:num-prefix.

Bug: Google loses the attribute style:num-prefix.

Bug: AbiWord loses the attribute style:num-prefix.

Bug: LibreOffice loses the attribute style:num-prefix.

Bug: MS Office loses the attribute style:num-prefix.

odt-num-suffix

Test problem: there is no page number field in the test. So the rendering of the page number cannot be checked.

Specification issue: the attribute style:num-suffix is defined twice in the specification. Once at General Attributes 19.503 and once at Formatting Attributes 20.317. The two definitions can be combined.

Bug: Calligra loses the attribute style:num-suffix.

Bug: Google loses the attribute style:num-suffix.

Bug: AbiWord loses the attribute style:num-suffix.

Bug: LibreOffice loses the attribute style:num-suffix.

Bug: MS Office loses the attribute style:num-suffix.

odt-paper-tray-name

Bug: Calligra loses the attribute style:paper-tray-name.

Bug: Google loses the attribute style:paper-tray-name.

Bug: AbiWord loses the attribute style:paper-tray-name.

Bug: LibreOffice loses the attribute style:paper-tray-name.

Bug: MS Office loses the attribute style:paper-tray-name.

print-orientation-portrait

No bugs.

print-orientation-landscape

Specification problem: it is not clear what this attribute should do. Only AbiWord does it creates a PDF in landscape orientation.

Bug: Google Docs changes the value of style:print-orientation from landscape to portrait.

odt-scale-to

Specification problem: it is not clear what the behavior should be when both style:scale-to and style:scale-to-pages are present.

Bug: Calligra loses the attribute style:scale-to.

Bug: Google loses the attribute style:scale-to.

Bug: AbiWord loses the attribute style:scale-to.

Bug: LibreOffice loses the attribute style:scale-to.

Bug: MS Office loses the attribute style:scale-to.

scale-to-pages

Specification problem: it is not clear what the behavior should be when both style:scale-to and style:scale-to-pages are present.

Bug: Calligra loses the attribute style:scale-to-pages.

Bug: Google loses the attribute style:scale-to-pages.

Bug: AbiWord loses the attribute style:scale-to-pages.

Bug: LibreOffice loses the attribute style:scale-to-pages.

Bug: MS Office loses the attribute style:scale-to-pages.

odt-shadow

Specification problem: it is not clear if style:shadow also applies to headers and footers.

Bug: Calligra loses the attribute style:shadow.

Bug: Google loses the attribute style:shadow.

Bug: AbiWord loses the attribute style:shadow.

Bug: WebODF does not render a shadow.

Bug: MS Office loses the attribute style:shadow.

table-centering-*

Test problem: this attribute only applies to spreadsheet documents.

odt-writing-mode

Test problem: the value lr-tb is often the default. It is better to use a different value so a change can be seen.

Bug: Calligra loses the attribute style:writing-mode.

Bug: Google loses the attribute style:writing-mode.

Bug: AbiWord loses the attribute style:writing-mode.

Bug: MS Office loses the attribute style:shadow.

Graphic testing

A collection of tests on the styling of graphic objects. These tests test the attributes on the element <style:graphic-properties/> on the graphic style family (style:family="graphic"). The graphic style is applied to a <draw:frame/> with a <draw:image/> element inside it.

The tests with 3d attribute apply to 3d objects and therefor the results from the tests that use 3d attributes are not evaluated in this text.

General issues

Test problem: the test style does not have a display name. It only has style:name="teststyle". This may, but should not, influence if the style is retained or not.

Bug: Calligra removes the entire style teststyle.

Bug: AbiWord removes the entire style teststyle.

Bug: MS Office removes the entire style teststyle.

These general issues are not repeated in the test specific findings in this section.

odt-draw-auto-grow-height-true, odt-draw-auto-grow-height-true

Test problem: The specification says: “This attribute is evaluated only for text boxes.” So it would be better to test it on <draw:text-box elements/>. Nevertheless, the style should keep the attribute draw:auto-grow-height.

Specification problem: the clause “if text is added” suggests that the frame should only grow when editing, but the next sentence in the specification talks about how a consumer, not producer, should grow the text box.

Bug: Calligra loses the attribute draw:auto-grow-height.

Bug: Google Docs changes the value of draw:auto-grow-height from true to false.

Bug: AbiWord loses the attribute draw:auto-grow-height.

Bug: LibreOffice loses the attribute draw:auto-grow-height.

Bug: MS Office loses the attribute draw:auto-grow-height.

odt-draw-auto-grow-width-true, odt-draw-auto-grow-width-true

Test problem: The specification says: “This attribute is evaluated only for text boxes.” So it would be better to test it on <draw:text-box elements/>. Nevertheless, the style should keep the attribute draw:auto-grow-width.

Specification problem: the clause “if text is added” suggests that the frame should only grow when editing, but nothing is said about how consumer software should handle the attribute.

Bug: Calligra loses the attribute draw:auto-grow-width.

Bug: Google Docs changes the value of draw:auto-grow-width from true to false.

Bug: AbiWord loses the attribute draw:auto-grow-width.

Bug: LibreOffice loses the attribute draw:auto-grow-width.

Bug: MS Office loses the attribute draw:auto-grow-width.

odt-draw-blue-green-red

Test problem: the graphic lacks the colors to determine if the rendering is successful. A better graphic would be the Phillips PM5544 image.

Bug: Calligra loses the attributes draw:red, draw:green, and draw:blue.

Bug: Google Docs loses the attributes draw:red, draw:green, and draw:blue.

Bug: AbiWord loses the attributes draw:red, draw:green, and draw:blue.

Bug: LibreOffice loses the attributes draw:red, draw:green, and draw:blue.

Bug: MS Office loses the attributes draw:red, draw:green, and draw:blue.

odt-draw-caption-angle-*

Test problem: there is no caption content in these tests, so there is no way to confirm compliance for the rendering.

Bug: Calligra loses the attributes draw:caption-angle and draw:draw:caption-angle-type.

Bug: Google Docs loses the attributes draw:caption-angle and draw:draw:caption-angle-type.

Bug: AbiWord loses the attributes draw:caption-angle and draw:draw:caption-angle-type.

Bug: LibreOffice loses the attributes draw:caption-angle and draw:draw:caption-angle-type.

Bug: MS Office loses the attributes draw:caption-angle and draw:draw:caption-angle-type.

odt-draw-caption-angle-escape-*

Test problem: there is no caption content in these tests, so there is no way to confirm compliance for the rendering.

Bug: Calligra loses the attributes draw:caption-escape and draw:caption-escape-direction.

Bug: Google Docs loses the attributes draw:caption-escape and draw:caption-escape-direction.

Bug: AbiWord loses the attributes draw:caption-escape and draw:caption-escape-direction.

Bug: LibreOffice loses the attributes draw:caption-escape and draw:caption-escape-direction.

Bug: MS Office loses the attributes draw:caption-escape and draw:caption-escape-direction.

odt-draw-color-mode-*

Test problem: rendering could be judged better if the image contains large colored areas.

Bug: Calligra moves the attribute draw:color-mode to an automatic style.

Bug: Google Docs loses the attribute draw:color-mode.

Bug: AbiWord loses the attribute draw:color-mode.

Bug: WebODF does not render the image according to the attribute draw:color-mode.

Bug: LibreOffice loses the attribute draw:color-mode.

Bug: MS Office moves the attribute draw:color-mode to an automatic style.

odt-draw-contrast-50p

Test problem: rendering could be judged better if the image contains large colored areas.

Bug: Calligra loses the attribute draw:contrast.

Bug: GoogleDocs loses the attribute draw:contrast.

Bug: AbiWord loses the attribute draw:contrast.

Bug: WebODF does not render the attribute draw:contrast.

Bug: LibreOffice loses the attribute draw:contrast.

Bug: MS Office moves the attribute draw:contrast to an automatic style.

odt-draw-shadow-visible

Test problem: the shadow is set to visible, but no other shadow properties have been set. So the rendering can be different and perhaps hard to see.

Bug: Calligra moves the attribute draw:shadow to an automatic style.

Bug: GoogleDocs loses the attribute draw:shadow.

Bug: AbiWord loses the attribute draw:shadow.

Bug: WebODF does not render the attribute draw:shadow.

Bug: LibreOffice loses the attribute draw:shadow.

Bug: MS Office loses the attribute draw:shadow.

Conclusions

The total number of bugs found at the plugfest (indicate by the Bug: lines) was 246.

Calligra 30

Google Docs 64

AbiWord 56

WebODF 17

LibreOffice 29

MS Office 52

Further improvements to the tests

1. The physical dimensions of the cropped snippets are useful for investigating the test results. Jos will add these to the report.

2. Some differences in rendering are caused by different defaults in the application. Variation in output can be reduced by explicitly setting all defaults.

3. Visual validation can be done with a reference ODF file where an attribute has a different value. Then, if the attribute is meant to give a different visual, the test can check that the rendered output PNG is different from the PNG for the reference file.

4. The test for oblique should differentiate italic for oblique. Oblique is just a slanted version of normal. For some fonts this is different from italic. The test should use a font that shows this difference (Times, Garamond?). The volunteer can choose. Use the text here: https://en.wikipedia.org/wiki/Oblique_type) and perhaps also one with black squares. It is clear in this case that we are seeking oblique, so there should definitely not be italics.

Design for test server

It was also agreed that a live test server should be created so that interested people could get involved in testing and analysis away from the plugfest as well. Jos, Stuart and Svante have begun the design, and will publish a plan.