I wouldn't rule out Apple standardizing their approach. I contacted Peter Lofting about this, but I don't think their schedule aligned with most recent set of Open Font Format updates.

A second question would be is their approach the best one for emoji? Would the SVG effort being led by Adam and picked up by Adobe be better? http://www.typecon.com/archives/646

First I'd like to know if the Apple stuff
is bitmaps, or color-gradated layers of
vectors, or what.

hhp

I'm pretty sure that even when Adobe starts shipping color vector emoji fonts they still won't put a glyph palette in Photoshop ;b

If it's the same as on the iPhone, it's PNGs in two sizes in a proprietary »sbix« table.

I had a day off recently and nothing better to do than hack the Apple Color Emoji font from the iPhone. I figured out the »sbix« table format and extended the Python FontTools so that I was able to decompile the table and extract the glyph images. The PNGs are in a different format than usual, supposedly to be rendered faster on the iPhone's processor, but I found a Python script that converts them to the standard PNG format.

BTW anybody could do that with a little web research and general knowledge about font formats, no Apple-specific insider knowledge required, let alone NDAs ;)

I think if Apple want to extend the support for this to more and different devices, with different resolutions, a vector-based approach would be better.

Jens, awesome! You da man.
(And then these artists complain about engineers ruining their lives...)

Next questions:
- You can extract, but can you also embed your own?
- What are the two sizes, and can you choose your own?

> a vector-based approach would be better.

For overly-emotional cartoon faces, sure.
But I'm thinking of handmade subpixel letterforms.

Concerning which: Is there a way (at least for an app)
to lock the orientation switching in an iDevice? Or is
there a way to make the colorfont being displayed
dependent on the orientation?

hhp

Apps can lock orientation switching, yes.

Sii> Would the SVG effort being led by Adam and picked up by Adobe be better?

It seems really short-sighted and silly to keep pushing svg, because all kinds of graphics effects perfectly possible in ttf or CFF including simple stuff like contour and fill don't work with ttf on the web!?... Fonts and what one needs to know are just getting fatter, and not smarter, and by the time the inexperienced are through we will wonder why WOFF or sfnt are no being intelligently built on. Instead, more, more we must be somehow useful instead of smart, keeps "winning" over thoughtful process.

Personally, I think just because emoji pushed the boundary for text encoding -- and you should have heard the arguments about that in Unicode circles! -- that doesn't mean they need to push the boundary of what constitutes a font. There is no reason at all that text encoded characters need to be represented by glyphs in a font; they could just as easily be represented by any indexed collection of bitmaps, vector graphics or, for that matter, robots with spraycans.

I think there are acceptable reasons why we might want to be able to incorporate colour into fonts in future: mostly in display type, of course, but also for text in some scripts that have traditionally used multi-colour signs (Ethiopic is an obvious example) but have been unable to do so in typography. But rushing to a bitmap-in-font solution as Apple have done to solve a particular use case for emoji seems to me shortsighted in a way that makes Adam's tentative analysis of the SVG option really very thoughtful in comparison.

Well John, II know from the past and in this case, that Apple, likes to first get stuff done to keep their constituency moving along and integrated. Later when everybody else figures out the right thing to do they join whatever standard works to maintain that integration and keep getting their platform Smarter. I also know that ttf and OT flavored ttf represent the majority of web developers in bringing quality text and quantity fonts to all platforms, and making the web possible on Windows, since the web was launched and remains the unsung hero format of the largest web constituency.

But who da hell do Adam and Adobe represent? Who is their constituency?

There are, broadly, two approaches to standardisation. One is that you makes something and then try to get other people to accept it as a standard, on the basis of its technical merits an/or the basis of its implementation. The other is that you recognise a need for or a benefit to standardising something and you sit down and start spec'ing a standard before you start making something.

Much of the mess that Web developers have to deal with is the fallout of a history of individual companies making things for their own 'constituencies' (customers, user base), rather than creating and following standards. And that includes the mess that is cross-browser text rendering, which you have elsewhere suggested should be standardised rather than treated as an area of competition.

Adam doesn't have a constituency. Which suggests that he's going to look at ideas based on general benefit and technical merit rather than corporate advantage.

I'm not faulting Apple for rushing to market with a colour bitmap in font solution for emoji, which serves their constituency and keeps their phones in a competitive position. I'm saying that a) there are use cases for coloured display of encoded characters that go beyond emoji, and b) a bitmap-in-font implementation doesn't seem like a good long-term basis for standardising support for such use cases. You said that SVG was ‘silly and shortsighted’, and I'm saying that colour bitmaps is shortsighted.

Specifically, you said that pushing SVG was silly and shortsighted in light of the problems we already have with TTF rendering on the web. But that doesn't follow, because while TTF rendering has been treated as an area of competition, and hence of differentiation and non-standardisation, by OS and browser makers, SVG is a Web standards project, and there is better chance of getting cross-browser compatibility in SVG rendering that there is in TTF rendering. Note that this is not to suggest that SVG can replace TTF as the text font format of choice for the Web, but that the rendering problems of TTF are independent of whatever might be done with SVG. So it doesn't make sense to me to criticise SVG on the basis of what doesn't work in TTF on the Web.

>Adam doesn't have a constituency.

Probably, but you could argue that a new version of FontLab supporting OT+SVG fonts would probably be a good seller. But I agree he probably suggested it for the reasons you mention.

Not Sii

I feel sorry for people who don't know, put words in my words and run away from even smallest intellectual challenge.

When any of you circle can go from drawing to serving in your web font efforts, like me, I'll be the first to listen again, if I feel like it.

Until then, pity the developer, pity the publisher, pity the reader, my constituecies, keeping them as far from you and your broken ideas as humanely possible.

I don't think I'm putting words in your words. You asked about constituency... Adam works for FontLab, so there might be a connection there: FontLab customers. FontLab has been interested in colour fonts since well before Apple and Google's emoji encoding push. You may recall PhotoFonts?

A few remarks:

First, the discussion is not about SVG Fonts but about SFNT-based fonts (i.e. OpenType fonts) that include an SVG table for outline description.

Thinking only of SFNT-based fonts with glyf|CFF table plus SVG table (meant to add a handful of colored glyphs to otherwise black glyphs defined in the glyf|CFF table) is shortsighted. It makes things unnecessarily complicated, like aksing for an extra mechanism to replaces glyf|CFF-table glyphs by SVG-table glyphs.
That is, besides SFNT-based fonts with glyf|CFF table plus SVG table, also include SNFT-based fonts with only an SVG table in your scenario.* SVG-only SFNT-based fonts have a few advantages:
–1– Outline description can be in either cubic or quadratic bezier curves, which allows designers to choose and stick to their preferred format.
–2– And they can make a outline format choice without making an implicit choice between CFF or glyf table. SVG format is just some friendly text.
–3– If there is only one outline description table, GSUB and GPOS can – as with normal glyf/CFF-only fonts – kick in. You can design a full-color glyph set. You can design a mostly black glyph set and a few colored glyphs, and then use a Stylistic Set OTL feature to replace default black glyphs by colored alternate glyphs. You can design a mostly black glyph set and a few encoded glyphs in color (the emoji example) when these are colored by default.
(Ignoring what may or may not be considered disadvantages of the SVG format and/or its current support.)

The pixel vs outline discussion seems pointless. Each serves a purpose. Existence of Illustrator/Freehand did not render Photoshop useless, nor the other way round.

* Mr Patel made an interesting remark on the OT List (9 July 2011), that an SVG-only SNFT-based font may need another version identifier. Which makes me wonder, though, why glyf|CFF-plus-SVG SNFT-based fonts are supposed to continue using 0x00010000 or OTTO version identifiers ...

"Mr Patel made an interesting remark on the OT List (9 July 2011), that an SVG-only SNFT-based font may need another version identifier. Which makes me wonder, though, why glyf|CFF-plus-SVG SNFT-based fonts are supposed to continue using 0x00010000 or OTTO version identifiers ..."

Fonts that also have glyf or CFF table are backwards compatible with existing font-consuming apps/OSes. So they can maintain the existing identifiers. Fonts that lack these existing tables would not be backwards compatible and would need a new identifier.

Cheers,

T

Karsten: The pixel vs outline discussion seems pointless. Each serves a purpose. Existence of Illustrator/Freehand did not render Photoshop useless...

No, but Photoshop stores text and geometries internally as vector graphics. Yes, bitmaps and vectors each serve a purpose, but the purpose of scalable shapes is better served by vectors. Bitmaps are fine if all you need is a couple of discreet sizes for screen display at known resolutions, which is Apple's immediate situation with regard to emoji support, but I presume they would acknowledge that this doesn't constitute the whole picture of multicolour, scalable text.
_____

I agree with you completely re. sfnt fonts with SVG only. It makes no sense to spec SVG as a secondary glyph source that also requires a glyf or CFF table, although that configuration should be made possible. For fonts that have both SVG and another outline table type, I can imagine a dedicated cmap subformat pointing to the former for a subset of characters (an analogue would be the format 14 cmap for variation selector sequences). An SVG-sfnt savvy app could check this cmap first, and render any codepoints assigned in it using the SVG table, and then render any remaining characters using the next platform appropriate cmap.

Thomas: This makes sense.

John: I didn't intend to start or contribute to a bitmap vs vector discussion; as a hint, I better remain silent about how useful I find PhotoFont. As to glyf|CFF-plus-SVG fonts and glyph substitution/mapping, Mr Patel's original proposal offered a quite straightforward solution, and something similar was discussed on one of the W3 lists (1 July 2011). Both seem useful – if implemented as a separate table: Including the glyph substitution/mapping mechanism in the SVG table does not make sense because it is unnecessary in SVG-only fonts. I am not sure about including adding another subtable to cmap, for a similar reason: According to proposals so far, what is needed is mere GID to GID mapping rather than codepoint to GID mapping. And according to proposals so far, SVG-glyphs are meant to be alternates of glyphs covered in glyf/CFF, which suggests that an independent substitution/mapping table is the better choice, e.g. you could remove or add SVG table plus substitution/mapping table without need to dissect cmap.

I was thinking in terms of ways to select SVG table glyphs without having to get into glyph-to-glyph mapping, which is typically slower than cmap mapping. Just an idea. And yes, I know, processor power these days makes these sort of questions moot, but old habits die hard.

I worked on my code some more and present to you: How to generate colour bitmap fonts.

Great work, thank you (and FontShop)!

FYI:

Last week on the OpenType list Google announced a competing color bitmap proposal...

https://color-emoji.googlecode.com/git/specification/v1.html
https://code.google.com/p/color-emoji/

Cheers, Si

Now we're talking!

hhp

... So... Adobe and Microsoft may choose an OpenType color bitmap standard between two put forth by Google and Apple?... What time is that on? and i hope it doesn't interfere with tonight's penguin roast.

So do you think Apple and Google are wasting their time?

hhp

Colour bitmaps are likely to be an adjunct format, just as embedded b/w and greyscale bitmaps are. The most likely scalable colour font implementation seems to be some form of the SVG-in-OT model. That currently has two draft forms, from Mozilla and Adobe. These will probably merge, but it's early days, so someone else may come along with something more compelling.

I make these comments as a bemused observer, whose interest in multicoloured glyphs doesn't extend much beyond the Ethiopic paragraph marker.

Adjunct, yes, but on occasion it can do the heavy lifting (in terms of readability). Picture a few hand-tuned sizes that can make a real difference on modest-res screens (with the OS snapping to them (if set to do that)).

hhp

>... So... Adobe and Microsoft may choose an OpenType color bitmap standard between two put forth by Google and Apple?

Actually OpenType (as the Open Font Format) has been standardized through ISO, so members (not just Microsoft and Adobe) can decide if they support the Google proposal being part of the standard. Apple hasn't submitted their format for standardization AFAIK.

Cheers, Si

http://cacm.acm.org/magazines/2013/7/165480-diffusion-curves/abstract?ut...
(Thanks to Kemie Guaida, via Twitter.)

hhp

I don't have an ACM account -- Is this new article significantly different from the 2008 version? (http://artis.imag.fr/Publications/2008/OBWBTS08/diffusion_curves.pdf)

I wonder what will happen when you dump character outlines into it. Would that result in something like Speed Punk's images?