Ios Emoji Font
Hermogenes Smardon
I'd been trying to merge my favorite fonts, so that I could use them as my system default font. I succeeded merging two fonts using the zFont tool app, but when I tried to merge an emoji TTF file with a font file, it said it's a bitmap file and it's not supported. I also tried to merge them with FontForge, but I got the somewhat same error that said a bitmap file can't be merged. If you know any app or website that can merge an emoji with a font, I'd be happy to see your solution :)
we have been trying to create a font with different layers, but we are not able to make it work with some devices. We have been successful in building it for working with IE and Firefox, but it is not working for the other browsers (it is displaying only the black contourn).
Different browsers/systems support different kinds of color fonts. There is a chapter about it in the handbook. And there are some recent additions for SVG-based color fonts that are only documented in the blog post: -features-in-glyphs-2-4
The main problem is that there are several formats of color fonts and most browsers do support only some of them. Firefox does support Colr/Cpal and SVG fonts, Internet explorer (win10) supplest those and Apples sbix and Safari only sbix. Chrome in win10 supports Colr/Cpal but not its own color format.
So you need sbix and Colr (or SVG) table to support most users.
Probably because Firefox has its own font configuration settings. On void, you had no other emoji fonts installed, so Firefox picked up the only one that you had. On NixOS, you have to change that in Firefox settings.
The default font settings are bit of a misnomer. It only adds a certain font to the top of fontconfigʼs list of fonts to use for the emoji family. But fontconfig will still prefer any other installed colour font when it does not recognize the preferred font as containing colour glyphs.
I mean, yes, it works but it never occurred to me (and other people I personally know) that emojis were even considered a font, initially, so having a link to that on the Discord Arch Wiki page would've prevented this thread in the first place
I don't quite get why you think this is in any way discord specific. It's a font, if you want certain fonts to be represented you need to install a relevant font package. Should every single gui application page have a link to emoji fonts just because you might run into them?
Does every single GUI package have an Arch Wiki page? No, they don't. In fact, most Linux GUI applications don't even use emojis.
Of course it's not Discord specific but, again, many people aren't initially aware that emojis are even considered a font.
It's stupid how discussions about contributing to the Arch Wiki always devolve into debates about how quality of life notes are somehow counterproductive; it only drives away new contributors and users.
You can use emojis in the terminal/everywhere you normally use a font. You'd have to expand this to literally every article if you think about it. In any case the wiki is open, if you feel this strongly about it you could add a new troubleshooting section on the discord article linking to the link we provided.
-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?
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).
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.
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.
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.
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: )
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.]
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.]
7c6cff6d22