ODF 1.2 comment: support for font embedding

[Michiel Leenaars <michiel.ml@nlnet.nl>]

           Note: since this concerns a missing feature in ODF, the choice of
           which part of the spec (1 or 3) this should be addressed is up to
           the editors. 

ODF currently does not describe how applications may embed fonts, leading to 
situations where applications that do support such a feature technically some 
way or another (e.g. Wordperfect Office, Microsoft Office, etc) cannot safely 
use it when saving to ODF - even when documents are used for personal 
consumption. 

For documents that contain non-ubiquitous fonts, for collaboration on 
documents and presentations across platforms or in the browser, this can be 
awkward and lead to a degraded user experience. For archiving purposing, fonts 
are often an issue in office documents as well. Applications may currently 
already choose to embed fonts in the ODF package, but they are not protected 
by the current specification against other applications deleting them while 
editing or reviewing.

Many fonts that are used by default in modern office applications as well as a 
growing amount of other fonts can be legally distributed for free (such as 
GPL, OFL or public domain fonts). There is also a significant amount of fonts 
that are only available under copyright conditions that legally limit some 
forms of distribution of the entire font - although I am not aware of 
limitation of use in well-known standards such as ISO 15930, ISO 19005 and ISO 
32000, nor of any patent issues for such mechanisms.

To satisfy both use cases as well as concerns that ODF could potentially 
become subject to patent litigation for describing specific implementations of 
font embedding, I propose to add a light-weight mechanism that would enable 
multiple font embedding technologies to be used in ODF and that I propose 
SHALL be kept intact by all ODF 1.2 compliant applications:

- file locations in the container (or URI if available online * ) 
- a URI describing the font embedding method 
- (if available) the mimetype of the font
- Dublin core data on the font such as the font name, making it easy for 
applications to determine if they even need to bother to open - and if they 
are 
(- optional: a digital signature from the foundry)
- the possibility to add additional parameters specific to the embedding
  method (in RDF)

Can probably be easily defined in terms of part 3, section 5 (Metadata 
Manifest Files)... 

Embedded font support should not be mandatory, in order not to burden those 
implementers that have no need for it. However, for the use case of freely 
distributable fonts, from an archiving point of view it would make sense to 
require applications that do support font embedding to always have the 
simplest available embedding method (just putting in the raw font files) 
available as well as any potentially proprietary methods juggling about glyphs 
and metrics. 

Applications do not have to support every font embedding technology, which
would leave them and more specifically their users in the current situation: 
the font would not be available. All applications should just recognise the 
generic method with which applications can choose to support it, and (while we 
are at it) should not be allowed to destroy parts of odf files concerning 
embedded fonts either. I think it is completely backwards compatible as 
currently, applications that receive an ODF file do not have any additional 
font data.

Even if a proprietary or patent encumbered embedded technology is used, there 
are still a number of use cases where uses could significantly benefit from 
font embedding.

Best,
Michiel Leenaars

P.S. A special case to consider would be the use of embedded fonts in hybrid 
ODF/PDF-files (a PDF with attached original ODF such as produced by a number 
of tools, or ODF with a PDF preview such as created by NeoOffice). It would be 
magic if fonts could be either referenced/discovered/shared among those two 
instances of the same document.