Most Central Government departments still depend on Microsoft Office. How will they and we cope with new official open standards?

If you work for or with central government, its agencies, or a non-departmental public body, you should be switching from proprietary document standards to the new UK open standards for government.

During the glorious weather in July 2014, the Cabinet Office confirmed to Microsoft’s overt annoyance that it was adopting open standards centred on Open Document Format (ODF) 1.2. These were updated just before the 2015 General Election. In future, files downloaded from government sources, or shared with colleagues in the central civil service, should be ODF or PDF, rather than Word or Excel documents.

New government standards, detailed here, concern documents rather than just data; the latter may be moved in CSV, or for more complex structured data using XML or RDF, as appropriate.

Text and PDF

Whilst text content should be kept within the narrow ASCII standard as much as possible, it is to be encoded using Unicode UTF-8 (detailed in Internet RFC 3629) and the Unicode 6.2 standard, although Yosemite currently supports Unicode 7.0, it appears. Metadata are supported, but whilst there are internal government standards for images and documents kept in sharepoints, more general standards are promised for the future.

Documents intended for viewing live over the Internet are to use HTML5, the de facto standard supported by all modern browsers. Where editing is not intended, particularly for static use and long-term preservation, documents are to use PDF/A-1 or PDF/A-2, but not PDF/A-3. Thus they can be cast in PDF versions 1.4 or 1.7, and may embed other PDF/A files, but not other types of embedded file.

Standard PDFs saved by OS X applications or by printing to file will need to be passed through the likes of Adobe Acrobat Pro to bring full compliance, but as of Yosemite still default to the PDF 1.3 standard.

Links, contacts, calendars

Persistent resolvable identifiers are to be given using HTTP 1.1 (according to Internet RFC 2616) and URLs (RFC 3986). The latter are intended as the most usual means, preferred over URIs and the likes of URNs as they should resolve to accessible web locations.

In March 2015, standards were updated to include contact and calendar information. Address book and other contact information is to be exchanged using the almost universal vCard (RFC 6350) format, with the UID field recommended to hold the persistent resolvable identifier for the person or organisation. Dates and other calendar events are to use the almost universal iCalendar (RFC 5545) format, with the UID field scoped to the domain of the publisher.

Shared documents

Shared documents, and those intended for collaborative work, are to use ODF 1.2 standards, at least as far as word processed documents (.odt), spreadsheets (.ods), and presentations (.odp). There is as yet no official support for the other document types, such as databases (.odb), formulae (.odf), or graphics (.odf). Indeed for the moment there are no set standards at all for shared graphics or image files.

Although the standard file formats for office suites derived from OpenOffice, few other OS X apps support ODF 1.2, least of all as a working native format. Shockingly, in contrast to more recent releases of Microsoft Office for Windows, Office 2011 for Mac still cannot open or export any ODF document formats, working instead with Microsoft’s subtly different OOXML. The current (15.9) pre-release versions of Office 2015 apps are also unable to work with ODF formats.

Apple has also been disappointingly tardy in supporting ODF: none of its Pages/Numbers/Keynote suite can even import or export ODF documents. Thankfully Quick Look previewing seems to cope well with ODF, and if your Spotlight searches cannot handle their contents, installing one of the OpenOffice family provides a metadata importer to rectify that. Nisus Writer Pro opens and exports .odt files well, and the free Bean RTF editor opens and saves in .odt format.

Working ‘in the Cloud’ may make ODF more accessible to many: Microsoft’s Office 365 and Office Online, and Google Drive apps, should be trouble-free. The Cabinet Office warns though that “it must be possible for documents created or worked on in a cloud environment to be exported in ODF.”

All we still need is good iWork support for ODF, please, Apple.

Tools: Which Office suite?

Mac apps which best support ODF are those derived from OpenOffice, as they use it as their default formats. Two of the three currently on offer for OS X are free – Apache OpenOffice, and LibreOffice – and the third, NeoOffice, is free to trial but £22.99 (inc VAT) from the App Store.

Choosing between these three remarkably similar apps is not easy. All offer an excellent and similar suite of features, and in parts are word-for-word identical.

LibreOffice has a slightly more cross-platform appearance, whilst NeoOffice as might be expected looks more Mac-native, using regular system dialogs for printer selection, for example, and feels slightly snappier. However all three deliver respectable performance on a modern Mac with plenty of memory.

Each comes with internal Spotlight metadata importers in their app bundle, but NeoOffice also embeds a Quick Look Generator. Support for scripting is best documented in Apache OpenOffice, which can use Basic, BeanShell, Java, JavaScript, and Python scripts and macros. LibreOffice offers the same set, although Java is deemed suitable for external control only, and NeoOffice should be similar. Sadly none has the slightest support for AppleScript.

Updated from the original, which was first published in MacUser volume 30 issue 11, 2014.