OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Font Embedding in ODF -- Existing Provisions and Opportunities

Here is further information on the potential for development of font embedding in ODF implementations.

 - Dennis


Here is the *technical* opening for font embedding in the ODF specifications.

In ODF 1.2 CS01 Part 1, sections 19.910.29 <svg:definition-src> xhtml:href attribute and  19.910.30 <svg:font-face-uri> xhtml:href attribute.  These can be relative references to internal parts of the package, of course.  That is how embedding can be done.  MIME types are needed (in META-INF/manifest.xml) for the  referenced parts.  The MIME type is what discriminate what kind of font-material is there.

Element <svg:font-face-uri> (15.24) is a none-or-more alternative child of <svg:font-face-src>.

Element <svg:font-face-src> (16.22) is an optional child of <style:font-face>.

Element <svg:definition-src> (16.25) is an optional child of <style:font-face>.

The gold is 16.21 <style:font-face>.  This only appears as a child of <office:font-face-decls> (section 13.4).

This structure has existed since ODF 1.0, so it already appears in ISO/IEC IS 26300:2006, in ODF 1.1, the forthcoming IS 26300 alignment with ODF 1.1, and now ODF 1.2.

This deals with the technical prospect for embedding.  The use cases, implementation notes, and above all the means for choosing embeddings, honoring licenses, etc., require a roadmap of progressive improvements.  And there is already here the least that could possibly work and can be used for some trials and resiliency testing with existing ODF consumers.

NOTE: It has been mentioned that a special kind of xlink:href value could be used to directly embed font data in the single-XML document case.  A better, less-dangerous approach would be to allow an <office:binary-data> element as an alternative child in those places where an xlink:href is an option.  There would need to be another way to know the MIME type and it is probably time to add some attributes to the <office:binary-data> element to facilitate that.  This would require down-the-road, ODF 1.3+ work.


A short time before the most-recent ODF Plugfest, Jos van den Oever demonstrated that ODF already has a means by which fonts can be embedded in the ODF document.

So, in fact, a *technical* solution seems to exist.  (Most of the debates about font embedding that I have been party to are around the legal and licensing niceties and avoiding becoming a contributory infringer by not handling this well. This is not entirely unlike issues around bundling of extensions that have license limitations [;<)

Staying on the technical side of the issue, the following is now known:

 1. Fonts can be embedded in ODF documents, using existing and long-present provisions of the ODF specification. 

There is now need for the following:

 2. Some (more) proof-of-concept sample documents that demonstrate such embedding need to be collected as test vehicles.  [Any solution applies to all ODF formats - text, spreadsheet, presentation, ... - that have a font section and definable styles in the format.]

 3. It needs to be determined what happens with ODF consumers when such unexpected documents are encountered.

 4. There needs to be some staging among ODF producers to support embedding in implementations (LO, AOO, Microsoft Office), etc.  There also needs to be upgrading of conversion software so that font embeddings can now be ported between formats that support them (and will make very many people very happy).  Consumers need to be upgraded at the same time or even ahead of producers.  There is also a concern for what happens when a down-level release encounters one of these ODF files, of course.

 5. A GREAT DEAL OF INTEROP TESTING AND RELEASE STAGING IS CALLED FOR.  (More security analysis is also needed because font injection is an exploit path and there have been past vulnerabilities around fonts.)  

 6. The next ODF Plugfest is scheduled for April in Brussels.  Now is a great time for moving proof-of-concept/prototype/finished/collaborative work forward for introduction and presentation on the agenda of that event.  The OASIS ODF Interoperability and Conformance TC has some resources (even an SVN for sample documents and test cases) and the Plugfest mailing list can be a valuable neutral forum.  (The last TC call of 2011 is tomorrow, 12-13, and this will definitely be discussed.)

 7. With regard to pro-active support and the interfaces necessary to control embedding, embedded-font usage, and when and how embedded fonts can be extracted and/or repurposed in other documents, there may need to be some technical support, and that will be a longer discussion that may require extended staging to be fully functional.  (It is in the nature of the ODF format that direct extraction of fonts embedded in the current structure is trivial for any teen-age hacker, with no cooperation of an ODF consumer required.)  Down the road, there may need to be more-specific consideration of font embedding in the ODF Specification beyond the current, simple hook.

 8. I suspect that there are cases that can be handled without too much difficulty and useful embedding can happen soon, with enrichment of the feature and functionality over time.

 - Dennis E. Hamilton
   tools for document interoperability,  <http://nfoWorks.org/>
   dennis.hamilton@acm.org  gsm: +1-206-779-9430  @orcmid

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]