F43 Change Proposal: Use COLR for Noto Color Emoji (system-wide)

Use COLR for Noto Color Emoji

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

The Noto Color Emoji fonts have released some new files with the COLRv1 format. The COLRv1 format is a color scalable font compared with the previous color bitmap fonts.

:link: Owner

:link: Detailed Description

The new Noto Color Emoji font uses the new COLRv1 format. The COLRv1 format provides the color scalable emoji glyphs with smaller file size.

:link: Feedback

:link: Benefit to Fedora

This new font format provides better scalable color emoji rendering results and smaller file size.

:link: Scope

  • Proposal owners: google-noto-emoji-fonts

  • Other developers:

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

The Noto Color Emoji font will switch to use COLRv1 font format.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? Y/N

:link: How To Test

After upgrading to Fedora 43, the new color scalable emoji fonts will replace the old color bitmap emoji font. Please open some documents or web pages which contain the emoji character sequence to check the emoji rendering results.

:link: User Experience

The new scalable font format should have better or similar rendering results compared to the old bitmap font format.

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: If the new font format has some issues with some applications, plan to provide another google-noto-color-bitmap-emoji-fonts sub package for compatibility.
  • Contingency deadline: Fedora Beta Freeze
  • Blocks release? No

:link: Documentation

Spec: COLR - Color Table (OpenType 1.9.1) - Typography | Microsoft Learn

Last edited by @amoloney 2025-04-16T14:26:40Z

Last edited by @amoloney 2025-04-16T14:26:40Z

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

Speaking of the contingency plan, is google-noto-color-bitmap-emoji-fonts provided only when there is any issues reported against COLRv1 format? not just reverting this change or keep google-noto-color-emoji-fonts for bitmap font like currently we have and provide another sub-package for COLRv1 instead?
It may depends how it is serious but it sounds to me like not for the contingency plan because google-noto-color-emoji-fonts still points to COLRv1. it says you do this change anyway.

Right, we can revert the google-noto-color-emoji-fonts package and provide another package, if the potential issue affects many components. If the potential issue only affects a few components, we will just simply add another google-noto-color-bitmap-emoji-fonts sub package.

Please reflect it to the Change page. and how does that google-noto-color-bitmap-emoji-fonts work? Basically they both provide the same family name and google-noto-color-emoji-fonts is always pulled by default-fonts-core-emoji though, even if one is going to install google-noto-color-bitmap-emoji-fonts, either of them may not work as expected. what is the advantage to provide it in a different sub-package? and how to achieve it?

Discussed with Akira TAGOH, I updated the contingency plan to just revert the google-noto-color-emoji-fonts package.