|
From: | Sascha Brawer |
Subject: | Re: [ft-devel] GX support now working |
Date: | Thu, 4 Jun 2015 22:40:12 +0200 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |