search

commontype-standard / commontype

Annotated OpenType Specification
Other
23 stars 1 forks source link

Invite existing projects #14

Open twardoch opened 3 years ago

twardoch commented 3 years ago

We should encourage existing projects to move to the CT umbrella, esp. @n8willis

twardoch commented 3 years ago

Also @pomax did https://github.com/Pomax/the-cff-table which may be better than what we have

Pomax commented 3 years ago

man, I had forgotten about stubbing that... but I do like the idea behind this repo. Any aim towards showing "correct" vs. "incorrect" implementations for the various things?

twardoch commented 3 years ago

I'll write up the goals but in short it's, in my view:

  1. Provide an accessible, liberally licensed variant of the text of the SFNT-based specifications (OpenType, TrueType, OFF), which reflects the original specs as much as possible.

  2. Improve the editorial quality of the spec: unify terminology, remove conflicting language, bring in real-life knowledge about existing implementations and their quirks.

  3. Create a platform where interested parties can annotate and comment the spec.

  4. Devise a plan for a comprehensive overhaul: split the text if needed into a mandatory formal portion and more freeform annexes or annotations.

  5. Provide a platform for proposing functional additions/extensions to the format.

  6. Provide opportunities to submit the additions/extensions to the more formally-driven bodies (OpenType, ISO OFF), so the owners of these specs can adopt the work of the CommonType community.

  7. Give some implementers the chance to implement CommonType in addition to or as an alternative to the other formats.

  8. Importantly: get rid of legacy baggage. Deprecate unneeded stuff or move it to archival content (like 'kern' table, the MacOS classic 'name' IDs and all sorts of antiquated stuff). Slim down, not just add.

In my personal view, unversioned CommonType should be a living "book" but then there should be versioned releases that capture specific reality.

Some years ago, someone at ATypI asked "what would you like to see in OpenType 2.0"? I said "no new functionality, but a real, proper spec".

twardoch commented 3 years ago

Re 7: Work with developers on conformance suites, and create versioned profiles of the spec so that implementers can actually build tests and implement towards realistic goals. Very sketch model of that might be the PDF/X or PDF/A formats, which are stricter subsets of PDF.

twardoch commented 3 years ago

In short: clean up house, remodel, then extend. And live while doing it!

twardoch commented 3 years ago

@Pomax I’ve incorporated by thoughts into https://github.com/commontype-standard/commontype-standard.github.io/blob/source/README.md

Pomax commented 3 years ago

I love it, a living spec in the same vein as HTML5 will be an amazing resource for both new and seasoned engineers in the typography space.

n8willis commented 3 years ago

The opensource-opentype feature documentation is definitely something that could move here, as-is. The original intent for that project was to focus on more UI/UX patterns and issues for FOSS projects interested in implementing support — it just started with feature documentation since that was a necessary step zero. Momentum for the longer-term parts of that dwindled for unrelated reasons, but then again the landscape has changed quite a bit since then anyway.