[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] GX support now working

From: Behdad Esfahbod
Subject: Re: [ft-devel] GX support now working
Date: Thu, 04 Jun 2015 12:53:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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>> 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.
>     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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]