-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fill out sections for New Font Request and Patch Font Request. #3
Conversation
A patch font request is sent by a client to add data for additional codepoints to its font. Patch font | ||
requests are sent via HTTP and can only use the POST method. The request body is a single | ||
<a href="#PatchRequest"><code>PatchRequest</code></a> object encoded via CBOR. The fields of | ||
should be set as follows: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect the reference to an object (PatchRequest?) is missing in this sentence.
The set of codepoints that the clients would like added to it’s copy of | ||
the font. Specified using indices obtained by applying <code>codepoint ordering</code> | ||
[[#codepoint-reordering]] to the set of codepoints. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest that we should maintain a clear differentiation between codepoints and indices, and not use these terms interchangeably. Indices are commonly associated with glyph IDs while codepoints are units of text content that, depending on a font used, can be associated with more than one glyph ID (contextual forms, stylistic sets, etc.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reworded this slightly to try and make it more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from my line-specific comments, one general topic we should keep in mind is the manifestation of requirements (i.e. using "must" vs. "MUST" according to https://tools.ietf.org/html/rfc2119). Capitalized MUST is what should be used to communicate a requirement of the spec, but there is a caveat - every MUST in the spec must be testable and eventually covered by a corresponding conformance test (as opposed to using lowercase must as a unit of English language). This is why we should be mindful about the language we use when differentiating the spec requirements from common-sense mandates or external constraints.
As discussed we'll leave these lower case throughout. I checked over all usages of must in the spec so far and removed a few that weren't really needed. |
No description provided.