Sustainability of Digital Formats
 Planning for Library of Congress Collections

Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact
Format Description Categories >> Browse Alphabetical List

OpenDocument Format (ODF) Family, OASIS and ISO/IEC 26300

>> Back
Table of Contents
Format Description Properties Explanation of format description terms

Identification and description Explanation of format description terms

Full name ODF Family. OASIS name: Open Document Format for Office Applications (OpenDocument). ISO name: ISO/IEC 26300, Information technology -- Open Document Format for Office Applications (OpenDocument)
Description

This description is an overview of the family of formats defined by ISO/IEC 26300: Information technology -- Document description and processing languages -- Open Document Format for Office Applications (OpenDocument) and the corresponding family of Open Document Format (ODF) specifications from OASIS.

The formats in the ODF family are XML-based, application-independent, and platform-independent file formats for editable documents. The specifications have been developed and are maintained by OASIS (Organization for the Advancement of Structured Information Standards). The ODF specifications are intended to support document authoring, editing, viewing, exchange and archiving for text documents, spreadsheets, presentation graphics, drawings, charts and similar documents commonly created or used in personal productivity software applications.

In addition to being XML-based and designed to support editing, requirements in the charter for the Open Document Format technical committee included:

  • it [the ODF format] must be friendly to transformations using XSLT or similar XML-based languages or tools
  • it should keep the document's content and layout information separate such that they can be processed independently of each other
  • it should 'borrow' from similar, existing standards wherever possible and permitted. [See General Notes below for a list of XML-based standards used by ODF.]

Content categories: The ODF family of formats includes subtypes for documents in different content categories, such as word-processing, spreadsheet, and presentation file formats. Documents comprise related component files bundled in a container/wrapper format called a "package." A typical ODF document has the following components:

  • mimetype -- one-line file containing the appropriate MIME type for the document type, for example, application/vnd.oasis.opendocument.text for a word-processing document.
  • ./META-INF/manifest.xml -- mandatory, a list of all the files in the ZIP-based package with their media types (MIME types), including information required for decrypting each file as relevant
  • content.xml -- actual content of the document, with markup inspired by HTML. Like HTML, ODF uses a "mixed-content" model for markup (with elements permitted to include both raw text and other elements), resulting in files that are relatively human-readable. See Notes below on mixed-content markup. The primary content is inside an <office:body> element, but this file may also contain the elements: <office:scripts>, <office:font-face-decls>, and <office:automatic-styles>.
  • styles.xml -- in ODF all formatting is done through styles. This file contains named styles, for example for headings of various levels and defaults for displaying dates and numbers. The <office:automatic-styles> section of a content.xml file is typically used for styles created automatically by implementations when users choose individual formatting features, such as emphasizing a word in bold-face or italics.
  • ./Pictures/ -- directory containing any embedded images in common formats such as JPEG or PNG
  • ./Thumbnails/thumbnail.png -- image to use as thumbnail
  • meta.xml -- file metadata, which may include not only predefined elements, but also user-defined elements and custom elements.  See Self-documentation below for details.
  • settings.xml -- holds settings that relate neither to content nor to layout of the specific document, for example, settings associated with the latest print action.

Chronological versions: OASIS has developed and published three versions of the ODF specification. Version 1.0 was published in May 2005, version 1.1 in February 2007, and version 1.2 in September 2011. Changes between ODF 1.0 and 1.1 were relatively minor, apart from extensions to address accessibility concerns. On this site, the plan is, over time, to develop descriptions for the package formats and categorical subtypes based on ODF 1.1 (also covering ODF 1.0), and separate descriptions for the ODF 1.2 versions. The OASIS Open Document Format for Office Applications (OpenDocument) TC is working on ODF 1.3, with a key effort being a markup structure for change-tracking that supports simultaneous collaborative editing. For the history of the format prior to submission for standardization through OASIS, and for more detail on ISO standardization for the later ODF versions, see History Notes below.

ODF package formats: An ODF document is always in a package that aggregates constituent components of a document (or other type of content) into a single object. The main ODF package specification is based on the ZIP format as defined in APPNOTE.TXT from PKWARE (see ZIP_PK). For details of the ODF package formats, see ODF_package_1_1 for ODF 1.1 and ODF_package_1_2 for ODF 1.2.

ZIP permits use of various compression and encryption algorithms. Compression in ODF files is restricted to the "deflate" algorithm. Encryption mechanisms as defined in APPNOTE.TXT are not permitted. A single encryption mechanism is specified for ODF_package_1_1 and the approach is updated in ODF 1.2 (ODF_package_1_2) specification to allow stronger encryption. Digital signatures are not supported in ODF 1.1; support for digital signatures was added in ODF 1.2.

See Notes below for more detail on versions of ZIP referenced by different versions of ODF. Also, see Notes below for information about an alternative wrapper format, a "flat" Single OpenDocument XML file format.

Production phase An ODF document can be used in any production phase. However, textual ODF documents (.odt) and presentations (.odp) are often converted to a static format rather than an editing format for final publication or archiving.
Relationship to other formats
    Has subtype ODF_text_1_2, OpenDocument Text Document Format (ODT) , Version 1.2, ISO 26300-1:2015
    Has subtype ODF_spreadsheet_1_2, OpenDocument Spreadsheet Document Format (ODS), Version 1.2, ISO 26300-1:2015
    Has subtype ODF_presentation_1_2, OpenDocument Presentation Document Format (ODP), Version 1.2, ISO 26300-1:2015
    Has subtype ODF_draw_1_2, OpenDocument Drawing Document Format (ODG), Version 1.2, ISO 26300-1:2015
    Has subtype ODF_chart_1_2, OpenDocument Chart Document Format (ODC), Version 1.2, ISO 26300-1:2015
    Subtype of ZIP_6_2_0, ZIP File Format, Version 6.2.0 (PKWARE). Various features of the ZIP File Format are not permitted in ODF. ODF 1.2 uses ZIP 6.2.0 as the normative basis for the package specification. See Notes below for more detail on versions referenced by earlier ODF specifications.
    Contains META-INF/manifest.xml file. This manifest file, not described separately in this resource, is mandatory in all ODF packages.
    Has earlier version OpenOffice.org 1.0 format, a precursor to ODF, not described on this site at this time.
    Has later version ODF 1.2 Extended formats, variants with additional markup supported by ODF implementations, for example LibreOffice and Apache OpenOffice, since OpenOffice 3.2.
    Has subtype ODF_package_1_1, OpenDocument Package Format, ODF 1.1. Includes ODF 1.0, not described separately at this site.
    Has subtype ODF_package_1_2, OpenDocument Package Format, ODF 1.2
    Defined via XML_1_0, XML (Extensible Markup Language) 1.0. ODF specifications include normative RELAX NG schemas.

Local use Explanation of format description terms

LC experience or existing holdings  
LC preference The Library of Congress Recommended Format Statement (RFS) 2015-2016 includes ODF (ISO/IEC 26300) as an acceptable format for textual works in digital form. In general, the Library of Congress prefers formats intended for final publication of textual works, rather than editable formats. Editable formats will be found in collections of papers of organizations and individuals.

Sustainability factors Explanation of format description terms

Disclosure International open standard. Maintained by OASIS Open Document Format for Office Applications (OpenDocument) TC. To summarize from the OASIS FAQ, OASIS promotes the development and adoption of open standards, using transparent governance and operating procedures, and offering a range of membership levels to support an inclusive, international, and balanced member base.
    Documentation

Specifications from OASIS: Open Document Format for Office Applications (OpenDocument) Specification v1.2. For other versions, see Format specifications below or the list on the page for the OASIS OpenDocument TC.

Specifications published as ISO/IEC 26300, with the latest versions available on http://standards.iso.org/ittf/PubliclyAvailableStandards/:

  • ISO/IEC 26300:2006, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.0 and Amd 1:2012, to align with ODF 1.1 as published by OASIS.
  • ISO/IEC 26300-1:2015, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.2 -- Part 1: OpenDocument Schema
  • ISO/IEC 26300-2:2015, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.2 -- Part 2: Recalculated Formula (OpenFormula) Format
  • ISO/IEC 26300-3:2015, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.2 -- Part 3: Packages
Adoption

As of 2015, office software suites using ODF as native file format include: LibreOffice, Apache OpenOffice, and Calligra. LibreOffice and Apache OpenOffice (AOO) derive from a split in 2010 when Sun Microsystems, sponsor of the open source OpenOffice.org was acquired by Oracle and some developers left to form LibreOffice. Oracle later licensed the OpenOffice codebase to the open source Apache organization. See Notes below for more detail on relationship between the AOO and LibreOffice projects in 2015. Both AOO and LibreOffice instal with a default format variant described as ODF 1.2 Extended. See Notes/History below for more on ODF 1.2 Extended. KOffice, an important product during the development of ODF, is no longer supported; its website was taken down in 2012. The Calligra suite has developed from a fork with KOffice in 2010. The KDE project and organization, formerly associated with the KOffice software application continues and the Calligra Development Wiki is part of the KDE Community Wiki. Microsoft Office 2013 and Office 365 permit the choice of ODF 1.2 or 1.1 as the default format for new files; when editing such files, features not supported in ODF will be hidden from users and no translation between ODF and OOXML occurs. The compilers of this resource believe that these suites offer three independent codebases that use the ODF format as the underlying native format: from OpenOffice/LibreOffice; Calligra/KDE; and Microsoft. Additionally, since the fork between OpenOffice and LibreOffice, significant differences between their codebases have been introduced. Comments welcome.

Other office applications that support ODF include: AbiWord (open source), which has a plug-in; EuroOffice, which extends OpenOffice/LibreOffice, in particular with support for spelling and grammar checkers for many European languages; and Corel WordPerfect Office Suite (since version X4). Two suites formerly available as independent products are no longer maintained: StarOffice and IBM Lotus Symphony. Code from these products was made available to Apache OpenOffice.

A number of government bodies have adopted the ODF family of formats as mandatory or recommended for documents which must be editable to support collaboration within the government or between the government and the public or other entities. The Wikipedia page on OpenDocument Adoption is intended to document evaluation or adoption of ODF by governments. As of April 2015, the page was clearly out of date. Examples of governmental policy documents that mandate ODF among editable documents include:

Policy documents that include ODF among acceptable formats for exchange of editable documents with governments include:.

  • Version 5.0 of the German Standards and Architecture for e-Government Applications (SAGA) includes ODF and OOXML among its formats under observation (beobachtet). Neither is yet categorized as recommended (empfohlen) or mandatory (verbindlich). This listing of formats is is a guide for system builders in relation to formats they need to be prepared to support.
  • eGovernment in Denmark-June 2014-v.16.0 indicates that Denmark continues to accept editable documents in "all common formats (including OpenDocument Format - ODF and Office Open XML - OOXML).
  • In France, the RGI (Référentiel Général d’Interopérabilité) issued in 2009 listed both ODF and OOXML in the status of "under observation" in relation to interoperability. As of Summer 2015, a new version of the RGI in draft form indicates that ODF is recommended.
  • In January 2014, a statement from the Vice-President of the European Commission Maroš Šefčovič recommended, "For revisable documents, all European institutions are recommended to support as a minimum two ISO standards, the Open Document Format (ODT) and Office Open XML (OOXML)." See EC recommends supporting open document format.

A sampling of support and categorization by archival institutions follows:

Despite all the official mandates and recommendations, adoption of ODF formats has been slow, particularly in the U.S. See, for example, The Long Slog to Level the Document Playing Field from January 2015.

    Licensing and patents No concerns. See OASIS Intellectual Property Rights (IPR) Policy and IPR statements from Sun Microsystems, Inc. specific to technology contributed to the ODF project.
Transparency

The XML-based files defined by the ODF schema are both human-readable and machine-processable. The mixed-content markup model, the prefixes, and the names for elements and attributes in the specification contribute to human readability. See Notes below on mixed-content markup.

Transparency of the ZIP-based container corresponds to that of ZIP_PK. It depends upon algorithms and tools to interpret and extract contents. It would require sophistication to build tools from scratch, but many tools exist.

Transparency ultimately depends on the files contained in the package. Files may be encrypted. Binary files, such as image files, may be included in the document package.

Self-documentation

Pre-defined metadata elements for the document as a whole include:

  • From the Dublin core namespace, using the dc: prefix: Title, Creator (of most recent modification), Description, Subject, Date (last modified), Language
  • From the ODF specification, using the meta: prefix: Generator (creating software application), Keywords, Initial Creator, Creation Date and Time, Modification Date and Time, Print Date and Time, Document Template, Document Statistics (word count, page count, etc.)

The pre-defined elements are all optional and repeatable. However, applications are not required to update multiple occurrences in a specific way to reflect modifications to a document.

In addition to pre-defined elements, ODF 1.0/1.1 specified markup to allow addition user-defined elements to be expressed by name and value. ODF 1.0/1.1 also provided a mechanism for custom metadata, by indicating that all content in an office:meta element should be preserved. In ODF 1.2, the earlier mechanism for custom metadata was deprecated in favor of using new markup specified for incorporating RDF-based metadata.

External dependencies Depends on files contained in the package.
Technical protection considerations Encryption is supported for files within an ODF package. In addition, an ODF package file may be encrypted during interchange or as part of DRM controlling distribution.

Quality and functionality factors Explanation of format description terms

Other
See note Quality and functionality factors will be considered for subtypes for specific content categories. See for example, ODF_text_1_2.

File type signifiers Explanation of format description terms

Tag Value Note
Filename extension See note.  ODF package files use extensions appropriate to the type of document packaged. Hence, .odt, .odp, .ods, are all extensions used for ODF packages.
Internet Media Type See note.  ODF package files use MIME types appropriate to the type of document packaged, using the pattern application/vnd.oasis.opendocument.xxxxx. For example, the MIME type for an ODF text document is application/vnd.oasis.opendocument.text. See ODF_text_1_2. The MIME type for a Flat ODF file is found in an attribute for the top-level <office:document> element.
Magic numbers See related format.  See ZIP_PK.
Indicator for profile, level, version, etc. See note.  The four root elements used in the primary files in an ODF package all permit an attribute that records the ODF version, e.g, "1.0" or "1.2". In a Flat ODF file the version is in an attribute for the top-level <office:document> element.

Notes Explanation of format description terms

General

Namespaces defined in ODF specification and schema : The OpenDocument Schema defines a number of namespaces used for different types of content, e.g., text:, table:, chart:, etc. A namespace is not constrained to a particular document category, but usable in any appropriate context. For example, the elements and attributes in the table: namespace are used for tables in text documents and for tables in spreadsheets. Namespaces defined in ODF 1.2 for different types of content include:

  • anim: For animation content.
  • chart: For chart content.
  • dr3d: For 3D graphic content.
  • draw: For graphic content.
  • form: For forms and form controls.
  • presentation: For presentation content and controls.
  • table: For tables in text documents, in spreadsheets, or in presentations.
  • text: For text documents or text parts in other document categories.

Additional namespaces are used for elements and attributes that relate to ODF packages and generic ODF features, including meta:, odf:, office:, style:, manifest: and number: (for display styling for numbers). Two namespaces are used primarily to hold application-specific content: config:, for application settings and script:, for macros. The ODF specification does not prescribe any particular macro language. It permits the inclusion of scripts in any language and allows the language for any embedded script to be declared.

ODF 1.2 introduced a new namespace, db:, designed to support use as a stand-alone database front-end document and to allow documents of other categories to import data from databases, for example to support mail-merge or dynamic update of charts from external data.

Standards from which ODF borrows: XML-based standards and the prefixes used in ODF are:

  • dc: Dublin Core namespace (DCMI) is imported
  • xlink: XLink namespace is imported
  • math: MathML namespace is imported
  • xforms: XForms namespace is imported
  • fo: used for attributes that are compatible to attributes in XSL
  • svg: used for elements and attributes that are compatible to elements or attributes in SVG 1.1
  • smil: used for attributes that are compatible to attributes in SMIL 2.0

Mixed-content markup: A simple example of an ODF paragraph demonstrates the readability of mixed-content markup:

  • <text:p text:style-name="Standard">
  • This is a
  • <text:span text:style-name="T1">very basic</text:span>
  • document
  • <text:span text:style-name="T2">with some</text:span>
  • formatting, and a
  • <text:a xlink:href="http://example.com">hyperlink</text:a>
  • </text:p>

The definitions for the named styles (Standard, T1 and T2) will be stored in the separate styles.xml file. For a comparison with the markup for the same paragraph in OOXML, see OpenDocument vs Microsoft OpenXML - Part II, a page from the website of the OpenDocument Fellowship, an organization that used to promote ODF, but now appears inactive.

Although human readability is an advantage and can make it easier for programmers to understand the structure when developing code to parse or display the content, mixed-content has disadvantages too. See Mixed content myopia for the opinion of a programmer who points out some challenges. More directly related to ODF, if a paragraph element allows mixed content, but it is necessary to apply attributes to a piece of text within the paragraph, for example, when tracking changes, then it is necessary to put that text into its own element, which detracts from the readability.

ZIP versions used for ODF: Version 1.0 as published by OASIS used a reference to the latest version of appnote.txt from PKWARE, which was subject to unannounced updates by the owner, PKWARE. Versions 1.0 from ISO/IEC and 1.1 from OASIS referred to an unofficial variant of PKWARE's appnote.txt from Info-ZIP. This adaptation of PKWARE's specification explicitly removed some capabilities for encryption and other services patented by PKWARE. The Info-ZIP software was used widely as a library for working with an interoperable open subset of the ZIP format. The open source Info-ZIP project has not seen much action since early 2009, although betas have been released since then. ODF 1.2 uses PKWARE's version 6.2.0 of appnote.txt [see ZIP_6_2_0]. The compilers of this resource are not aware of substantive differences in the intent of the ZIP specifications in ODF 1.0-1.2 or among software implementations creating ODF files. Comments welcome.

Flat ODF format: Although ODF documents are almost always packaged in ZIP files, a format that is a Single OpenDocument XML file is specified. The specification is in clause 2.1 (Document Roots) the specification for ODF 1.1 and in clause 3.1.2 (Single OpenDocument XML file) in ODF 1.2 Part 1. This format is often termed Flat ODF. The root of a Flat ODF file is the <office-document> element. In contrast, a packaged ODF document has several separate XML files in its ZIP-based structure with root elements: <office-document-content>; <office-document-styles>; <office-document-meta>; and <office-document-settings>. There are advantages to the flat representation for parsing, validation, document comparison, and programmatic generation with basic XML tools, as argued by Fridrich Štrba in Flat ODF as the Swiss Army Knife.

Relationship between Apache OpenOffice and LibreOffice: Although the codebase for LibreOffice and Apache OpenOffice (AOO) has common heritage, the codebases have grown apart since the 2010 split. The fact that the organizations opted for different open source licenses means that although LibreOffice can absorb code from the AOO project, the reverse is not true. According to a blog post by Chris Hoffman at How-To Geek, "The Apache OpenOffice project uses the Apache License, while the LibreOffice uses a dual LGPLv3 / MPL license. The practical result is LibreOffice can take OpenOffice’s code and incorporate it into LibreOffice — the licenses are compatible. ... the two different licenses only allow a one-way transfer of code. LibreOffice can incorporate OpenOffice’s code, but OpenOffice can’t incorporate LibreOffice’s code." Daniel Brunner, head of the IT department of Switzerland's Federal Supreme Court has argued that the two projects should merge back together, as reported in Open and Libre Office projects should reunite in September 2014. In response, Reuniting LibreOffice and AOO – a personal take is a blog post by Charles-Henri Schulz, who was heavily involved in OpenOffice and ODF standardization before the split and later in building support for LibreOffice, concludes that the projects themselves have little interest in merging and without such interest there would be no benefit. His personal view is clearly that arguments made by outsiders for a reconciliation are flawed. LibreOffice, OpenOffice, and rumors of unification, another blog post response, this one by Bruce Byfield, concludes that, "the idea of unification should be shelved as unworkable." He includes the sentence, "In other words, for some reason, development of OpenOffice has all but stalled, while LibreOffice remains an active project."

History

History prior to ODF standardization: The charter stated, "Since the OpenOffice.org XML format specification was developed to meet these criteria and has proven its value in real life, this TC will use it as the basis for its work. ... In the first phase, this TC will use proven and established constructs so that the resulting standard can satisfy the immediate needs of many users, as well as serve as a base for future, less restricted development. ... In the second phase, this TC will maintain the specification delivered in phase 1 and will extend it to encompass additional areas of applications or users, which may also include adapting the specification to recent developments in office applications." The first phase resulted in a Committee Draft in March 2004. The second phase, of maintenance and extension, is ongoing. After publication of ODF 1.0 by OASIS in May 2005, ODF 1.0 was submitted to ISO/IEC JTC1/SC34 for ISO standardization in late 2005 and published as ISO/IEC 26300:2006 in late 2006.

A detailed chronology for the development of ODF prior to publication of version 1.0 by OASIS follows:

  • 1999: Sun Microsystems acquired the StarOffice Suite from the German “Star Division” company. At the time, StarOffice used a binary format and did not support Unicode, but the programming team was already working on an XML-based format. Sun offered StarOffice 5.0 for free download which created a stir in the software industry.
  • 2000: Sun launched the OpenOffice.org project (aka OOo), which developed an open file format called the "OpenOffice.org XML file format" or, later, the "OpenOffice.org 1.0 format." The first draft of the format specification was released.
  • 2001: Sun opened the source code that was the basis for StarOffice 6.0 and OpenOffice.org 1.0. Both applications used the XML-based format as native file format; neither supported a binary alternative.
  • 2002: Support for CJK and scripts requiring complex text layout was added. Discussions began with the KOffice project over improvements to the format. The OpenOffice.org 1.0 format was submitted for OASIS standardization. In addition to Sun Microsystems, founding members included Boeing, Stellent, Arbortext, the National Archive of Australia, and the Society of Biblical Literature. The first conference call of the OASIS Technical Committee (TC) was on Dec 16, 2002.
  • 2003: KDE (developer of KOffice) joined the TC and active work began to prepare the standard, including adapting to new versions of standards incorporated into the specification, such as SVG and CSS. Enhancements to the format as submitted included switching from XML DTDs to Relax-NG as schema language; better support for validation; and extensions to support functionality in KOffice and OpenOffice.org 2.0.
  • 2004: Two committee drafts were circulated within OASIS and made available for public review. The name of the specification was changed to "OASIS Open Document Format for Office Applications (OpenDocument)," abbreviated to ODF.
  • 2005: ODF 1.0 was approved as an OASIS standard in May. StarOffice 8.0 from Sun Microsystems, with ODF 1.0 support, was released in September.

The chronology above was pieced together from a variety of sources, including Rob Weir's 2007 blog post, Introduction to OpenDocument Format (from IBM, apparently from 2006), Office opens its doors (July 2006 article in the Guardian newspaper), Office Productivity Suite Competitive Analysis (by Martijn W.H. Dekkers. 2002), From Open Source to Open Standard: The OASIS OpenDocument Format (presented by Michael Brauer at XTech 2005: XML, the Web and beyond. April 2005), and Open by Design: The Advantages of the OpenDocument Format (2006 OASIS white paper).

After the OASIS approval of ODF 1.0, the specification was submitted to ISO/IEC JTC1/ SC34 in late 2005, with approval as ISO/IEC 23600 in May 2006 and publication in late 2006. Maintenance of ODF continues to be through the OASIS Open Document Format for Office Applications (OpenDocument) TC.

History since ODF standardization through ISO: OASIS has developed and published two additional versions of the ODF specification. Version 1.1 was published in February 2007, and version 1.2 in September 2011. Changes between ODF 1.0 and 1.1 were relatively minor, apart from extensions to address accessibility concerns. A 2012 amendment to ISO/IEC 26300:2006 brought the ISO standard into alignment with ODF 1.1. ODF 1.2 was approved by ISO/IEC JTC1/SC34/WG6 in September 2014 and published as an ISO/IEC standard in June 2015. ODF 1.2 introduced several substantive extensions, for digital signatures, for RDF-based metadata, and OpenFormula for spreadsheet formulas.

History of OpenOffice implementations after standardization through ISO: According to Wikipedia entry for OpenOffice.org, "Versions 2.0–2.3.0 default to the ODF 1.0 file format; versions 2.3.1–2.4.3 default to ODF 1.1; versions 3.0 onward default to ODF 1.2.". No later than OpenOffice 3.2 (released in February 2010), new versions of OpenOffice (and successors AOO and LibreOffice) have installed with a default format described as ODF 1.2 Extended. From OpenOffice.org 3.2 New Features, "As OpenOffice.org 3.2 currently requires a superset of the ODF 1.2 specification, the software now warns users when ODF 1.2 Extended features have been used." LibreOffice provides both an explanation for this practice and detailed documentation on its extensions.


Format specifications Explanation of format description terms


Useful references

URLs


Last Updated: Tuesday, 05-Jan-2016 09:42:14 EST