CFF format

Rob O. Font's picture

I was searching Adobe documentation to see if anything important's been updated since... 1996 and I became so put-off by the composition of the PDF describing the Type 1 format..

...I had to stop.

Does anyone know, does CFF still require that "sub-paths" do not overlap, (just like the faces of hot metal faces), and does CFF still demand a 1,000 unit em?

frankrolf's picture

Maybe the PDF has been shaken a lot during the 16 years of its existence …

These threads might help on your UPM question:
http://typophile.com/node/30727
http://typophile.com/node/30913

Overlaps must still be removed in the font, unfortunately.

Rob O. Font's picture

Thanks for your response Frankrolf.
Why is it unfortunate that overlaps must be removed?

BeauW's picture

I'm trying to find an old thread here that shows why. Can't even remember who showed this- but someone was making the joins of the glyphs (the example was an 'M') so that they overlapped in such a way as to make it easy to adjust the thickness of the strokes, without affecting the joining stroke. I know that what I just said is confusing. If anyone remembers what thread I am talking about... I'd want to re-read it myself.

Rob O. Font's picture

>to make it easy to adjust the thickness of the strokes, without affecting the joining stroke

Well it is easier to design with overlapping contours for sure! But I was looking at the international and other critical issues of overlaps in manufactured fonts. Sounds like I'll have to blog this one. Take cover. ;)

BeauW's picture

Still can't find the thread, but the idea was something like this:

John Hudson's picture

I've always understood two reasons for avoiding overlapping contours, both of which are to a certain extent historical, i.e. they used to be more critical than they are now.

1. Some renderers and RIPs get confused and paint overlapping segments the wrong colour. This issue seems mostly (completely?) to have been resolved.

2. Software does not remove overlaps when converting text to curves or when applying an outline stroke, as in BeauW's illustration. This depends on the sophistication of the software.

JanekZ's picture

3. Cutting letters in self adhesive PVC foil. (especially overlapped ogoneks... also depends on the software)

Rob O. Font's picture

>This depends on the sophistication of the software.

Only needs to be sophisticated enough to know how to use the core OS graphics.

Rob O. Font's picture

The other quest I'm dumbfounded on right now, and find no documentation of, is that the "C" in CFF stands for compressed. So a CFF comes to the altar to become a WOFF, does it get compresed again? and whether it does or not, what software decompresses the CFF after it leaves the WOFF? Tanks for your thoughts on this crucial issue.

John Hudson's picture

The C in CFF does not stand for compressed. Never has. CFF = Compact Font Format, and the compactness is provided by the type 2 charstring, i.e. it is an optimisation in the PS code not a form of compression.

Compact Font Format documentation:
http://partners.adobe.com/public/developer/en/font/5176.CFF.pdf

Type 2 Charstring documentation:
http://partners.adobe.com/public/developer/en/font/5177.Type2.pdf

Yes, a WOFF'd CFF font will be compressed, but relatively less so than TTF.

Rob O. Font's picture

And does the decompaction use the subroutined parts to rasterize parts that are merged or does the outline get decompacted and reassembled and then the total glyph is rasterized?

twardoch's picture

Also, I recall that the font renderer of older versions Mac OS X used to draw and antialias each path or component separately. Therefore, if they overlap, you could see a "ghost" white outline around the overlaps. This no longer happens these days with Mac OS X, but there may be other rasterizers that behave that way.

The subroutine mechanism in the "CFF " table also contributes to its compactness. In fact, the subroutine mechanism *is* a compression mechanism, so the difference between an unsubroutinized and a subroutinized CFF-based font is that the latter is compressed.

The composite glyph mechanism in the "glyf" table also is a form of compression. However, the principal difference between the composites in "glyf" and the subroutines in "CFF " is that the CFF subroutines can be just parts of a path, not necessarily entire closed paths.

Due to this fact, in the CFF rasterization process, the glyph outline is first assembled from the subroutines and then rasterized.

John Hudson's picture

Type 2 charstrings do not need to be 'decompacted'. They are more compact expression of the same data that used to be expressed using type 1 charstrings, and are directly interpreted by PS rasterisers. It isn't a compression mechanism; it's a code optimisation.

Subroutinisation -- great word -- is optional in CFF, and represents a secondary method of reducing CFF table size. This is more like compression, and as Adam notes, the glyph outline is assembled from the subroutines, if present, and then rasterised.

Rob O. Font's picture

Adam, how could subroutinized parts made in the compaction of s CFF overlap? Are they not sub contours between two on-curve points?

>It isn't a compression mechanism; it's a code optimisation.

Is the code optimized for some reason other that smallening the file size? And is this the primary compaction to subroutining's secondary compaction?

Are the subroutined parts stored separately, just like components, or are the master parts identified in a particular glyph and then employed by other glyphs?

I can kind of see from this why adobe hints can't get much smarter, and never did.

I guess the next avenue of inquiry is that folk from Warnok to the present, as we hear, have claimed the separation of hint and rasterizer is an advantage that allows the improvement of the rasterizer without changing the installed base of fonts. Assuming that means the installed base of well hinted fonts, and that web font quality seems like a fairly good reason to change the rasterizer, how come it still doesn't provide good enough web font appearance. i.e. the rasterizer is not changing to take advantage of the claimed advantage, in the face of great need?

twardoch's picture

David,

Subroutines are indeed always curve parts between two on-curve points. It has no relation to overlaps. You draw a "flat" outline, and the rasterizer gets a "flat" outline. What happens in between is compression and decompression, and the compressed form has no relation to overlaps. If you have overlaps in the "flat" outline before compression, then the rasterizer will get overlaps in the decompressed ("flat") outline. How the rasterizers (Adobe’s, FreeType etc.) will interpret the overlaps is their thing.

Incidentally, Adobe’s webfonts that are being served at TypeKit are TrueType-based. The reasons for this are two:
1. Microsoft Internet Explorer 8 and lower only accept webfonts as EOT, and only with TrueType outlines
2. The Microsoft Windows GDI rasterizer (used by Opera, Chrome, Firefox except 4.0 on Windows 7) renders PostScript-flavored OpenType fonts (be it in plain OTF or in WOFF wrapper) in a rather unfavorable way (with very strong grayscale antialiasing which makes them look extremely pale)

It’s only the DirectWrite rasterizer (used in Firefox 4 and IE 9 on Windows Vista and 7) which will render PostScript-flavored fonts in a similar way as the DirectWrite ClearType rendering of TrueType-flavored fonts. But please note that AFAIK, Microsoft has no plans to deploy DirectWrite to Windows XP, so on Windows XP, users will always be stuck with the "old" rendering of PostScript-flavored outlines, which, well, doesn't look very good.

For that reason, Adobe decided to convert all their fonts to TrueType outlines, and autohint them (with some manual hinting) when they published their webfonts on TypeKit.

Adam

Rob O. Font's picture

Adam, I'm well aware that Adobe’s web fonts being served at TypeKit are TrueType. Their release was soon followed by a blog praising the virtues of CFF over TT.

Adam, I'm also aware that the next DirectWrite rasterizer will render correctly hinted PostScript-flavored fonts in a similar way as correctly hinted TT fonts, which is what I think you mean to say above?

The issue is, that MS and Adobe are finally reacting to the supposed weakness of TT hinting instead of reacting to the superiority of a rasterizer needing no hints at all, like Quartz.

Mr. Hudson yonder, and others like him, are fond of touting the competition in rasterizers and how much more important that is that any sort of output compliance one can imagine.

But really, what advantage is gained unless confusion is the goal? I mean, presumably after this improved rasterizer is released, then what? Release all the Adobe fonts again in CFF?!

As a font developer, am I going to go back and rerelease my fonts in CFF? Doubtful. Am I going to release new fonts in two formats? Not likely because it'll be years before a font stack requires CFF, or brings any advantage to the user, if ever...

I mean hints is hints. The same few hints are required for both TT and CFF. I can't tell you how important it is to get them right once, put the font into the market, and be done, in ttf.

I have, in 20 years of making both formats, never gotten the feeling I could be assured of getting past the voodoo of type1 hints for any and all designs at any and all sizes. So, Ttf is the only sure path.

And this despite the fact that (ahem) tool makers have ignored good technical practice, not to mention my repeated advice and all but forced unknowing font developers to work backwards, with lossy conversion from T1 to TT both hints and contours.

This year, the web font sh!t hit the w3c fan, and what's been done? A wrapper, a parallel quality rasterizer, enough font freedom to ignore 90% of what is offered for the web, and negative education, like 50% of the blogs I read.

Apparently though, no amount of confusion is enough to slow down web fonts done the right way.

oldnick's picture

As a font developer, am I going to go back and rerelease my fonts in CFF? Doubtful. Am I going to release new fonts in two formats? Not likely...

IMHO, both of those decisions are bad ones. I have been conducting some impromptu market research in advance of packaging my entire library as a whole and in thematic/historical parts, and I have found that there is a lot of lingering mistrust of TrueType due to the serious badmouthing it received (primarily from whom will not be mentioned) after the format was introduced. A number of Mac users were even amazed--and changed their tunes--after learning that the TTF format was developed jointly by Apple and Microsoft.

CFF and TTF are here to stay--for the foreseeable future--and not offering your customers both only leaves money on the table that you might otherwise claim. Over the course of the last several months, I have reworked my entire library--over 560 fonts--and generated them as CFF and TTF. The exercise has afforded me the opportunity of correcting some unintended errors and misguided choices, and generally to tune up the whole kit and kaboodle. It's worth the effort...

blank's picture

…I have found that there is a lot of lingering mistrust of TrueType due to the serious badmouthing it received…

Likewise there are plenty of Windows users who believe that OpenType is a a proprietary Maconly format. Usually because Opentype fonts don’t work with their cut-rate software that only supports TrueType fonts.

oldnick's picture

Likewise there are plenty of Windows users who believe that OpenType is a a proprietary Maconly format. Usually because Opentype fonts don’t work with their cut-rate software that only supports TrueType fonts.

That's odd, because I was under the impression--perhaps mistaken--that the OS did the basic font handling and Windows, since Win2000/NT4 has had native PostScript support built-in. Even my trusty old CorelDraw 9 (copyright 1999) works with OpenType fonts: although it can't access OpenType features, it sees them and renders them as PS Type 1, no problem.

John Hudson's picture

David: Mr. Hudson yonder, and others like him, are fond of touting the competition in rasterizers and how much more important that is that any sort of output compliance one can imagine.

I don't think I've ever said anything to suggest that I think the total free-for-all of type rendering competition and resulting lack of compatibility and predictability is a good thing. What I have pointed out -- and what surely doesn't need to be pointed out; you cite Warnock, you've read the blogs -- is that the companies consider rendering technologies to be an area of competition. And so long as they continue to do so, you're not going to get them to sign up to standardisation.

John Hudson's picture

David: Is the code optimized for some reason other that smallening the file size?

I don't know. You'd have to ask PS RIP engineers. Possibly there are also speed benefits to the type 2 charstring?

Rob O. Font's picture

JH> I think the total free-for-all of type rendering competition and resulting lack of compatibility and predictability is a good thing.

Well we just disagree then. :) (how's that for FOX-like editing?)

twardoch's picture

I also do think the competition is a good thing, in particular because of the rapid development of display technologies. CRT, e-paper, all kinds of flat panels — they all produce different results, and the varying ppi densities contribute to it as well. I think it makes perfect sense that device manufacturers such as Apple fine-tune their rasterization filtering depending on the device, and the device generation.

For example, a "slavish" following of the original TrueType rasterization model on something like iPhone 4 would be ridiculous. This does not mean that those vendors always get it right: in my opinion, Verdana or Arial were rendered better on iPhone 3G than it is being done on iPhone 4, because on the new "retina" display, the type is rendered too thin. I'd like the ability to add some weight (or virtual ink spread) to type on my iPhone 4. In fact, as a user, *I* do want the ability to customize the rendering of type on my machine, or portable devices. On Windows, I used to make customized versions of systems fonts for my own use, where I fiddled with the "gasp" table or even rehinted the whole thing, but it was a laborious process. The ClearType tuner on Windows was a step in the right direction. Safari on Windows has a wonderful font appearance tuner which toggles between Windows default rendering (which can be ClearType or plain-aa, depending on your system setting), and Mac-like rendering in five or so different modes.

I'd actually even like this type of control to be added to CSS so authors can add or remove a bit of weight when rendering a certain font — depending on which color the foreground and background has, the basic font sizes etc.

A.

Rob O. Font's picture

...what you're saying Adam, is that you like the selections made by Apple and Microsoft for their respective DESKTOPs. Good or you! Me too! But wAKe up! This is not an area of competition and thoroughly different from what's best for their BROWSER users, with browsers being a window to a world of possible visual experiences beyond the desktop... what I say, now for 7 years, is if non-competitive solutions are enforced in users BROWSERs, it is constraining the competition in hinting and that follows from there. One can hint only to prevent visual disaster, not to compete on real readability, and one can only draw and hint from scratch to actually solve the problem of the non-competition you and Hudson think of, and parrot onward, as 'competition'.

How y'all became 'invited experts' on anything other than surrendering is a mystery to me. ;)

twardoch's picture

[Personal rant]

1. I don't think I've ever been an invited expert to anything. Maybe one time in 2001, but that's really ancient history. I was almost still a student then, and had, well, lots of spare time on my hands.

2. Come on, David. As far as I remember our discussion about EPAR in Dublin: you've been trying hard to make me surrender to your narrative, and I don't think I was *that* an easy "opponent". You should know me well enough to know that I'm not an ideological drone. (Neither is John.)

3. I fondly remember your lecture at Typo Berlin, was it two or three years ago, when you came up with a great sentence "The only difference between a Microsoft readability study and a bucket of shit is the bucket". While I did enjoy it a lot, I also realized that this certainly is a very straightforward way (for you) *not* to become an "invited expert" on anything.

You know that I admire your work, and I truly enjoy your ground-shaking perspective. I'm not afraid to be proven wrong *because* I'm not ideological (or at least I like to think that I am not).

You, me, John — I don't think our goals are so dissimilar. Yet each of us has a difference in style. You're an expert of telling other people what they don't want to hear. Some can take it, others cannot. I like to think of myself of trying to become an expert of *pretending* to tell other people what they *want* to hear, while in reality, I'm telling them what *I* want them to hear. I'm trying to walk a tightrope between becoming Molière's "Misanthrope" and, well, *getting results*.

I would never come close of accusing you of any ill will — on the contrary, I think what you're doing is driven by lots of good will and idealism. So I don't mind a healthy punch from your side. But I'm an idealist as well.

I'm different than you. But I'm on your side. I'm an ally. Keep that in mind :)

[End of personal rant]

twardoch's picture

> if non-competitive solutions are enforced in users BROWSERs

That's simply not true. Right now, on one and the same machine, using Windows 7, I can have Chrome running pure black-and-white, Opera running GDI ClearType, Firefox 4 and IE 9 running DirectWrite ClearType, Safari running Mac OS X-style rendering, a forked WebKit using FreeType and an Adobe-AIR-based browser running Flash-style rendering.

All on one and the same desktop, simultaneously.

WebKit, Chromium and Mozilla are all opensource. FreeType is opensource. Get some developers to your island, brainwash them, make them fork the projects, add Berlowesque mode to FreeType, and there you go. Seriously. It's actually not that expensive. Making Firefox compile with FreeType as the font renderer on Windows or Mac is actually flipping one switch.

*Unlike* in the desktop days, *now* is the time when a user (or a developer) can build their own browser, which will be 100% compatible with all the standards, but will render fonts *exactly* as *you* want it to render. What's bloody non-competitive about that!?

In the old times, the Apple & Microsoft "pure" TT and Adobe's closed-source Type 1 rasterization -- *that* was non-competitive.

But maybe you have a different opinion on that because, ahem, back then you *used to be* the "invited expert", huh? (Sorry.)

The people behind font renderers are not some evil mafia. They just happen to be where they are, and do what they do, probably as well as they can. Pretty much all of Firefox's text rendering is de facto in hands of four people: Werner Lemberg (the maintainer of FreeType), Behdad Esfabod (the maintainer of HarfBuzz), Jonathan Kew & John Daggett (who are at Mozilla).

They'll probably all meet this year at the LGM in May in Montreal:
http://libregraphicsmeeting.org/2011/

Go there, and show them how this should be done. And perhaps they'll do it. Chances are they will. The Berlowesque code will be there, and it'll be only a matter of flipping a switch.

Cheers,
Adam

Rob O. Font's picture

>All on one and the same desktop, simultaneously.

You don't get it. No hard feelings, and good luck.

>back then you *used to be* the "invited expert", huh? (Sorry.)

You're confused, I was hired. When I'm on stage, where I never accept money, I'm invited.

twardoch's picture

Good. :)

Still, I don't think your depiction of "non-competitive solutions are enforced in users BROWSERs" is accurate. The browser is currently more in the user's control than any other major piece of software before. Hell, even I wrote myself a simple Google Chrome extension to have basic control over the rendering: https://chrome.google.com/extensions/detail/ifijlgjpdgojmjphpleniimbgbkb...

And seriously, I'm not much of a programmer, especially when it comes to JavaScript.

dezcom's picture

Rendering raises reactions regularly.

Rob O. Font's picture

Adam> Still, I don't think...

Has it passed? Read the thread about the guy who just wants to find out if CT is on and change it to Std rendering.

Adam> ...your depiction of "non-competitive solutions are enforced in users BROWSERs" is accurate.

REaaaaalllllly!? because you can have 5 browser choices? do you choose the browser that's best for each site? Who pays for this kind of user's time?

Adam>The browser is currently more in the user's control than any other major piece of software before.

Have you not used indesign then to compose type? I'd rate control of type in indesign as a 10, in any one browser you can name as a 3, and in any five browsers, (the real thinker's deal), as a 1.

dez>Rendering raises reactions regularly.

Competition confounds conspicuous coagulators

Anyone here who wants competition in leading? How about style selection? anyone want competition in any browser's interpretation of any basic font properties?

You'll notice perhaps, over the past year that browsers have “come together” to render ttfs like the native browsers of each platform. The Mac browsers all render pretty much like safari, the windows browsers render pretty much like IE.

To keep in the weft, let's hope CFF has a smooth @ff rendering launch.

twardoch's picture

> You'll notice perhaps, over the past year that browsers have
> “come together” to render ttfs like the native browsers of
> each platform. The Mac browsers all render pretty much like
> safari, the windows browsers render pretty much like IE.

But this is an intermediate point in time. The browsers are growing from being "just one application among so many" on a desktop towards being "a really really important application". But Chrome OS shows that the browser may become "the desktop" (Microsoft tried that years ago with Active Desktop, but that was too early).

Applications that run in the browser already give the user more control over the UI than desktop apps. For example when working on something like Google Docs, you can ZOOM in an out the entire UI (not just the edited text but also all the controls) — which you cannot do in Word. With things like popup or ad blockers you can modify your user experience in a web app by YOUR decision as a user (desktop apps only allow you to customize the user experience if the app developer decided that you can do it). Etc.

In my view (but of course I may be wrong, we're predicting future here), browsers will give more control to the user rather than less. I mean, it's already possible. I can inject my own client-side JavaScript and CSS to any app. This website http://userscripts.org/tags/flickr shows you how HUNDREDS of user-side tweaks exist that modify the user experience of Flickr. Those tweaks can add new buttons in place that Flickr doesn't offer, change the behavior of Flickr's UI elements etc. Same applies for Facebook: http://userscripts.org/tags/facebook . There are TONS of alternative user experience packages for Wikipedia, including some that "convert" Wikipedia pages on the fly into multicolumn full-justified "newspaper" with automatic hyphenation.

Or have a look at http://fontfonter.com/ — I want the NY Times website set in FF Meta and and FF Meta Serif? There you go. What's non-competitive about that?

Of course the general public doesn't bother with it now, but they can. Or intermediate providers can. (So they can compete with the original makers for "creating the best user experience" for Facebook, Flickr, Wikipedia, NY Times etc. etc.)

This is all possible because the web is driven on open protocols.

> because you can have 5 browser choices?

No, the choice of browsers is actually open-ended. I can fork, patch and build my own version of WebKit or Firefox if I so choose, that will do whatever I want. (Agreed, not EVERYBODY can do it, but intermediate providers can.)

I'm not saying everything is "much better" than it used to be, but I definitely don't agree with you that it's supposedly "worse". It _is_ better.

Again: if I want some feature in Google Docs or Facebook or whatever, at least to a large extent I can ADD IT MYSELF. Rather than waiting for the vendor of the site to do it. (Userscripts on Flickr prove how powerful this is).

This does not yet obviously apply to font rendering, but we'll get there.

dezcom's picture

"Competition confounds conspicuous coagulators"

Truer tales told too tumultuously to tender tabulation twixt typed text and tyranny today ;-)

Té Rowan's picture

Durn designers discombobulate...

Rob O. Font's picture

>This does not yet obviously apply to font rendering, but we'll get there.

No.... It doesn't. It does however illustrate one of the two main strategies for dealing with an inability to envision in the face of an ability to envision. You can blather on endlessly off the topic and then claim you don't understand what i'm talking about, or you can pick an argument, make sure it escalates to bad words, and then claim unworkable differences. Both have their advantages and have been employed vs me in the last year or two. Either strategy leaves a group of non-visioning, but agreeable dummies in place. :)

Syndicate content Syndicate content