Emoji support

[M. J. Star]

There's one thing preventing me from updating to 1.10 Affinity Designer, and that is the new emoji support.

Things are going in the right direction but it needs some tweeks. I have some emoji fonts that I use regularly. One being Segoe UI Emoji. However after 1.10 Affinity designer always uses the default emoji with color. This is a problem because I want the black only glyphs.

Repro

1. In Affinity 1.10.x make a new document on a Windows computer

2. Create a new text object with the font set to Segoe UI Emoji (or other font with emoji support). Paste in a 😀 into that object

Expected:

The black only Segoe UI Emoji version of 😀 appears

Actual:

The default san-serif 😀 appears complete with color.

[walt.farrell]

Welcome to the Serif Affinity forums.

Segoe UI Emoji has the color version of 😀 available (U+01F600), so why should Designer paste a black/white version?

From the Glyph Browser, this is the full set of "smiling face" emoji in that font on my Windows system:

It doesn't seem to have any black/white versions of "smiling face" except for "black smiling face", which is a different code-point/glyph that you'd need to ask for.

[M. J. Star]

How did you create the image above? Did you create it in Affinity Designer 1.10. If you did then that would be more evidence of the bug I'm talking about.

I have attached (1) the expected result and (2) the Segoe UI Emoji glyphs as they appear in Microsoft Word. As you can see in the first image, Affinity 1.9.2.1035 is doing what I want with the black only emojis. However the latest Affinity Designer is forcing me to only use the default colored emojis.

I should also note that this isn't just for Segeo UI Emoji. This is a problem with all fonts as far as I can tell. Dollyn, a font with partial emoji support isn't working either. It's using the default colored emojis before it uses the emojis that the font supports.

[walt.farrell]

1 hour ago, M. J. Star said:

the Segoe UI Emoji glyphs as they appear in Microsoft Word

What does the Glyph Browser in Designer show you? They might not appear correctly in Word  

1 hour ago, M. J. Star said:

How did you create the image above? Did you create it in Affinity Designer 1.10.

Yes. It's the glyphs in Segoe UI Emoji, on my system, as seen by Affinity Designer. I have no reason to suspect a bug, but I'll look around some more.

[Komatös]

It is not a bug of the Affinity programmes but a display weakness of Microsoft Word.

When I am in the symbol browser in MS Word, all characters, symbols and emojis are displayed in black and white. If I then add an emoji by selecting and confirming it, the colour counterpart is displayed in my document.

I get a pure black and white emoji with Sergoe UI Symbol, for example.

[M. J. Star]

FYI Are you sure about that? This is what the glyph browser for Segoe UI Emoji looks like in Affinity 1.9. Notice how they are not in color. I think this is the better behavior because the way Affinity 1.10 does it I can't use the specific fonts implementation of emoji. As a result the emojis look the same no matter what font I select, even if the font has it's own implementation of emoji character.

[kenmcd]

On 8/20/2021 at 12:35 PM, M. J. Star said:

Expected:

The black only Segoe UI Emoji version of 😀 appears

Actual:

The default san-serif 😀 appears complete with color.

The black versions are the fallback for applications which do not support the color versions. This is the way the font is constructed. Since AD does support color in this case it is correctly showing the color.

[walt.farrell]

Thanks for confirming, @LibreTraining.

Possibly an alternative for @M. J. Star then would be to use Segoe UI Symbol, which seems to omit the color, and just has the black/white versions.

[kenmcd]

On 8/20/2021 at 2:26 PM, M. J. Star said:

I have attached (1) the expected result and (2) the Segoe UI Emoji glyphs as they appear in Microsoft Word. As you can see in the first image, Affinity 1.9.2.1035 is doing what I want with the black only emojis. However the latest Affinity Designer is forcing me to only use the default colored emojis.

The Symbol dialog in Word 2016 works the same way as AD - it shows them as just black.
But when they appear in the document they are full color.

[GaryLearnTech]

17 hours ago, LibreTraining said:

The black versions are the fallback for applications which do not support the color versions. This is the way the font is constructed. Since AD does support color in this case it is correctly showing the color.

Putting a little more meat on the bones of @LibreTraining's explanation, I found the following info at Wikipedia > Emoji > Implementation > Vendors and platforms > Microsoft Windows.

Differently from macOS and iOS, color glyphs are only supplied when the application supports Microsoft's DirectWrite API, and Segoe UI Emoji is explicitly declared, otherwise monochrome glyphs appear.[161] Microsoft's COLR/CPAL format for multi-color fonts such as Segoe UI Emoji is supported by the current versions of several web browsers on Windows (including Firefox, Google Chrome, Internet Explorer and Microsoft Edge), but not by many graphics applications.[126]

[walt.farrell]

15 minutes ago, GaryLearnTech said:

Putting a little more meat on the bones of @LibreTraining's explanation, I found the following info at Wikipedia > Emoji > Implementation > Vendors and platforms > Microsoft Windows.

Differently from macOS and iOS, color glyphs are only supplied when the application supports Microsoft's DirectWrite API, and Segoe UI Emoji is explicitly declared, otherwise monochrome glyphs appear.[161] Microsoft's COLR/CPAL format for multi-color fonts such as Segoe UI Emoji is supported by the current versions of several web browsers on Windows (including Firefox, Google Chrome, Internet Explorer and Microsoft Edge), but not by many graphics applications.[126]

Thanks, Gary. Earlier in that section that Wikipedia article also hints that Segoe UI Symbol should be requested by users wanting black/white versions of the emoji.

[lacerto]

(...)

[lacerto]

(...)

[walt.farrell]

2 hours ago, Lagarto said:

Affinity apps crash if I try to convert Segoe UI Emoji to curves

That's fixed in the 1.10.1 beta, and will be fixed in the formal 1.10.1 release planned for this week.

[lacerto]

(...)

[kenmcd]

On 8/23/2021 at 7:01 AM, Lagarto said:

@LibreTraining, can you shed some light on the way fallbacks work -- interestingly e.g. Adobe Photoshop 2021 does not support color versions of Segoe UI Emoji. On the other hand, Photoshop can convert EmojiOne Color (by Adobe) glyphs (which Affinity apps do not support in color versions) to vector shapes so that the user can colorize and modify them as any shape:

The fallback to the monochrome shapes has to be supported by the application.
And the font needs to supply the fallback shapes (was not required and some do not have them).
In COLR color fonts the glyphs/shapes are kept in the COLR table.
In OpenType-TT fonts the glyphs are kept in the glyf table.
So both can be present.
When an application opens a font it looks at what tables are included and then decides what it wants to do with them. So the app can see a COLR table and say "oh no, we do not support COLR fonts, so let's see if it also has a glyf table, oh good, it does have a glyf table, so we can use those and treat this font like any other OpenType-TT font."

Or the app can be dumb like those which rejected Source Code Pro when they added an SVG table as a test. This SVG table was added to a complete fully working OpenType-TT or OpenType-PS font and some apps simply saw the SVG table and said "we don't support SVG, we cannot use this font" - when it could just use the other "normal" tables. So they took the test SVG table out.

So apps need to be updated to expect these fallbacks.
Here in the forum we have already seen an SBIX font which also had an SVG table as a fallback.
Glyphs App can create these automatically.
FontCreator can automatically create an SVG table from the COLR table glyphs.
So a font can have normal glyphs, COLR glyphs, and SVG glyphs.
An app that does not support COLR but does support SVG can still have a color font.
But I do not know of any app which does support all this at the moment.

So the font needs to support the fallback, and the application needs support that fallback.

 

[kenmcd]

On 8/23/2021 at 7:45 AM, Lagarto said:

I got a partial answer while visitng Adobe XD, that does support Segoe UI Emoji (color versions, as does actually Photoshop but strangely only via Clipboard), and yes, they can be converted to fallbacks by converting to paths:

Most likely those are just the color shapes, not the fallback.
Some of the fallback shapes are quite different, so you can test.
Look at some emoticons like fearfulface (1F628) or facescreaminginfear (1F631).
Those outlines are not in the color shapes.
And some of the buildings - 1F303, 1F306, 1F307.
Some of the shapes are simply missing on those.

Edit: demo of the buildings switching from color to the fallback mono.

Edit: the fallback mono versions of 1F628 and 1F631
In 1F628 the color versions do not include those circles around the eyes.
In 1F631 the color versions do not include those lines around the hands.

 

[kenmcd]

On 8/23/2021 at 9:43 AM, Lagarto said:

The best option would be a possibility to get fallback glyph on demand, and then be able to convert either one to curves. Perhaps sometimes, when the color font technology matures.

This needs to be done by the application, the font technology is already there.
Would be a nice feature in Affinity apps.

[walt.farrell]

5 minutes ago, LibreTraining said:

Would be a nice feature in Affinity apps.

But for now, and for Segoe UI Emoji, the user can simply choose Segoe UI Symbol instead, I think.

[kenmcd]

9 minutes ago, walt.farrell said:

But for now, and for Segoe UI Emoji, the user can simply choose Segoe UI Symbol instead, I think.

Maybe yes, maybe no.
The characters available are different.
There is a lot of overlap, but there are also many in one that are not in the other.
And the drawings are usually quite different.
So it may be kind of a hit-or-miss situation.

[kenmcd]

Interesting note: I have been testing some other COLR color fonts ... and they work!

Example below is Bungee COLR exported to PDF using APub v1.10.1.1138.x64.Beta
Then using PDF-XChange exported from that PDF to a PNG.

 

Hell has frozen over. We have color font support in APub. 🙂

 

[lacerto]

(...)

[kenmcd]

20 hours ago, Lagarto said:

I wonder if there is also some recent OS API development in the background that has matured and made it easier for apps to handle at least certain kinds of color fonts

One of the selling points for the COLR color font format was that "it can use existing rasterizers" so that may have been a factor here in choosing it first.

20 hours ago, Lagarto said:

(I suppose Outlook and Word are still the only ones that support color versions of Segoe UI Emoji while on macOS the whole suite can handle all kinds color fonts).

I have been testing various COLR fonts in APub today and so far all work. Did not think about MS Word until I saw this so I tested some there also. So far in Word 2019 some work and some do not.

Will post the results and fonts info in a new thread when done testing.