Re: [ft-devel] GX support now working

[Behdad Esfahbod]

On 15-06-04 01:40 PM, Sascha Brawer wrote:
>> How did you number the points?  It seems to be dropping control points, and 
>> as
>> such the point numbers are inconsistent with glyph data.
> 
> Yes, I only counted the on-curve points, in the order as supplied by MacOS.
> Attached a version where the control points are numbered, too.
> 
>> I think at this point the question is, why does the slash change orientation
>> at certain ranges.
> 
> If FreeType doesn't have these artifacts,

Perhaps the best way forward is to write another tool that generates the exact
output, but using FreeType.

> it might possibly be a bug in Apple's code?

We can contact Apple people and ask, but might be easier to confirm with
FreeType first.

> Another Skia glyph with the same issue is Q: at width=0.7, MacOS
> gives the Q’s tail in clockwise orientation up to and including weight=1.2.
> Above that weight, the tail’s orientation is counter-clockwise, causing the
> same kind of artifact as with Oslash. Again, this shows both in the outline
> returned by the MacOS API, and in the rasterized glyphs displayed eg. by 
> TextEdit.
> 
> -- Sascha
> 
> On Thu, Jun 4, 2015 at 9:53 PM, Behdad Esfahbod <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     How did you number the points?  It seems to be dropping control points, 
> and as
>     such the point numbers are inconsistent with glyph data.
> 
>     I think at this point the question is, why does the slash change 
> orientation
>     at certain ranges.
> 
>     On 15-06-04 05:46 AM, Sascha Brawer wrote:
>     > Regarding the Skia artifacts, it seems to be trickier than merely 
> applying the
>     > right filling rule.
>     >
>     > Have a look at the attached document (it uses the PostScript "fill" 
> operator,
>     > which implements the non-zero winding rule; there also exists an 
> "eofill"
>     > operator for even-odd filling but the document doesn't use it). In the 
> Skia
>     > font, the Ø glyph consists of an exterior ring, an interior ring, and 
> the
>     > slash. At width 0.7 and weights all the way up to 1.8, the exterior 
> ring comes
>     > in clockwise order; the interior ring is counter-clockwise; and the 
> slash is
>     > clockwise. Therefore, the glyph looks as expected when applying the 
> non-zero
>     > winding filling rule. However, starting at weight 1.9, the slash 
> suddenly
>     > flips its direction, which causes visible artifacts. This continues up 
> to
>     > weight 2.2. At weight 2.3, the slash gets moved into the O shape, but 
> because
>     > it still has the wrong order, it creates a hole into the O. — At width 
> 0.8,
>     > the slash starts flipping its direction at weight 2.1. At width 0.9, the
>     > direction flipping happens only at weight 2.3.
>     >
>     > Not sure if this is due to a bug in the Skia font, or due to a bug in 
> MacOS's
>     > handling of 'gvar' tables. But if FreeType doesn't run into the 
> problem, it
>     > smells more like a MacOS problem.
>     >
>     > -- Sascha
>     >
>     >
>     > On Thu, Jun 4, 2015 at 9:03 AM, Werner LEMBERG <address@hidden 
> <mailto:address@hidden>
>     > <mailto:address@hidden <mailto:address@hidden>>> wrote:
>     >
>     >
>     >     Hello Sascha!
>     >
>     >
>     >     > Looking at the PostScript output for Oslash, there seem to be 
> plenty
>     >     > of artifacts in the glyph.  [...]  At least, TextEdit on MacOS X
>     >     > 10.10.3 shows the very same artifacts; see the attached 
> screenshot.
>     >
>     >     Ouch.  This seems to imply that TextEdit isn't capable of handling
>     >     Apple's own GX fonts...
>     >
>     >     > Just wondering, what would you think about unit-testing FreeType's
>     >     > 'gvar' handling by emitting similar PostScript for some test font?
>     >
>     >     Good idea!  However, as mentioned in my other response, it would be
>     >     necessary to fix the TrueType->PS outline filling rules.  If you
>     >     provide something, I can add it to the FreeType demo programs rather
>     >     easily, I believe.
>     >
>     >     > I guess we'd have to build some custom font for stress-testing
>     >     > 'gvar', but this shouldn't be so hard.
>     >
>     >     Ha, *THIS* is something I want in FreeType: A tool to create test
>     >     fonts, even invalid ones, to systematically test FreeType's
>     >     capabilities, including error and recovery handling.
>     >
>     >     Ideally, there is a small file that contains a textual, 
> human-readable
>     >     representation of a font, and a `compiler' that converts it to a
>     >     binary.  It must be on a far lower level than ttx, of course.  I
>     >     looked around in the internet, and the closest thing I've found is a
>     >     template for SweetScape's 010 editor, cf.
>     >
>     >       http://www.sweetscape.com/010editor/templates/files/TTFTemplate.bt
>     >
>     >     I can imagine to have a similar template written in python, say.  
> The
>     >     test files would then selectively override the default structures 
> with
>     >     the necessary (possibly invalid) data.
>     >
>     >     Does this sound sensible?  Would you like to work on such a tool?  I
>     >     guess that *all* font tool developers would crave for it :-)
>     >
>     >
>     >         Werner
>     >
>     >
> 
>     --
>     behdad
>     http://behdad.org/
> 
> 

-- 
behdad
http://behdad.org/