Fuzz about Google supporting odf

Since Google announced their new so called support for the open standard for documents; odf, there has been a lot of fuzz. And yesterday when the new version of Google Docs and Drive, there has been even more fuzz.




I'm happy that Google is finally implementing support for odf BUT... and there is a but:

Honestly I'm not impressed. I'm very disappointed.

First of all because the support comes way too late. Secondly because its not even close to be good.

Back several years ago Google was politically supporting the process of getting odf approved as an open standard but they never really bothered. The business was clearly to keep both odf and ooxml/docx out of their products and keep their own proprietary document format.

Implementing good and solid interoperability is actually not difficult but it is a huge task. Google could have done this three or four years ago if they wanted to. But they didn't. Both proprietary software vendors has been busy making interoperability difficult while the providers of true open standards has been improving interoperability month by month. 

What about the implementation?
I'm not impressed by the implementation. Not at all. First of all because it works differently between different browsers and computers. If you are running a computer with chromium OS or is using a Chrome browser you get the best result. You will experience pretty good results besides the lack of collaboration features like comments and change tracking. One would think that collaborative tools would be obvious for Google to implement as the first. Collaboration between users are one of Googles advantages over local installed software.

If you are using another browser (I have tried with Firefox) the core functionality works completely different. If you have odf-files in you Google Drive and opens them with Google Docs, you are actually not editing you odf-document, but a converted Google Docs document. And now you have two versions of the same document. Both claiming to be the same file because the new Google Docs document is claiming to be an odf-document (the name is still xyz.odt) but now in Google Docs format. And as a consequence the default download format is ... docx.

Please try again Google. And this time please support odf in stead of stealing documents from odf. And don't force users to use a specific operating system or browser. You make me think of the browser war between Netscape and Internet Explorer when websites was "Optimized for [insert browser brand here]".

Making good and solid templates

When your organization is migrating from Microsoft Office to LibreOffice its important that you provide the users with some good and robust templates. If your users are using LibreOffice in parallel with Microsoft Word or if your users are collaborating with other users outside the organization, then your templates must take this into consideration. The templates must in this case be extra robust when it comes to interoperability.

Why not just open your old .DOT or .DOTX templates in LibreOffice and save the result at .OTT?

Well this is exactly one of the most common mistakes. Making templates for Writer is NOT converting Word templates. Its building new templates from scratch using the best tool for it: LibreOffice. If you choose the short cut and converts Word templates to LibreOffice templates, you will get into trouble. Big trouble.

Experience show that lack of interoperability often comes down to poor quality templates.

Another advise: Don't try to make LibreOffice look like Word and don't try to make your templates look like Word templates. You can't fool the users.

If you are the expert in Word you might not be the right person to develop LibreOffice templates. Use LibreOffice as LibreOffice and don't pretend its Word.

Before you begin

Try to work smart - not hard. Analyze the existing Word templates into categories of logically connected templates. Does any of the templates have common properties? Identify the commons and put the templates into categories or “families”. For examples if you have several letter templates with different content or in different languages, they are most likely using the same font types and sizes. Identify these common properties and take notes.

Also try to get your hands on the company design strategy or design guidelines if they exist. Large organizations often have something in the communication department. Best case is if you can find a design and style guide for letter with precise measurements and color identification.

Ask the provider of the original Word templates to also give you a PDF-version of each template. That give both you and the owner of the templates a baseline reference for the layout and you can avoid later discussions about pixel precise position of an object somewhere. You can make the reference PDF your self, but its better and more correct if you can get it from the owner of the templates.

Think of who the users are

Don't believe that the IT department is qualified to define the requirements. First of all because this group of people in general has a higher understanding of how IT works and as a consequence of that are actually too high qualified. The average user should be setting requirement for the functionality while the department in charge of communication (who ever they are) should set requirements for the look and feel of the templates.

Users are different. Some users are very well educated and has a master in text editing. Others are just office clerks and has no idea of how text editing and office automation works. Your templates should be possible to operate by the people using them. Some templates can be very sophisticated and with a high level of automation while others - letter templates for example - should be as simple as possible to use.

Create the master

From there you can create what I use to call the master template. This template will actually not be used by any one else than template developers and it contains only the common styles and measurements. Only what can be defined in styles should be part of the master. In the future when you start creating new templates you can use the master template as the template. And when you need to make adjustments to the common properties, you can do it once in the master template and load the changes into all other templates.

Logo and objects

Always try to get the original source files in stead of trying to pick from the Word templates. When you resize images - and even if you are using high quality tools for it - will loose quality. If possible you should get the logos in some vector format like SVG or a Photoshop source file. Then you can compile image versions in the exact size and quality that you need. A logo compiled for the web site is normally compressed and optimized for smaller file size and is not good enough quality for a printed letter.

Interoperability

Making templates that are interoperable with Word is not easy. It requires a lot of work and a lot of testing. And one thing you must remember, is the fact that LibreOffice and Microsoft Office are two different applications with two different file formats. Conversion between the two are getting better for each version of LibreOffice, but its not perfect and it will most likely never become perfect. Document conversion is therefore to be considered a deviation from the normal. A special situation that should be taken special care of.

And round trip conversion? Forget it. It doesn't work.

Cross platform templates

LibreOffice is a cross platform application and it is possible to develop templates that works on multiple platforms. Most organizations has policies for this, but its a good idea to take the issue into consideration anyway. It might turn out that there actually are a few Mac computers even if the policy says the opposite. And it doesn't require much more than a thought now and then.

Cross platform templates has in general higher quality than templates that only works on one platform.

The dilemma

Do we want the LibreOffice templates to look pixel to pixel as the Word templates does?

Most would say yes, but I say no. I agree that it helps people to understand how it works if it works the same today than it did yesterday. But this pixel precise requirement is a misunderstanding. For more than two reasons.

First of all: Is our Word templates as good as we think? Perhaps they are but they might have been developed many years ago. So if we create new templates as exact copies of the existing ones we might inherit some legacy misunderstandings and lack of quality. So lets take the opportunity to make even better, more modern and robust templates now we are migrating. We might never get this opportunity again.

One of the main rules to remember while it comes to interoperability is, that the more you customize the less interoperable the template will be. So while you are trying to make them look exactly equal, you will loose the interoperability.

Try to stick to the defaults.

An example:

Footnotes in Writer looks pretty different from similar footnotes in Word. But they are quite easy to make interoperable if you leave them with the default settings. You can though make footnotes in Writer look precisely as they does in Word. But if you do, they will not survive a round trip conversion.

Same thing can be said about indexes and other advanced office automation features.

Making templates that are interoperable doesn't mean they look like the Word templates. It means that they can work across the two applications.

Images and objects

Images like the company logo and objects like a text box with the company contact information and information about the sender of a letter are central to any templates. These things are on the other hand rather difficult to make in a way, that are acceptable after conversion to lets say Microsoft Word. The key problem is not the positioning (the exact place on the paper) but to what they are positioned. Its the anchor that matters. The reason for this problem is that Word and Writer has two different ways of thinking when it comes to this anchoring problem. The main rule is to use the same anchoring for objects that are placed together. If the text box with the address information is anchored "to page" then the logo just above should not be anchored "to paragraph". Use the same anchor method for all objects that are grouped together and you will make things much easier to develop, maintain and use.

In general you should ask you self if the object is to be positioned on a specific position on the page or at a position relative to something. A company logo on a letter template or a text box with the senders address is to be positioned at a specific position on the page and therefor anchored "to page". In case the object are supposed to be repeated on several pages it should be anchored “to paragraph” in the page header or footer but with measurement relative to the page.

Macros

Try to avoid using macros. Many templates developed for MS Office 2003 has embedded or referenced macros to obtain some advanced functionality. Using macros implies a risk that the document in special situations doesn't react as expected simply because the macro is not available or macro execution is disabled for security reasons. Using macros should not be necessary with modern office applications.

In case you have systems of macros running and being dependent on other macros being available, you should consider how to obtain the same functionality without using an office suite at all. Such systems of several macros are not suitable for business environments and should in most cases be developed as part of a document management system or similar. Putting business logic into a complex system of templates and macros is risky.

Tools

Generate content

When you design templates its important that you test the template with some content. For that purpose I have developed an extension to LibreOffice Writer that can generate large amounts of Lorem ipsum text. You can pick the extension for free here:

http://extensions.libreoffice.org/extension-center/magenta-lorem-ipsum-generator

As an alternative you can use the built in dummy text (writer dt and hit F3).

Word

Use word to see how the original templates works, looks and reacts.

Export the resulting document to PDF for comparison.

LibreOffice

Use LibreOffice to develop new templates. But before you begin; learn to use it. You will discover that the first three or four attempts to make a good template fails. But during the work you will learn from experience and your failures.

I recommend that you use the same operating system while developing the templates as the regular users of the templates will be using. LibreOffice is independent from platform but there are some minor differences from OS to OS. The safest approach is to use the same OS.

Compare result

Compare the result (PDF) with reference output from Word with diff-pdf. 

Compare output

With this nifty tool you can merge two PDF files as overlay and compare pixel precise position of e.g., the logo and margins. Get it here: https://github.com/vslavik/diff-pdf

Please help with testing

Some years ago I developed an extension for LibreOffice for direct search for clip art from www.openclipart.org.

I have recently been working on a new version that use a new OpenClipart API.

Please help me test this extension:

Install it and use it. Post your result and comments to this blog post. I would like to know witch operating system and LibreOffice version you are using. I'm specially interested in Windows 7 as I have seen some problems running it on my own Windows computer.

Find the extension here: http://extensions.libreoffice.org/extension-center/openclipart-org-integration/releases/2014.12.01

When you install this extension please make sure to install it for "current user" only. Installing it for "all users" wont work. When you download the oxt-file please make sure that it doesn't change file name. The extension file name must be openclipart.oxt.

Changes in this version is...

• Action icon added to the Drawing toolbar.
• Fine polish the user interface.
• Implemented support for sort order
• Implemented optional 'add to gallery'
• All code is now Python - removed the Basic macro
• Added some more error handling
• Changed the concept so files are downloaded temporary to disk before inserted. This was caused by some problems getting things working over http directly.