Review feedback wrt making spec more readable

[rsheeter]

Per f2f at TPAC, Garret or Chris volunteered to review https://docs.google.com/document/d/1MAuXOJr7FQevxTg9NhaBOB5Y45Ak9Ad3SRyKDfND8SY/edit?usp=drivesdk and see if any edits made sense.

[svgeesus]

The suggested changes to the abstract make a lot of sense to me.

[svgeesus]

A lot of the comments seem to assign great importance to the filename, Overview.html which is mistaken. The convention at W3C comes from the CERN convention (linking to a directory gives you Overview.html rather than a directory listing, if one exists) rather than the NCSA convention (the magic filename is index.html).

So "too detailed for an overview" is understandable but wrong. This is the whole spec, not just an overview.

[svgeesus]

Speculation: I wonder if we should just have a hook to provide a url to the whole font? - to go offline fetch whole-font-uri and call it a day.

Earlier drafts talked about post-processing an original font for produce the subset font and the set of patches. That is one way, but not the only way. There might not be an original font at all (as an OpenType font); instead an font authoring tool might export an IFT-encoded OpenType font plus the set of patch files.

So I think we are avoiding the term original font or whole font, except perhaps as an illustration of one workflow.

[svgeesus]

In addition, since an IFT-encoded font is an OpenType font this means that:

• WOFF1 can be freely applied
• WOFF2 can be applied, subject to certain conditions

so the authoring tool mentioned above might well export

• a WOFF2-encoded IFT font
• the set of patch files

and again, the OpenType IFT font might not actually exist as a separate entity

[svgeesus]

The suggested changes to the abstract make a lot of sense to me.

Pull request for better abstract #246

[svgeesus]

The definition of incremental font needs to be more clearly established. We say it's an OT font reformatted with new tables and and then in "At a high level…" we refer to an "initial font file" that seems to be what we just referred to as an incremental font in the beginning of the overview. And then a Font Subset ambushes us in an alley.

Fair criticism. We overload the term incremental font, because the initial font file is an incremental font file, but also a partially-expanded font is also an incremental font file. And the initial font file is a font subset, but a non-incremental static subset is also a font subset. The difference is that one can be expanded and the other can not.

We do define font subset. I think we should use that as the base definition, then define other terms from it:

Static subset

A font subset which cannot be expanded.

Incremental font

A font subset which, together with a set of patch files, can be expanded to produce a larger subset.

Initial font

An incremental font which constitutes the smallest subset. This is what a stylesheet links to.

[svgeesus]

I see we also use fully expanded non-incremental font.

And, sadly, the definition of font subset uses the term original font. I think we are asseting that fully expanded non-incremental font. is functionally identical to original font.

Each time I read these introductory sections, I imagine diagrams in my head. The spec would be more readable if those diagrams existed.