A new project name?
lianghai opened this issue · 11 comments
Certainly not a critical issue for now, but, just saying, with this current name, “OpenType shaping documents”, it’s pretty awkward to refer to this project, because it sounds quite official and general.
For example, in the type designer and font developer oriented Indic shaping documentation I’ve been drafting recently, I had to avoid emphasizing the “OpenType shaping documents” name with this workaround:
It is a long-standing problem that the official OTL script development specifications do not accurately reflect what shapers actually do, due to being generally incomplete and outdated. The work-in-progress project n8willis/opentype-shaping-documents is a major community effort to address the need of a complete, developer-oriented documentation for OTL shapers.
That is true, placing it at the beginning of the phrase ("OpenType shaping documents") makes it sound like it comes from OpenType (Microsoft), perhaps placing it at the end ("Complex shaping in OpenType") makes it sound more like an observation made by others?
So it seems like there are two (at least) issues you're identifying here:
- Does the project name sound too "official" and cause confusion?
- Is the project name clear enough that the material documents shaping-engine implementation behavior?
[Agree?]
On (2), I do think you're right; more on that below. On (1) I'm less certain; I don't know if I am convinced there's a way to avoid using "OpenType" without the result being way more confusing, and I think we can be clear about this being an external / non–MS-Adobe-Apple effort with other messaging & comms. Like the short description line and README / intro text. And the account name used (mine, at least presently, not some formal org).
As for (2), I will say that I initially tried to pick a really informal project name, intentionally, avoiding terms like "specification" and "standard" and actually avoiding "OTL" and its variations. Partly that to avoid (1) confusion, of course, but it was also because initially we were not totally sure how implementation-specific it was gonna end up being. It's gotten pretty detailed from the implementer's POV, but the scope and focus has really emerged along the way.
So, for the future, we might consider changing to something that mentions shaping engines or 'implementation' or something along those lines. But for now, I think we ought to just keep this issue open to collect input (and brilliant suggestions, even), while tabling actual renames for later. That's where I come down on it, anyway.
That's a good point about being from a shaping implementation point of view, as contrasted with Liang Hai's work for type designers and font developers: https://github.com/typotheque/text-shaping
By the way I am planning on putting together a small fontspec site to catalog all of these different efforts and other related technical documentation and tools.
The placeholder site is up with links to the specs we have been consulting so far:
After some unsupervised quarantine-speculation time, I am going to add a couple of hypothetical names as individual comments below, and over time we can see if any of them see emergent community support....
"OpenType Layout Implementers' Standard"
"OpenType Layout Common Implementation"
An Implementation Guide for OpenType Shaping
Text Shaping in OpenType: A Detailed Specification
OpenType Layout Explained
Pinning this now because, in concert with attaching a license, it becomes rather important.
I'm not sure that everyone in the Microsoft camp would even approve using "OpenType Layout" anywhere in a project name, even if we somehow make it clear that it's a reference, not a trademark claim of its own.
I did add a clarification of the OpenType and Unicode trademarks themselves in #157 to hopefully be more direct about that. But it would be best to hear from anyone who knows from "inside" or who has dealt with a similar case in the past.
Perhaps most directly, the ISO spec calls it "Open Font Layout" ... which isn't bad.
However, since there is a lot of fallback & legacy assurance involved in these docs, "Open Font Shaping" or "Open Text Shaping" might make the distinction between "the docs" and "the ISO spec chapter 6" better.
Regardless, I think it would still be acceptable to refer to OpenType, Unicode, and other things (AAT, Graphite, etc.) within the text as they arise in the discussion. I can imagine a future in which some other pieces are well-supported enough in Allsorts and Harfbuzz that people would want them documented together even if they're out-of-scope for the ISO, but it is most important to be clear in the name of the project.
"Open Font Shaping" or something along those lines that includes "Open" and "Font" but not "OpenType" sounds good to me.