I've just noticed that there is U+1F49C - PURPLE HEART.
I always thought that Unicode would abstract from color, hence I wonder why this symbol exists in the first place.
The next thing I wondered is how
<span style="color: red;">I 💜 Unicode</span> 💜
is supposed to look like. Should the heart be red or purple?
Chrome 61 (on Linux) makes the purple heart red. Hence it is black in normal text. But then I would expect the BLUE HEART to look identical, which it isn't (see jsfiddle).
What is the reason for this?
Related
My guns have a certain range. When hovering over one I want to demonstrate what that means. So I've added a 3d-object (a flattened cylinder) which I want to show/hide onMouse-enter/leave.
But first I need it to be transparent - I've searched and found how - It's materials rendering mode must be transparent, and the color must have an alpha value (here 128).
But it looks VERY SOLID BLACK to me...?
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.
I am stuck on a blending problem that appears to have only started once I started blending without any color. I am painting a grey suit and using shades to capture the lighting realistically. For some reason, when I paint with a dark grey over a light grey, with say 20% opacity, with enough strokes, the color I am painting will match the color in the color picker. With the reverse situation (light to dark), the paint tool never quite blends to the color in the color picker, it is always a shade or two off. No matter how many times I stroke the area, it will not become the color I have chosen. It has me dumbfounded and is crippling my ability to make light and shadow and show depth.
I have tried googling and messing with every possible option, deselecting all, triple checking what layer I am in, but I cannot seem to find anyone else with this problem...
I openned GIMP 2.8 (stable version) and the development version of GIMP and tried a procedure like the one you tell about:
Indeed, when working with 8 bit color, the wayGIMP is structured internally will prevent the gray values to converge toa precise shade of gray in same cases. When GIMP applies 20% of the difference between a value 129 to a pixel valued 127, that "20%" is a "0.4" darkening, which is rounded down to zero.
This certainly won't be dealt with on current GIMP stable, since it is fundamental to the way 8 bit color works, ansd given that GIMP unstable - the 2.9 version that will eventually be out as GIMP 2.10 can be set to use higher color precision so that this behavior does not happen. (With floating point pixel values, you just get as close as you want from your shade of gray).
I'd suggest you either find a compiled "nightly" version of GIMP 2.9 for your system, or try some other way of painting: maybe using a more spread shade of gray with values varying over a broader range, and after you are done, compressing the results to the desired range with the Levels or Curves tool.
Anyway, this is offtopic here - if you have further doubts on painting, please take the question to graphicdesign.stackexachange.com
This question is in regards to forcing emacs to use a 256 color xterm color scheme.
When you open emacs in a terminal that supports xterm-256, it defaults to the xterm-256 color scheme, where default emacs font face colors like 'Firebrick' turns into something the xterm color scheme can display, which in this case is 'Red', so on and so forth. I really like this. I do not like the default emacs colors in a non-terminal setting; I think they are too faded and washed out-- I much prefer the brightness of the terminal colors.
(In fact I find myself programming in the terminal most often simply because I vastly prefer the typeface and the colors-- but I'd like to start using Aquamacs more for various reasons.)
For the life of me, I cannot figure out how to force Emacs (or in my case, Aquamacs) to force itself to downgrade the default color scheme to the xterm 256 color scheme like it does in my terminal. There has to be an easier way than making a new, ridiculously detailed color theme, but beyond the "TERM= " command you can set in your bashrc file (which obviously Aquamacs doesn't care about or use) I can't find anything equivalent in Emacs/Aquamacs that tells it to adopt a 256 color range so that it does things like turns Firebrick into the closest 'available' color, in this case, red.
I've attached screenshots. The first is how I want it to look like. (jpeg ruins the cripsness/brightness of the colors, but you get the idea.)
Second shot here is the default 'washed out' colors in aquamacs. See how the comments are in Firebrick (correctly displayed), versus the bright red of the comments in the above pic.
Variable names show up as more yellow in the top pic, but as more 'brown' in the bottom. Strings in the above file show up as more 'light brown' whereas in the bottom, it's more a dark brown. You can see they are definitely the same color scheme-- it's just that the terminal doesn't know about some of the colors and so it converts them to their baser, brighter forms.
Anybody know how to force this in Aquamacs? I've spent far too many hours researching this. :-)
Thanks!
Nick
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.)