Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: emoji (monospace) support #82

Closed
yzhang-gh opened this issue Mar 18, 2019 · 14 comments
Closed

Feature request: emoji (monospace) support #82

yzhang-gh opened this issue Mar 18, 2019 · 14 comments

Comments

@yzhang-gh
Copy link

Thank you so much for this great work!

Just wondering whether there is any chance to also make emoji monospaced (for Sarasa Mono).

I have found you said "Sarasa is not, and never, designed for displaying Emoji" in #44. May I know something more about the concern? Is it just not worth the effort?

Best

@polarathene
Copy link

Generally you shouldn't mix emoji with other fonts. Noto fonts for example explicitly keep emoji out of their fonts and have a specific emoji(and symbols) font for such glyphs.

It does not provide much advantage to combine them(unless your OS lacks any control/influence over fallback fonts), since when an emoji is not available, your OS should be able to fallback to an appropriate font. Noto Color Emoji is considered monospace for example.

You'd also be placing a burden of maintenance each year as new emoji come along, unless you were combining another font(as this one is the composition of two other sources already).

For users, you can't really override the emoji with a preferred font easily either. You generally do not want to place the emoji font at a higher priority(and hope to fallback to the intended font which is far more annoying to deal with), as these fonts tend to cover certain glyphs like numbers that will look awkward, pretty sure you'd notice an issue with spacing being rather wide too.

Definitely not worth the effort. If you're on Linux, use fontconfig and add a config that prioritizes Sarasa-Gothic followed by the emoji font. You might opt for an alias rule to the Sarasa-Gothic font family, and instead of prefer tag, use accept tag, which will use that emoji font directly after as fallback when you've chosen to use the Sarasa Gothic font family. For macOS or Windows, they presumably have some equivalent.

@yzhang-gh
Copy link
Author

@polarathene Thanks for your input. I now realize that emoji is provided by other fonts and there is nothing can be done here. (Actually, I have been using Sarasa Mono, ..., Segoe UI Emoji font list in VSCode for a very long time.)

So essentially what I need is another monospace emoji font that can work with this font. I am going to give Noto Color Emoji a try.

@yzhang-gh
Copy link
Author

Well, it seems not to support Windows...

@yzhang-gh
Copy link
Author

Twitter Color Emoji is another monospace emoji font. It works well with Sarasa Mono in Firefox.

image

However, Chrome/Chromium don't support this SVGinOT font, which means VSCode and all Electron-based applications don't support this font. 😑

@polarathene
Copy link

polarathene commented Oct 12, 2019

@yzhang-gh there is a ttf version that does work, it is similar to Noto Color Emoji and uses PNG images for the emoji inside the font afaik.

What did you mean by it is not supported in Windows? Looks like what is described in this issue, I linked to a specific comment there which has a comparison of Noto Color Emoji to Googles Blobmoji(earlier android emoji font) and the comment below that is a repo author for a version that works on Windows you could try.

You can find the repo for the blobmoji font with Windows install instructions here, it doesn't appear to have had activity since 2017. There's also the Twemoji equivalent also with Windows install instructionshere, which has had activity as recent as Aug 2019. Both provide colour version in the format Firefox uses, so you'll probably only get black/white fallback that it includes where SVGinOT is not supported. EDIT: I see you linked to that one specifically.

For VSCode / Electron, the support appears to have been there, you just had to ensure you specify the font stack(fallbacks) in the CSS or editor preferences as described here, very recently improved support appears to have arrived in Chrome for some glyphs that were not rendering with the intended emoji font apparently, so as soon as Electron adopts that and then VSCode, that should improve further :)

You should have fairly decent support for Noto Color Emoji though? It works in Firefox for me and according to this chromium bug report has had full COLR/CPAL support that the font uses since Sep 2018 for each platform. Out of the browsers Windows support might not be as good as the Noto Color Emoji Windows support issue shows with users that Windows doesn't recognize the font as valid, potentially because it's lacking some information.

Some more information about colour fonts that emoji use here at colorfonts.wtf. If you'd like the TTF build that Fedora makes for Twemoji, it's linked here, Arch Linux has a package that has a PKGBUILD script to grab the TTF font called ttf=twemoji. Although if Noto Color Emoji isn't working for you, this probably won't either as it's using the same Noto Color Emoji tooling to create the font iirc..

Perhaps Noto Sans Symbols2 would work in the meantime? It provides black/white glyphs, other fonts like DejaVu has a mono variant, but I think their sans-serif font is the one with most black/white emoticons/symbols. Neither of these cover the latest emoji afaik, but Noto Sans Symbols2 should cover a fair amount. I'm not sure how consistent it's widths are though, so it might not be suitable for monospace fallback.

There's also a black/white version of Noto Color Emoji called Noto Emoji, it's no longer maintained so won't have support for the newer emoji.

@be5invis
Copy link
Owner

Emoji is not a design goal for Sarasa, and currently Sarasa already have 60,000 glyphs, so we don't have room for them.

@yzhang-gh
Copy link
Author

@polarathene Thank you.

My problem now is to find a monospace emoji font (to put at the end of my font list).

I have been using Segoe UI Emoji for a long time, but it is not a monospaced font. That is why I opened this issue.

I just tried Noto Color Emoji and Twitter Color Emoji (ttf, SVGinOT). They work well in Firefox.
But Chromium doesn't support SVGinOT font (see https://bugs.chromium.org/p/chromium/issues/detail?id=306078)
So in VSCode, Twitter Color Emoji looks like this

image


@be5invis Yeah, I see. Emoji has its own font.

Just out of curiosity, what emoji font are you using along with Sarasa Mono?

@polarathene
Copy link

@yzhang-gh regular Noto Colour Emoji(no SVGinOT) should work fine in Chrome and Electron/VSCode. I have it working fine on my Linux system.

I linked to an issue for VSCode where Windows users seemed to have success in adding the font in the editor fontFamily list, is that not working for you? Here is Noto Color Emoji working in VSCode on Linux, each emoji has the width of two characters:

vscode_emoji

I've not added any emoji font to my settings, but rather told my OS how to handle fonts(Linux uses fontconfig). I don't have Windows available to compare. It should have support according to the Noto Color Emoji README, if you can't get it working perhaps raise an issue on the repo there(or on the VSCode issue you have) . Feel free to @ mention me. This discussion / issue doesn't have anything to do with Sarasa Gothic.

Just noticed I accidentally linked to issue 43 on this repo accidentally in my prior comment, that was meant to be the Noto Color Emoji issue 43 about Windows support.

@yzhang-gh
Copy link
Author

yzhang-gh commented Oct 12, 2019

@polarathene In a different page, it says Noto Colour Emoji doesn't support Windows and macOS (but only Android and Linux)

Do you have a non-SVGinOT version of Noto Colour Emoji font? Or do I need to build it on Windows?


I linked to an issue for VSCode where Windows users seemed to have success in adding the font in the editor fontFamily list

Actually, it is me who opened that issue 🤣. Yes, it works for me as I am using Consolas, Segoe UI Emoji font list. That issue is, even with this setting, ✔ is still black-white.

Segoe UI Emoji (not monospace)
image

Noto Color Emoji blobmoji (SVGinOT)
image

@polarathene
Copy link

@yzhang-gh I'd trust the github README more than the Noto website tbh :)

Do you have a non-SVGinOT version of Noto Colour Emoji font? Or do I need to build it on Windows?

AFAIK, Noto Colour Emoji is not SVGinOT by default, it's CBDT colour font type. The thread I linked has this comment which states they got the Noto Color Emoji font to render/work in Chrome, and so it should work in VSCode too, just perhaps not anywhere else on Windows.

Yes, it works for me as I am using Consolas, Segoe UI Emoji font list.

Place the Noto Color Emoji font in the fonts directory for Windows, reference the font name like you did with Segoe UI Emoji? Supposedly, that should work.

That issue is, even with this setting, ✔ is still black-white.

Github is not rendering that as an image like others, but it is appearing as colour/emoji version for me(which I can copy/paste correctly).

A: ✔
B: ✔️

It does seem like it's rendering the image version(at least in preview tab) B version above. I added the VS16(FE0F) codepoint. In HTML text content, &#x2714 &#x2714&#xFE0F will input the default text version, and the 2nd is the colour presentation variant. Quite a few emoji technically require that to render as emoji instead of text. I pointed this out on the VSCode thread.

Although I see them as identical(Github image emoji are using Noto Color Emoji afaik), you perhaps see A as text? If not, this inline code block A: ✔, B: ✔️ should avoid B being turned into an image, they might both look the same to you, copy/paste them and try them out in VSCode, B will probably render as emoji. If it does, then the behaviour is actually correct, and the code that is producing the ✔️ in VSCode should be using the VS16 codepoint to support emoji rendering.

Noto Color Emoji (SVGinOT)

Is that the DeeDeeG repo? It looks like blobmoji emoticons in the 2nd row. That packages a SVGinOT font with black/white outline fallback when the colour SVG is not supported.

@yzhang-gh
Copy link
Author

Noto Color Emoji on Windows

Do you have a non-SVGinOT version of Noto Colour Emoji font? Or do I need to build it on Windows?

AFAIK, Noto Colour Emoji is not SVGinOT by default, it's CBDT colour font type. The thread I linked has this comment which states they got the Noto Color Emoji font to render/work in Chrome, and so it should work in VSCode too, just perhaps not anywhere else on Windows.

Well, the README does say it supports Windows. But I cannot find instructions or font files anywhere.
"The linked comment" also didn't give a solution :(
image
dead end...


A: ✔, B: ✔️

It looks like image in my browser (Chromium-based Edge)

And in VSCode (with Segoe UI Emoji at the end of the editor font list)
image

(I cannot catch up with your thoughts. Just provide some results for your information)


Is that the DeeDeeG repo?

Yes, it should have been blobmoji (SVGinOT).

@polarathene
Copy link

Well, the README does say it supports Windows. But I cannot find instructions or font files anywhere.

The font is in the font directory, there's also the much older black/white version you can try there. I found a more up to date / maintained version of blobmoji here, if you prefer that style.

It looks like [image] in my browser (Chromium-based Edge)

They render the same for me:

green_ticks

(I cannot catch up with your thoughts. Just provide some results for your information)

Ok.. so the Preview test.md shows that it can render the emoji version when it has the extra hidden codepoint, called a Variation Selector(VS), the one that tells a text "emoji"/symbol to be in colour is VS16, unicode is 0xFE0F.. The ✔️ is unicode 0x2714.

You need to have the VS16 right after the ✔️ for it to be combined into one character/emoji, but it's a bit difficult since it is invisible(no width in text) to select/copy the VS16, I showed code for using in HTML text which will create it(if you add to the HTML in a webpage), I then copy/paste the emoji that renders on the page, which gives us B: ✔️.

I am a bit surprised that the left test.md did not render it. It looks like a different font compared to the Preview test.md A? So it is taking priority, whatever the font is, probably has the (A) glyph, so no fallback font is used.

The main point I was trying to make was that (A) was being used, not ✔️(B). A is meant to render as text, no colour/emoji, B is meant to be emoji. Think of it as similar to when use Shift, to get uppercase and lowercase letter. You push the same letter on keyboard, but different combination instructs to use different version.

Yes, it should have been blobmoji (SVGinOT).

That one use SVGinOT if your app supports it(like Firefox and some version of Edge), otherwise it has a black/white font as well, which you got and showed in screenshots. As you know SVGinOT is not supported in Chrome, so if you want colour emoji, you need to use different font.

@yzhang-gh
Copy link
Author

The font is in the font directory, there's also the much older black/white version you can try there. I found a more up to date / maintained version of blobmoji here, if you prefer that style.

I tried both. Exactly the same issue "not a valid font on Windows". And looks like nobody succeeds in installing them on Windows. 😔

You need to have the VS16 right after the ✔️ for it to be combined into one character/emoji...

I see that B has extra information (codeprint?), just like
image

I am a bit surprised that the left test.md did not render it. It looks like a different font compared to the Preview test.md A? So it is taking priority, whatever the font is, probably has the (A) glyph, so no fallback font is used.

I find it is Sarasa Mono that has priority over the emoji font!

image

image

Is it time to @ be5invis? 😂

@polarathene
Copy link

polarathene commented Oct 13, 2019

I see that B has extra information (codeprint?)

Yes, you can copy/paste both A and B versions into this site and it will convert to the input to codepoint values that represent it. You'll see one has VS16(FE0F), while the other doesn't.

I find it is Sarasa Mono that has priority over the emoji font!

Great find! :) So it was due to a font overriding priority after all, not a fallback issue.

Is it time to @ be5invis? 😂

Yes. I've just inspected the glyphs and the font is providing them, thus no fallback will be searched. You can change the priority and place the emoji font earlier in the priority/order, but if that emoji font contains latin glyphs(or numbers, which isn't uncommon afaik), then those will have the same issue and your rendered text will look quite badly spaced apart.

Some users may want the font to provide these symbols, as depending on the application, the fallback font might not be possible to set like you can with VSCode. On linux, that would probably mean the font falls back to a sans-serif font due to fontconfig behaviour(a system config would need to assign monospace earlier to avoid it, or a user config will have to detect it and fix it). On Windows presumably you have no control in that situation and have to pray for a compatible fall back.


So I guess the best solution is another set of the fonts excluding the symbols? You can't really do so for the emoji fonts, since the latin characters/numbers are there for ligatures/sequences afaik(not a font developer, not sure of the correct term).

@be5invis thoughts on removing the symbols so their colour emoji equivalent in another font can be used as fallback? Otherwise they will have priority(depending on app implementation). Rarely do I see apps that will use a different font if the glyph is already available despite any following Variation Selector codepoint, some do select text/colour fallbacks based on variation selectors which allows for a mix of the two, but only when searching for fallback font to replace that character with text symbol or colour emoji.

Googles Noto fonts split symbols to a separate font(Noto Sans Symbols / Noto Sans Symbols2) and their related emoji font Noto Color Emoji(doesn't have full parity as not all symbols have emoji equivalents). Since this is intended as a programming font, perhaps the symbols for Mono/Term could be split off too? This might affect some editors like was discussed above, and any terminal UI that uses the font symbols(such as the checkmark for passing tests or some other task, or shell themes like Powerline).


@yzhang-gh Can you confirm this only affects the Mono/Term fonts? I used "Adobe Blank" as a fallback font to confirm that no other glyph was being sourced from another font, I didn't see it available in Gothic/UI variants.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants