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

Anne's feedback re: Non-goals and alternative approaches #20

Open
chasephillips opened this issue Aug 21, 2019 · 4 comments · Fixed by inexorabletash/font-table-access#10

Comments

@chasephillips
Copy link
Collaborator

@annevk writes at w3ctag/design-reviews#400 (comment):

The various non-goals seem like they would make it rather hard for alternative approaches to doing fonts to enter the market or for smaller players with alternative approaches to compete. If even on the same platform the data you get back depends on the implementation it's highly likely sites will code toward a single implementation.

Hi Anne, thank you very much for your feedback! I'd like to understand it better.

Can you please clarify which of the explainer's non-goals you're referring to and why that is likely to introduce problems?

@annevk
Copy link

annevk commented Aug 21, 2019

Normalize differences in processed font tables across browser implementations.

If user agent A has a lot of market share and uses algorithm 2 and user agent B has few market share and uses algorithm 5, sites might be inclined to only account for A if the cost of doing the normalization client-side is too high (or not of interest).

Generally the web platform tries very hard not to have implementation-defined behavior and whenever we do it's usually a problem.

chasephillips referenced this issue in inexorabletash/font-table-access Sep 4, 2019
Also, clarify non-goals to ensure that the expected output, while
possibly altered by the font processing in a browser, is still
expected to continue to be in a valid OpenType format.

Fixes https://github.com/inexorabletash/font-table-access/issues/6.
@chasephillips
Copy link
Collaborator Author

Hi Anne, thanks again for your feedback. The non-goal you're referring to is meant to give browsers necessary flexibility in their font sanitizer systems and not to introduce possibly non-standard table data formats.

While we can't specify the font sanitizer algorithms in use by different browsers, we can make it clear that the output of the font table access APIs itself is expected to be in a valid OpenType format.

I've posted inexorabletash/font-table-access#10 to make these changes. I'd like to hear if this change addresses your concerns, either in part or in whole. Feel free to post comments on the PR directly if you have suggestions. Thanks!

@annevk
Copy link

annevk commented Sep 4, 2019

I don't think anything apart from canonicalized/normalized addresses the concern expressed above.

chasephillips referenced this issue in inexorabletash/font-table-access Sep 4, 2019
Also, clarify non-goals to ensure that the expected output, while
possibly altered by the font processing in a browser, is still
expected to continue to be in a valid OpenType format.

Fixes https://github.com/inexorabletash/font-table-access/issues/6.
inexorabletash referenced this issue in inexorabletash/font-table-access Sep 4, 2019
Also, clarify non-goals to ensure that the expected output, while
possibly altered by the font processing in a browser, is still
expected to continue to be in a valid OpenType format.

Fixes https://github.com/inexorabletash/font-table-access/issues/6.
@chasephillips
Copy link
Collaborator Author

@chasephillips chasephillips reopened this Sep 5, 2019
@inexorabletash inexorabletash transferred this issue from inexorabletash/font-table-access Mar 24, 2020
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 a pull request may close this issue.

2 participants