U+1F1EB and friends have gone missing

[GoogleCodeExporter]

It may be a FreeType bug, a chrome bug, or a font issue.

But I basically get a capital gamma when I display the character as 15px in 
Chrome at 100% zoom.

Behdad, since you probably have a setup similar to mine, would you take a quick 
look to see if you can reproduce?

Install the font from 
https://code.google.com/p/noto/source/browse/fonts/individual/unhinted/NotoSansS
ymbols-Regular.ttf

Here's the snippet for Chrome: data:text/html;charset=utf-8,<span 
style="font-size: 15px;">&#x1f1eb;</span>

Attaching a screenshot.

FreeType version 17.1.11
Chrome version 36.0.1985.103 beta

Original issue reported on code.google.com by roozbeh@google.com on 11 Jul 2014 at 9:07

[GoogleCodeExporter]

Attachment added.

Original comment by roozbeh@google.com on 11 Jul 2014 at 9:08

Attachments:

• F-to-gamma.png

[GoogleCodeExporter]

+werner

Confirmed with pango-view.  FreeType autohinter fail.

Currently FreeType hints the U+1F100..1F1FF Enclosed Alphanumeric Supplement 
(and the non-supplement one) with Latin, whereas fonts typically have smaller 
letter shapes for these.  I think they need to be separated and treated 
differently.

Or maybe the fact that an entire stem is being lost is a bug on its own that 
can be fixed.

Original comment by behdad@google.com on 11 Jul 2014 at 9:24

[GoogleCodeExporter]

Note that the stem appears again in smaller and larger sizes. Something happens 
at 15px.

Original comment by roozbeh@google.com on 11 Jul 2014 at 9:30

[GoogleCodeExporter]

This is certainly an autohinter bug.  It gets confused by the lack of bluezones 
and existence of the dotted box around the glyph.  The part of code that is 
misfiring looks wrong to me.  This branch:

diff --git a/src/autofit/aflatin.c b/src/autofit/aflatin.c
index a1f2b33..1de6c10 100644
--- a/src/autofit/aflatin.c
+++ b/src/autofit/aflatin.c
@@ -2603,7 +2603,7 @@
         edge->flags  |= AF_EDGE_DONE;
         edge2->flags |= AF_EDGE_DONE;

-        if ( edge > edges && edge->pos < edge[-1].pos )
+        if ( 0 && edge > edges && edge->pos < edge[-1].pos )
         {
 #ifdef FT_DEBUG_LEVEL_TRACE
           FT_TRACE5(( "  BOUND: edge %d (pos=%.2f) moved to %.2f\n",

Werner, any chance you can take a look at this?

Original comment by behdad@google.com on 14 Jul 2014 at 11:03

[GoogleCodeExporter]

I'm on vacation right now so it will take some time until I can work on this.  
However, I guess that the `BOUND' action misses an additional constraint – 
I've contacted David Turner whether he can remember a typical usecase for it so 
that I can implement something sensible...

Original comment by lemzw...@googlemail.com on 15 Jul 2014 at 2:36

[GoogleCodeExporter]

This works for me using pango-view, so perhaps it has been fixed?  Behdad can 
you confirm?

Original comment by dougf...@google.com on 21 Apr 2015 at 5:30

[GoogleCodeExporter]

Still reproduces for me:

pango-view --font='Noto Sans Symbols 15px' 
--text=`~/hb/test/shaping/hb-unicode-encode 1f1eb`

Note the "15px".  Or you can use 15 with --dpi=72.

I also didn't see any fix for this going in.

Original comment by behdad@google.com on 21 Apr 2015 at 5:42

[GoogleCodeExporter]

Oh, left of the 'px'.  Yes, not fixed.

Original comment by dougf...@google.com on 21 Apr 2015 at 6:52

[GoogleCodeExporter]

... and David told me that he no longer knows what he was coding :-(

I hope to finally start a FreeType font rendering database project soon, 
collecting renderings of fonts.  This should help play with modified settings 
and rules in the auto-hinter.

Original comment by lemzw...@googlemail.com on 21 Apr 2015 at 7:02

[GoogleCodeExporter]

Yeah, if we have such a database, making the change the autohinter is trivial.

Want to talk about it?

Original comment by behdad@google.com on 21 Apr 2015 at 7:40

[GoogleCodeExporter]

Yes :-)  If you have thoughts on this, please share them on the freetype-devel 
mailing list!  I'm a complete noob with setting test suites, so any guidance 
would be a great help.

Original comment by lemzw...@googlemail.com on 25 Apr 2015 at 5:16

[behdad]

cc @roozbehp

[dougfelt]

This appears fixed in NotoSansSymbols 1.07, in my environment (for the pango-view test rendering of 1f1eb at 15px).

[lemzwerg]

I can't reproduce it either with current git of both FreeType and noto-fonts.

[nizarsq]

It seem U+1F1EB currently not in NotoSansSymbols or NotoSansSymbols2 fonts.

[SKing-2003]

It seem U+1F1EB currently not in NotoSansSymbols or NotoSansSymbols2 fonts.

This is still the case.

[simoncozens]

Closing in favour of consolidated report #69.