Workaround for emoji font "splitting" in Affinity Photo for Mac?

[Christofer]

I'm using the built-in macOS emoji font quite often in Affinity Photo. However, for some reason, a lot of the emojis with humans are not displayed correctly. For example, if I input the 👨‍⚕️, AP will instead give me 👨‍ ⚕. And if I try to input 🙋‍♀️, I get 🙋‍ ♀. See attached screenshot (the emoji input palette to the right and the result to the left). They seem to work fine in all other applications.

Does anyone know if there is a workaround not involving other software?

Running latest versions of Affinity Photo (1.10.4) and macOS Monterey (12.2.1).

[kenmcd]

The Apple Color Emoji font is an SBIX font.

Affinity applications do not support SBIX fonts.

[Accordion Bruce]

On 2/21/2022 at 5:33 PM, LibreTraining said:

The Apple Color Emoji font is an SBIX font.

Affinity applications do not support SBIX fonts.

A few months later:

Is there any plan for Affinity apps to support SBIX? It's an edge use, but Apple is adding more of them to their emoji font. It may be the only place users would see it. Apple might only use them for zwj sequence emoji like "Heart-On-Fire"? ❤️‍🔥 Other OS's may render these differently. May be reason to avoid the hassle to support? (As a workaround I cut and pasted the emoji image where I needed it.)

https://emojipedia.org/emoji-zwj-sequence/ 

Curious: The combined sequence emoji show up on the side in the Layers Panel on MacOS 12.6 Monterey, but not in text items in Affinity Design. Panel labels are presumably rendered separately by the OS?

[Komatös]

@Accordion Bruce

Did you know, that you have emoji's by Windows 10/11 itself? Press Windows key + . to activate them.❤️🔥

OK, you are Mac sorry for that.

[lacerto]

16 hours ago, Accordion Bruce said:

Is there any plan for Affinity apps to support SBIX?

They are supported at least to some extent:

I am not an expert so I cannot say exactly what works and what does not (and more importantly, why). The Glyphs Panel lists categories up to Mahjong Tiles but does not e.g. show Flags, and if picked form the system Character Viewer, do not show correctly. Some glyphs might have several alternatives, and it may be that not all of them can be selected from within Affinity apps Glyphs Browser.

I have myself created a very elemental SBIX font consisting only of color swatches to be used with palette simulations and the font works fine. It was created based on Apple Color Emoji which was just emptied, but when I have tried to create SBIX color fonts from the scratch, they have not worked properly in Affinity apps, but do work properly in other apps supporting color fonts. Perhaps there is OS level support that apps get "free", but generic support is missing, which would explain the described behavior.

The color glyphs that do show, can also be exported fine, including CMYK PDF. The color emojis are rasterized -- they are initially in raster format (unlike Windows equivalent Segoe UI Emoji, which are vectors, and supported both on Windows and macOS versions of Affinity apps), but I mean that they are not exported as glyphs of a font; Segoe UI Emoji is not, either, but the glyphs are converted to outlines and accordingly stay sharp when zoomed in).

EDIT: I forgot to mention that these tests were done on macOS Monterey 12.6 (but I think the mentioned color font types, SBIX and Microsoft CPAL/COLR, have been working at least for about 6 months; I have not tested the behavior with earlier major macOS versions).

EDIT2: Looking more closely @Christofer's examples, I can get both without the secondary glyph when I pick them from the Glyphs Panel within an Affinity app: the U+1f468 MAN, and U+1f64b HAPPY PERSON RAISING ONE HAND. But if I pick these glyphs from the system Character Viewer, and choose one of the alternatives shown there by holding down the mouse button, and then copy the selected glyph in an Affinity app, instead of getting an alternative, some kind of composing parts or in some other way related glyphs are shown side by side, instead. So below, when choosing the second alternative for "MAN" (a guy with a moustache), the basic "MAN" and a color swatch are shown, instead:

In context of some glyphs it seems these alternatives can be correctly picked but most often not, and they do not seem to be listed within the Glyphs Browser of Affinity apps. So it would seem that in order to use Apple Color Emoji in Affinity apps, they should be picked from the Glyphs Browser rather than from the system Character Viewer. [I also tried to copy the alternative glyphs from another app, like Pages, where they are correctly displayed, but when pasted in Affinity apps, similar composing parts are shown, instead.]

EDIT3: I just realized that the "variations" that macOS Character Viewer shows can be a mix of multiple fonts (based on glyph name). In such cases, the alternative glyphs might be correctly shown if displayed in certain order, like here three red dragons from Apple Color Emoji, Apple Symbols and Segoe UI Emoji:

However, if the glyphs from different fonts are picked and copied in different order (in this case in the order Apple Color Emoji, Segoe UI Emoji and Apple Symbols), the glyph from one of the fonts can be repeated three times (but shown correctly in an app like Pages that fully supports this feature). The macOS Character Viewer is confusing in its "user-friendliness" since it effectively hides the font names and different font technologies and mixes the glyphs with a similar name into one happy family. However, the variations shown above for "Apple Color Emoji",  which Affinity apps fail to show, are truly variations within one and the same font, which is indicated by listing the alternatives in a popup rather than as a static table. 

EDIT 4: I finally realized that if the glyphs are shown within Affinity apps viewed by using the context menu option "Glyphs" (rather than "Unicode with Alternates", which I was using), all glyphs available in Apple Color Emoji will be shown in the Glyphs Browser within Affinity apps. The alternatives (variations) that could not be selected from the Character Viewer, are now all shown in sequence and selectable, and glyphs that were not shown at all, like flags, are shown. So finally: the answer to OP's question seems that the "workaround" is to use the Glyphs Browser within an Affinity app and browse the glyphs using the "Glyphs" view:

...and second: SBIX fonts, at least the kinds that have been prepared like Apple Color Emoji, seem to be fully supported in Affinity apps (why the test SBIX fonts that I created from the scratch did not work is most probably caused by some mistake I have made, even if there were no problems in apps like Pages to use these fonts).

[R C-R]

8 hours ago, lacerto said:

I finally realized that if the glyphs are shown within Affinity apps viewed by using the context menu option "Glyphs" (rather than "Unicode with Alternates", which I was using, all glyphs available in Apple Color Emoji will be shown in the Glyphs Browser within Affinity apps.

Good to know! Thanks for that.

[kenmcd]

17 hours ago, Accordion Bruce said:

A few months later:

Is there any plan for Affinity apps to support SBIX? It's an edge use, but Apple is adding more of them to their emoji font. It may be the only place users would see it. Apple might only use them for zwj sequence emoji like "Heart-On-Fire"? ❤️‍🔥 Other OS's may render these differently. May be reason to avoid the hassle to support? (As a workaround I cut and pasted the emoji image where I needed it.)

https://emojipedia.org/emoji-zwj-sequence/ 

Curious: The combined sequence emoji show up on the side in the Layers Panel on MacOS 12.6 Monterey, but not in text items in Affinity Design. Panel labels are presumably rendered separately by the OS?

My statement is correct that they do not support SBIX fonts.
And I do not expect them to anytime in the future.
There are better alternatives that support open standards.

SBIX fonts contain color images in the sbix table, and they can have multiple sizes.
Apple Color Emoji has five sizes - all very small.
So they do not scale.
There are just much better alternatives.
The upcoming COLRv1 supports gradients, and opacity, and a bunch of other stuff.
And it scales, and it can be variable.

Affinity may need to support COLRv1 fairly soon as I think the next generation emoji font from Microsoft is going to be COLRv1. They and the Google fonts folks have been been working non-stop on the tools and the standards. Already added to OpenType 1.9.0, and more changes coming in v1.9.1. They have been added very quickly.

It appears that Affinity supports the Apple Color Emoji font by just getting the images out of the SBIX table - that's all. There is no "font" support. There is no text. It appears it is being accessed as an image container.

The ZWJ sequences you mention are basically ligatures.
Character1 + ZWJ + Character2 = Character3.
In normal standard OpenType fonts this character substitution is done using the GSUB table (Glyph Substitution).
Apple Color Emoji does not have a GSUB table.
It uses Apple's MORX table which has a similar function, but it is not the same.
Affinity does not support MORX tables as they are not standard OpenType.
Why waste precious time and resources to program a non-standard parallel system to support a few Apple proprietary fonts? Makes no sense.
So in my opinion there is not going to be support for Apple Color Emoji as a font ever.

[Accordion Bruce]

2 hours ago, LibreTraining said:

There are better alternatives that support open standards.

 

Helpful responses. I'll have to try that glyph trick.

Emoji in general are more complicated that most people realize, and maybe more trouble than they're worth. But they've got more attention (welcome?) on UNICODE than it's ever had before. 🤓

I wrote the proposal for the surprisingly successful 🪗 emoji, so got to learn more about them than I'd ever considered. So many issues with rendering on different platforms with non-standard images, and now the combination "sequence" emojis that only work sometimes. It's a bit of a mess. I appreciate people working on standards everybody can adopt. Good for Affinity folks deciding what's worth spending time on. It's appreciated.

[thomaso]

3 hours ago, LibreTraining said:

The upcoming COLRv1 supports gradients, and opacity, and a bunch of other stuff.
And it scales, and it can be variable.

Affinity may need to support COLRv1 fairly soon as I think the next generation emoji font from Microsoft is going to be COLRv1. They and the Google fonts folks have been been working non-stop on the tools and the standards. Already added to OpenType 1.9.0, and more changes coming in v1.9.1. They have been added very quickly.

According to this recent article (5 Oct, German Typography online magazine) aside "COLRv1" also "OpenType SVG" (Adobe/Mozilla) might become a preferred format. The text gives a rough intro into various formats, starting with the early "PostScript Type 3", and developers, skills and limitations.

https://www.typografie.info/3/artikel.htm/wissen/farbige-schriften/

Not sure if this is fully true for AD:

Quote

OpenType SVG for graphic design programs

OpenType SVG, on the other hand, has the great advantage of not being limited to vectors or bitmaps. The common graphic design programs (Photoshop, Illustrator, InDesign, QuarkXPress, Affinity Designer) already support OpenType SVG. Designers who work with these programs can also use the corresponding color fonts without hesitation. 

However, file size could be a reason which prevents from using such fonts, e.g. 565 MB for this appealing hand painted "Hello Monday" SVG font, made of 328 .PNG images. (compare 160 MB: )

[lacerto]

On 10/13/2022 at 5:50 AM, thomaso said:

Not sure if this is fully true for AD:

I suppose it is not, because they are currently not supported, at all [EDIT: other than as b/w fallbacks]. EmojiOne from Adobe is one such font, and they can have both bitmap and vector based glyphs. Here accessed from within Adobe Photoshop:

As for the other two types of color fonts, SBIX (bitmap based) and Microsoft CPAL/COLR (vector based), both seem to be at least to some extent supported in Affinity apps (macOS; the latter also on Windows):

What comes to the degree of support that Affinity apps have for these font types, the meaning of this question is for someone like me more or less philosophical, as long as e.g. Apple Color Emoji, an SBIX-based bitmap font, behaves like a font in the UI (i.e., can be picked from the Font lists and Glyph Browser, referred to similarly as glyphs in any font, and its size, scale, slant, shift and optical alignment, etc. can be defined by using the Character panel (see the bug guy above off the text frame edge treated this way), and the glyphs can be copied via Clipboard and exported (disregarding of them being rasterized, or converted to outlines, as CPAL/COLR based fonts are, in the process). [As long as the fonts only consist of image glyphs, this normally does not matter.]

As for the benefits of each technology, SBIX-based glyphs are of course limited in functionality, but work well in Emoji-based usage, and can have rich visual outlook that is easy to create and is supported already today.

I now also remembered, what causes [self-made] SBIX-based glyphs to fail in Affinity apps, and it is transparency so when they are imported, the images cannot contain transparent background. Other apps supporting SBIX based color fonts do not seem to be affected by this so they show these kinds of glyphs without problems (and without a background fill).[Transparent background is not a problem in SBIX fonts that have been prepared "by the book", like e.g. Apple Color Emoji; whether deviating from this is ok, I have no clue, but as said, the other macOS apps that I have tested do not seem to mind.]

Personally I have not found much use for color fonts, besides the obvious emoji-context, but I created both SBIX and CPAL/COLR based versions of R, G and B swatches with 10 shades (with different blend modes capable of producing thousands of colors), that I use in Affinity apps on both platforms to create data merges where the color of data (text or shapes) can easily be determined by using sequential characters from 0 to colon, A to K and a to k from within a data source (and especially Excel, where the color can be determined conditionally):

That's enough color font functionality for my needs, and more than I can achieve with older generation competition from Adobe or Corel. 

 

[kenmcd]

20 hours ago, thomaso said:

Not sure if this is fully true for AD:

Quote

OpenType SVG for graphic design programs

OpenType SVG, on the other hand, has the great advantage of not being limited to vectors or bitmaps. The common graphic design programs (Photoshop, Illustrator, InDesign, QuarkXPress, Affinity Designer) already support OpenType SVG. Designers who work with these programs can also use the corresponding color fonts without hesitation. 

 

I think that is an error which was made on one of the color fonts websites,
and others just keep repeating it.

[kenmcd]

22 hours ago, Accordion Bruce said:

Emoji in general are more complicated that most people realize, and maybe more trouble than they're worth. But they've got more attention (welcome?) on UNICODE than it's ever had before. 🤓

I wrote the proposal for the surprisingly successful 🪗 emoji, so got to learn more about them than I'd ever considered. So many issues with rendering on different platforms with non-standard images, and now the combination "sequence" emojis that only work sometimes. It's a bit of a mess. I appreciate people working on standards everybody can adopt. Good for Affinity folks deciding what's worth spending time on. It's appreciated.

Yeah, emoji fonts have all the color fonts complications, and then they add all this sequences craziness, plus the presentation selectors and modifiers characters.
They are a different beast.
I am impressed you got an emoji into Unicode.
Yes, I know what you mean about their odd undue attention to emojis.
Perhaps to keep some big donors happy. It is a bit weird.
More that once I have seen the lament ... "I have been trying to get <x-character> required for <some language> into Unicode for 3 years, unsuccessfully, and now they just added another 99 freakin' emojis!"

17 days ago a request was posted in the opentype-shaping-documents repo for info on all the different emoji fonts - to document how they are built.
Emoji font implementation notes #150
https://github.com/n8willis/opentype-shaping-documents/issues/150

They were waiting for someone to post the info for Segoe UI Emoji so I added it at the bottom.

The 14 emoji fonts listed are all completely different.
No wonder trying to copy emojis between devices, operating systems, applications is such a hit-or-miss adventure.

 

Google Fonts wants to be able to serve color emojis like other fonts.
So they created the nanoemoji project which was designed to convert the SVG source files for their Noto Emoji (CBDT) font into COLRv1 and Color-SVG, and put those both in the same font. That has been expanded into what they call the maximum-color tool which can put COLRv0, COLRv1, SVG, SBIX, and CBDT - all in one font (not that they will actually serve that).
They want to be able to serve color fonts (not just emojis) like they do with the other fonts where the format changes based on the user agent. They figure they can cover most users with COLR and SVG. They just need the tools to build the online fonts. They are already serving color fonts. Just not 100% there yet.

Like other GF developed font tools, other font designers are already using them.
They can create a COLRv1 font and convert it into SVG, CBDT, SBIX, etc.

Oh well, I'm rambling . . .

[lacerto]

23 hours ago, LibreTraining said:

More that once I have seen the lament ... "I have been trying to get <x-character> required for <some language> into Unicode for 3 years, unsuccessfully, and now they just added another 99 freakin' emojis!"

I  can imagine the frustration. Besides emojis, I have not seen many useful or interesting creations of color fonts, LiebeHeide is one of the rare, and is a bitmap based SVG font and has some interesting ideas, but appears to require some extra effort from developers to make it operate as intended (I suppose it only works properly in context of Adobe apps and QuarkXPress but e.g. VectorStyler has several quirks when using the font, both on macOS and Windows, and I am not sure if this font can be exported to PDF retaining the text content even when using InDesign or QXP), while based on Affinity apps it seems that the most limited (and technically and feature-wise least interesting but visually rich) of the three color font technologies is easiest to get partially supported, but then only on Apple platforms.

I wonder if the new features of COLRv1 are technically less challenging to get supported on different apps and platforms, and also versatile enough to make it worth an effort to try to achieve things that LiebeHeide does, in vector format?

 

[kenmcd]

15 hours ago, lacerto said:

LiebeHeide is one of the rare, and is a bitmap based SVG font and has some interesting ideas

LiebeHeide is SBIX and SVG.
SBIX can have multiple size images per character - and it has two images.
When exporting an SBIX font, Glyphs App has an option to add SVG.
That is probably what was done, and why the SVG is only an image.
So applications can use whichever format they support.
If the application is smart enough to recognize the multiple formats in one font.

15 hours ago, lacerto said:

I am not sure if this font can be exported to PDF retaining the text content even when using InDesign or QXP

InDesign exported it to PDF, and it remained a text object, but the word LiebeHeide became basically two characters, and it could not be edited. Copying the "text" got me two .notdef characters. The two PDF apps I usually use to examine PDF text both crashed just trying to open the PDF. So yes it can be exported for final use.

 

15 hours ago, lacerto said:

I wonder if the new features of COLRv1 are technically less challenging to get supported on different apps and platforms, and also versatile enough to make it worth an effort to try to achieve things that LiebeHeide does, in vector format?

That is kinda the whole point. Any bitmap font is basically a hack; an image delivery system with some spacing/alignment built in. Same with SVG, even as vector it is basically an image. Emojis are a good example of what is missing in COLRv0 - gradients, opacity, shading, blending, etc. You will never get to 100% of what you can do with an image editor or vector drawing application, but you can get a very usable result which retains its character as text.
COLR fonts can have multiple pre-defined palettes built into the font, and users can change the colors via CSS on the web, or via the application interface on the desktop. Users do not have to convert it to shapes and the change the colors in some high-end graphics application. It is still text.
And it can be variable.
The usual width and weight axes are available, but there are other axes.
For example, Rocher Color has Bevel and Shadow axes, which can change colors.

No more hassling with layered fonts.
Just change the font colors in the font palette editor.
Think about all the layered initials fonts which could be one COLR font with an editable palette.
Gradient can be an axis.
Many corporate logos could easily be a character in a COLR font, just like they are now in one color corporate fonts, but they could be the multi-color logo.
No having to make sure users always use the correct colors - they are in the font.
The government approved highway signs currently distributed as many SVGs could be in one COLR font.
SVG/PNG icon collections could be one COLR font.
This is going to happen.
The font technology is already here.
The applications are the lagging factor.

In the context of a high-end graphics application, it may seem like - we can already do this or that - but think of some Word user, or web developer being able to set all this in a text style. And even a less experienced, less knowledgeable, beginner user of APub. They set all this is a simple text style interface and move on.

As this all progresses some more innovative uses will emerge.
The FoldIt COLRv1 font has been released, and will be on GF soon.
The developer who made BungeeColor is now making a wild new COLRv1 font.

In the color fonts arena, the COLRv0/v1 and SVG fonts are going to be the winners.
The color bitmap fonts will still be entrenched in various places.
And some niches, like a blue handwriting font.
But they will be replaced eventually.
The bitmap emoji fonts were created for user interfaces, but they are used in applications like APub for many other things.
For those other things, a vector font makes more sense.

If MS does change the Segoe UI Emoji font to COLRv1 as I think they will, we are most likely going to have COLRv1 in APub eventually to support that.
But as discussed in another thread, that may be when APub v11 arrives. 😀

 

[Accordion Bruce]

21 hours ago, LibreTraining said:

The 14 emoji fonts listed are all completely different.
No wonder trying to copy emojis between devices, operating systems, applications is such a hit-or-miss adventure.

While I was writing an emoji proposal it often seemed like the system wasn't sustainable. It seems mostly like a fun way to get people to update their operating systems. But the fact that they appear differently on different platforms seems against the foundational UNICODE idea of unifying fonts across platforms. So many issues as they multiply though.

I know some UNICODE folks have long been uncomfortable with having been given responsibility for them, sort of by default. But they're so popular! "Emoji studies" has become a little niche corner of computer science and sociology now. Fun but weird.

It'll be curious to see what happens to them. The coming Emoji wars may get ugly, while being so inconsequential. 

Tangent on this tangent:
Currently I'm supporting the creation of an Antique Record Player / Phonograph Emoji. For Antiques, Vinyl Records, and Deprecated Technology. It looks good at 16pt, unlike say, 📟 Pager which, who recognizes that? In our proposal I discuss Emoji eWaste, little-used emoji for outdated tech. But once they're coded, they remain supported. So we got 💽 Minidisk forever! The antique Phonograph is sort of a commentary on this, with a recognizable object that has meant "old fashioned" for a long time. Future-proof old fashioned. 

I'm surprised my little question has had such meaningful response. Emojis and fonts in general generate such odd interest.

[lacerto]

On 10/15/2022 at 1:23 AM, LibreTraining said:

You will never get to 100% of what you can do with an image editor or vector drawing application, but you can get a very usable result which retains its character as text.

Yes, but isn't it possible to create visually rich content with a bitmap based color font and still export it so that it conveys the text? Like here when using a b/w bitmap font: colorfonts_bw.pdf

Btw, when I tried LiebeHeide on macOS version of Affinity apps, they crash as soon as the font is accessed. On Windows, however, the following odd behavior happens:

 

(The lower row has the same text written in LiebeHeide, but only the words Liebe and Heide show, separated with a large space! Really strange, perhaps it is a kind of an easter egg by the designer, but strange because occurrences of the same glyphs are not rendered elsewhere...EDIT: Seem to be custom ligatures, but why are they the only glyphs rendered, as they seem to consist of SBIX and SVG layers similarly as every other glyph in the font...)

EDIT: Actually, now that I tested both FontLab 7 and 8 fail to open LiebeHeide Color.otf for editing (Error (OT exception): 17 and 20 are shown), but Glyphs 3 opens it without problems, and macOS Font Book validates it ok with no errors or warnings.

UPDATE. The fourth color font technology, CBDT based TrueType, which is also purely bitmap based, I have not managed to get working so far anywhere else than within font editors. I am sure that I do something wrong there, but it does not appear that this font type makes it any easier to create color fonts capable of conveying text and rich visual content.

UPDATE2: Related to this, I converted Apple Color Emoji to SVG color fonts with FontLab and while the conversion is fine and bitmap color font works, I cannot embed the font and export glyphs when exporting to PDF. I have tried Photoshop 2022 latest version and QuarkXPress 2018 and they both export just images. On the other hand, Affinity apps that use the b/w fallback do embed the font and export as glyphs, so I wonder it this could really be some kind of a color font limitation, also within SVG? The same happens e.g. with Playbill SVG color font (specifically a text oriented and vector based color font), and Adobe EmojiOne, also vector based, when exporting from QXP 2018 (and all exported as glyphs when fallbacks are used in Affinity apps). Or, if this could be "just" an app-related issue. I have currently no CC-based Illustrator or InDesign installed so that I could test the behavior on recent Adobe software, but as mentioned, at least Photoshop 23.5.1 exports SVG color font glyphs as images whenever exporting to PDF, so no fonts embedded. The only technology where I can have bitmap based color fonts embedded and text exported has been SBIX on macOS (12.6), using e.g. Pages. And only technology where I have managed to export vector based color fonts as glyphs is Microsoft COLR (e.g. Segoe UI Emoji), e.g. from QXP 2018.

[kenmcd]

On 10/16/2022 at 12:44 AM, lacerto said:

EDIT: Seem to be custom ligatures

Well that would explain why I only got two .notdef characters when I tested with only the font name. I did not notice the ligatures. Have to look at that closer.

On my phone at the moment but I may be able to test more later today or tomorrow