Closed Mottie closed 7 months ago
I believe this is required for opentype.js to support emoji fonts.
@mqudsi Yes but actually it depends on the platform as Google's emojis are in CBDT
CBLC
tables, Microsoft's COLR
CPAL
, Apple's sbix
Supporting a single standard is a whole lot better than not supporting any of them. As a first step I would suggest having the forEachGlyph function to return information about what character it can't render allowing things like emojis to be handled as exceptions in user code rather than returning glyph 0.
@talltyler the problem you're describing needs to be fixed, check the issue https://github.com/nodebox/opentype.js/issues/168 for more info
I've addressed first issue in #297. The next issue has a few parts. We can only render vector paths. Color also isn't currently managed within the core code. If we are supporting bitmap fonts we should maybe talk about what other things we want to support. Also should we talk about how fallbacks fonts should work. After looking at these different table types, personally I don't like sbix as much as the other two. But adopting full SVG support has a few issues https://connect.microsoft.com/IE/feedback/details/809823/draw-svg-image-on-canvas-context but I also wonder what kind of browser support this library is trying to hit? If we don't think SVG is going to fly sticking with one of the bitmap focused formats might be best. Also SVG animation wouldn't be able to be supported unless we made a svg parser and managed all of this in code.
Is this the issue why I get a "Error: Font doesn't contain TrueType or CFF outlines" message when uploading "Noto Color Emoji" font (google.com/get/noto/#emoji-zsye-color)?
@talltyler I somehow missed your comment, and you raise some very good questions. Font rendering was never easy, but now it's become a whole new level of complicated. But I think the goal behind the adoption of SVG and not a new vector/path markup language is to enable developers in need of rendering glyphs and symbols like this to make use of already existing, battle-tested libraries instead of needing to reinvent the wheel. I'd argue that the creators of the OpenType standard would probably be aghast to discover people thought it meant they had to write their own SVG parser and animation library to support these new features. 😉
FYI this is a highly requested feature over at Glyphr Studio. This, plus supporting Non-BMP ranges (which was fixed in #338) is crucial to supporting emojis... which people seem to be interested in at the moment :-D
COLR/CPAL +1
Add COLRv0 + CPALv0 support in : https://github.com/opentypejs/opentype.js/pull/490
As far as I can see, merging #490 should have closed this issue, right? Any objections?
SVG fonts are not the same as color fonts. The SVG table is mac specific, we should support it and the other methods of rendering emoji.
Microsoft is not adopting the SVG table btw, only apple.
SVG and COLR/CPAL are both now supported.
It looks like Microsoft is adopting the openType SVG color fonts format, so adding support for the SVG
colr
andcpal
objects would be necessary.I was trying to see if I could figure it out myself, but I am just now learning how to process
ArrayBuffer
objects andDataViews
. That combined with figuring out an unfamiliar code base would take me a long time. I won't stop trying to learn, and I'll still work on adding this feature in my free time, unless someone beats me to it.Useful links:
SVG
table details (since it doesn't appear to be included in this library).COLR
(color) table details.CPAL
(color palette) table details.