Another thing. How does this downloading work in the browser? Will it look for the first font, and if that is not present move on to the next? Or will it download all of them?

I am just curious: why do you want to set it up this way? If you provide TrueType-flavoured fonts (TTF/EOT), why do you want to send just the WOFF version as PostScript-flavoured?

Because, as far as I know, the only up-to-date browser that does not support WOFF is Internet Explorer, and it needs EOT files. TTF is fallback for older browsers (Fontsquirrel provides a layer of security with its Web-only setting, and I don’t know any similar solution for OTF files), and SVG is for older mobile browsers.

How would you set it up?

If you wonder why I want to serve Postscript based fonts, it is because they force Windows to use the Standard GDI rendering. If you wonder why I want to do that, take a look at any headline sized font rendered with Cleartype GDI!

I don't think what you're trying to do is a good idea. (Or even necessary. So the font looks scratchy in some environments, so what?)
In web design, everything is relative to the viewport of the device. There is no such thing as a "headline sized font".

But, since you're trying to do it:
If you are sure Chrome is NOT rendering the WOFF, have you figured out which font file Chrome IS rendering?
According the spec, Chrome should be rendering the first format it finds that it supports - in this case WOFF. But you say it isn't doing that so I'm intrigued.
First, how do you know for sure that it's skipping the WOFF? And what's the test environment or environments? (Diagnosing stuff like this isn't simple.) Chrome version what, running on what?
And if Chrome is not rendering the WOFF, is it rendering the TTF or is it rendering the SVG?

I am assuming you think it's the TTF, because the SVG would render the font similarly to the OTF, I would imagine. (I stopped bothering with SVG fonts a long time ago so I haven't seen any to compare lately.)

If you're stumped, I'll test the files independently for you. Let me know.

Rich

Hmm. I think it was in fact a cache issue, and nothing else. I've tested it since, and it works fine.

I don't think what you're trying to do is a good idea. (Or even necessary. So the font looks scratchy in some environments, so what?) In web design, everything is relative to the viewport of the device. There is no such thing as a "headline sized font".
I don't agree with that. Don't go blind over hacks! Postscript has to be the future if you want a detail rich, Opentype savvy web. Truetype is too bloated in file size for large character sets and organic lettershapes. And off course it matters if the font looks scratchy! If you don't think so, you're surely come to the wrong corner of the web. And btw: There is such a thing as a "headline sized font". It’s fracking BIG.

But, to pull us back on topic (sort of), I'm still looking for answers to my two other questions:
How does the downloading of font files work in web browser -- do they pull all or only one file? And how should one ideally set up the CSS for Postscript-based webfonts?

That syntax you are using is already set up in a way, so unnecessary fonts are not downloaded.
The details of how the browsers should process the declaration can be found here: http://www.w3.org/TR/css3-fonts/#font-face-rule

The syntax should also be fine for delivering the WOFF font as PostScript-flavoured.

>There is such a thing as a "headline sized font". It’s fracking BIG.

In web design, you don't get to decide what's fracking BIG. The bigness and smallness of type is not under your control. This is difficult to accept, I understand.

You can fight against this lack of control using elaborate server-side user agent "sniffing" if that is available to you.
For example, if you detect that the user agent is Safari running on an iPad, you will know the physical size of the viewport and you can "feed" a set of default sizes accordingly.
But those settings are only a starting point. Your "design" is a recommendation that may have very, very limited influence.

In web design, you've got a lot of partners. The user is one of them. And the user can effortlessly enlarge or reduce your carefully chosen "sizes" to suit their tastes.

Using CSS and HTML alone, the idea of being able to specify big type or small type has become so vague and unpredictable if not totally meaningless, it's counterproductive.
If you can't predict (or detect) the size of the viewport, you can't control the size of the type. And even if you do predict (or detect) the size of the viewport, your decision is easily overriden.

So, good luck with setting the "size" of your web fonts.

BTW - I don't understand what you mean by "going blind over hacks".

Although things are certainly malleable, it's not so totally uncontrollable; just because some people (although not Frode) are control freaks doesn't mean anybody should strive to be a berserker hippie. For example, if you want a certain piece of text to end up very large, make it a large number of steps away from the smallest that has to be read: in the process of making the critical text large enough the user can't avoiding making the biggest size very large.

hhp

I’m not here to argue with you, Richard. I understand very well the nature of the web.

@hrant who said:
>it's not so totally uncontrollable

@frodefrank who said:
>I’m not here to argue with you, Richard. I understand very well the nature of the web.

I don't know if there's anything to argue. There's no right or wrong here.
It's more of a perceptual thing. Understanding and accepting are two different things.

The way I see it, until the rise of small screens on smart phones and tablets, web design wasn't regarded as all that different from print design. It was print design that accomodated a few different paper sizes and made some allowances for low res.
Today, there are way too many canvas sizes for that thinking to continue.

This is interesting:
For example, if you want a certain piece of text to end up very large, make it a large number of steps away from the smallest that has to be read: in the process of making the critical text large enough the user can't avoiding making the biggest size very large.

I don't think anyone's yet done decent research on size ranges. What the limits are. How big should text within an h1 tag be in relation to the text in the p tag, that kind of thing. And if the user goes large on the body text, will the h1 text become useless because you are only seeing a fragment of it?
That kind of thing.

Later.....

If you want a lot of specifics, Zoe Mickley Gillenwater is an expert on - call it what you will - fluid, liquid, responsive - design and just gave a talk on it. There's a slide presentation that sums up the madness nicely.

http://zomigi.com/blog/responsive-web-design-presentation/

http://zomigi.com/downloads/CSS3-Media-Queries-Responsive-Design_STC-Sum...