I know this is maybe off-topic on SO, but I don't know where else to ask. The Unicode blocks Miscellaneous Symbols and Miscellanous Symbols and Arrows contain these characters:
HEAVY LARGE CIRCLE (U+2B55) ⭕ (before emojis it used to look like ◯)
BLACK LARGE CIRCLE (U+2B24) ⬤
MEDIUM WHITE CIRCLE (U+26AA) ⚪
MEDIUM BLACK CIRCLE (U+26AB) ⚫
WHITE CIRCLE (U+25CB) ○
BLACK CIRCLE (U+25CF) ●
MEDIUM SMALL WHITE CIRCLE (U+26AC) ⚬
But there is no MEDIUM SMALL BLACK CIRCLE. Why is that? Is there an alternative for this symbol? (Ie. the same size as its white counterpart?)
According to the annotations in the chart for the Geometric Shapes Extended block, the set of differently sized black circles is ordered as follows:
U+22C5 DOT OPERATOR (⋅)
U+2219 BULLET OPERATOR (∙)
U+1F784 BLACK SLIGHTLY SMALL CIRCLE (🞄)
U+2022 BULLET (•)
U+2981 Z NOTATION SPOT (⦁)
U+26AB MEDIUM BLACK CIRCLE (⚫︎)
U+25CF BLACK CIRCLE (●)
U+2B24 BLACK LARGE CIRCLE (⬤)
⋅∙🞄•⦁⚫︎●⬤
Therefore, DOT OPERATOR serves as tiny black circle, BULLET OPERATOR serves as very small black circle, BULLET serves as small black circle, and Z NOTATION SPOT serves as medium small black circle.
These unifications with existing characters were implemented to cut down on the number of new additions needed when Wingdings/Webdings were incorporated into the standard.
Is there an alternative for this symbol?
Try • ∙ ⦁ 🞄
Why is that?
In the past, Unicode just collected existing character repertoires. If the originating did not have a medium small black circle, then for round-trip reasons Unicode would not have one, either.
You can get a definitive answer on the appropriate mailing list.
Related
In NetLogo 6.1.1, in the link editor, there are four line styles: solid, dotted, dashed, and a more complex dashed pattern.
However, when the visual representation of a link is thick, the spaces between dashes become invisible. It seems that the thickening surrounds each point in every direction, so that in thick lines, the color of the line overlaps the space between dashes.
Is there any way to edit dashes to create more space (or to produce better behavior for thick lines)?
I have a question regarding Cairo codings (http://cairographics.org/).
I have a filled rectangle (cairo_fill (cr)), how can I cut a hole in the middle of it representing for example the letter "S"?
So basically, I want to "engrave" text in that rectangle but also making the text transparent (like cutting a hole in the rectangle).
Anyone have any tips?
Set the fill rule to even-odd and use cairo_text_path() to get the shape of the letter "S", then cairo_fill() as you do now.
I have a to make an application that recognizes fruits. So far i have made that you can crop the image and get the color of the fruit you want. Now i am trying to get roundness of the fruit but i need the fruit to be black and the background to be white so i can find area and roundness value. This is my code so far for that part :
crop_temp = rgb2gray(crop);
threshold = graythresh(crop_temp);
bw = im2bw(crop_temp,threshold);
imshow(bw)
Crop i get passed when i crop the image. The problem gets when the fruit has a camera flash and that part stays white.
An example image is this lemon picture:
The problem is the white area in the lemon stays white after the code but i want it so that the whole lemon is black. But not just the lemon, but for other fruits to.
The problem is the white area in the lemon stays white after the code but i want it so that the whole lemon is black. But not just the lemon, but for other fruits to.
Yeah and how can you make so that the fruit is white and the background is black.
I am new to image processing so don't jump on me. I just can't find specific stuff for this.
Try this one:
fbw = ones(size(bw))-imfill(ones(size(bw))-bw);
imshow(fbw)
A brute force approach would be to check every white pixel in your image, and see if it is boxed in by black pixels in both the X and Y directions, turning it black if this is the case. This would take care of blobs inside your fruit, and shouldn't give you too many false-positives unless your fruit are strangely shaped, or you have a lot of noise around the edges of your image.
You can start by practicing with this Matlab demo, segmenting (and counting) rice in an image. In particular the part where the background is estimated.
Also helpful will be reading on Otsu's method and these two questions on background/foreground estimation on SO and DSP which take local statistics into account.
I'm working with this excellent example of converting an image to grayscale: Convert Image to B&W problem CGContext - iPhone Dev
However, for my purposes, I would like to have only pure black and pure white left in the image.
It appears that to do so, I need to pass a black and white color space to the recolor method using a call:
CGColorSpaceRef colorSpace = CGColorSpaceCreateWithName(/*black and white name*/);
However, I was unable to find the proper iOS color space names. What I found was from Mac, and the "color space names" referenced from the iOS docs does not point anywhere.
How can I properly create a black and white CGColorSpaceRef?
Thank you!
I am not familiar with a black and white only color space but what you can do is calculate the total average RGB value from all the pixels (lets call it totalAvg) and use it as a threshold. Meaning for each pixel if its rgb average is greater than the calculated totalAvg than set it to pure white, otherwise set it to pure black.
I agree it is a bit of more work but thats whay I can think of unless you find the colorspace you are looking for.
You might try creating a gray color space, then creating an indexed color space with two colors (black and white, obviously) and using that.
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.)