Adobe contributes rasterizer to FreeType, CFF on the web?

James Puckett

Adobe has open-sourced a CFF rasterizer to improve CFF hinting. Most corporate and government Windows XP desktop installs are likely upgrade to Windows 7/8 within the year. Will hinted CFF be a viable format for web fonts once the vast majority of IE users are running IE 9/Directwrite and most phones/tablets have better a better CFF rasterizer and a HIDPI screen? Will anyone care at that point, or will TTF have too much momentum to overcome (assuming that either Robohint or a working version of Fontlab 5.1 finally arrives)?

Dave Crossland

Yep, I expect CFF to be the future use-format of fonts, and I think ttfautohint will tie us over until we reach the promised land

James Puckett

Is CFF suitable for Chinese and Japanese web fonts in regard to file size? Or can those be better handled with component-based TT fonts?

Georg Seifert

Is it the rasterizer or the autohinter or both? If it is the autohinter, will it always rehint everything or respect the hints in the font.

James Puckett

I think they open-sourced the rasterizer, which the auto-hinter is tuned to work well with.

John Hudson

I expect CFF and TTF will both continue to be used, but with greater parity as targeted device resolutions increase and software applies the same rendering model to both formats (as now happens in DWrite). The decision which format to use will be determined by a range of factors, including script- and design-specific considerations. In any situation in which autohinting provides acceptable results, it won't make much difference which format is used, and CFF may be preferred because of its smaller file size. But on Windows at least the possibility to use TT instructions to make explicit overrides of e.g. y-direction alignments at a given ppem size, will mean TTF remains important for some projects.

Deleted Account

When I think on the format-file size-quality-web font issue, CFF looks great! In practice, however, I have not heard anything about subset ability, so all subsetting must be pre-cff conversion. Thus, the file size of the source font, and possible size ranges of the target fonts plays a rôle. Also, if serving a particular file so as best to take advantage of a ppm, were simple, lots or better things than solving MS rendering issues would be possible in web type.

But remember what we are talking about? if there is enough resolution so that auto hinting will always work on any font of any script, then hinting is probably not very, or at most, marginally important. If that's the case, why not just turn off the hints, as opposed to switching formats, much less to a format who's main advantage is web-relatively rather inflexible file sizing. It could change with the sudden surge in popularity of say, a 130 dpi device, but that isn't a likely spot, it seems, for devices to develop.

Thomas Phinney

It is (at least) the rasterizer.

Regarding FreeType on-the-fly autohinting, I understand that there is a switch in FreeType which a client app can set, as to whether to do autohinting or to respect the hints in a font. I expect this would be true for CFF as well.

I agree with John's assessment as to the future of CFF and TTF.

> Is CFF suitable for Chinese and Japanese web fonts in regard to file size?

Yes, very much so.

> Or can those be better handled with component-based TT fonts?

Not particularly better, no. (IMO)

> In practice, however, I have not heard anything about subset ability, so all subsetting must be pre-cff conversion.

It is not a lot harder than TTF subsetting. It can be done dynamically (on the fly).

John Hudson

I agree with Tom regarding CJK fonts. Comparing one of Adobe's CFF Japanese fonts with Microsoft's Meiryo TTF, the file sizes are roughly equivalent for a similar 20,000+ glyph set. I expect the size of Meiryo could be reduced by making more use of composites, but that would require addition of component ingredient glyphs and because the vertical positioning of such components wouldn't be consistent there would be position rounding issues to contend with (which is probably why composites are not much used in CJK fonts).

Meiryo uses y-direction instructions for stroke reduction at small sizes, so is a good example of something that is possible with TTF that isn't possible with CFF. But, again, this ceases to be an advantage as resolutions and, hence, the ppem sizes accessible to display typical text sizes on screen increase.

Matthew Butterick

Is this the rasterizer formerly known as CoolType?

What's the purpose of open-sourcing it — to encourage the Webkit & Mozilla maintainers to integrate it into the browser rendering engines, so text renders in a browser-specific way rather than platform-specific?

Deleted Account

Tom, are you suggesting that TTFs can't be subset on the fly?

And are folk suggesting that even when tripling the device resolution, autohinting CFF solves CJK well enough for text sizes?

John Hudson

And are folk suggesting that even when tripling the device resolution, autohinting CFF solves CJK well enough for text sizes?

I don't know what anyone else was suggesting, but I was referring specifically to stroke reduction, which ceases to be a factor when resolutions enable a sufficient number of vertical pixels to display all the strokes. How well those strokes are displayed is going to depend on everything from format to platform to hinting.

When we're talking about CFF, we're pretty much always talking about autohinting, yes? Does anyone manually hint PS fonts since Adobe made their autohinter available with AFDKO? The last time I manually hinted a PS font was Adobe Devanagari, and Adobe promptly dumped all my hints and ran their autohinter on it. I gave up after that.

Jason Campbell

For text sizes, the resolution would have to get quite high to resolve all the strokes in every ideograph. I know there are some characters that have Y direction stroke reduction hints at 50ppm, although they aren't usually the most commonly used characters. Although in order to leave enough room for all those strokes, you have to also force the stem weights of the most complicated glyphs to 1 pixel - another TrueType technique.

Deleted Account

"...ceases to be a factor when resolutions enable a sufficient number of vertical pixels..."

...you must mean around 67 ppm you can stop hinting CJK, (that's 265 dpi 18 pt).

John Hudson

I was anticipating somewhere between 50 and 60 ppem, so the sort of thing that Retina screens could fairly easily represent at text sizes. That's allowing both for variation in horizontal stroke thickness and variation in height of counter elements. Did you have a particular CJK character in mind? Something in modern use?

Thomas Phinney

DB asked: “Tom, are you suggesting that TTFs can't be subset on the fly?”

No, I am saying that CFFs can as well. You said that all subsetting must be prior to CFF conversion. I am saying that is definitely not the case.

Deleted Account

Oh good, though it didn't sound right. I said subsetting "must" be prior to CFF conversion as there are no CFF-subsetters generally available, (right!?). I'd rather not make anything I'm not sure I need, like a CFF subsetter, as long as I've already got something else and another way to make cff, woof, svg and any other functionally inferior derivative of a virtual typeface.. . . if you know what I mean.

Thomas Phinney

There aren't any generally available today, but Google is working on one.

Deleted Account

So, sub-setting now must be prior to CFF conversion until a public version is available. Until then, one must sub-set ttf for subset cff, after which sub-setting cff becomes silly unless one don't have a ttf sub-setter;)