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.

Managing settings (on Windows)

I have written quite a few articles about installation and administration of LibreOffice on Windows. My latest post was an update on the installation parameters (read it here: http://lodahl.blogspot.dk/2014/09/silent-installation-on-windows-again.html ).

This time I will write about a new and very convenient way of managing the user settings on each desktop computer. In earlier versions settings could be manipulated by installing an extension with some XML-files. Nice but not perfect as you had to distribute files to each and every computer. This method is on the other hand independent of operating system so the same extension can be used for both Mac, Linux and Windows computers.

From LibreOffice 4.2 its possible to change settings through the Windows Registry and this can be managed through one or more Group Policies in the Active Directory or similar administration system.

Read more about that here: https://wiki.documentfoundation.org/ReleaseNotes/4.2#Windows_Registry_changes.
 You can find some more detailed examples here: http://ask.libreoffice.org/en/question/29537/42-registry-configuration-backend-not-applying-all-settings/.

In this example I needed to make two small changes:

1. Set “Warn alien format” to “false” and lock the setting. 
2. Set “Macro security level” to “High” and lock the settings.

All I needed to do was to create two new keys in the Windows Registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Save\Document\WarnAlienFormat]
"Value"="false" 
"Final"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Security\Scripting\MacroSecurityLevel]
"Value"="2" 
"Final"=dword:00000001

Export

When you have implemented the new keys on one computer and tested it, you can easily export the new keys.

Select the branch of the registry tree (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common) and click Files - Export. In the dialogue you should select Selected branch and enter the name "Common" because that is the brach you want to export.

Click Save and you will get a Common.reg-file with the following content:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Save][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Save\Document][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Save\Document\WarnAlienFormat]
"Value"="false"
"Final"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Security]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Security\Scripting]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Security\Scripting\MacroSecurityLevel]
"Value"="2"
"Final"=dword:00000001 

This file can easily be imported on other computers or you can push them to the computers through a new Group Policy to the machines:
You create a new Group Policy object and link it to the OU you have configured for all the relevant users in the domain.

1. You open it up and edit “User Configuration | Windows Settings | Scripts (Logon/Logoff).
2. Under the Logon node, you add you settings so that regedit.exe calls your Common.reg file silently (with the /s switch): REGEDIT.EXE Common.reg /s
3. You click Show Files and drop your Common.reg into SYSVOL. 

Some information about Microsoft Windows Registry:
http://technet.microsoft.com/en-us/library/cc753092.aspx http://blog.thesysadmins.co.uk/group-policy-preferences-1-deploying-registry-settings.html
http://blogs.technet.com/b/askds/archive/2007/08/14/deploying-custom-registry-changes-through-group-policy.aspx

Conclusion

I must say this is a much easier approach than the extension method and it makes the whole setup much more flexible since we don't need to handle extensions on each computer any more. For enterprises I recommend using this method for future maintenance.

Silent installation on Windows (again)

One of many advantages of open source projects is for sure the eternal transition and evolutionary progress. This keeps people like my self busy just following the changes.

Last week I was asked to help a large organization prepare their LibreOffice install package for Windows and I thought “Cool – that gonna take about half an hour”. -Wrong!

The Windows installation parameters has been changed and as always it takes quite some time to find the documentation. You can find some documentation here: https://wiki.documentfoundation.org/Deployment_and_Migration But have ind mind that parameters has changed over time so you can't trust all of it.

The idea of installing all modules ( ADDLOCAL=ALL) and the remove individual modules ( REMOVE=gm_r_ex_Dictionary_Fr, ….) is still valid. But choosing language for the GUI is a little easier than before (UI_LANGS=en_US,da). Earlier you had to add all the language codes to the string and then choose your choice for each (… IS1030=1 IS1031=0 …).

Below is an example that installs LibreOffice in Danish and US English with some but not all dictionaries:

msiexec /qn /i C:\[path_to_install]\LibreOffice_4.3.2.2_Win_x86.msi /l* C:\[path_to_logs]\libreoffice_install_log.txt UI_LANGS=en_US,da CREATEDESKTOPLINK=1 ALLUSERS=1 RebootYesNo=No ADDLOCAL=ALL ISCHECKFORPRODUCTUPDATES=0 QUICKSTART=0 REMOVE=gm_r_ex_Dictionary_Fr,gm_r_ex_Dictionary_Es,gm_r_ex_Dictionary_Sr,gm_r_ex_Dictionary_Pt_Br,gm_r_ex_Dictionary_It,gm_r_ex_Dictionary_Af,gm_r_ex_Dictionary_An,gm_r_ex_Dictionary_Ar,gm_r_ex_Dictionary_Be,gm_r_ex_Dictionary_Bg,gm_r_ex_Dictionary_Bn,gm_r_ex_Dictionary_Br,gm_r_ex_Dictionary_Bs,gm_r_ex_Dictionary_Pt_Pt,gm_r_ex_Dictionary_Ca,gm_r_ex_Dictionary_Cs,gm_r_ex_Dictionary_De,gm_r_ex_Dictionary_Nl,gm_r_ex_Dictionary_Et,gm_r_ex_Dictionary_Gd,gm_r_ex_Dictionary_Gl,gm_r_ex_Dictionary_Gu,gm_r_ex_Dictionary_He,gm_r_ex_Dictionary_Hi,gm_r_ex_Dictionary_Hu,gm_r_ex_Dictionary_Ru,gm_r_ex_Dictionary_Lt,gm_r_ex_Dictionary_Lv,gm_r_ex_Dictionary_Ne,gm_r_ex_Dictionary_No,gm_r_ex_Dictionary_Is,gm_r_ex_Dictionary_Oc,gm_r_ex_Dictionary_Pl,gm_r_ex_Dictionary_Ro,gm_r_ex_Dictionary_Si,gm_r_ex_Dictionary_Lo,gm_r_ex_Dictionary_Sk,gm_r_ex_Dictionary_Sl,gm_r_ex_Dictionary_El,gm_r_ex_Dictionary_Hr,gm_r_ex_Dictionary_Sv,gm_r_ex_Dictionary_Te,gm_r_ex_Dictionary_Th,gm_r_ex_Dictionary_Uk,gm_r_ex_Dictionary_Vi,gm_r_ex_Dictionary_Zu

Some other things that has been improved dramatically is the new way of handling settings. In earlier versions settings could be manipulated by installing an extension with some XML-files. Nice but not perfect as you had to distribute files to each and every computer. 

From LibreOffice 4.2 its possible to change settings through the Windows Registry and this can be managed through one or more Group Policies in the Active Directory or similar adminsitration system.

Read more about that here: https://wiki.documentfoundation.org/ReleaseNotes/4.2#Windows_Registry_changes. You can find some more detailed examples here: http://ask.libreoffice.org/en/question/29537/42-registry-configuration-backend-not-applying-all-settings/.

I needed to make two small changes:

1. Set “Warn alien format” to “false” and lock the setting.
2. Set “Macro security level” to “High” and lock the settings

All I needed to do was to create two new keys in the Windows Registry and push this through a new Group Policy to the machines:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Save\Document\WarnAlienFormat]
"Value"="false" 
"Final"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice\org.openoffice.Office.Common\Security\Scripting\MacroSecurityLevel]
"Value"="2" 
"Final"=dword:00000001

I must say this is a much easier approach than the extension method and it makes the whole setup much more flexible since we don't need to handle extensions on each computer anymore.

Apache Open Office and LibreOffice should join forces

This proposal has been said many times over the last couple of years and lately repeated by Daniel Brunner, head of the IT department of Switzerland's Federal Supreme Court.https://joinup.ec.europa.eu/community/osor/news/open-and-libre-office-projects-should-reunite.

And from the first point of view I can only agree. There is no reason what so ever that the two open source projects shouldn't. But it hasn’t happened yet and there are reasons. Its not a simple thing to do.

Before I continue I would like to emphasize that I'm part of the game and therefore you should consider this as one of many voices in the choir and not some kind of "I know the truth" statement. I'm member of The Document Foundation and not a neutral opinion. I would also emphasize that I'm speaking on behalf of my self and not as member of any organization. 

First lets take a tour down Memory Lane. Kind'a old school but it can help understand the complexity.

Sun was purchased by Oracle Corporation in early 2010. OpenOffice.org community members were concerned at Oracle's behavior towards open source software, and the lack of activity on OpenOffice.org.

On 28 September 2010, The Document Foundation was announced as the host of LibreOffice, a new derivative of OpenOffice.org. The announcement was well accepted in the free software environment because The Document Foundation shares many values with free software. This includes strong copyleft licensing, and a meritocratic organization. At the same time TDF decided NOT to ask contributors to hand over any other rights to the foundation than licensing the code which was clearly a result of requirements from SUN Microsystems and Oracle in the OpenOffice.org-days. The foundation focuses furthermore very much on the diversity among members and contributes which has attracted hundreds of volunteer contributors.

Shortly after Oracle announced their continuous strong commitment to OpenOffice.org.

Oracle announced in April 2011 that it was ending its development of OpenOffice.org and in June 2011 it was announced that it would donate the OpenOffice.org code and trademark to the Apache Software Foundation. Open Office was then re-licensed with the Apache License which is not copyleft. The Apache License is considered permissive in that it does not require a derivative work of the software, or modifications to the original, to be distributed using the same license (unlike copyleft licenses).

The two license philosophies means that code can go from Apache Open Office to LibreOfffice but NOT the other way. This is not a decision made explicitly but its a consequence of the choice of licenses in the two projects.

Please take notice of the order in which these actions took place! When TDF was announced, nobody knew about Oracle donating anything to Apache. But when it happened, it was clear to both Oracle and Apache that TDF was strongly in favor of strong copyleft licenses.

The consequence of the choice of a permissive license was at the time clear to all: It can never happen that code goes from LibreOffice to Open Office but visa versa is possible at any time. The decision was in other words taken by Oracle and Apache NOT by TDF.

Conclusion

I agree that it would be great if the two projects would join. Combining the effort would naturally benefit the community, but the decision can only be taken by one of the parts. Members of the projects has been invited to join TDF at many occasions from the very beginning.

It takes two to tango and the one who can make the decision is Apache Open Office - who unfortunately refuses to dance. TDF can't make any decision except from stick to its original honorable principles about openness and diversity.