search

web-platform-tests / interop

web-platform-tests Interop project
https://wpt.fyi/interop
280 stars 28 forks source link

Emoji text rendering using non-system emoji fonts #569

Closed reinhart1010 closed 7 months ago

reinhart1010 commented 11 months ago

Description

Investigate things which may prevent web developers to include and use custom emoji fonts by using the @font-face and font-family CSS attributes. Some possible use cases include:

Rationale

Investigation Roadmap

The author of this proposal suggests that this investigation may produce CSS standards specific to text rendering. However, the general timeline may look like:

  1. Investigate rendering related to custom emoji fonts in different formats (monochrome, COLRv1, CPAL, SVG-in-OpenType, etc.)
  2. Fix existing issues related to emoji font overriding (like https://bugzilla.mozilla.org/show_bug.cgi?id=1845450)
  3. Discussing on making custom emoji fonts easier to implement using pure CSS
fantasai commented 11 months ago

https://drafts.csswg.org/css-fonts/#font-variant-emoji-prop also seems related

drott commented 10 months ago

@reinhart1010 - Thanks for the proposal, could you perhaps sharpen the intended outcomes or use cases a bit more?

Prefer to use a monochrome emoji font to improve contrast on specific website themes

When I read this, I am wondering:

  1. Are you looking for a CSS property to control which glyph form to choose in a hybrid font that contains color and monochromatic glyphs? Or do you observe implementation issues in UAs that ignore a @font-face declaration and font-family entry, go past those, and choose a system emoji font instead, as in https://bugzilla.mozilla.org/show_bug.cgi?id=1845450 which you're quoting?
  2. Would you like to see better emoji fallback? Browser providing their own reliable emoji fonts, in monochromatic and color versions, and better support for font-variant-emoji?

Introducing a custom emoji font, containing a subset of supported emoji, for theming/branding reasons

What obstacles do you observe currently when doing that?

Investigate rendering related to custom emoji fonts in different formats (monochrome, COLRv1, CPAL, SVG-in-OpenType, etc.)

What specifically would you like to investigate? What are blockers?

Discussing on making custom emoji fonts easier to implement using pure CSS

What are obstacles, other than the mentioned FF bug? What outcomes would you like to see in a "perfect world"?

reinhart1010 commented 10 months ago

Hi @drott, thanks for asking.

  1. Are you looking for a CSS property to control which glyph form to choose in a hybrid font that contains color and monochromatic glyphs? Or do you observe implementation issues in UAs that ignore a @font-face declaration and font-family entry, go past those, and choose a system emoji font instead, as in https://bugzilla.mozilla.org/show_bug.cgi?id=1845450 which you're quoting?

In this case I am looking for the @font-face implementation issues.

  1. Would you like to see better emoji fallback? Browser providing their own reliable emoji fonts, in monochromatic and color versions, and better support for font-variant-emoji?

I believe that the decision of emoji fallback mechanisms (specifically whether browser or OS vendors should introduce both color and monochrome emoji versions) could be a broad topic for vendors to discuss, and it's okay if vendors decided not to do so.

However, app developers should be able to set up fallbacks for emojis that are not supported in some operating system versions, akin to EmojiCompat for Android native app developers.

This also includes letting the web browser to know new or custom ZWJ sequences (to simplify this term for laypersons, let's call them as "ligatures"), like some of the emojis introduced on Emoji 15.1, so the web browser recognizes these ligatures to be rendered using the fallback emoji font, provided that some of the emoji characters may have been supported in the current system emoji font.

What obstacles do you observe currently when doing that?

There are some web browser quirks that prevent some specific emojis to render correctly, even when using a monochrome emoji font. In this case, the latest version of monochrome Noto Emoji is being loaded from Google Fonts, but this can be substituted into others including brand-specific emoji fonts.

Screenshot_20231024_143359_Firefox Beta.jpg Screenshot_20231024_143219_Chrome.jpg image
Firefox 119 on Android (see the Bugzilla report) Chrome 118 on Android (all emoji characters are rendered as expected) Safari on iOS 17 (some emojis are rendered blank)

Additionally, feel free to check https://reinhart1010.id/browser-test#modern-emoji where I've written the original test case for the Bugzilla report.

What specifically would you like to investigate? What are blockers?

Since there are multiple technologies that empower the ability to create emoji fonts, there may be cases for using specific emoji font for specific emoji formats. For example,

font-family: "System Emoji", "COLRv1 fallback", "SVG fallback", "CPAL fallback", sans-serif;

Let's say that, on a Windows 8 machine (which doesn't natively support emoji versions other than CPAL), the website contains an emoji that is not available in the system emoji, but are in every fallback emoji font sets. In this case, will the web browser correctly refer to the CPAL fallback, or just use the COLRv1 version just because the emoji character is supported in the COLRv1 fallback (even though it is guaranteed that Windows won't be able to render this font)?

The above case could be more simplified by defining emoji technology versions right in the @font-face, like

@font-face {
  font-family: "Fallback Emoji";
  src: url("/fonts/emoji-colrv1.woff2") format("woff2") emoji("colrv1"), url("/fonts/emoji-svg.woff2") format("woff2") emoji("svg"), url("/fonts/emoji-cpal.woff2") format("cpal") emoji("colrv1");
}
drott commented 10 months ago

Thanks for the additional feedback. I am still trying to extract what would be suitable for interop investigations, or signal of direction for future spec work.

In the helpful screenshots you're providing: Since you're providing a Noto Emoji full-set monochromatic emoji font, I see no reasons for the UA to mess with that. Both Firefox and Safari seem to have implementation issues there. For FF you already filed it, which make sense. Did you file one on bugs.webkit.org for Safari as well?

Let's say that, on a Windows 8 machine (which doesn't natively support emoji versions other than CPAL), the website contains an emoji that is not available in the system emoji, but are in every fallback emoji font sets. In this case, will the web browser correctly refer to the CPAL fallback, or just use the COLRv1 version just because the emoji character is supported in the COLRv1 fallback (even though it is guaranteed that Windows won't be able to render this font)?

I still have trouble understanding this part, for two reasons. A) Windows 8 is no longer supported by Chrome and Firefox (link), so I am not sure this works as a good example. B) The tech() function of the @font-face src: descriptor would already let you control which supported format would be selected? https://www.w3.org/TR/css-fonts-4/#font-face-src-parsing - but I have feeling I am not understanding the nuance of your intention here.

Note that in Chrome the level of font format support is generally independent of the underlying OS. We do support COLRv1 everywhere, not only on OSes that have support for it. That's a difference to Firefox, which to my knowledge, has some platform specific limitations.

So the second part of your requirements I am still not 100% clear on. What is it that you would specifically like to see solved there, separate from the implementation issues you listed higher up in your response.

reinhart1010 commented 10 months ago

First, I didn't have much time to report the WebKit issue (might report it by tomorrow), yet I was not aware about the tech() property and browsers abandoning Windows 8 for good. (Note that earlier versions of Windows 10 also only natively support CPAL emojis). In this case the CSS Font Level 4 spec seems to have covered most of my concerns, perhaps except two: the custom ZWJ/ligatures thing and dynamically subset the emoji webfont.

There may be some specific cases where developers wanted to include custom ZWJ emoji sequences for branding, and Microsoftʼs Ninja Cat is one well-known example. Adding custom sequences could also support backwards-compatibility, when an Emoji webfont contains newer Emoji standards who recognize new ZWJ sequences, too.

However, looking at that Firefox case, browser engines might not recognize these new or custom ZWJ sequences, because they hard-coded them or leave the OS (who also hard-coded the available set of sequences) to do the job. There's currently no standard way of declaring/managing that aside from implementing OpenType features and let the browser and OS decide the rest. Or just push users to download the latest web browser.

There might also be cases when web developers wanted to cherry-pick which parts of a webpage to be rendered using custom sequences/ligatures, and which one isn't (perhaps because of standarization concerns, like sending text messages across platforms). And in this case, OpenType stylistic sets and font-feature-settings CSS property might not work great, as many developers commonly places Emoji fonts right after other font types (e.g. the system font stack, system-ui, ..., sans-serif, emoji) which could also trigger the unwanted stylistic sets of the preceeding font families.

Speaking of subsetting, I've aware of unicode-range in @font-face. But not all emojis are meant to be loaded in a single webpage, so adding a mechanism to detect and download needed emojis could potentially improve performance (in terms of network traffic).

As a comparison, JavaScript-based libraries like Twemoji fetches emojis as PNG images only if the emoji is actually being used in the website. If the webpage dynamically adds another different type of emoji, the web browser simply download the left ones.

This could be an interesting area to investigate, as existing "webfont best practices" might not be a good solution for emojis. WOFF requires the font files to be compressed, so it is not possible to download specific portions of a WOFF file to load specific emojis.

drott commented 10 months ago

the custom ZWJ/ligatures thing

I am not quite sure what expectations you have for web specs to address this. This issue touched upon emoji exchange, and RGI and what Unicode TR#51 defines as compatible emoji sequences.

Chrome supports custom ZWJ sequences if you're inclined to use them. For sure, they have interop issues. If FF hardcodes font usage and that's breaking custom ZWJ sequences that is still "just" an implementation bug, not a standards issue.

and dynamically subset the emoji webfont.

Dynamic subsetting is being developed in the web fonts working group, compare: https://w3c.github.io/IFT/Overview.html https://lists.w3.org/Archives/Public/public-webfonts-wg/

unicode-range does work for subsetting the emoji font into unicode-range segments, as an example, Google Fonts' delivery of Noto Color Emoji works that way. https://fonts.googleapis.com/css2?family=Noto+Color+Emoji

drott commented 10 months ago

CC @anthrotype

jgraham commented 7 months ago

Thank you for proposing Emoji text rendering using non-system emoji fonts for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

We believe this proposal is too broad, and that as such, Interop 2024 is not the right venue to do this investigation.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.