Of the four fonts used in the latest comparisons, only the Droid Serif seems to have been well hinted. I'd like to seem more comparisons with carefully manually hinted fonts. I don't like the greying of the smaller text sizes, although I recognise that for a lot of fonts it will be more desirable than higher density but more distorted shapes. [We used to do the same thing with gasp table settings in (semi-)autohinted fonts, applying greyscale antialiasing across all sizes if the client didn't want to pay for manual hinting. We made a lot of Arabic fonts that way.]

I'd also really like to see some examples of ttfautohint applied to non-European scripts. How does it do with Japanese? Arabic? Devanagari? Sinhalese?

good points :)

It's difficult to get hold of freely available fonts that have been manually hinted to the highest level - hence the need for a tool that comes at least close. I originally chose the Ubuntu Font as i know Dalton Maag documented it's hinting process, see here, so for the sake of comparison, it seemed to me a pretty good real-world choice. Personally i don't have commercial fonts and i won't test the screen-optimized Windows system fonts.

The other angle to all this, as i see it at least, is that ttfautohint is not an attempt to emulate manual hinting or be a substutute for it, though it's allways tempting to compare :) ttfautohint is really a tool to quickly create truetype instructions in fonts that are to be rendered on Windows machine from web based font servers. I guess the mark of whether ttfautohint instructed fonts are hinted well enough is whether web designers and web users accept the way they render on Windows OS screens.

-vern

ps @ john hudson or others
feel free to recommend fonts that should be tested with this tool.

@vernon

I believe the Paratype fonts were manually hinted using VTT.

@jh or anybody:

I believe Vernon and I have both seen auto-hinted versions of outlines that - at least to me - look not equal to, but better than their manually done counterparts.

To paraphrase Duke Ellington once again: "If it looks good, it is good."

So, I guess my question is: what's to be gained by manually hinting if the auto-hinted product looks satisfactory?

rich

*No trick question. There might very well be advantages beyond looks - just wondering what they might be.

Rich: So, I guess my question is: what's to be gained by manually hinting if the auto-hinted product looks satisfactory?

Nothing, if ‘satisfactory’ meets your purposes. My interest in seeing comparisons with better quality manually hinted fonts is to be able to determine exactly what sort of differences we might expect between ttfautohint results and deliberate decision making by an experienced hinter. I'm not interested in saying that one is better or worse than the other, especially not in a general sense independent of particular designs and intended purposes, but in getting a better understanding of what ttfautohint does in given situations compared to what I or someone else might do.

My interest in seeing examples of non-Latin results of ttfautohint is due to many years of having witnessed technological breakthroughs in font rendering that were not adequately tested beyond the Latin script. My take on all technology is that one should seek out the use cases that will provide the greatest challenge to the approach implemented in the technology.

I am planning to test some non-Latin fonts this week, which will probably be from SIL as i need them to be open source. Names of free, quality hinted, non-latin fonts would be appreciated! Will post results, for those interested. Again, whilst it's interesting to compare against professionally hinted fonts the aim is not to emulate traditional Truetype hinting at all, but to see if this particular approach to auto-instructing can produce readable and 'pleasing' text for web use on post Windows2000 OS's.

Richard- i believe what we have both seen is autohinted fonts look equal or better to below-par manually hinted fonts. But isn't kind of the point to all this - why spend many many hours to reach that 'adequate' below-par, when you can reach it, or better, in seconds?

many thanks for the comments.

As of now, anyone intending to hint for web must consider Greyscale rendering as well. With a market share of 30% plus, there's no way you can neglect that.

I tend to test both Cleartype (GDI & Directwrite) and standard greyscale, and i think i now what you are getting at :) One detail is that the default for the autohinter at the moment is to create a flat version1 gasp table with all flags on, so under standard greyscale the smallest type sizes can render pale, but that is alleviated by re-toggling the gasp table if necessary.

btw 30% plus of what? 30% of windows users are not using cleartype? Windows web users? world wide?

I tested the autohinter on some of our fonts and I'm not impressed so far.

Each font file gains around 40 kB in file size compared to our hand-hinted fonts when ttfautohint is specified to generate hints from 8 to 96 ppm.

Some of the fonts aren't displayed at all in Firefox in our HTML test page.

And MS Font Validator takes ages in the rasterization test, only to fail completely in the end, so I can't judge if there are any errors in the hinting.

30% plus with less than IE8 or non-IE browsers on Win XP, which produces the default greyscale rendering.

John Hudson,
i'm really hoping you can add some more on all this from your wealth of knowledge.
One thing i'm noticing in my screen tests with XP and Win7 is the varied performance of manually hinted fonts under standard windows greyscale smoothing and to a lesser extent under cleartype. I think i understand why you say the Droid font is the only well hinted font in my tests, but can you clarify that a bit more?

To me the mark of 'well hinted' is the fact that the appearance of Droid Serif stays fairly constant between cleartype and greyscale, compared to e.g. the Ubuntu Font. Also with Droid Serif, whilst staying clear and legible at all ppm sizes, there are no dramatic changes in e.g. relative stem widths going from one ppm size to the next. In the Ubuntu Font stem widths change noticeably below certain ppms. Would these be fair criteria for the nitty gritty of defining 'well hinted'?

many thanks

Jens, many thanks for feeding back, it's much appreciated. The added file size is comparable with other autohinters and it will be brought down at some point in future but, yep, it's not a plus point. Depends a lot on the font too, e.g Droid Serif Regular goes from 45kb to 53kb, wherease Bitstream Vera Regular falls from 64kb to 63kb. Basically the more optimised a font's design is for TT hinting the less the bloat will be. It's a font autoinstructor, not an alchemist ;)
With the fails on Font Validator - you mean all the outputted fonts fail?!? hmm not seen *that* yet. Great though, i will check, it may not yet be fully in line with the MS engine specs. It certainly wasn't some weeks ago.

thanks again

@Jens: There are three issues:

• ttfautohint 0.1 indeed produced invalid bytecode. This has been fixed in release 0.2, uploaded a few hours ago (it may take 24 hours until it gets distributed to all mirrors).
• FontValidate reports some trivial errors, caused by the fact that the freely downloadable version is too old (from 2003!). For examplę it doesn't understand `gasp' table version 1. Probably related to this are checksum errors which are not important either.
• Far more serious is that FontValidate reports zillions of
  

  E6049 Twilight zone point not set

  errors which are incorrect, according to my interpretation of the OpenType specification.

  According to the `instgly.doc' file (part of the specification), page 164, chapter `Points', section `Zones':

  The profile table establishes the maximum number of twilight points. These are numbers 0 through maxTwilightPoints-1 and are all set to the origin. These points can be moved in the same manner as any of the points in zone 1.

  This essentially means that all twilight points are set to (0,0) as soon as I start to execute the bytecode of a glyph (and no point is not set)! Obviously, either FontValidator or the documentation is incorrect... Compare this to the values in the storage area, where the specification explicitly mentions that access to unassigned values is undefined.

I would be glad if anybody here can give more details...

@John: I haven't yet ported the CJK module of FreeType's autohinter to ttfautohint. More tests are needed whether this is useful at all. Similarly, there is no special module for Arabic scripts. It may be possible that the default latin hinter works fine also, but again, this needs more testing.

Werner,

I'm not sure what makes FontValidator choke. The rasterizing test is very slow, several seconds per size as opposed to about half a second on "normal" fonts. In the end, FontValidator gets unresponsive and the results are never displayed.

Hm, just now I saw that the resulting validator XML file is 160 MB in size, that might explain the slowness ;)

When I open the XML file with a text editor, I see that most of the errors are indeed "E6049 Twilight zone point not set" and a lot of warnings "W6008 Value for count is less than 1. Function will not be called".

What's odd is that also ttx (from the fontTools Python module) seems to have problems with decompiling the instruction code. Not on all fonts I tested, but on most:


An exception occurred during the decompilation of the 'glyf' table
Dumping 'glyf' table...
Traceback (most recent call last):
File "C:\Python24\Lib\site-packages\fontTools\ttx.py", line 289, in main
process(jobs, options)
File "C:\Python24\Lib\site-packages\fontTools\ttx.py", line 274, in process
action(input, output, options)
File "C:\Python24\Lib\site-packages\fontTools\ttx.py", line 171, in ttDump
disassembleInstructions=options.disassembleInstructions)
File "C:\Python24\lib\site-packages\fontTools\ttLib\__init__.py", line 267, in saveXML
self._tableToXML(tableWriter, tag, progress)
File "C:\Python24\lib\site-packages\fontTools\ttLib\__init__.py", line 301, in _tableToXML
table.toXML(writer, self, progress)
TypeError: toXML() takes exactly 3 arguments (4 given)


When I set the Font Validator to do the rasterization test only for one size, it works fine. The list of rasterization warnings and errors is still long, but not as long so it's too much for FontVal.

BTW, I used version 0.2 of ttfautohint with FreeType 2.4.5, just downloaded freshly some hours ago from Sourceforge.

Jens, I am using ttx 2.3 on Linux constantly to check fonts that have been run through ttfautohint, i've not seen any errors. Also running them through OTMaster on OSX for a 2nd opinion. No errors. weird.

So.. i just ran a few through ttx on a mac :) and sure enough i get a whole bunch of similar errors to yours above, on any TTF i test - i even downloaded the droids to test and get same errors :-/ Are you only getting your ttx errors on fonts from ttfautohint? or maybe just on Windows? Could be a fonttools/python issue.

I'm sorry if this is a dumb question, but how do I install/use it? Does it work at all on OSX? I downloaded freetype-2.4.5.tar.bz2, and got a folder. Is it a plugin, or a seperate application? I just want to test how my own font would look like with TT autohinting.

Thanks in advance,
Jasper de Waard

Jasper,
ttfautohint is only just at version 0.2, so keep that in mind. There's no gui yet either.
I'm running it on Linux Fedora and it's simple to build, install and run. Needs the freetype 2.4.5 source to build.
It should build & run on OSX the same but that will be dependent on you installing some other libraries that are not part of OSX by default.
Does that help at all? Short story - it's not a Mac app with a gui :)

Jasper,

if you have the Apple Developer Tools installed:

In Terminal.app, the command sequence is (press enter after each line):

cd Downloads/freetype-2.4.5
./configure
make
sudo make install


You also need the folder for ttfautohint-0.2, it's a separate download. The commands to build and install are the same.

Then you can run ttfautohint from the command line:

/usr/local/bin/ttfautohint

Jens,

the warning W6008 Value for count is less than 1. Function will not be called should IMHO be switched off by default within FontValidator. I consider calling LOOPCALL with a zero valued counter as a very elegant method to skip a loop, making the code compact and simple. In other words: This warning will stay forever, since I'm not going to uglify perfectly valid and easy to understand bytecode just to pacify FontValidator.

Werner,
I tested ttfautohint with Arabic fonts and the result is distorted behind recognition (used -f option), which is surprising since FreeType autohinting gives good results. It is not clear to me where to report bugs, should I report it to FreeType's Savannah bug tracker?

Khaled,

assuming that you've used ttfautohint 0.2, this shouldn't happen indeed. Please send me your test font privately for further examination.

@Khaled: Yes, I believe it's easiest to use FreeType's bugtracker. However, writing me directly is probably as effective right now :-)

To me the mark of 'well hinted' is the fact that the appearance of Droid Serif stays fairly constant between cleartype and greyscale, compared to e.g. the Ubuntu Font.

Maybe I'm alone on this, but I don't understand why you'd use comparison between two rasterization methods as a mark of quality hinting. It seems to me that the goal of hinting should be that the font is as legible as possible given the current conditions, so that the font should be as legible as possible given the restraints of B+W rendering, and also as legible as possible under grayscale rendering. Whether the solutions to these issues are very close, or have some differences seems to be irrelevant.
The one thing a user is never going to do is flip between rendering modes while reading. Nearly all users will only see the font in B+W, or only see it in grayscale, depending on their system settings. So if the user can't flip between these options and see both, why the insistence on the solutions being the same?

Jason C

"I don't understand why you'd use comparison between two rasterization methods as a mark of quality hinting"
erm... maybe to see what the font will look like when viewed on different browser/render engines? e.g. Looks good on cleartype & greyscale = well hinted. Looks good on cleartype but bad on greyscale = not well hinted. etc.

"The one thing a user is never going to do is flip between rendering modes while reading"
Windows users with OCD? ;)

erm... maybe to see what the font will look like when viewed on different browser/render engines?

No, I get that. What i'm saying is that it could look good in greyscale, and look good in B+W, even if it looked different between the two. As long as each solution works and looks good for each environment, I'm not sure it's important that they look the same.

Jason C

Jason - Ah yes of course. I think we misunderstood each other. I meant 'sameness of quality', not necessarily 'sameness of form'. To be honest my quesion of 'what is well hinted?' was rhetorical, hoping John Hudson would explain more about his statement that Droid Serif was 'well hinted' whereas the Ubuntu Font was not. I'm still curious what criteria he uses to consider that. Personally i see Ubuntu Font as a perfectly adequately hinted font in the context of user experience. Maybe a font engineer can find some holes in it (especially if they go looking for holes) but real world users' experience of a font is as (or more) important imo :)

Hello Werner,

Thanks for developing a free tool like ttfautohint. Over the past few weeks I tested ttfautohint and overall I am quite impressed by the results. There are some issues, like reported above, but still I think it is pretty amazing that (with some simple shell scripting) one can hint (large quantities of) fonts on this quality level automatically.

I very much like the idea of circumventing manual hinting as much as possible; despite the fact that we earned some good money with it, euphemistically stated, I never really liked the work. So, thanks again for your efforts, and I will happily test version 0.2 today.

FEB

Happy to point out that one of the advantages of the open source approach is that a tool like ttfautohint can be freely developed further for extended or specific needs. So in the case of 'yeh, but can it hint non-latin?' - if a non-latin script has a need for a tool like ttfautohint, then other, perhaps non-latin programmers, can freely take the code and, if necessary, hone it for their specifics. You couldn't do that with a proprietary tool :)

hoping John Hudson would explain more about his statement that Droid Serif was 'well hinted' whereas the Ubuntu Font was not.

I'll let John comment on that. I'm not exactly objective about it, having worked on hinting for both of them.

Jason C

@werner

Same as what Frank Blokland said. Great to have somebody applying themselves to the problem of auto hinting so diligently. Ethan Dunham at Font Squirrel deserves a mention here, too, with the auto-hinting done by the Font Squirrel generator. It isn't open-source, but it's free for anybody.

I've been using both FontLab, FontForge, and the FS Generator for auto-hinting - each has it's strengths and weaknesses and biases but between the three I usually get a satisfactory result within a short period of time.
It's great to have yet another option in the works. I've been keeping an eye on Vernon's screen shots, and it's pretty impressive.

And - in line with what Vernon Adams said - I would say to concentrate on getting the tool to "speak" Latin based languages really, really well before complicating matters with other systems. A solid tool for the WinAnsi set alone, is a big, big win.

Richard Fink
http://readableweb.com

I've just posted a comprehensive install guide that works on GNU/Linux and Mac OS X:

http://code.google.com/p/googlefontdirectory/wiki/InstallingTTFAutoHint

Thanks a lot for that Dave. I'm traveling with my XP laptop at the moment but the second I get back to the office I'm gonna get that sucker going and see whut's up.

Sorry for the late reply, Vernon. I've not had a chance to read this whole thread, but in response to your query re. my comment on the hinting quality of your initial test fonts, let me clarify:

I think the manually hinted Droid Serif looks best of the specimens (excepting in the smallest three sizes, which I'm assuming are below the sizes spec'd for hinting), and best in both GDI and DWrite rendering. But it was misleading for me to describe this quality in terms of 'well hinted' relative to the other test fonts, because a significant factor in this quality in addition to hinting is probably in the nature of the outlines and spacing, which enable Droid Serif to perform better, especially under DWrite, than the other fonts, including the well-hinted Ubuntu font, at the text sizes: there is less fuzzing of vertical stems in Droid Serif, and better stroke density.

John Hudson, thanks for the clarification. It's what i thought you meant :) On top of what you said above, i think the Ubuntu Font didn't do itself justice on modern Windows systems with a gasp table that toggled off smoothing between 9-16 ppm (or thereabouts). Ubuntu Font can be improved for Windows simply by 'fixing' the gasp table.

http://www.freetype.org/ttfautohint/ :)

“Intentionally, ttfautohint adds hints only along the y-axis.”

Seriously? Hinting the y-axis by hand is easy.

I’m sorry about being a mean bitch, but is the default settings in Win XP something you completely ignore?

What do you want to say? On the abovementioned ttfautohint webpage it is explicitly mentioned that the results with GDI ClearType (as used by default on Win XP) are not satisfying yet...

Werner, GDI ClearType is not used by default on Win XP. The default rendering in Win XP is 'Standard' (bi-level and greyscale as determined by font gasp table settings), and ClearType had to be turned on manually (the exception was some hardware manufacturers with XP OEM licenses, who chose to turn on ClearType by default, but this was not Microsoft's default for that OS).

What Frode is showing is XP greyscale rendering, which really suffers without x-direction stem links.

I fully agree. The question is whether it makes sense to implement support for that rendering mode, given that Win XP is really old...

But not so old that the question has an obvious answer.

I'd love to be able to cross XP off the list of operating systems that I have to care about, but it lingers there: not exactly important, but not ignorable.

As I stated earlier in this thread, XP is still significant. As many as 1/4* or more of all web users might still see XP's default rendering mode. Until just recently a lot of new netbooks were shipped with Win XP, because newer versions of Windows are too heavy on the system resources.

Yes, Windows XP is really old, but the two next versions of Windows were really crappy so people "downgraded" instead of upgrading. It's a shame that even big leagues like Fontfont doesn't acknowledge this.

* Wikipedia statistics: Win XP 37,92%, and off those about 50% non-IE users (none of these browsers change the default OS setting), and probably some IE6 users plus those who disable Cleartype for various reasons.

John Hudson said

What Frode is showing is XP greyscale rendering, which really suffers without x-direction stem links.

adding hints in the xdirection for greyscale, results in almost if not the same work as adding hinting for black and white. As soon as x-hints are introduced, you have to start worrying again about moving stems, and sidebearings, to get the best spacing. Adding y-hints only and lowering the GASP to be always set to use FontSmoothing might reult in acceptable results on XP.

If those XP results are acceptable, why did we need x-direction hinting in the first place?

My comment was the results *may* be acceptable

Mike, what we typically did when 'auto-hinting' fonts for greyscale was to apply x stem hints but still set the gasp table to apply smoothing at all sizes. The stem hints improved the density of the vertical strokes, especially in lighter types. Yes, this can introduce spacing issues, but those are relatively easy to deal with, and the gain in stroke density and hence text contrast is worth it.

hi John, I would have to see a convincing example of that, showing also how easy it was to maintain good spacing

Note that I suggested that spacing issues may need to be dealt with, but that this is typically fairly easy to deal with by adding some manual hints, and only at some very small sizes or for particular glyphs.

Here's a comparison of autohinting results for an all-caps fonts I am working on at the moment (note that this will not, eventually, be autohinted; these are just tests for this thread). Although it is an all-caps design it is not intended for display work: its for publishing the diplomatics of Byzantine lead seals. I don't consider the XP rendering acceptable, but I do think the addition of x direction hints provides for better stroke consistency at some key reading sizes. As you see, there are spacing problems for some glyphs and for most at the smallest size, but I'm not sure I prefer the trade-off with fuzzier stems in the version without x-hints.

And for comparison, here is the same font with the x and y autohints with ClearType turned on.

Much depends, I think you'll agree, on the individual typeface design: how light/heavy it is and how it has been spaced.

[It would be nice if the gasp table enabled one to apply or not apply x and y instructions independently. Looking at those screenshots, there are sizes at which I think the version with x hints is working better and sizes at which that with only y hints is working better.]