Is it possible to use NotoColorEmoji.ttf?
brandoncc opened this issue · 5 comments
I'm trying to get emoji rendering working, and I'm failing. I'm trying to use NotoColorEmoji.ttf and I am experiencing this error:
2020-03-09T00:23:31.723Z 35337 TID-ouxjoy04c WARN: NoMethodError: undefined method `key?' for nil:NilClass
2020-03-09T00:23:31.723Z 35337 TID-ouxjoy04c WARN: /Users/brandoncc/.rbenv/versions/2.5.7/lib/ruby/gems/2.5.0/gems/ttfunk-1.6.2.1/lib/ttfunk/table/glyf.rb:32:in `for'
/Users/brandoncc/.rbenv/versions/2.5.7/lib/ruby/gems/2.5.0/gems/ttfunk-1.6.2.1/lib/ttfunk/subset/base.rb:105:in `glyph_for'
Here is my list of fallback fonts:
def fallback_fonts
[
'NotoColorEmoji',
'IPAGothic',
'IPAMincho',
'IPAPMincho',
'IPAPGothic',
'WenQuanYi Zen Hei',
'DejaVuSans',
'DroidSans',
'DroidSerif'
]
end
All of the other fonts work, but many of the emojis just render as boxes.
Any points on either another way, or getting this font to work, would be appreciated. Thanks!
The NotoColorEmoji font cannot be used because the font outlines are not stored in the standard TrueType glyph font table but in a separate, special font table that supports colors. And this special table is not supported by ttfunk.
In short: It is not possible to use a font with colored glyphs with ttfunk.
Thanks @gettalong. I guess that must be why I keep seeing recommendations of using Japanese fonts (which I am also doing, but many emojis are not supported).
I'm still struggling with this. is there any chance there will eventually be support?
Thanks!
The reason why this is not that easy to support are manyfold. For example,
- ttfunk would need to be updated to correctly parse and interpret the necessary TrueType/OpenType tables.
- Prawn would need to support parsing Unicode emoji which means, if fully implemented, support for knowing Unicode composite glyphs that are described using multiple Unicode codepoints (e.g. smiley emoji + zero width joiner + dark skin color). I don't know the specifics but this is probably implemented in the font by using the various glyph positioning and substitution tables.
- Prawn would need to gain the ability to interleave the emoji images (these are not standard glyphs but real PNG/SVG/JPEG images) in text. Which would most probably mean a complete overhaul of the implemented text support due to how it is currently implemented.
So your best bet would be to do the Emoji parsing yourself, output the text before, output the emoji (taken from a list of images extracted from the font), output the text after.
You might want to look at asciidoctor-pdf which has implemented support for inline images. Generally, that codebase extends Prawn in many ways and is a good resource to find solutions to common text layout problems. It is rather huge, though.
Thank you for that excellent information @gettalong. I suspect that https://github.com/hidakatsuya/prawn-emoji probably implements a solution like you are describing. Unfortunately, it is unusable because of this issue.
I'm actually blown away that nobody has solved this yet. It is safe to say that I currently don't have nearly the knowledge needed to solve it myself.
Thanks again for entertaining my question!