How to display multi character unicode emojis in Overleaf LaTex? - unicode

So apparently Overleaf now can render emojis using packages of Noto Color Emojis, where you can use {\NotoEmoji \symbol{"1F343} \symbol{"1F338} } to input an emoji with corresponding unicodes.
My question is how to input complex emojis that are composed of multiple emojis? For example, this one πŸ‘©β€πŸ‘©β€πŸ‘¦β€πŸ‘¦, the unicode is U+1F469‍ U+200D U+1F469‍ U+200D U+1F466‍ U+200D U+1F466.
I've tried combinations like
\symbol{"1F469‍200d1f469200d...1f466}
\symbol{"1F469 200d 1f469 200d...1f466}
\symbol{"1F469} \symbol{"200d}...\symbol{"1f466}}
But none of them works.

You don't need to concatenate them. Here's the solution that I tried in Overleaf and it worked fine.
{\Large
\NotoEmoji
% family emoji
\symbol{"1F468}\symbol{"200D}\symbol{"1F469}\symbol{"200D}\symbol{"1F467}\symbol{"200D}\symbol{"1F466}
}
Expected Output
πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦ Family: Man, Woman, Girl, Boy,
You can use the same trick for Emoji Skin Tone Modifiers in Overleaf where the modifier comes right after the emoji Unicode.
{\Large
\NotoEmoji
% Waving Hand emoji
\symbol{"1F44B}%
% Waving Hand: Light Skin Tone
\symbol{"1F44B}\symbol{"1F3FB}
}
Expected Output
πŸ‘‹
πŸ‘‹πŸ»
Here's the Overleaf Project page about Displaying Color Emojis in Latex that you can check out.
Updated 2020-11-28 : Adding emoji as an image in Latex
Since you mentioned adding emojis as images, I'm also including my solution for that.
\usepackage{tcolorbox}
% change font size here
\includegraphics[height=12]{family-man-woman-girl-boy.png}
The image can be downloaded from EmojiPedia.

Related

Characters in FontForge appear distorted

I'm trying to create a font using FontForge which is 'simply' the alphanumeric characters from Lato (original version) as well as the greek alphabet characters from Lato (extended version). I opened both fonts in FontForge and copied and pasted the greek letters over to the original version. I generated the font and displayed it in Google Chrome. But the characters that I've copied come out jagged / distorted. I've also tried opening the original font, then going to element and then merge fonts and selecting the extended version font and then generating a font from that but the same problem occurs.
The screenshot provided below shows the distortion going on. The top line shows how the letters should look. The bottom line shows how the letters actually look. Many of the letters - even the ones that were in the original (such as the 'a') - aren't displaying properly. The bottom and top of some characters has been flattened and for other characters, extended. Notice the top of the alpha, rho and epsilon are pointed and aren't smooth as they should be. The top of the beta has been flattened. Look at the top and bottom of the 'o' - both have been flattened as if to fit into a minimum allowable area.
If I zoom in a lot, the jagged edges become smooth again.
What can I do to fix this?

Psychtoolbox not drawing German Umlauts

I am presenting a German Text in Psychtoolbox. The special characters (Umlauts) are not displaying properly with the DrawText nor DrawFormattedText. The characters are recognized correclty by Matlab when I read in a .txt file to a char cell struct, but Psychtoolbox substututes then the characters with other symbols.
Has anyone solved this issue before?
Thank you!
We just found a solution. If the text is stored in the variable "message"
message='ΓΆΓ€ΓΌΓŸΓ„Γ–Γœ'
Display text by casting message as uint8()
DrawFormattedText(w, uint8(message)); % Use uint8() to display Umlaute and other non-ascii signs (UTF-8) by passing as uint8
instead of DrawFormattedText(w, message);** % does not work with Umlaute etc.
Use font that displays all characters, e.g. Arial
Screen('TextFont', w, 'Arial', 1); % Dont use Helvetica, does not show uppercase Γ„Γ–Γœ properly (even after converting it to uint8)
Best, Kai

Why does the red heart emoji require two code points, but the other colored hearts require one?

It appears that the red heart emoji (❀️) "\u2764\uFE0F" requires two Unicode codepoints, specifically Heavy Black Heart followed by a Variation Selector. However, blue πŸ’™, green πŸ’š, yellow πŸ’›, and purple πŸ’œ each have their own single codepoint.
Why is red so different?
For historical reasons. Originally, there was only U+2764 HEAVY BLACK HEART which the first applications that supported Emojis decided to render as a red heart. These early applications always rendered U+2764 as Emoji. Later it was realized that this was a bad idea and the variation selectors for Emojis were standardized. When additional heart emojis were added, there was no need for another red heart, so it was omitted. Instead there's a separate black heart emoji U+1F5A4 πŸ–€.
In theory, an application could require that the Emoji variation selector is appended to other heart code points as well. But it doesn't make much sense to render characters like PURPLE HEART as a non-Emoji. It does make a difference for HEAVY BLACK HEART, though, which is often intended to be rendered as the original, plain heavy black heart character.
HEAVY BLACK HEART was added to Unicode decades before emoji. When emoji were incorporated in Unicode 6 some already existing characters were simply reused as emoji to avoid unnecessary duplicates. Later, variation sequences were defined for characters that also map to a non-emoji character set to allow for better control over how they display. For example, U+2744 ❄ SNOWFLAKE is originally from Zapf Dingbats (I believe) but was later also made an emoji. So if you want to force the original text-style display you can use VARIATION SELECTOR-15 (resulting in β„οΈŽ), and if you want to force the newer emoji-style display you can use VARIATION SELECTOR-16 (resulting in ❄️).
Note, however, that not many platforms actually support those variation sequences correctly at the moment. Also not all of them automatically apply the variation selectors when using the emoji keyboard. In theory ❀ and ❄ (and many other emoji) should display as text style by default without VS16, but many applications ignore that as well.
I have a list of all code points that can display differently via a variation sequence, on my website, if you're interested. The next Unicode update in June is going to add some more.

Color in the Unicode standard?

Unicode 6.0 added several characters with descriptions that suggest those characters are supposed to be rendered in a specific color:
RED APPLE U+1F34E
GREEN APPLE U+1F34F
BLUE HEART U+1F499
GREEN HEART U+1F49A
YELLOW HEART U+1F49B
PURPLE HEART U+1F49C
GREEN BOOK U+1F4D7
BLUE BOOK U+1F4D8
ORANGE BOOK U+1F4D9
LARGE RED CIRCLE U+1F534
LARGE BLUE CIRCLE U+1F535
LARGE ORANGE DIAMOND U+1F536
LARGE BLUE DIAMOND U+1F537
SMALL ORANGE DIAMOND U+1F538
SMALL BLUE DIAMOND U+1F539
UP-POINTING RED TRIANGLE U+1F53A
DOWN-POINTING RED TRIANGLE U+1F53B
UP-POINTING SMALL RED TRIANGLE U+1F53C
DOWN-POINTING SMALL RED TRIANGLE U+1F53D
I had thought font symbols were always grayscale.
Did the unicode authors forsee that these might be rendered in different colors?
Within the official unicode.org PDFs (http://www.unicode.org/charts/PDF/U1F300.pdf), these are portrayed only as having different types of crosshatching.
Is there any current mechanism that would allow for specific characters to be rendered in a specific color, based only on its codepoint, and not any other rich-text formatting? (eg. a color property within TrueType or OpenType font files)
From the Unicode FAQ: Emoji and Dingbats, bolding mine:
Q: What about characters whose name specifies a color?
A: Some of the characters from the core emoji sets have names that include a color term, for example, BLUE HEART or ORANGE BOOK. These color terms in the names do not imply any requirement about how a character must be presented; they are intended only to help identify the corresponding character in the core emoji sets. Even names of symbols such as BLACK MEDIUM SQUARE or WHITE MEDIUM SQUARE are not meant to indicate that the corresponding character must be presented in black or white, respectively; rather, the use of black and white is generally just to contrast filled versus outline shapes, or a darker color fill versus a lighter color fill. [PE]
There was quite a bit of debate on the mailing lists at the time on whether these should be named with colors, or generic names that didn't reference color, and whether that was setting a bad precendent. The Emoji Symbols: Background Data includes "old names" such as APPLE-1 instead of RED APPLE and BOOK-3 instead of ORANGE BOOK.
The final names use this principle:
Symbols with an inherent color shall bear this color in their
name unless the entity denoted by the name has identifies the color
anyway (e.g., a BANANA is uniquely yellow and therefore does
not need to be called YELLOW BANANA, while a RED APPLE must be
named so as there are also green apples).
Unicode 6.1 have a feature to change glyph for the same unicode code point, by specifying Variation Selector(U+FE0x).
For example, left-pointing triangle(#"\U000025C0", β—€) can be colored by adding "\U0000FE0F" ◀️* and non-colored by adding "\U0000FE0E" as suffix. (#"\U000025C0\U0000FE0E", β—€οΈŽ**).
*looks default on Mac OS X 10.8**This is default on Linux.
From https://learn.microsoft.com/en-us/typography/opentype/spec/otff#tables-related-to-color-fonts:
Tables Related to Color Fonts
COLR: Color table
CPAL: Color palette table
CBDT: Color bitmap data
CBLC: Color bitmap location data
sbix: Standard bitmap graphics
SVG : The SVG (Scalable Vector Graphics) table
In short,
CBDT/CBLC contain colored bitmaps (in PNG). They were proposed by Google.
sbix contains colored bitmaps (in JPG, PNG, or TIFF). It was proposed by Apple.
COLR defines one or more accompanying color glyphs (in vector format) for each glyph, and when they are overlapped they create the final colored glyph. CPAL defines several color themes (dark-on-white, white-on-dark, ...) since COLR is merely paletted images. COLR/CPAL were proposed by Microsoft.
SVG was proposed by Mozilla and Adobe. It may be used with CPAL.
FreeType (part of Android, iOS, and macOS) supports CBDT/CBLC and sbix since 2.5 and 2.5.1 (released in 2013), and COLR/CPAL since 2.10.0 (released in 2018). DirectWrite (part of Windows) supports COLR/CPSL since 8.1 (released in 2013) and all four above since 10 1607 (released in 2016).
Noto Color Emoji (default on Android) uses CBDT/CBLC. Segoe UI Emoji (default on Windows) uses COLR/CPAL. Apple Color Emoji (default on iOS and macOS) uses sbix.
See also https://en.wikipedia.org/wiki/OpenType#Color
I don't know that there's any standard mechanism for colored fonts, but obviously there are colored fonts. For example, the emoji font in iOS and OS X. Emoji characters in any text view on OS X will result in colored symbols, and they won't be affected by choosing a text color. These emoji even show up in Terminal.app.
(From this page.)

font with graphic "blackspace" character

I'm looking for a font which contains a graphic character which is (essentially), the space character, inverted. I'm looking for a graphic character equivalent to the largest-possible solid-black box. The closest I have been able to find is Wingings 2 character 162, but that doesn't fill the entire available character space. When I insert two consecutive Wingdings 2 162 characters, there is still appreciable whitespace between them when displayed or printed. Does anyone know of a black-box font/character which would fill all available character space?
All characters are going to have whitespace between them, or they would be unreadable. This is called "kerning". You can adjust the kerning and line-height in whatever program you are using to send the malicious fax, if you want to be sure to use the maximum amount of toner per page.
Have you considered creating your own font using a software package like this or like this? You could edit the space character to be a solid black square. But as Chris McCall mentioned, you may still have space between characters of any size due to kerning applied by the layout engine that draws the fonts.
You other option is to owner draw your own text and programmatically replacing spaces with black boxes. You would have complete control over kerning and everything else.
I don't know if this is exactly what you were looking for, but...
I was looking for the same thing, since I wanted to create a "textbox" when I wanted to write text using the spritefont, but I never knew how long the total string was going to be, so I wanted something that I could "write" in the same location right before the string with a contrasting color which could be expected to be as long as the string it needed to encompass. That being the case, try:
Webdings - character 103.
I tried lining them up and there wasn't even any space in between. Perfect.