Open chasephillips opened 5 years ago
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.
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 https://github.com/inexorabletash/font-table-access/pull/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!
I don't think anything apart from canonicalized/normalized addresses the concern expressed above.
Re-opening based on https://github.com/inexorabletash/font-table-access/issues/6#issuecomment-527773005.
@annevk writes at https://github.com/w3ctag/design-reviews/issues/400#issuecomment-522934738:
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?