RE: Proposal: OFF/X

Hello WG,

Speaking with my WG chair hat on (and not as Monotype representative whose views may differ substantially :):

I suggest that we should discuss this in details (either during the conference calls or at the F2F or both) but here are my first impressions on this proposal:

- the idea to define a profile of OFF that could be optimized for web font usage is interesting and definitely deserves further consideration, however
- An attempt to develop a web font profile should in no way present obstacles to web font adoption (we are still too early on an adoption curve and any disruption may have a profound effect).
- I would not want the development of a web font profile to be directly connected to the development of a new WOFF 2.0 container format. I believe it is a benefit to keep the container as generic as possible, something that can be used for any existing or future flavors of SFNT-based fonts.
- Last, but not least - don’t forget that the scope of our activities is determined by a WG charter, and that any new activity that deviates significantly from the existing charter [1] needs to be approved according to the W3C process. (This is a necessity considering the W3C RF policy.)

Let's talk more about it at our telcon tomorrow.

Cheers,
Vlad

[1] http://www.w3.org/2012/06/WebFonts/charter-2012.html



> -----Original Message-----
> From: Adam Twardoch (List) [mailto:list.adam@twardoch.com]
> Sent: Thursday, June 20, 2013 12:02 AM
> To: public-webfonts-wg@w3.org
> Subject: 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 Tuesday, 25 June 2013 20:22:24 UTC