Jagged rendering on Windows 10 22H2

[bladeSk]

When rendered in Chrome or select few supported apps, the icons are very jagged. It looks like they're downscaled from a larger image using the nearest neighbor filter:

I wanted to replace the ugly built in icons, but this defeats the purpose somewhat. Would it be possible to use the actual vectors from Noto Emoji?

[mindplay-dk]

Yeah, I was wondering about this as well.

They look great on a small 12" 4K tablet - but they look really bad on a 34" 3K monitor.

The worst example so far is the 😅 emoji, which renders with the mouth in a frown for some reason.

Is it just that Windows can't render this type of font with anti-aliasing? But it renders the original font that ships with Windows with anti-aliasing... so it's kind of a mystery to me.

Man, I wish Microsoft would just pull their heads out of their asses and stop ruining Windows. I'm close to just quitting Win 11 and installing Ubuntu, which I can at least configure to look the way I want it to. 😔

[mindplay-dk]

Would it be possible to use the actual vectors from Noto Emoji?

Would that help? how?

[bladeSk]

Would that help? how?

I believe it may, from what I gathered, the built in emoji font uses vectors in COLR/CPAL format and they render just fine (anti-aliased and all that). Windows seems to have problems rendering images within fonts. It's likely a half-assed implementation on Microsoft's part and not a problem with the font itself, but the result is jagged.

Man, I wish Microsoft would just pull their heads out of their asses and stop ruining Windows. I'm close to just quitting Win 11 and installing Ubuntu, which I can at least configure to look the way I want it to. 😔

Agreed. Windows has been on a downward spiral for the last decade. I actually tried switching, and as a Windows power user, I liked KDE's interface (Kubuntu) much more, but it wasn't as stable as I would've liked, especially with Nvidia drivers. But the emoji looked superb. :)

[mindplay-dk]

What would be really help, is if Microsoft would open source the script to build the official font - then we could go ahead with a fork and build one or more replacement fonts the way they intended.

[DellZHackintosh]

Why don't check the offical way from Google? That might be better.

[mindplay-dk]

They build 7 different versions of the font - one of them named as "WindowsCompatible", I'm not sure what that means. Do you think it would it possible to just modify their build script and change the font name/family/description to fool Windows into thinking it's the same font? (I'm not really Python savvy.)

[DellZHackintosh]

Sorry that I might wrong.
Windows seems doesn't support the 'colrv1' format from google's official repository.
So the "WindowsCompatible" font is the only font that Windows is supported, although its format is CBDT and looks jagged.
The last way is https://github.com/mozilla/twemoji-colr, I don't know is that useful, but similar.

[DellZHackintosh]

Or try to build font manually:
Use Nanoemoji and SVG Emoji images, and then run the command (in Linux):

nanoemoji --color_format glyf_colr_1 $(find ../noto-emoji/svg -name 'emoji_*.svg')

Just that, but I haven't tried it, don't know if that works.

[mindplay-dk]

According to the OpenType wikipedia article:

In Windows 8.1 Microsoft also added color support to fonts, first implemented in the Segoe UI Emoji font.[72][76][77][78] Microsoft's implementation, however, relies entirely on vector graphics:[72][79] two new OpenType tables were added in Microsoft's implementation: the COLR table allows layered glyphs and the CPAL ("Color Palette") actually defines the colors for the layers. The multi-layer approach allows a backwards compatible implementation as well as varying the rendering depending on the color context surrounding the glyphs.[72] According to Adam Twardoch: "At TypeCon [2013], Greg Hitchcock clarified the envisioned roles of the palettes: first palette is used by default for "dark on light" color situations while second palette is intended for use in "light on dark" situations. Additional palettes should be selectable by the user."[75]

This is what we want, I think - vectors, not bitmaps.

It does look like Nanoemoji supports two versions of COLR, which (from my limited understanding) should imply support for CPAL, which (as I understand it) goes together with COLR.

It might be worth a try - let me put this at the bottom of my infinite to-do list. 😅

[BroJac5246]

Same issue here, I just installed it and while I think I'll be keeping the emojis since they're still better, they nevertheless are low resolution unless you zoom in.

[mindplay-dk]

The problem isn't the resolution - they're actually pretty high resolution.

But yeah, the look bad, even on a 4K monitor - the "😄" emoji actually looks like it's crying on my screen.

The problem is bitmap-based emoji are rendered without anti-aliasing on Windows. Barring they fix that (which they won't, because their own emoji are vector-based) the only way to get a sane set of emoji on Windows is figure out how to build a Window-compatible vector-based version.

The only practical way to do that would be if Microsoft would open-source the build-scripts for the emoji font - but they haven't given any indication that they will, so please go and comment/upvote that issue.

I mean, you could try to replicate what they've probably done, with a lot of guesswork and experimentation, but I'm not sure anyone has that kind of time or patience just to get back a useful set of emoji... personally, I've found myself reverting to old school :-) text based emoji since that tragic Win 11 update... :-(.

[BroJac5246]

The problem isn't the resolution - they're actually pretty high resolution.

But yeah, the look bad, even on a 4K monitor - the "😄" emoji actually looks like it's crying on my screen.

lol

I was referring to how they appear low resolution, not how they are low resolution (since they aren't). I noticed that if I zoom into a website, the quality improves.

The problem is bitmap-based emoji are rendered without anti-aliasing on Windows. Barring they fix that (which they won't, because their own emoji are vector-based) the only way to get a sane set of emoji on Windows is figure out how to build a Window-compatible vector-based version.

Could this somehow be manually implemented?

The only practical way to do that would be if Microsoft would open-source the build-scripts for the emoji font - but they haven't given any indication that they will, so please go and comment/upvote that issue.

I mean, you could try to replicate what they've probably done, with a lot of guesswork and experimentation, but I'm not sure anyone has that kind of time or patience just to get back a useful set of emoji... personally, I've found myself reverting to old school :-) text based emoji since that tragic Win 11 update... :-(.

I mostly use Ubuntu so it's not a huge problem for me but I feel you.

[mindplay-dk]

Could this somehow be manually implemented?

Yes - Microsoft did it, so we can too.

Probably the best source of reference is Google's Noto Emoji project, which has build scripts for vector fonts:

https://github.com/googlefonts/noto-emoji

If you could alter this to emit a font with the right family name, you might already have something that works.

(I suck at Python.)

[mindplay-dk]

It might be literally one line of code 😂

https://github.com/googlefonts/noto-emoji/blob/934a5706f1f3dd2605c4d9b5d9162fd7f89d8702/colrv1_generate_configs.py#L21

I've had zero good experiences even running python apps, so I didn't even want to look - but if it's really only a matter of getting the script running and changing a few lines, I might actually take a look... 🤔

[BroJac5246]

It might be literally one line of code 😂

https://github.com/googlefonts/noto-emoji/blob/934a5706f1f3dd2605c4d9b5d9162fd7f89d8702/colrv1_generate_configs.py#L21

I've had zero good experiences even running python apps, so I didn't even want to look - but if it's really only a matter of getting the script running and changing a few lines, I might actually take a look... 🤔

I'm also not very experienced with Python, but that's very interesting.

How exactly does it work? I'm picking up that you generate a vector version of the Noto emojis and name them as Windows' emojis and then what? Are you done or do you have to do another step? Depending how complicated it is, I might try it myself as a learning experience with Python.

[mindplay-dk]

How exactly does it work? I'm picking up that you generate a vector version of the Noto emojis and name them as Windows' emojis and then what?

I don't even think you'd need to do that - as far as I understand, the emoji in the resulting file don't have names, just Unicode character codes.

Best I can figure, it's a matter of getting the Windows compatible version of the font emitted with the correct font family name, Segoe UI Emoji.

I just spent 3 hours trying to do that, ha ha - it's a complete circus of missing dependencies and written directions that may have worked at some point. It's what I expected. Very Python. 🙄

[mindplay-dk]

If you get as far as I did and actually get some part of this to run, note that, despite the variable I mentioned, the font-name appears to be hard coded into NotoColorEmoji.tmpl.ttx.tmpl times 3 - it does not look like the changed font-name actually carries over to anything other than the *.toml files in the colrv1 folder, where they appear to have no effect on any emitted files.

I'm also not sure where the NotoColorEmoji_WindowsCompatible.ttf file is supposed to come from - it's mentioned in the build scripts, but does not appear to get updated after running the build.

It's all very, very Python. Good luck, have fun.

[mindplay-dk]

Here's as far as I got with a build.sh script:

rm -rf venv  # in case you have an old borked venv!
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python size_check.py
rm -rf build/ && time make -j 48 BYPASS_SEQUENCE_CHECK='True'
# Should take 2-3 minutes to create noto-emoji/NotoColorEmoji.ttf

mv *.ttf fonts/

# If you are updating to a new Unicode rev, update configs
python colrv1_generate_configs.py
git diff colrv1/*.toml | cat

# Compile the fonts
(cd colrv1 && rm -rf build/ && time nanoemoji *.toml)
cp colrv1/build/NotoColorEmoji.ttf fonts/Noto-COLRv1.ttf
cp colrv1/build/NotoColorEmoji-noflags.ttf fonts/Noto-COLRv1-noflags.ttf

# Post-process them
python colrv1_postproc.py

This is based on the instructions in BUILD.md, but adding BYPASS_SEQUENCE_CHECK='True' as the make command fails without it. I added | cat to the git diff command, since otherwise it will stall the script. And I changed (cd colrv1 && python colrv1_generate_configs.py) to just python colrv1_generate_configs.py since that's not actually where the script is located.

I'm out of steam, but let me know if you get anywhere with this...

[BroJac5246]

Sounds complicated...

I've been busy, so I have no idea if I'll be able to try it, but I'll let you know if I do.