[Top][All Lists]

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

Re: [ft-devel] GX support now working

From: Sascha Brawer
Subject: Re: [ft-devel] GX support now working
Date: Thu, 4 Jun 2015 14:46:03 +0200

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> 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 :-)


Attachment: Oslash.pdf
Description: Adobe PDF document

reply via email to

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