#999 Invisible emoji font

[Anders]

I am trying to use https://github.com/MorbZ/OpenSansEmoji for rendering emoji that can easily be input on an iPad.

This test program shows two issues:

1) The OpenSansEmoji font does not render any glyphs at all.

2) The emoji character U+1F60A (smiling face in iOS) is apparently rendered as two glyphs, making it unlikely that it would render correctly, even if the OpenSansEmoji font was visible.

Tested on tcpdf_6_0_099.

[Nicola Asuni]

This doesn't seems a TCPDF bug. Please ask help on the Help forum.

[Anders]

Yes, it absolutely seems like a TCPDF bug, or at least an undocumented limitation. I am not sure how you can come to any other conclusion.

I asked the forum for help but I seriously doubt that I will get any.

For kicks, I implemented a similar test program in Perl. It shows all the glyphs perfectly (attached).

[Jim Hanlon]

So ... in my "forum post" I wasn't really trying to imply that this is a "bug" ... but a "new requirement". Though I'm sure they exist, I've never encountered any TTF fonts that with Unicode encoding that extends beyond BMP, so IMHO an implementation of TTF that only worked in BMP fonts wouldn't be a bug, per se. But ... whatever. Because Unicode SMP fonts are fairly rare, I don't think you should be surprised if you might have to do some work to get one to work for you. I was really trying to suggest places in the code that you might look at to find the source of your problem.

FWIW, I just downloaded 6.0.99 and took a very quick look and the most glaring "16-bit" assumption is, IMO, at line 804 of "include/tcpdf_fonts.php". That loop is extracting character width (what wil eventually become entries in the "CurrentFont['cw']" table) and character bounding box (the extrema of the glyph's splines in each Cartesian dimension). The later is almost certainly not involved in your problem, by I can easily imagine code that uses an entry in the 'character width' table as a proxy for determining if the glyph exists at a codepoint. Just a grep of the source code shows expressions like:

if (isset($this->CurrentFont['cw'][$char])) {

which would surely fail as a result of the 16-bit assumption referred to above.

I suggest you focus your hunt there.

[Anders]

Don't worry, I came to my own conclusion after seeing that the font works in all other programs, including the Perl-based PDF creator library that I tried.

Telling me to ask for help on the forum is quite a roundabout way to say "that feature is not supported, implement it yourself".

[Jim Hanlon]

Cool. I really do believe that if you could rework the loop at line 804 of tcpdf_fonts there is a high likelihood that everything would "just work". There is a thing called "encoding map" that maps codepoint to glyph id and it is constructed before the character width table is constructed. My guess is that the best approach is to use the encoding table to drive the loop at 804. Your SMP glyphs should appear in the encoding map and then their geometry (cw and cbbox) will get picked up and you're off and running.

Good luck!