Skip to content
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

Merged
merged 7 commits into from
May 6, 2021

Conversation

garretrieger
Copy link
Contributor

No description provided.

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:
Copy link
Contributor

@vlevantovsky vlevantovsky Apr 19, 2021

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.

Copy link
Contributor

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.).

Copy link
Contributor Author

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.

Copy link
Contributor

@vlevantovsky vlevantovsky left a 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.

@garretrieger
Copy link
Contributor Author

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.

@garretrieger garretrieger merged commit e25e3c8 into main May 6, 2021
@garretrieger garretrieger deleted the request_response branch May 6, 2021 21:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants