Re: [ft-devel] GX support now working

[Sascha Brawer]

> 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, it might possibly be a bug in Apple's code? 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> 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>> 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/

OslashWithControlPoints.pdf
Description: Adobe PDF document