Support Web Typography, Support ttfautohint

abattis's picture

ttfautohint is the new autohinter in town, which I hope will make hinting fonts faster and easier, so all type designers can make web fonts that look good on Windows :-)

I made a fun little promotional video, http://youtu.be/81ioae5XNew

There's more details on the ttfautohint homepage, http://www.freetype.org/ttfautohint

And Werner is accepting donations to help fund the development at http://pledgie.com/campaigns/15816

Rob O. Font's picture

No contact information? Oh well. If contacting me will help, then please do so as I have an offer to make.

Jens Kutilek's picture

Shouldn't Google be paying for this, if they want it so badly?

Richard Fink's picture

@abattis

I will be blogging about this to spread the word and donating some money, too.
Between what FontLab can do, FontForge can do, and now this - it looks like by the end of the year the problem of adequate hinting for Windows will be largely solved. At least for Latin-based fonts.

What's needed very much is an online front-end for this tool ala the Font Squirrel Generator.
You can't expect designers to be command line gurus and it will be hard to get feedback from the community at large without such a tool to upload a font and see the result quickly and easily.
(There's no doubt in my mind that it's only a matter of time before this tool is integrated into the FS Generator. But the more the merrier. :-)

rich

lemzwerg's picture

@David: Are you missing my email address (wl@gnu.org)? I've just added it to the web page. Or do you mean something different?

lemzwerg's picture

@Richard: A GUI is the main thing which I want to add :-)

Richard Fink's picture

@jens

Google? Why is it their problem? Is Windows GDI and TrueType their product?

The scandal is that Microsoft has not put any resources into this. The need for a simplified auto-hinting tool such as this has been plainly obvious for years now.
But so far all they've done is leave everybody swinging slowly in the wind, doing absolutely nothing to mitigate the situation for the benefit of type designers, web designers, and the billion Windows users out there.

The really crazy thing is that TTFs look better hinted in DirectWrite, too, so it's not as if the issue is being solved technically going forward.

The way fonts look in GDI is perhaps THE biggest barrier to adoption of web fonts. But as far as I can tell - MSFT doesn't give a hoot about it.

So be it. You might as well complain about the weather.

abattis's picture

Jens: Neither I or Werner represent Google, and I can't speak for that company. Google did already provide some financial support to Werner to start the project, and I personally will be surprised if they do not provide any more. I think this project is something that many in this community will benefit from though - probably even yourself - so I think it makes sense to engage the wider community in helping fund it :-)

dbrerlow: good catch, thanks :)

Rich: You'll note that a GUI is mentioned in the video and is the top item on the roadmap section of the site :)

apankrat's picture

Wow.

But can you please switch from pledgie.com to kickstarter.com? Latter gets far more foot traffic and the crowd there is far far more engaged and enthusiastic. This project has all chances of going viral, and kickstarter is the place to be for that. 30K should be more easily achievable there (assuming you won't get a large check from a corporate sponsor).

Jens Kutilek's picture

»Neither I or Werner represent Google, and I can't speak for that company.«

I was indeed under the impression that you represented Google. But you are involved with the Google Font Directory, aren’t you?

»You might as well complain about the weather.«

I do, the summer in Berlin really sucks this year ;)

apankrat's picture

Reposted on HN and reddit.

lemzwerg's picture

@apankrat: Kickstarter is no option, unfortunately. You must be US citizen to use it. I'm sitting in Vienna, Austria...

@Jens: Du mußt einmal den Salzburger Schnürlregen genießen, so wie ich die letzten drei Wochen :-)

Richard Fink's picture

@jens
You should try Naples, Florida from June through September.
I don't bother to check the weather because it's the same sub-tropical oppression every day:
90+ degrees with high humidity and a chance of thunderstorms.

I take it you don't disagree with my assessment of Microsoft's behavior in regards to this. ;)

Nick Shinn's picture

Companies which publish both layout software and fonts are in a conflict of interest situation.
Such behaviour is par for the course.

John Hudson's picture

From the 'How it works' section of http://www.freetype.org/ttfautohint :

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

So other than perhaps providing some better algorithms for automating y-direction hints, I wonder what ttfautohint does that is significantly different from what we've been able to do with a simple batch process in FontLab for well over a decade now -- and hence, Rich, perhaps why MS didn't see a need to produce an alternative? --, which we also had the ability to edit.

Don't get me wrong: I'm glad Werner is doing this, and will likely contribute some money, because I like having tool options, and when it comes to automation differences in algorithms are as important as different capabilities.

But if ttfautohint really ignores the x-direction completely, then it is of limited interest and is dependent on sub-pixel rendering environments, so doesn't help users employing XP standard font smoothing, which remains a significant demographic for the Web.

abattis's picture

John: I believe Werner will look into this, but I'm not sure he will produce good results in the time that the target $30,000 will allow :( That is certainly the long term goal, though :-)

Jens: I am involved with the Google Font Directory project as a independent, 3rd party consultant, yes.

abattis's picture

John: I also want to add, I think its important that how it works isn't a secret and can be reviewed and discussed by the public, which is a substantial difference in quality to the FontLab process.

Té Rowan's picture

*blinks slowly* Okaaayy... Mebbe dat anti-rot stuff I bin 'elping sis slop on 'er 'ouse is vegging me, but this statement comes quite a few tuns north by borth-west to me.

abattis's picture

Té: huh? :)

k.l.'s picture

I am a bit surprised to see the y-direction-only approach being criticised (here and there) when at the same time 1) this is all that about every webfont producing foundry is offering right now and 2) this is what I understand to be the way to go according to Microsoft (my reading of some past months' Typophile posts).

To be clear, I do not say that I appreciate the y-direction-only approach, I only say that I observe a contradiction.

lemzwerg's picture

@John: FreeType has an experimental autohinter option (off by default) for special `hinting' along the x axis, and I want to investigate whether it can be transformed somehow into TT bytecode. From the file ‘afwarp.c’:

The idea of the warping code is to slightly scale and shift a glyph within a single dimension so that as much of its segments are aligned (more or less) on the grid. To find out the optimal scaling and shifting value, various parameter combinations are tried and scored.

John Hudson's picture

Dave: I also want to add, I think its important that how it works isn't a secret and can be reviewed and discussed by the public...

Agreed.

...which is a substantial difference in quality to the FontLab process.

Which aspects of the FontLab process can't be reviewed and discussed by the public? [Serious question.]

The actual algorithm used to auto-generate the stem hints, I suppose. What else?

John Hudson's picture

Karsten: this is what I understand to be the way to go according to Microsoft

With the caveat that this applies if one is targeting only subpixel rendering environments. Part of the continuing need for hinting with regard to webfonts is to support the still significant number of users not using subpixel rendering, esp. XP users.

lemzwerg's picture

John,

it's trivial to add hinting à la FreeType's autohinter along the x axis. Actually, it's even simpler because the blue zone code can be omitted (at least for non-CJK fonts).

Of course, this is on my TODO list :-)

Rob O. Font's picture

If x complexity = y complexity then I guess all of basic quality manual hinting complexity is a ruse. And, when all the x and y hinting is automated, what to do about diagonals...

To not be too cryptic, you are warned here that the gap between y auto hinted normal fonts to average qaulity CT use, and even the simplest effective auto hinting of x with modest quality spacing, is larger than it might seem. Imagining from your perspective with all due respect.

John Hudson's picture

Ah yes, I see it on to the TODO list now. Good, good.

With regard to expressing the ttfautohint actions in high-level hinting command languages, may I request that you prioritise VTT in this regard? I'm sure others will disagree and favour FontLab, but my take on this is that the people who are most likely to want to manually edit the hinting are those who want to do things that FontLab can't do anyway.

Add full OpenType Feature support – currently, all glyphs which can't be directly addressed with a character code in the ‘cmap’ table are handled with a fallback mechanism only.

Isn't it possible to address them via glyf table index, rather than having to support OTL tables?

Are there any other reasons you can think of for supporting OTL tables in an autohinter? Now you've got me wondering about auto-generating GPOS device adjustment lookups. :)

John Hudson's picture

David: the gap between y auto hinted normal fonts to average qaulity CT use, and even the simplest effective auto hinting of x with modest quality spacing, is larger than it might seem

Yes.

I think it is worth exploring a very specific target area in terms of x-direction autohinting, though: stem density in full-pixel smoothing environments, esp.XP. This is where the absence of x-direction hints is most obviously problematic, and where trying to obtain better consistency in the darkness of stems is worth some effort in terms of impact on both appearance and readability. Sure, the results are never going to be as good as manual hinting for these environments including control of spacing and other distances, but the results can be better than what Frode showed in the other thread.

Frode Bo Helland's picture

"I am a bit surprised to see the y-direction-only approach being criticised ..." That would be me, yes. This smells like the 80's too me: Back when everyone converted analogue to digital the cheapest possible way and as a results forced me to grow up through two decades of horrible typography.

Frode Bo Helland's picture

John: I'm only learning this now. Like four weeks in or smthn. I can do better for sure. I already am. And I haven't gotten around to VTT yet.

Edit: Or did you not refer to my own hinting experiments, but rather the autohinter examples?

Richard Fink's picture

@jh

"Don't get me wrong: I'm glad Werner is doing this, and will likely contribute some money, because I like having tool options, and when it comes to automation differences in algorithms are as important as different capabilities."

We are on the same page! Tool options are a good thing.
For everybody.

"But if ttfautohint really ignores the x-direction completely, then it is of limited interest and is dependent on sub-pixel rendering environments, so doesn't help users employing XP standard font smoothing, which remains a significant demographic for the Web."

Here's where we start to part company. X direction, shmex direction. Picky, picky, picky.
If the font coming out looks a hell of lot better than the font going in, with the only effort being the click of a mouse or a keystroke, then something really critical has been accomplished.

In the early years of the twentieth century, Bell Telephone relied on female operators to handle the problem of switching. (Remember Lilly Tomlin's caricature?)
Anyway, as the phone system grew, the problem of switching started getting out of hand and the company undertook a survey and came to the conclusion that, at the current rate of expansion, in just a few years, every female in America would have to be employed as an operator to handle the volume. Faced with this, a method for automatic switching was developed and deployed only a few years later.
It's the same situation here. If we could clone Berlow or Tom Rickner to create an army of Berlows and Rickners hey, no problem.
But that's as absurd as having every woman in America employed as a telephone operator.

Every tool has it's own personality. At this point I've spent hundreds of hours with FontLab auto hinting and FontForge autohinting, and I know exactly what FL will balk at and what FF will balk at and what either one will gladly accept and improve.

Of course, fonts that are missing important characters or are internally inconsistent present special problems that consume more time. But that's a different issue, anyway.

The auto hinting provided by the Font Squirrel Generator is also quite excellent once you get the hang of the settings and prepping the font to get the best out of it. And while the back-end stuff at Font Squirrel isn't open-sourced, it's free and that's close enough for me. Kudos to Ethan Dunham for taking the bull by the horns. And he's perfectly entitled to profit from it and keep it proprietary if that's his druthers.

With ttfautohint, I welcome that someone is working on yet another tool, open-source, with input from the larger community. When I see that somebody like Greg Hitchcock is offering feedback to Werner, I get hopeful.

John Hudson's picture

Frode: Or did you not refer to my own hinting experiments, but rather the autohinter examples?

These: http://typophile.com/node/83829#comment-473415

lemzwerg's picture

Dave,

I think my reply caused misunderstandings. Hinting along the x axis is far more complex and demanding than hinting along the y axis, at least for the Latin script. I was just replying to the technical side of FreeType's autohinter, which treats both axes (almost) the same. The results are very pleasing for the vertical direction, as ttfautohint demonstrates, but not as good for the horizontal one, which can be seen if you use, say, the ‘ftview’ FreeType demo tool to test the various autohinter modes. And there is no hinting for diagonals at all.

Please don't forget that the autohinter in FreeType has been designed to do real-time hinting. In my opinion, David Turner has done an excellent job in designing and implementing it. If you remove the real-time constraint, a lot of improvements should be possible.

The primary goal of ttfautohint was (and still is) to bring the quality of FreeType's autohinter to the non-FreeType world. With the suggestions and wishes you all provide, it should be able to make it more versatile.

lemzwerg's picture

John,

the main reason for needing OpenType support is automatic script recognition. How shall ttfautohint know whether a particular glyph is Latin or Arabic, say?

Regarding VTT support, this has no priority right now. The next step is to improve ttfautohint's basic abilities so that it does its announced job as expected.

For the stem density in full-pixel smoothing environments problem, as you call it, the already mentioned ‘warper’ code in FreeType might help at a very basic level. Again, this is something to explore in the next months.

lemzwerg's picture

@Frode: Have you read this nice, old article?

http://www.antigrain.com/research/font_rasterization/

The shown results are quite convincing, and DW ClearType is essentially heading into this direction IMHO.

Frode Bo Helland's picture

lemzwerg: I just read halfway through. It's a bit too much right now, but in any case the writer says:

"I do respect the pixel grid, but only in the Y-direction. In the X direction the sub-pixel positioning must be allowed. In this case we can reasonably sacrifice some sharpness (very gently!), but obtain freedom."

In Win XP this sharpness you sacrifice is not reasonable. Yes, it can theoretically be done, but the system wasn't designed to allow and the system moves slow. This whole thing seems to be written from an engineeer's point of view: there's no mention (yet) of the importance of consistent rendering and weight of stems and rounds in x-direction. There's a reason why even colour is the alpha and omega of type design.

abattis's picture

John Hudson: Which aspects of the FontLab process can't be reviewed and discussed by the public? [Serious question.] The actual algorithm used to auto-generate the stem hints, I suppose. What else?

I wonder if the output of the algorithm, being itself a program, is subject to the copyright of the algorithm - as that is the result of the yyparse() function in http://en.wikipedia.org/wiki/GNU_bison

k.l.'s picture

Karsten – this is what I understand to be the way to go according to Microsoft
John – With the caveat that this applies if one is targeting only subpixel rendering environments. Part of the continuing need for hinting with regard to webfonts is to support the still significant number of users not using subpixel rendering, esp. XP users.

I know. This was my argument against y-direction-only.  :)
(The other part of the argument is that Microsoft – and Adobe – first of all address new platform/application versions when making new fonts for these. It allows them to make relatively safe assumptions about these fonts' target rasterizer. Independent foundries need to address whatever still-popular versions are out there. They cannot follow Microsoft's practice – the premise is a different one.)
Resolved anyway, however, since Herr Lemberg already wrote "it's trivial to add hinting à la FreeType's autohinter along the x axis".

Richard Fink's picture

@lemzerg

ttfautohint-Support Web Typography

Good luck and keep going. It sounds like you've got a solid grasp of the issues and the right priorities.

rich

lemzwerg's picture

Thanks, Richard! Being a very slow worker, I definitely need such a priority list :-)

lemzwerg's picture

Frode,

at the cost of larger fonts (due to more bytecode) I think your concerns regarding even stem colour along the x axis can be handled automatically to a certain extent by a forthcoming version of ttfautohint, using the techniques already available in FreeType's autohinter.

However, there is room for improvements, using algorithms not part of FreeType, but this is something yet to investigate.

John Hudson's picture

Werner: the main reason for needing OpenType support is automatic script recognition. How shall ttfautohint know whether a particular glyph is Latin or Arabic, say?

Ah, that makes sense. In theory, there could still be some ambiguities, with the same unencoded glyph being used accessed via GSUB in more than one script, but I imagine those situations would be rare.

Regarding VTT support, this has no priority right now.

Understood. I meant that if/when you get to the stage of adding support for higher level language expression I would favour prioritising VTT talk over e.g. FontLab expression.

Thomas Phinney's picture

Extensis is seriously considering support. We will likely kick in some funding.

I can only second John's comment on the importance of considering x-direction hinting and non-ClearType GDI environments, however. This is important to Extensis, at least for another year or two. If there was no plan to address such rendering, we probably wouldn't help with funding today.

Regarding Rich's rejoinder: if it doesn't yield good results in the x-direction under GDI greyscale rendering, it may be worse rather than better in that environment, which won't fly right now for us.

T

Richard Fink's picture

@tp

"Regarding Rich's rejoinder: if it doesn't yield good results in the x-direction under GDI greyscale rendering, it may be worse rather than better in that environment, which won't fly right now for us."

I understand. And I'm usually the one arguing for Windows users and as much backwards compatibility as is feasible. But, forgive the pun, I think it's a grey area. There's always a cut-off point. (And I'm not sure what you consider "good results".)

I'd love to hear why it won't "fly". What's your thinking?
Ten years ago when I was doing network support in Manhattan, there was no greyscale anymore even then. (But I actually did experience a greyscale sighting just recently at a Marriott hotel in North Carolina. So, it does exist.)

But who's afraid of the big bad greyscale wolf?
And where is Sii when you need him? How about MSFT shares it's telemetry with us so we can actually know what percentage of users will get the degraded performance?

Later,

rich

Thomas Phinney's picture

Without going into painful detail, my estimate is 20% of web viewers are viewing on browsers with GDI greyscale rendering. That's too many for us, is my take.

Yeah, in a year and a half or two years it will be like 5-8% and that will probably be time to give up on these poor people. But not today.

T

Rob O. Font's picture

JH: ...prioritise VTT in this regard?
I 2nd the suggestion for the same clearly described reasons. 

JH: ...the results [of automatic x hinting] are never going to be as good as manual hinting for these environments [low res enough to make adjacentcy fail regularly enough to effect readability]...

Is so utterly common up to 25-30 pixels per em, that auto hinting developers should simply surrender, IMHO, on the grounds that the tri-pronged diversity in x, glyphs + designs + x rendering technologies defines the problem as manual, unless someone has a breakthrough under development somewhere... ;)

Then to warp to the end of thread, I've been listening patiently to the puzzling over how many Vindows users are in Greyscale of some kind, and wonder "what's the goll-darn difference?" I've worked with clients, off web, where the font developer can make a staggering qualitative difference in low ppm text because the users are all in GS mode. But if font engineering cannot count on the vast majority or all of the users using GS, economics just say no!

Lemzwerg: "Dave,"

I assume this means me, though I'm usually either David, dberlow, or "guy with hair on fire because diversity in appearance of text at low res only severs those who seek to retard the web for the majority"...

Lemzwerg: ...don't forget that the autohinter in FreeType has been designed to do real-time hinting...

If by realtime, you mean on-the-fly or otherwise without human intervention, then I guess JH and my point of post auto hinting interaction are largely problematic and moot?

Té Rowan's picture

Sorry, @abattis. Musta been fumed out. Was thinking of Nick's statement right before your post.

Té Rowan's picture

@John Hudson: Whatever ttfautohint does or does not do, there are several cases where the result looks better than the original on my cruſty old Win98 laptop.

lemzwerg's picture

@dberlow (not called “Dave” :-) FreeType's autohinter has been designed about ten years ago (!) to do on-the-fly hinting. This then limited the possible algorithms to the ones which don't need too much processor time. It by no means implies that the derived ttfautohint processor has the same limitations.

The idea of post-processing the hints is probably the future IMHO if ttfautohint is going to be integrated into font editors. As far as I know, no font editor is able to add hints. Right now, all of them replace hints.

Richard Fink's picture

@lemzwerg

>As far as I know, no font editor is able to add hints.
>Right now, all of them replace hints.

I've added Deltas to existing hints in FontLab. But basically you're right and it's all a giant pain in the ass. There's no modularity that I can see. Everything is intertwined.
I think of TT hinting as connecting the points with rubber bands. Snip one band and all hell breaks loose.

TT hinting seems to me like a very poorly conceived system, frankly. It addresses a genuine problem but if Apple/Microsoft could go back and do it all over again, I doubt this would be the system devised.

But it's too firmly ingrained to replace. So here we are.

Thomas Phinney's picture

There are a number of proprietary autohinters out there (owned by various folks) that do auto-hinting and can produce VTT code, which can then be further tweaked by hand. I think I know of three or four such beasts. I tried talking one owner of such a proprietary auto-hinter into making theirs publicly available, but they resisted due to concerns about support costs/issues. (You know who you are! :)

This sort of approach seems immensely sensible and sane to me. It may or may not be cost effective in all cases, but it clearly is a huge leg up on getting hand-hinted fonts for a lot less work.

A regular auto-hinter that doesn't generate VTT code is still highly useful, of course.

Cheers,

T

Rob O. Font's picture

"TT hinting seems to me like a very poorly conceived system, frankly."

To get to the point would be too much to ask but I'm sure you mean the compiled-to-confusion form of TT as shown via FL or VTT lacks the current UI needs of a user interface for "dummies like us."

Or perhaps not.

Syndicate content Syndicate content