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?

• Login or register to post comments

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

• Login or register to post comments

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

• Login or register to post comments

@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.

• Login or register to post comments

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.

• Login or register to post comments

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.

• Login or register to post 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.

• Login or register to post comments

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?

• Login or register to post comments

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.

• Login or register to post comments

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

• Login or register to post comments

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

• Login or register to post comments

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

• Login or register to post comments

@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...

• Login or register to post comments

@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.

• Login or register to post comments

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)


• Login or register to post comments

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.

• Login or register to post comments

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.

• Login or register to post comments

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

• Login or register to post comments

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 :)

• Login or register to post comments

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

• Login or register to post comments

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.

• Login or register to post comments

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?

• Login or register to post comments

Khaled,

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

• Login or register to post comments

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

• Login or register to post comments

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

• Login or register to post comments

"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? ;)

• Login or register to post comments

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

• Login or register to post comments

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 :)

• Login or register to post comments

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

• Login or register to post comments

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 :)

• Login or register to post comments

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

• Login or register to post comments

@werner

Same as what Frank Blokland said. Great to ha