Noto Sans Symbols: U+1F1EB loses its cross bar in 15px on Linux

[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