Meta proposal: font demos & typography demos

[davelab6]

I would like to suggest here that each proposal should be required to include a working demo font, with source files and build script, and a working web typography demo that uses it.

Then "regular people" can comment on the actual usage utility of the proposals, and type designers can see how to actually build fonts with such axes.

[tiroj]

Working demo fonts and implementation examples make great sense for any new axis, whether they're being proposed for registration in the spec or not. I think we need to be clear about the latter question, though, because registration implies not just being able to make a font and demo it, but having interoperable behaviour defined for software, which I think is why no new axes beyond the initial five have been registered yet.

In Berlin, I suggested to Peter and others that the whole way we've approached new axis documentation has been wrong, because we've set up a formal registration proposal process as basically the only way into the field, so people are trying to write proposals as a first step, are not being able to define the software interoperability side, and then getting frustrated that their proposals are not proceeding to registration. So I'd like to see this GitHub restructured so that formal registration proposals are a last step rather than a first step, and instead we have a sandbox/playground for demo'ing new axis ideas as Dave suggests, inviting comment on utility, discussion of possibilities for interoperability, and then formal proposals for registration for those axes that need or would benefit from registration (bearing in mind that not all axes need to be registered, and that interoperability at the font level — i.e. different fonts from different foundries sharing axis tags, scales, and implementation — doesn't necessarily require registration, only open documentation).

[davelab6]

not all axes need to be registered, and that interoperability at the font level — i.e. different fonts from different foundries sharing axis tags, scales, and implementation — doesn't necessarily require registration, only open documentation

I think this is more clearly phrased as:

Microsoft is the only official OpenType axis registrar, since they are the single public-facing owner of the OpenType Specification. But while interoperability at the font level — i.e. different fonts from different foundries sharing axis tags, scales, and implementation — requires registration, anyone can assert they are an unofficial axis registrar and provide public documentation of the axes that they register (aka recognize.)

For example, the W3C is the only official owner of HTML, but when the W3C was not meeting the needs of its browser stakeholders, they set up the WHAT-WG organization to develop 'unofficial' HTML standards without the W3C, until the W3C was ready to meet their needs.

[davelab6]

not being able to define the software interoperability side

Has any proposal done this to your satisfaction, John? I guess no :)

I wonder if you could provide a first draft of something that would, for any of the existing proposals, as I am not exactly sure what you mean =)

[tiroj]

But while interoperability at the font level — i.e. different fonts from different foundries sharing axis tags, scales, and implementation — requires registration, anyone can assert they are an unofficial axis registrar and provide public documentation of the axes that they register (aka recognize.)

For now, at least in this forum, I prefer to reserve the term registration for formal inclusion in the OpenType Design-Variation Axis Tag Registry since it's OpenType variable fonts that we're talking about. But the notion that anyone can document how they and others make and use axes is certainly the case, and that documentation could be gathered together in one place, and so long as its identity and nature weren't confusable with the OT spec registry, you could call it whatever you like.

The parallel that comes to mind is something like agreement of different parties to use a set of PUA codepoints in some particular way, thereby providing interoperability between some fonts and possibly some software, but without any implication that this use is part of the Unicode Standard and therefore without any expectation of interoperability that involves conformance with the Standard.

[tiroj]

Has any proposal done this to your satisfaction, John?

I'm not the one who needs to be satisfied. :)

See what I wrote above regarding the registration process. I've come the conclusion that it was wrong-headed to frame this process in terms of the first step being submission of a formal proposal to register an axis. So I'm going to decline your invitation to attempt to draft a proposal that would satisfy what seem to me the kind of criteria that registration implies (criteria of standardised text layout interoperability), because I don't think I as a font maker should have to do that.

See also what I wrote a few days ago regarding the initial five registered axes and how they relate to pre-existing text layout functionality. These were all defined by a bunch of text layout engineers and font file format experts sitting around a table. And I kind of think that's probably how any other variation axes will end up getting registered. If any end up getting registered.

As you may gather, I'm somewhat less than optimistic about any axis proposals proceeding to registration under the current procedure and in the absence of existing layout functionality that can be mapped to variable font space. Instead of layout providing the model for the axes, we're looking at trying to define axes in a way that might attract layout engineers to implement. It's the cargo cult model of software standardisation.