The Future: Versioning, format++, editors drafts, etc

[davelab6]

Adjacent to #8 (comment), I see that beyond documenting what is already implemented in a more satisfactory way, there is also a need for a project to collate and pool public proposals for future iterations of the Common Text Stack.

This is, I think, really a versioning question: If CommonType is better (best) docs for the current common implementation, how should it deal with both uncommon implementations (eg MATH, kerx, or say soon I can imagine that CPALv1 would be implemented first in freetype and not yet anywhere else for a while..?) and with (speculative) future versions? Something like the W3C spec process with an 'editors draft', where anyone can fork their own, eg I myself personally maintain a "davelab6 Editor's Draft branch"?

(While it might be nice for CommonType Standard v1.x.x numbers to match OpenType v1.x.x numbers, a simple lookup table in the appendix would suffice for that I think?)

Anyway, there are certainly plenty of uncollated public proposals floating around:

I've had or been involved in a few runs at this in the past:

https://meta.wikimedia.org/wiki/Future_Global_Font_Format_Requirements

About 5 years ago I started that page to collect some of these ideas in a 'vendor neutral location.' Since then the 'social knowledge' around using Github to collaborate has exponentially grown, which is I guess why Github is now owned by Microsoft, but MS is keeping it "at arms length" and I think it can still be considered a vendor neutral space for the Common Text Stack community.

https://github.com/microsoft/OpenTypeDesignVariationAxisTags

Back in 2017, folks at Microsoft set up a fully public MIT repo for pooling proposals for VF axes to be registered in the OT spec.

https://github.com/OpenType

I just wrote "Maybe 1 year ago" LMAO but I see in https://github.com/OpenType/opentype-next/commits/master that it was only November last year. Anyway as explained in OpenType/opentype-next#6 we do need somewhere to pool these things, and there's a proposal

https://github.com/googlefonts/colr-gradients-spec/

In February, Google published a proposal for a new version of COLR/CPAL that adds gradients, and it seems to me personally that since that color font format was designed according to the principles originally intended by the TrueType spec authors, it "just works" with the OT 1.8 variations tables - color variable fonts!

RoboCJK

BlackFoundry is developing publicly a large RoboFont extension for designing CJK fonts using the varLib mutation model, and has proposed how that design-time use of nested var components could be compiled into a format++

https://github.com/BlackFoundryCom/black-robo-cjk/blob/master/ProposalForDeepComponent.md

Mailing lists

There are proposals for XVAR and ZVAR tables floating around in some mailing lists.

https://typedrawers.com

There was more context on the OpenTypeDesignVariationAxisTags repo at https://typedrawers.com/discussion/2441/otvar-next-step-for-variable-fonts-process-for-registering-design-variation-axes and there are probably other format++ ideas floating around in TD, perhaps eveen in Typophile.

Twitter

Amazingly/sadly, there are some ideas which may be only publicly documented in tweets. While this is also on some mailing list, one example would be the proposal to add cubic bezier support to glyf table (which was mentioned recently @ https://twitter.com/simoncozens/status/1274815547151208451 & https://twitter.com/TiroTypeworks/status/1274761724030185472) and this may be a good case study as it is not without controversy (https://twitter.com/Litherum/status/1274768212144480260)

[simoncozens]

I was kind of envisaging that potential changes to CommonType are expressed as issues/PRs here. This gives you a central place for open discussion. We can require that PRs which add new functionality must include examples and links to an implementation.

I also agree with the editor's draft idea (in fact I'm already calling what we have at the moment an "editor's draft") - once there's agreement on a version then you remove the "this is an editor's draft" boilerplate and tag that as a release. Matching OT version numbers just seems like the right thing to do - until we start diverging, which I suspect will happen sooner rather than later once this text is current to 1.8.

We also need to spec out deprecation procedures, as I am hoping that the "next" edition starts to deprecate a lot of cruft. And a future feature roadmap would be helpful.

Yes, know about all the proposals floating around, and I have a few of my own too. :-)

[simoncozens]

In terms of introduction/deprecation procedures, specification of tables and other data structures should carry metadata about

• What version of the spec they were introduced (this could be the Version number in the table header going forwards).
• What version they become mandatory for compliance.
• What version they were deprecated.
• What version they will be removed.

e.g.

JSTF

• Introduced: 1.4
• Status: Optional
• Deprecated: 1.9
• Will be removed 1.10

Another thought is that year-based release cycles may be more useful for planning.

[simoncozens]

I think we need to essentially maintain three branches of CommonType in parallel:

• CommonType now is our improved documentation of current practice. (OT 1.8 equivalent)
• CommonType next is our near-term improvements. (OT 1.9 equivalent)
• CommonType future is long-term improvements. (OT 2.0 equivalent)