Erik, Are you testing the rendering via web browsers only? Or do you get same results with e.g. ftview?
-vern On 21 Apr 2012, at 16:51, Infinality wrote: > Hi Vernon / Werner, > > I tried it out with the version of Oxygen you sent me, with similar results. > I was also able to view it in Windows XP, and as I thought it renders fine > there (although they filter the hell out of it). > > 1. This is the image in my original email. The settings I'm using here are: > Infinality patches, native TT hinting. (I also have a custom FIR filter > value set on the LCD filter for all of these images) > http://www.infinality.net/files/oxygen-infinality-problems.png > > 2. This is what it renders like with native TT hinting if I disable all > Infinality TT instruction tweaks: > http://www.infinality.net/files/oxygen-freetype-tt-hinting.png > > 3. This is what it renders like with Infinality-patched autohinting (which > uses "slight" hinting): > http://www.infinality.net/files/oxygen-infinality-autohinting.png > > You can see with #2 that it's faithfully rendering the instructions as you'd > expect, and it looks much like standard Freetype "slight" hinting, which > you'd also expect, since ttfautohint is creating the TT hints from autohint. > (The main difference between #2 and #3 is that #3 snaps horizontal stems to > pixel boundaries, which normal Freetype slight hinting does not do. I > personally prefer the stems to be snapped to integer pixels like this. It > looks less dirty to me, however there are some issues with diagonal stem > weights, which is a known issue since autohint doesn't do diagonal hinting at > all.) > > After experimenting around with the TT tweaks in the infinality subpixel > hinting patches, I am able to get rid of most of the artifacts by turning > *on* SHPIX instructions. By default they are off in my patches because (my > understanding is) this instruction was used historically as a "hack" to make > outlines fit around pixels, and not much else. (See: > http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx ). Is > it possible to accomplish the same things that SHPIX is doing in ttfautohint > with the more common MIRPs and such? Not only for my patches, but perhaps > for other device compatibility? > > Thanks, > Erik > > > On 04/21/2012 02:07 AM, vern adams wrote: >> Many thanks for this Erik, >> >> You seem to have recreated the glitchy rendering that earlier versions of >> ttfautohint created on iOS and when adobe apps converted ttfautohinted fonts >> to outlines. That's very interesting i think, as it probably points to >> something important still going on. >> >> First though i think we should check that the issue is not with a particular >> buggy build of Oxygen; very occasionally a nightly build of an oxygen font >> has been sent to the git repo with weird extra points that could upset ttf >> instructions. I'll mail you some Oxygen fonts to test with and confirm that >> you get same rendering? >> >> Many thanks >> >> vernon >> >> >> >> >> On 21 Apr 2012, at 03:15, Infinality wrote: >> >>> Hi guys, >>> >>> Today I tested out the TT-instructed Oxygen font from the KDE repo with my >>> TT subpixel hinting patches. This is the result: >>> http://www.infinality.net/files/oxygen-infinality-problems.png >>> >>> Yikes!!! After examining the TT instructions in the instructed version of >>> the Oxygen fonts, it looks like the way that ttfautohint is generating >>> instructions is substantially different than typical TT-instructed fonts. >>> Since my patches are attempting to do what the MS rasterizer does (at least >>> with legacy fonts), I'm curious how these render on Windows. Unfortunately >>> I don't have a Windows system available to test that on at the moment, >>> however my guess is that it renders just fine on Windows. >>> >>> I have a way to exclude certain fonts or individual glyphs within a font >>> from using the tweaks that my patches employ (i.e. render it the way >>> Freetype TT hinter does by default), but I'd rather not build up a giant >>> hard-coded exclusion list of fonts generated by ttfautohint if at all >>> possible. And, given that the TT subpixel hinting patches may soon land >>> into Freetype, I'd like make them work nicely with other Freetype-related >>> software. :D So, I'd like to adapt my TT hinting patches to gracefully >>> handle fonts that have been hinted with ttfautohint. >>> >>> My question is this: Is there something unique about ttfautohint-ed fonts >>> that indicates they are already taking into account subpixel-hinting? I >>> know there is the "ready for Cleartype" flag, but it never seems to be set >>> in any fonts I've seen (including Oxygen), even the MS ones. Also, the >>> Microsoft Cleartype fonts seem to behave well with my patches just as they >>> are. They are designed for Cleartype/subpixel just as the ttfautohint >>> fonts are. I guess I'm trying to reconcile what exactly ttfautohint is >>> doing differently that causes these issues. Can any of you provide any >>> insight? >>> >>> Thanks, >>> Erik / Infinality >>> _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel