3monkeys

Rob Weir recently posted “How to hire Guillaume Portes“, which appeared on Slashdot, both of which both are great resources for additional comments and debate. The basic premise of Rob’s article was that the Microsoft Open XML Specification was similar to creating a job description that would allow for only one qualified respondent. Such a job description might read as follows:

• 5 years experience with Java, J2EE and web development, PHP, XSLT
• Fluency in French and Corsican
• Experience with the Llama farming industry
• Mole on left shoulder
• Sister named Bridgette

While perhaps a little extreme, he continues to show that indeed the Open XML Specification is indeed written to accommodate Microsoft products. I will not bore you with all of his examples, but here are a few are worth inspection.

2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a document’s content.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

and

2.15.3.51 suppressTopSpacingWP (Emulate WordPerfect 5.x Line Spacing)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (WordPerfect 5.x) when determining the resulting spacing between lines in a paragraph using the spacing element (§2.3.1.33). This emulation typically results in line spacing which is reduced from its normal size.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

This gluttony is further illustrated by the shear complexity of the specification. As many 3Monkey readers know, I’m conducting a series of articles comparing the ODT and DOC formats. With Microsoft Office due to hit consumer shelves at the end of January, I thought I would get a jump on things and download the OOXML specification to get a jump on things. To my surprise the Open XML specification comes in 5 different PDF files with an 6 accompanying electronic annexes in excess of 43 megabytes. For comparison the ODF specification is a single 11 megabyte PDF, with 3 separate XML schemas. The ODF specification weighs in at a mere 722 pages, where as, the largest PDF in the Open XML specification is 5219 pages long.

While I have to wonder at Microsoft’s motivation for producing the Open XML standard, I do not have to guess at the motivation for ODF. Started as early as 1999, ODF was designed as an open and implementation neutral file format. The open specification process started in 2000 with the foundation of the OpenOffice.org open-source project. An even higher level of openness was established in 2002 with the creation of the OASIS Open Office Technical Committee (TC). ODF had gained full adoption with it’s early adopter including OpenOffice.org 1.0 and StarOffice 6 being introduced in May of 2002 and KOffice adoption of the ODF format in August of 2003.

IBM has provided the one voice of reason in this travesty. IBM voted against the certification of Microsoft Office document formats (Open XML) as an international standard at a general assembly of Ecma International in early December 2006. Bob Sutor, IBM’s vice president of standards and open source, confirms Mr. Weir’s sentiment that the ODF standard is of superior quality, versus Open XML which he considers to be “a vendor-dictated spec that documents proprietary products via XML“.

Open XML has been submitted to the ISO for standardization. I encourage each and every reader to oppose this standardization effort. Further details will be outlined on this blog as they become available.

Until next time-

-3Monkeys

Popularity: 15% [?]

Overview

In my last article, OpenOffice .odt Opened Up – Part 1: Overview, I discussed the overall package scheme for ODT documents, and pointed out that OpenOffice uses the subdocument form. In this article, I will be taking a closer look at two of simpler top level subdocuments of the four included in the specification. Specifically, we will be taking a closer look at the office:document-meta and office:document-settings elements.

As before, my test cases where produced with the following software:

• SuSE Linux 10.1
• OpenOffice 2.0.2.7.1
• zip 2.31 (March 8th 2005)

The original source document can be downloaded here oo_part1.odt, and in particular the two subdocuments under observation can be downloaded here meta.xml and settings.xml.

The office:document-meta element

The office:document-meta element provides metadata with respect to the document, such as, author, creation time and editing time, among other data. The metadata elements can be either pre-defined or user defined. Pre-defined elements should be respected and updated by the editing application. User defined elements provides a more generic way of storing and using metadata. Each user defined metadata element is compossed of a name, a type and a value. Supporting applications can access this information and display it to the user based on its type. Both pre-defined and user defined should be able to be referenced through appropriate document text fields.

The pre-defined metadata elements are largely based upon the metadata standards developed by the Dublin Core Metadata Initiative (http://www.dublincore.org), thus many of the elements use the dc namespace.

There are 18 pre-defined metadata elements, these are listed below:

• meta:generator
• dc:title
• dc:description
• dc:subject
• dc:keyword – Can appear multiple times
• meta:initial-creator
• dc:creator – Last modifier
• meta:printed-by
• meta:creation-date – Format YYYY-MM-DDThh:mm:ss
• dc:date – Last modification date, format YYYY-MM-DDThh:mm:ss
• meta:print-date
• meta:template
• meta:auto-reload
• meta-hyperlink-behaviour
• dc:language – As defined by RFC3066, with ISO 639 language code and ISO 3166 country code
• meta:editing-cycles
• meta:editing-duration – Format PnYnMnDTnHnMnS
• meta:document-statistic – Can appear multiple times, ODT attributes below
  • meta:page-count
  • meta:table-count
  • meta:draw-count
  • meta:image-count
  • meta:ole-object-count
  • meta:paragraph-count
  • meta:word-count
  • meta:character-count
  • meta:row-count
  • meta:frame-count
  • meta:sentence-count
  • meta:syllable-count
  • meta:non-whitespace-character-count

As I suggested regarding the thumbnail image in a prior article, this information could easily be extracted and displayed to users of popular search engines such as Google, Yahoo and Ask. Additionally these services could allow the user to narrow their search based on certain criteria found in the metadata.

Provided here, meta.pl, is an example written in perl using the XML::Simple package that extracts the last editor, modification date, and page and word count. If anyone would like to contribute ports of this to another language feel free. If there is significant interest, I will cover XML::Simple or other XML packages or utilities.

The office:document-settings element

Next we take a look at the office:document-settings element. This element contains application settings that may impact thedocument. It does not caontain a complete set of application settings. Being application settings, there are no particular entries that are defined ih the ODF Specification. A office:document-settings element will contain one or more config:config-item-set elements, these elements will in turn contain config:config-item, config:config-item-set, config:config-item-map-named or config:config-item-map-indexed. The discovery of how each of these elements works with a particular application, such as OpenOffice.org Writer, is left as an exersise to the reader since they do not directly affect our goals of understanding ODF as it relates to Microsoft’s .doc format. Suffice it to say, the office:document-settings element is of little interest to all but an application developer.

What’s up next?

Next up we will investigate the significantly more interesting office:document-styles element. We will also learn some optimization techniques that we can apply to this element and perhaps discover a little of how it relates to thee office:document-content element.

Until next time,

-3Monkeys

Popularity: 8% [?]

Overview

In the first article in this series, OpenOffice ODF/.odt compared to Microsoft Word .doc, I compared various file types for size efficiency. Of particular interest was the fact that OpenOffice Write stores .odts in a zip format, an implementation of PKZip to be exact. With this knowledge and the Open Document Format standard, we can investigate how certain elements of a document effect its size and overall efficiency.

My test cases where produced with the following software:

• SuSE Linux 10.1
• OpenOffice 2.0.2.7.1
• zip 2.31 (March 8th 2005)

Starting Out

As we previously observed, .odt documents are stored in ZIP format. It is possible to store the document as a single XML file that conforms to the OpenOffice.org document type definition (DTD). It is also possible to store the document as several subdocuments, each with a different document root that represents a particular aspect of the document, such as, content or style.
Quoting the Open Document Format for Office Applications (OpenDocument) v1.0 (Second Edition), (ODF Specification):

The OpenDocument format supports the following two ways of document representation:

• As a single XML document.
• As a collection of several subdocuments within a package (see section 17), each of which stores part of the complete document. Each subdocument has a different document root and stores a particular aspect of the XML document. For example, one subdocument contains the style information and another subdocument contains the content of the document. All types of documents, for example, text and spreadsheet documents, use the same document and subdocuments definitions.

There are four types of subdocuments, each with different root elements. Additionally, the single XML document has its own root element, for a total of five different supported root elements. The root elements are summarized in the following table:

Root Element	Subdocument Content	Subdoc. Name in Package
office:document	Complete office document in a single XML document.	n/a
office:document-content	Document content and automatic styles used in the content.	content.xml
office:document-styles	Styles used in the document content and automatic styles used in the styles themselves.	styles.xml
office:document-meta	Document meta information, such as the author or the time of the last save action.	meta.xml
office:document-settings	Application-specific settings, such as the window size or printer information.	settings.xml

So, what is in our reference .odt? We will use the Linux produced document from a prior article (oo_part1.odt) with XML compression disabled. We’ve done this so that the XML is more human readable. After we unzip the file using the Linux utility unzip, we have the raw files as shown below.

As you can see all four subdocuments as specified in the specification are present as well as several other files. In particular META-INF/manifest.xml list the contents of the package, including information such as full path and type.

The file Thumbnails/thumbnail.png although part of the package, is not part of the document. The thumbnail image should conform to the Thumbnail Managing Standard (TMS) at www.freedesktop.org, and therefore should be24bit, non-interlaced PNG image with full alpha transparency. The required size for the thumbnails is 128×128 pixel.

Here is the thumbnail from our reference document.

Having the thumbnail available in the package, allows other applications such as file managers to preview the document to the user. With a little creative programming, sites such as Google, Yahoo or Ask, could extract this thumbnail and preview the document for users, with little difficulty.

Document Elements

The office:document may contain any of the document elements listed below.

• office:document-attrs
• office:document-common-attrs
• office:meta
• office:settings
• office:scripts
• office:font-face-decls
• office:styles
• office:automatic-styles
• office:master-styles
• office:body

When the subdocument method is used however, elements are restricted to certain subdocuments.

Elements in content.xml

• office:document-content (subdocument root)
• office:document-common-attrs
• office:scripts
• office:font-face-decls
• office:automatic-styles
• office:body

Elements in styles.xml

• office:document-styles (subdocument root)
• office:document-attrs
• office:document-common-attrs
• office:font-face-decls
• office:styles
• office:automatic-styles
• office:master-styles

Elements in meta.xml

• office:document-meta (subdocument root)
• office:document-common-attrs
• office:meta

Elements in settings.xml

• office:document-settings (subdocument root)
• office:document-common-attrs
• office:settings

What’s Up Next?

At this point we have a clear understanding of the subdocument method that OpenOffice applies to its ODF implementation, and we know what top level elements are handled by each subdocument.

In the next article, we will ease into the subdocument elements by exploring the office:document-meta and office:document-settings elements. These two elements are rather simple and will not require as much review compared to office:document-content or office:document-styles.
Until next time.

-3Monkeys

Popularity: 23% [?]