[macOS] System emoji font is not accessible
Created attachment 311908 [details] Patch
Created attachment 311909 [details] Patch
Comment on attachment 311909 [details] Patch Attachment 311909 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/3864950 New failing tests: fast/text/system-emoji-font.html
Created attachment 311910 [details] Archive of layout-test-results from ews100 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews100 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 311909 [details] Patch Attachment 311909 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/3864954 New failing tests: fast/text/system-emoji-font.html
Created attachment 311911 [details] Archive of layout-test-results from ews107 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Comment on attachment 311909 [details] Patch Attachment 311909 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3864973 New failing tests: fast/text/system-emoji-font.html
Created attachment 311913 [details] Archive of layout-test-results from ews123 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews123 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.5
Comment on attachment 311909 [details] Patch Attachment 311909 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/3865126 New failing tests: fast/text/system-emoji-font.html
Created attachment 311914 [details] Archive of layout-test-results from ews117 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews117 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 311932 [details] Patch
<rdar://problem/31639090>
Created attachment 311936 [details] Patch
Given we expose the system font to the web, why wouldn't we want to expose the system emoji font to the web?
Comment on attachment 311936 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=311936&action=review > Source/WebCore/ChangeLog:3 > + [macOS] System emoji font is not accessible In the accessibility sense or the "can't be used by web pages" sense?
Why can't this happen automatically if the font specified is -apple-system or system-ui (also maybe -apple-system-monospaced-numbers)?
(In reply to Sam Weinig from comment #14) > Given we expose the system font to the web, why wouldn't we want to expose > the system emoji font to the web? I haven't received any requests from web authors to make this available on the Web. Because this is being created specifically for a native app, it seems best to be cautious. I'd prefer not to add to the surface area of things we need to support forever, if it's possible not to. If you think we should make this available on the Web, I'd be happy to do that. (In reply to Sam Weinig from comment #16) > Why can't this happen automatically if the font specified is -apple-system > or system-ui (also maybe -apple-system-monospaced-numbers)? It does happen automatically in this situation. However, the cost is a round trip to fontd for each emoji character to be looked up. The goal of this patch is to improve performance by adding a keyword to the native app's font fallback list. Perhaps this patch should include a performance test.
(In reply to Myles C. Maxfield from comment #17) > (In reply to Sam Weinig from comment #14) > > Given we expose the system font to the web, why wouldn't we want to expose > > the system emoji font to the web? > > I haven't received any requests from web authors to make this available on > the Web. Because this is being created specifically for a native app, it > seems best to be cautious. I'd prefer not to add to the surface area of > things we need to support forever, if it's possible not to. > > If you think we should make this available on the Web, I'd be happy to do > that. > > (In reply to Sam Weinig from comment #16) > > Why can't this happen automatically if the font specified is -apple-system > > or system-ui (also maybe -apple-system-monospaced-numbers)? > > It does happen automatically in this situation. However, the cost is a round > trip to fontd for each emoji character to be looked up. The goal of this > patch is to improve performance by adding a keyword to the native app's font > fallback list. > > Perhaps this patch should include a performance test. I'll upload a new patch with a performance test that describes this stuff in the ChangeLog (as well as making the title of the bug more clear).
Created attachment 311945 [details] Patch
Created attachment 311946 [details] Patch
(In reply to Myles C. Maxfield from comment #17) > (In reply to Sam Weinig from comment #14) > > Given we expose the system font to the web, why wouldn't we want to expose > > the system emoji font to the web? > > I haven't received any requests from web authors to make this available on > the Web. Because this is being created specifically for a native app, it > seems best to be cautious. I'd prefer not to add to the surface area of > things we need to support forever, if it's possible not to. > > If you think we should make this available on the Web, I'd be happy to do > that. Another reason is that, once I implement system-ui correctly (aka honoring the Core Text font fallback mechanism inside the system font), the need for this will go away. However, implementing this fallback correctly shouldn't be done now.
Created attachment 311947 [details] Patch
(In reply to Myles C. Maxfield from comment #17) > (In reply to Sam Weinig from comment #14) > > Given we expose the system font to the web, why wouldn't we want to expose > > the system emoji font to the web? > > I haven't received any requests from web authors to make this available on > the Web. Because this is being created specifically for a native app, it > seems best to be cautious. I'd prefer not to add to the surface area of > things we need to support forever, if it's possible not to. > > If you think we should make this available on the Web, I'd be happy to do > that. > > (In reply to Sam Weinig from comment #16) > > Why can't this happen automatically if the font specified is -apple-system > > or system-ui (also maybe -apple-system-monospaced-numbers)? > > It does happen automatically in this situation. However, the cost is a round > trip to fontd for each emoji character to be looked up. The goal of this > patch is to improve performance by adding a keyword to the native app's font > fallback list. > > Perhaps this patch should include a performance test. This seems like a bad solution. We should not make each application know they need to do this just to get better performance. Perhaps you can explain more clearly why this needs to be specified by the application and can't happen automatically.
(In reply to Sam Weinig from comment #23) > (In reply to Myles C. Maxfield from comment #17) > > (In reply to Sam Weinig from comment #14) > > > Given we expose the system font to the web, why wouldn't we want to expose > > > the system emoji font to the web? > > > > I haven't received any requests from web authors to make this available on > > the Web. Because this is being created specifically for a native app, it > > seems best to be cautious. I'd prefer not to add to the surface area of > > things we need to support forever, if it's possible not to. > > > > If you think we should make this available on the Web, I'd be happy to do > > that. > > > > (In reply to Sam Weinig from comment #16) > > > Why can't this happen automatically if the font specified is -apple-system > > > or system-ui (also maybe -apple-system-monospaced-numbers)? > > > > It does happen automatically in this situation. However, the cost is a round > > trip to fontd for each emoji character to be looked up. The goal of this > > patch is to improve performance by adding a keyword to the native app's font > > fallback list. > > > > Perhaps this patch should include a performance test. > > This seems like a bad solution. We should not make each application know > they need to do this just to get better performance. Perhaps you can explain > more clearly why this needs to be specified by the application and can't > happen automatically. I could special-case the combination of system-ui and emoji characters in lookupFallbackFont(), but it would still require some opt-in because semantics would be changed. Any characters that exist in both the emoji font as well as any other item in the Core Text fallback list (like ♀ and ♂) would get a different font. Or, I could guard this special-case on characters that I know are only in the emoji font, but I don't think we want to be in the business of listing characters that have to match another part of the system. Doing this special-casing would effectively be moving the emoji font to the top of the fallback list (to just behind San Francisco). It seems to me that, if the client is going to have to do some opt-in, listing the emoji font in the font-family list is the most descriptive way of describing what is going on. If you think these other alternatives are better, I'd be happy to implement them.
Created attachment 311950 [details] Patch
(In reply to Myles C. Maxfield from comment #24) > Doing this special-casing would effectively be moving the emoji font to the > top of the fallback list (to just behind San Francisco). It seems to me > that, if the client is going to have to do some opt-in, listing the emoji > font in the font-family list is the most descriptive way of describing what > is going on. My point is that the client should not need to opt in. It seems you mentioned the solution that would work without requiring an opt in, "honoring the Core Text font fallback mechanism inside the system font". If that is the correct solution, we should do that. It doesn't seem like a good tradeoff to add SPI for a performance problem we can solve in our own code.
(In reply to Sam Weinig from comment #26) > (In reply to Myles C. Maxfield from comment #24) > > Doing this special-casing would effectively be moving the emoji font to the > > top of the fallback list (to just behind San Francisco). It seems to me > > that, if the client is going to have to do some opt-in, listing the emoji > > font in the font-family list is the most descriptive way of describing what > > is going on. > > My point is that the client should not need to opt in. It seems you > mentioned the solution that would work without requiring an opt in, > "honoring the Core Text font fallback mechanism inside the system font". If > that is the correct solution, we should do that. It doesn't seem like a good > tradeoff to add SPI for a performance problem we can solve in our own code. Okay, I'll work on that instead.