Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome

[신정식, 申政湜]

The latest finding from http://crbug.com/229010 : 

As it turns out, I do have access to the original font, as it is available at https://github.com/georgd/EB-Garamond . Very nice font, by the way. The font is, in fact, 1000upem, and makefont.py (part of the build process for the font) tells font forge to push the em to 2048. This seems to be the step causing the issue, as ttfautohint is leaving all these values alone. As a result, the issue appears to be in fontforge. There appear to have been related issues in the past as well, see http://sourceforge.net/mailarchive/forum.php?thread_name=1228364630.1432.0.camel%40lynch&forum_name=fontforge-devel 

Jungshik

2013/4/10 Jungshik Shin (신정식, 申政湜) <address@hidden>

2013/4/9 Vernon Adams <address@hidden>

Same font file goes to all browsers. Just to keep things simple. The font file would be a single autohinted file that gets served to whichever OS/browser calls for it, as you say OSX should ignore the truetype instructions.

Well, web font services like Google Web Fonts and others send down different fonts depending on platforms. 

Anyway, one of Skia engineers had a very detailed look at the font and came up with a speculation on what's going on. 

Why don't you go and read what he's found at  https://code.google.com/p/chromium/issues/detail?id=229010 ? You can keep track of the bug activities by 'starring' the bug.  

To Werner (as the author of ttfautohint), you may want to read what he wrote there. 

Jungshik 

-v

On 8 Apr 2013, at 22:24, "Jungshik Shin (신정식, 申政湜)" <address@hidden> wrote:

> BTW, why would like to serve a font with hint instruction to OS X? OS X will not utilize the hint instructions.
>