Where are the cute yellow blobs? #185
Comments
|
Gone, but not forgotten.
It is possible to go back in git history and get the blob versions of the
images you want, then rebuild the color emoji font with a custom image set.
You'd still have to install the font on the devices you use, though. I
think on Android you have to root the device to install custom system fonts.
…On Nov 18, 2017 6:42 PM, "Justine Tunney" ***@***.***> wrote:
[image: emoji_u1f625]
<https://user-images.githubusercontent.com/49262/32986849-b2ddaf16-cc8f-11e7-8878-0d4f4782007e.png>
I had a feeling this day would come.
Please bring back the cute little yellow blobs.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#185>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJepDLN5VYdtXUk5TUW0hkwuczot4Arxks5s35WvgaJpZM4QjOz4>
.
|
|
That makes me sad, because those yellow blobs were the reason why I adopted Google Hangouts. So I hope Google reconsiders. If not, then I'd at least like to have the choice to easily opt in to yellow blobs, on websites I operate. I'm noticing that the only place where a yellow blob font file still seems to exist, is What I would like to see happen is a woff2 upload to GCS (and hopefully the other formats too, and ideally via Google Fonts) so I can do something like this: @font-face {
font-family: 'Yellow Blob Color Emoji';
src: local('Yellow Blob Color Emoji'), url(https://fonts.gstatic.com/s/yellowblobcolor/v18/uYECMKoHcO9x1wdmbyHIm3-_kf6ByYO6CLYdB4HQE-Y.woff2) format('woff2');
unicode-range: U+1F300-1F5FF, U+1F600-1F64F, U+1F680-1F6FF, U+1F910-1F9EF, U+2600-26FF;
} |
|
Using color web fonts in browsers is still very complicated. OpenType has four different ways to store color glyphs (SVG, sbix, CBDT and COLR), each operating system supports only some of those (or none), and each web browser engine supports some or none, depending on the operating system it is running on. |
|
Wow I didn't know showing color fonts in a browser would be that complicated. Thankfully we have the Google Fonts service. @davelab6 @garretrieger @laerm0 I would like to see the priority of google/fonts#1173 elevated so we can serve the cute yellow blobs. This is the kind of problem Google Fonts was invented to solve. I'm sure you guys remember back in the day when no one could figure out how to serve the hodgepodge of EOT, TTF, OTF, WOFF, and WOFF2. Google Fonts was our savior. But as we converge on a future where everything supports WOFF2 I'm sure you're all hungry for a challenge. |
|
I think WOFF and WOFF2 are mostly about how the font is packaged and delivered, but at a lower level it is still similar to ttf or otf "on the inside". Wikipedia says:
... And since the only standards for color fonts we have are baked into Opentype, and WOFF includes Opentype fonts, (these days TrueType and Opentype are basically the same thing) WOFF/WOFF2 inherits the features and issues of Opentype wrt color emoji support. tl;dr WOFF2 has Opentype in it, and as @twardoch mentioned, browsers and OSes are still working on color support in Opentype fonts. I think many people are shocked by how hard color fonts are, myself included. (That said, there is no technical barrier to making a .ttf or .otf with the old blobby emoji, converting that to a .woff, and serving that, just that support on site visitors' browsers will be hit and miss for now. Ubuntu should be fine by next April: Source. I believe this font as a WOFF works in at least Edge ["contributor" note: I am listed as "contributor" here, but my commits were only a few minor fixes to some SVGs. I don't really develop for this repo, nor have any expert knowledge, I'm just somebody interested in browser support for color emojis.] |
|
I think you can skip WOFF for color fonts and create a WOFF2 file directly as the browsers that supports color fonts also supports WOFF2. And happy to now that color fonts are coming to Ubuntu next year! 🎉 We'll update the dedicated color fonts website then! @DeeDeeG Do you know which formats Ubuntu will support? (OpenType-SVG, sbix, COLR, CBDT? - only one or multiple?) |
|
The difference between WOFF2, WOFF, EOT and TTF has been quite trivial, because those formats differ in compression only (it's really like the difference between .tar.gz, .zip and .rar). Color fonts present a challenge. First, they're very new so there are still tons of users who don't have OSes capable of rendering them yet. So what should Google Fonts serve as fallback? Monochrome fonts? (We're not just taking here about a particular flavor of emoji — color fonts can represent any text characters). Or maybe some complicated polyfills that replace color glyphs with bitmaps or SVGs? Are such polyfills available? Since color font support is a moving target, the way they're served by Google Fonts would need to be updated often. At this point, having a viable infrastructure for serving color web fonts would be quite high maintenance. And there aren't yet to many opensource color fonts that users would be dying to see on their webpages. Doing it just for the blobs is tough to justify the effort. There is also the actual problem of what the color fonts can be: the COLR flavor supports just plain vectors and simple fills, the SVG flavor is vector+bitmaps, with gradients, strokes etc. The CBDT and sbix flavors are PNGs packed inside a font. So not every flavor can render each artwork. The COLR flavor would work for your blob-style emoji but not for emojis in the style for iOS. Then, there is the file size. The sbix flavor supported natively by iOS and the CBDT flavor with native support on recent Androids are both PNG-based inside. The Apple Color Emoji font that ships with iOS is over 90 MB large! That's because the emoji are stored in several master sizes up to 1024px. When a website uses only a few emoji, it would be stupid to serve a 90MB WOFF2 just so the user can see the blobs. So these fonts would need to be smaller. But how small? What px size should Google Fonts choose as master sizes — and how soon would they have too remake those to include bigger sizes? Of course I would love to see color fonts on the web sooner. I was involved in developing the SVG extensions of OpenType and have written about the topic over four years ago: https://blog.fontlab.com/font-tech/color-fonts/color-font-format-proposals/ Since that blog entry, things have evolved a bit, and all four flavors are part of the standard. But their platform support is spotty, in some flavors the fonts can be large, and designers haven't — in those four years — quite brought the flurry of interesting designs (though it is a bit of the chicken and egg problem). So, I'm only very cautiously optimistic :) |
|
And, as the excellent https://www.colorfonts.wtf/ website points out, Chrome currently doesn't support any color font flavor, really. I think we ought to concentrate on lobbying browser vendors to support OpenType+SVG based WOFF2 (since all browsers have an SVG renderer already, right? :) ). We can forget about the other flavors for the purpose of the web, I think. Even OT+SVG can support PNG bitmaps after all. |
|
On Mon, Nov 20, 2017 at 1:45 AM, Adam Twardoch ***@***.***> wrote:
And, as the excellent https://www.colorfonts.wtf/ website points out,
Chrome currently doesn't support any color font flavor, really.
I expect @jungshik would have somewhat more complete information on this.
|
|
Since browser infrastructure has not yet matured to the point where we can choose yellow blobs, would it be possible for Google to temporarily rollback the yellow blob turndown? Then, once we have the ability to choose, I would not object to Google moving forward with its intentions to have Android & Hangouts emoji look like all the other emojis. |
|
Hi, thanks for including me on this, but the Google Fonts team has no input on this matter. While I'm with you on loving the blobs, this decision is far above my pay grade and @twardoch is very correct on the technical issues of serving color web fonts. |
|
[Sorry all for being a bit off-topic, I wanted to address @Jolg42's question. I'll try to keep this contained to one comment.]
[Edit: Here's where support is at right now: Gist. It's still very mixed, but presumably should get better as Ubuntu updates more of their software packages (and app developers rewrite/bugfix their apps for color font support) in the run-up to Ubuntu 18.04 in April. Right now support is pretty much equivalent to Ubuntu 16.04.] I would love to say, because this is indeed exciting and interesting for us color font (emoji) lovers and Ubuntu fans. But I am just a regular user of Ubuntu, not a developer there, so I don't have the answer. I would suggest this: give the daily Live image of Ubuntu 18.04 a spin (maybe now and in a month or two from now), and try to load several formats of color fonts in various browsers. Here's where to get all four formats: sbix: copy AppleColorEmoji from a Mac you own A few things to test:
(Again, I don't know the answer, but it's easy to infer CBDT/CBLC i.e. Noto Emoji will be supported, due to @behdad's work on cairo being completed and upstreamed recently as a group effort by a few people. That's the only technical advancement I had heard of tbh, but it's well possible those patches included support for other formats, or that other work has been done and I hadn't heard of it. -- Hands-on testing, or asking the ubuntu maintainers, are the only true ways to know, though.) |
> I expect @jungshik would have somewhat more complete information on this. I'm at loss what @twardoch meant. The table in the cited web page is completely off. Only on Android ? It must be kidding. Chrome on Android/Linux/Chrome OS support CBDT/CBLT color font (web and local fonts) as well as sbix color font (local font) [1] Anyway, there's a WiP to make CBDT/CBLT and sbix supported across platforms using FreeType (see [1] I have a fix to make sbix web font work as well, but haven't submitted it because I failed to make a test sbix font to use in layout test ( https://bugs.chromium.org/p/chromium/issues/detail?id=605334 ). Or, maybe I did make a test sbix font, but simply forgot to land the CL. |
|
@jungshik can I assign this to you so you can update it when Chrome's status changes? Or perhaps we should close this and add a more specific bug and reference this? |
|
I am writing a font creation program, and it is planned to be used in a Discord Bot that builds blob fonts. As for color emoji formats, which platforms support SVGinOTF? |
That would be Firefox and other Gecko-based browsers (all platforms) and Edge (Windows) For more details I did some pretty thorough testing two months ago: For an explanation of my tests/what the results mean, see [this comment]. If you need something that works everywhere as of today, I think SVG-in-OT has the best black and white fallback behavior. That is to say you can load traditional non-color glyphs into the font in case the color glyphs aren't supported, so it works in some form everyhwere, but you would have to supply high-quality black and white glyphs, or deal with some automatically-generated black/white fallback glyphs that would be so-so in quality. There isn't a color font format that I know of with perfect support everywhere as of the moment. |
|
So having COLR/CPAL, CBDT/CBLC, sbix, and SVG tables in an OTF will guarantee all platform support? From my testing, WOFF2 isn't natively installable (so no solution exclusive to WOFF2 is viable), and from @DeeDeeG's testing, SVGinOTF isn't supported natively in all environments. Firefox and Chromium support OTF via |
This is a bit pedantic but I want to clear this part up... OTF is almost like a "container format" at this point... Any browser will recognize that a proper OTF file is a font file, and attempt to treat it as such. In that sense, OTF is universally supported by modern browsers, whether in However, when the browser digs into the various font tables, their support for all OTF features is hit-and-miss. That's what my tests show. (Okay, if your argument is, no modern browser is fully compliant with entire OpenType spec, since they don't support all the new color font tables, I'd agree. Sorry for being pedantic... Just wanted to be crystal clear, since these threads tend to stick around and continue to get read for a long time. Moving on to the meat of your question...)
As far as I know, having all four formats' tables in the same font hasn't been tested much in the real world. There is no reason, looking strictly at the OpenType spec (if I recall correctly), that you couldn't do that. That said, there are some problems you'd likely run into due to how browsers treat fonts in
These are due to browser implementations, so you can file bugs with the browser makers to get it fixed, or else you might want to avoid the sbix table for now. (Compatibility note regarding black/white glyphs: At the moment, if you do include black/white style glyphs (glyf table), they would show for IE on Windows, and Chrome/Opera on macOS, and possibly other browsers as well. Personally, I would recommend getting something in the glyf table for every emoji you want to show up. The alternative would be some way of automatically posting a PNG or a JPEG of the emoji directly on the site (not in a font file) when your color font isn't supported. I think GitHub and Slack do that, and Twitter probably does too. Don't quote me on that, though.) (P.S. I think black/white glyphs can be in either glyf/loca tables, a cff or cff2 table, or even ebdt/eblc tables) |
|
If you're upset about lack of cross-platform support, maybe file some bugs (or comment on existing bugs) with the browser vendors? (Especially if you want to make/publish/use a font in one of these formats but lack of support is holding you back. Please be respectful to the devs, also.) Here's what they're all up to, near as I can tell:
|
|
You can have a font with all four color formats in them. The test font in ChromaCheck, a JavaScript test to check browser support for all four formats, originally had all four formats in one file. To make the test more robust I eventually created separate fonts, but for regular use you can combine them — if you don't mind the huge size it'll most likely have, and the fact that it's wasteful to send formats over the line that will not be used. So it would be better to use ChromaCheck to check which format is supported, and serve only the corresponding font. @DeeDeeG Thanks for that overview! I'm not interested in any of the bitmap formats, but it'd be cool to get wider support for OpenType SVG and COLR! |
|
@DeeDeeG The purpose of having the OTF have all 4 tables in my case is to be installed natively. In a web environment, this is proven to work by the above, but will operating systems support all tables in the same file? |
By "installed natively," do you mean "built into a font on the web, served via
It's not really clear what you mean here... Windows has some issues installing pure CBLC/CBDT or pure SBIX fonts. macOS has issues installing a pure CBDT/CBLC font. I haven't tried installing a font with all four formats in it, so you'd just have to find (or make) such a font and try it. If you mean "can I use it in Microsoft Word?" the answer is, it depends on how Microsoft Word is programmed, with regard to how it handles fonts. A totally separate, independent question would be "Can I use it in Notepad?" or "Can I use it in Firefox?" because each application has its own way of dealing with fonts. There is a mixture of apps using underlying OS support for fonts, and just each app rolling its own code to deal with fonts. It's very hit-and-miss. |
|
@jart you could try this one: it worked for me ;) |
|
+1 Bring back the old emojies!!! |
|
+1 on the new emojis are bland and poorly executed, the old ones were individually good enough to put on t-shirts.
Case in point, I have a t-shirt with this one on it, and I would love to see hangouts/android go back to the set which contained it. It's a mistake to mess with such success. |
|
is weird that i have android 7.1.1, and in notifications i still see the blobs |
|
The blobs weren't changed to the circular emoji until 8.0 @asturur |
|
oh so i m not updating :) |
|
Android decided years ago to change the emoji style, and there have been no updates to the blobs since. That horse is out of the barn. The images we maintain support Android's requirements, so we won't take changes that revert them to the blob style, and there is no funding to create new images in that style. Currently the repo is not structured to support multiple stylistic variants of the emoji, though it's relatively straightforward to build a font with whatever images you want as long as they are the expected format and size. |
|
The blobs might not have a future as Google's flagship emoji, but they could have a new home with the community if you start a GitHub repo for them. For example, MS-DOS was recently immortalized on GitHub by Microsoft. Could we do that? |
Yes, as long as you follow the license, you are free to modify and distribute this project or older versions. But it's a lot of work to update the font for the new Unicode versions every year. Here's one project that is trying to maintain the older emoji style: |
|
I love the blobs but this repo will continue to track Google's latest emoji. |
I had a feeling this day would come.
Please bring back the cute little yellow blobs.
The text was updated successfully, but these errors were encountered: