Noto color emoji font not rendering

[hernantz]

I'm using debian buster and melt 191020. I've installed the fonts-noto-color-emoji package.

$ fc-match emoji
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"

But when redering the following xml, the emojis do not show up in the final video:

<property name="mlt_service">dynamictext</property>
<property name="argument">M 🎅ANY THANKS!</property>
<property name="geometry">
2.8823532941176464%/19.166667333333333%:103.83137198055492%x54.61666666666666%:100
</property>
<property name="size">500</property>
<property name="halign">center</property>
<property name="valign">middle</property>
<property name="family">AmaticSC</property>
<property name="weight">700</property>
<property name="style">normal</property>
<property name="pad">20</property>
<property name="bgcolour">#00000000</property>
<property name="fgcolour">#ff222222</property>

Any ideas on how to troubleshoot this?

[ddennedy]

You might need to an XML entity to include the emoji. Also, you might need to use a font that supports it. I am not certain if AmaticSC can. qtext and dynamictext cannot switch fonts to something special and unidentified to handle an emoji. Even with those combined, I am not certain it works. I have NotoColorEmoji.ttf as well, and it did not work for me even if I use the entity and changed the family property to Noto Color Emoji. I guess we can simply say this is not supported at this time.

[bungeman]

Taking a quick look at producer_qtext.cpp, it looks like the strategy is to retrieve the path of the text and then draw the path. However, Noto Color Emoji is bitmap only (CBLC/CBDT) and does not contain any paths. I would expect the same behavior for fonts like Apple Color Emoji (sbix) as well. Fonts with like Segoe Color Emoji (COLR) will report the outline of the base glyph and not the color version.

Support for mutli-layer or bitmap glyphs will require using a different interface than just paths. Supporting color glyphs will also force some kind of decision about how color coverage should be handled (the current assumption is that glyphs are coverage only).