freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] ttfautohint / Oxygen / infinality


From: vernon adams
Subject: Re: [ft-devel] ttfautohint / Oxygen / infinality
Date: Sat, 21 Apr 2012 20:51:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

Ok, so i've tested this with a infinality patched freetype 2.4.9 w Kubuntu.
Using ftview or the system font viewer any truetype font instructed with ttfautohint (i'm using 0.8) renders as Erik has shown. Pretty much the same screwed up rendering that we saw with old versions of ttfautohint w iOS and converted font outlines in Adobe apps.

Curiously web browsers aren't effected for me, nor is the system GUI if i use a ttfautohinted Oxygen for the system font. Just ftview etc.


-v


On 21/04/12 18:44, Infinality wrote:
I've only been using browsers for these, but AFAIK it *should* be the
same. :)

On 04/21/2012 12:03 PM, vern adams wrote:
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



--

b: code.newtypography.co.uk
t: +44 (0)79-142-00506
e: address@hidden



reply via email to

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