[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 13:46:14 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
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/
- Re: [ft-devel] GX support now working, (continued)
- Re: [ft-devel] GX support now working, Dave Arnold, 2015/06/04
- Re: [ft-devel] GX support now working, Werner LEMBERG, 2015/06/08
- Re: [ft-devel] GX support now working, Dave Arnold, 2015/06/22
- Re: [ft-devel] GX support now working, Werner LEMBERG, 2015/06/26
- Re: [ft-devel] GX support now working, Behdad Esfahbod, 2015/06/26
- Re: [ft-devel] GX support now working, Dave Arnold, 2015/06/26
Re: [ft-devel] GX support now working, Werner LEMBERG, 2015/06/04
Re: [ft-devel] GX support now working, Dave Crossland, 2015/06/03
Re: [ft-devel] GX support now working, Cosimo Lupo, 2015/06/06