Proposal: OFF/X

Dear list members,

Here's my proposal for what I call OFF/X -- "open font format for 
exchange".

== INTRO: SPRING CLEANING ==

In the following, I'll be using SFNT as an umbrella term for all font 
formats and specs which are hosted in the "sfnt" data structure (ISO 
OFF, OpenType, TrueType, TrueType AAT, etc. etc.).

A web font technical profile is a set of recommendations that aims to 
create a formalized subset of various aspects of the SFNT font format 
which are allowed, recommended, deprecated and disallowed within that 
profile. As an analogy, the ISO PDF/X is a standardized subset of the 
PDF format that acts similarly. Some PDF files conform with PDF/X, 
others doesn't.

SFNT (just like PDF) is a "large" format, which is very extensible, but 
also has evolved over many years. There is a number of standards that 
define aspects of it (the ISO OFF spec, the OpenType spec, the TrueType 
spec, plus vendor-specific extensions). Some tables are mandatory, 
others optional. Many tables have evolved in terms of version numbers, 
there is a number of subformats for many tables, and some of them are 
better supported or less well supported. On top of that, there are many 
provisions in the current specs which exist due to legacy reasons -- 
most famously, the OpenType spec makes many provisions which allow the 
fonts to be compatible with the old Windows GDI subsystem which dates 
back to Windows 3.1.

Backwards compatibility has its good reasons in the desktop font world. 
There is a tremendous number of environments on which SFNT fonts can be 
deployed, and many operating systems, graphic rendering subsystems and 
libraries, and applications, that rely on this or that aspect of the 
OpenType font to behave this or that way. Some of these environments are 
"out there", but will never be revisited, extended, changed.

With the OFF/X proposal, I'd like to see some big "spring cleaning" 
happen. When looking for a real-life analogy, the most effective spring 
cleaning you can do is when you move from one apartment or house to 
another. When you put all things together into a box, and then you 
unpack them in the new place, and arrange everything anew -- this gives 
you the best opportunity to throw things away. (Or leave them in the 
boxes unpacked and stow away in the garage -- which is effectively the 
same thing).

Using this analogy for the font world: the best opportunity to do 
"spring cleaning" is when we change container formats.

Historically, the SFNT fonts started as an "sfnt" resource inside of the 
resource fork of an Apple font file.

SFNT fonts then went on through several container format changes. Some 
of the changes only involved the change of the file extension, others 
involved some larger changes. The most significant changes that are 
still relevant today were:
1. Original "sfnt" resource in an Apple font file
2. TTF: The "Windows TrueType font file" which later became the 
"TrueType-flavored OpenType font file"
3. OTF: The "CFF-flavored OpenType font file"
4. WOFF: The "Web Open Font Format file"

Especially when you look back at the moment when OTF was introduced, I 
think it proves my point that the change of a container format is a good 
chance to clean things up. For example, "out in the world", we can still 
find TTF files with the OS/2 table version 1, while the majority of OTF 
fonts have OS/2 table version 3 or 4. Same goes for WOFF, albeit for 
somewhat different reasons (Google's OT sanitizer library, which, among 
others, rejected some malformed SFNT fonts which would otherwise work 
fine on desktop systems).

One key factor in this is that the change of a container format involves 
"touching" the font file, i.e. converting them into the new format using 
some kind of tool. Font manipulation tools get updated, so whenever we 
come to a point that we need to convert some old fonts into a newer 
container format, it often happens that the updated tool enforces some 
upgrades and cleaning. But if the old container format (such as TTF) is 
still supported, there is no need to "touch" the font files, i.e. no 
need to convert, upgrade or clean.

== WOFF AS A CHANCE ==

The WOFF container is still relatively new, and we're now working on 
WOFF 2.0. So there will be chances, once again, to convert (and 
therefore also upgrade and clean) much of the old font data. So we could 
use this opportunity to create a new set of recommendations for what 
should exist inside the WOFF. Since WOFF is primarily used by web 
browsers, there is also a much greater chance that the recommendations 
we propose will be actually honored -- because there is a much more 
limited number of web browsers than there are desktop environments.

And, since we're talking about recommendations for a NEW container 
format, only the web browsers that are actively maintained need to be 
concerned. "Dead meat" environments like, say, Netscape Navigator 
running on Windows 95, or even Internet Explorer 7 running on Windows 
XP, can be disregarded, since they won't understand the new container 
format.

== OFF/X:2014 -- OPEN FONT FORMAT FOR EXCHANGE, 2014 VERSION ==

So I'd like us to start thinking about what aspects of the SFNT contents 
could be formulated in a stricter way. While those recommendations could 
primarily target WOFF, they don't need to be "tied hard" to it. 
Developers of new desktop environments, or font creation tools, could 
also use them as a reference. This is why I've tentatively called my 
proposal "open font format for exchange", or OFF/X in short, taking a 
clue from PDF/X in relation to PDF.

The first iteration of the OFF/X recommendation could be named 
OFF/X:2014 (if we publish it in 2014 :D ), taking a clue from the ISO 
way of denoting the versions using a year number after a colon. This 
terminology would have the advantage that desktop fonts (in the OTF and 
TTF containers) which comply with the recommendations could be referred 
to as "OFF/X:2014", while web fonts that would comply could be named 
"WOFF/X:2014".

The OFF/X:2014 recommendation would refer to the ISO OFF spec as its 
basis, and on top of that define stricter rules as for what should be 
inside the SFNT tables.

The WOFF/X:2014 recommendation would simply refer to the OFF/X:2014 
recommendation for the contents, plus to the WOFF spec current at that 
time (say, WOFF 2.0) for the WOFF container format. In addition, 
perhaps, WOFF/X:2014 could contain some stricter rules as for the WOFF 
metadata etc.

== TENTATIVE OFF/X SPECIFICS ==

Below are some issues which spontaneously come to my mind which could be 
included in OFF/X. This is just an initial idea, and should be debated, 
edited, extended.

== Nature of OFF/X ==

I think each item within OFF/X should define the requirement level. I 
propose to adopt the widely accepted RFC 2119 for reference: 
http://www.ietf.org/rfc/rfc2119.txt for the distinction between MUST, 
MUST NOT, SHOULD, SHOULD NOT etc. I think there will be value in 
defining both "strong" and "soft" requirements. Any font vendor or 
browser vendor may choose to comply with OFF/X, and of course fonts 
which not comply with OFF/X shall still work.

I think the OFF/X should state that web browsers which choose to comply 
with OFF/X *MUST* support fonts which are OFF/X-compliant, but they can 
also continue to support fonts which are not OFF/X compliant.

There probably need to exist two kinds of requirements:
* for the fonts (what kind of data a font must or should or must not or 
should not contain)
* for the clients (e.g. which data must be used if some redundant data 
cannot be removed)

==  Choice of the Layout Model ==

Within SFNT, there is a number of valid Layout Models. My own 
categorization of what's currently relevant is as follows:
a) TrueType: the original TrueType layout model i.e. the "kern" table as 
currently defined in the OFF spec
b) OpenType: the OpenType layout model that relies on GSUB, GPOS, GDEF, 
BASE, JSTF
c) AAT: the Apple-made extensions to the TrueType layout model that rely 
on mort, morx, feat, extended kern, kerx etc.
d) Graphite: the SIL-made layout model
e) Microsoft MATH: mathematical layout model that relies on the MATH 
table along with OpenType Layout tables

[OFF/X] My proposal is that an OFF/X:2014 font:
1. MUST use the OpenType Layout model (-> describe more specifically)
2. MUST NOT contain the "kern" table
3. (?) MUST NOT contain any tables from the AAT, Graphite or Microsoft 
MATH layout models (-> list explicitly)

This certainly is a political decision, but since the CSS Fonts 3 spec 
explicitly relies on the OT Layout system for --font-feature-settings, I 
think it's the right call. Of course font vendors can continue to build 
fonts with other layout systems -- and web browsers can support them at 
their discretion. The main point is, however, that ALL web browsers 
should support AT LEAST OFF/X fonts. Whether a web browser supports 
anything else, is at the web browser maker's discretion.

== Choice of the Rendering Model ==

The way I see it, within SFNT, there are three major categories as how 
to past, current and future Rendering Models can be categorized:
* static vs dynamic glyphs
* monochrome vs color glyphs
* outline vs bitmap glyphs

Here's a rundown of examples of different more-or-less relevant 
Rendering Models and how they fit into each category. Each example 
describes where the glyphs are sourced from:
a) only the glyf table as described by OpenType spec version 1.6: static 
monochrome outline
b) only the CFF table as described by OpenType spec version 1.6: static 
monochrome outline
c) the glyf table plus Apple-defined fvar, gvar tables: dynamic 
monochrome outline
d) the CFF table as per OpenType spec version 1.2 or earlier plus from 
fvar, MMSD, MMFX tables: dynamic monochrome outline (this is now removed 
from the OpenType spec)
e) the bdat, bloc or EBDT, EBLC, EBSC tables: static monochrome bitmap 
(typically used in combination with (a))
f) the Apple-defined sbix table: static color bitmap (not published but 
supported in Mac OS X 10.7+ and iOS)
g) the Google-defined CBDT, CBLC tables: static color bitmap (published, 
some initial support in Chrome)
h) the Mozilla-defined SVG table: static (?) color outline (published, 
some initial support in Firefox)
i) the OpenType SVG WG proposal: dynamic (?) color outline (doesn't 
really exist yet, may embrace the Mozilla proposal)

[Note: My personal view is that one of the dynamic monochrome outline 
models ("MM" or "gvar") has great potential and should be resurrected. 
But that's a wholly another subject matter, on which I'll send another 
e-mail around, with the subject line "Idea: MM webfonts resurrection?".]

[OFF/X] My proposal is that an OFF/X:2014 font:
1. MUST use one of the static monochrome outline Rendering Models (glyf 
table only or CFF table only), as those are the only ones which are 
stable and widely supported.
2. MUST NOT use any other Rendering Model (-> list SFNT tables which are 
DISALLOWED).

== Specific recommendations per SFNT table ==

This is very draft, and should be widely debated.

* Disallowed tables: PCLT (-> more to be added)

* cmap table
1. MUST use Unicode as its only character encoding
2. If the font supports Unicode codepoints >U+FFFF, MUST NOT contain 
subtables other than PID 3 EID 10.
3. If the font only supports Unicode codepoints <U+FFFF, MUST NOT 
contain subtables other than PID 2 EID 1.
4. -> Some recommendations regarding the PUA with relation to OTL.

Effectively, all situations like cmap 3.0, cmap 1.0, cmap 0.3, cmap 4.x 
or cmaps 3.10 and 3.1 at the same time are DISALLOWED.

* post table
MUST use post table format 3.0.

* OS/2 table
1. MUST use version 4
2. fsSelection bit 7 must be =1.
3. fsSelection bit 8 must be =1 and the font's naming must be 
WWS-compatible.
4. fsSelection bits 1, 2, 3, 4, 9 must be =0.
5. -> Some recommendations for usWeightClass/usWidthClass fields, and 
the usWeightClass<250 mess should be cleaned up!

* name table
1. MUST NOT contain entries for PID/EID other than 3.1.
2. -> Some additional recommendations, which could be a bit "brave"

* OTL tables (GSUB, GPOS, JSTF)

** OTL script tags
1. MUST NOT use the script tags: beng, deva, gujr, guru, knda, mlym, 
orya, taml, telu
2. MUST use one of the tags specified in -> the appropriate list

** OTL language tags
1. MUST NOT use the language tags: DHV
2. MUST use one of the tags specified in -> the appropriate list

** OTL feature tags
-> DISALLOW some unreasonable feature tags which these days should be 
obsoleted (like mgrk(?))

* -> Something to be done with linespacing values in OS/2 and hhea

* -> Something for clients how to deal with redundant styling or 
linespacing data etc.

...and possibly many more recommendations which will make the OFF/X:2014 
format stricter, get rid of legacy stuff and eliminate as many 
redundancies as possible.

All-right... So that's that from me so far. Comments welcome :)

Best,
Adam

-- 

May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)

Received on Thursday, 20 June 2013 04:02:09 UTC