Richard--

I'm brand new to this site and to this sort of thing. And particularly new to the problem you raise since I still do not have my own website.

However, here's one solution that I think gets around both the copyright issue and the reproduction (as you would like it) issue. But I'm not a lawyer, don't even play one in the shower.

It occurs to me that for isolated pieces of text, i.e., headlines, call-outs, initial caps, or even short pieces of body type, etc., you may want to consider creating the text in the font you desire, then making a "picture" of that text, then place the picture on the page where your design calls for it.

By picture, that could be a screen shot, or perhaps a copy of text set up in Photoshop where you have control of color of text/background, size, and file type.

You may need to experiment with how different browsers reproduce the image you choose and where they put it and what size. And as a practical concern, how such a solution may adversely affect loading time.

I know that some designers do this for stand-alone logos. I'm unaware of anyone doing that for inline (with text) work.

For what it's worth.

--rlk

I ran into a problem once where the name of a font caused a problem. I don't know enough about web technology to completely understand this, but here is what happened:

I stumbled on a website while at work that I seemed to have a proprietary font that I had designed being used as display type. After exchanging a few emails with the site owner I realized my computer was using a font I had called Jester for display, but the owner had an entirely different Jester. For proprietary fonts I typically don't worry about name duplication since they are for internal use only, but I can see how this can be a problem with web technology. It turned out there were at least 2 commercial fonts called Jester as well.

^^ Your problem is not a new one.

http://www.bleisetzer.de/cms/front_content.php?idcat=57&idart=512
Gruppe VIII - Schreibschriften - Rheingold kräftig
J.D. Trennert & Sohn, Hamburg-Altona
Erstguß 1936
Erich Mollowitz

http://www.bleisetzer.de/cms/front_content.php?idcat=57&idart=459
Gruppe VIII - Schreibschriften - Forelle Auszeichnung
C.E. Weber Schriftgießerei, Stuttgart
Erstguß 1936
Erich Mollowitz

Rheingold (Rhinegold) and Forelle (Trout)

Would be intersting to know which one was sold better. But I don't have any information about it. Rhinegold... what a great name. And I don't like trouts. ^^

Georg
_______________________________________________
„Ich bin ein Preuße, kennt Ihr meine Farben...“

Richard -- What you bring up is indeed a potential problem.

The kind of confusion that Felici describes is often resolved in the actual font naming fields, as most vendors will use a unique element in their font naming (i.e., AGaramond, GaramondITC, GaramondFB, etc.) even if the name of the typeface is pretty much the same.

However, there are occasions when two different typefaces will have the same name *and* the fonts themselves will also have the same naming.

Several years ago, I was working on a project with Peter Bruhn's Farao fonts. I also happened to have loaded on my system Frantisek Storm's Farao fonts. Not only were the two typefaces named the same, but so were the font files, and this was causing problems. I alerted Peter and Veer to this issue (I think Storm's face came first) and suggested that, at the very least, they change their font naming to "FaraoFTN" or some such, to eliminate technical conflicts.

It is also distinctly possible for different versions of the same font to exist with no distinction in the internal font naming. So, for instance, as mentioned in another recent thread, I use a different version of Georgia than most. So I don't always see exactly the same thing as others.

Also, and I may be wrong about this (someone more technically savvy, like John Hudson or Karsten Luecke may be able to answer better), but I think different platforms/systems reference different name fields within a font, which may or may not contain exactly the same form of the name. So the browser examining what's already available in the local system may need to be looking for different names for the same font, depending upon the platform.

@all
I fear I may have been too technical about the nature of the problem.
Rephrased: "How often does it happen that fonts from different sources are named the same?"
Or, "Are there certain font names that seem to crop up frequently?"
End of question.

@rlketch
You gave me a chuckle. Sometimes I wish I could turn the the clock back and view everything with the same eyes I had when I didn't know anything. It helps in seeing the forest for the trees. Highly useful but ultimately impossible.
I just know someone's going to take a swipe at me for this next statement (Hah!) but with regards to certain technical issues regarding fonts I've taken pains to guard my ignorance carefully. I really don't want to know too much.
Yet.
You are quite correct, fonts can be presented as images and until very recently - some would argue still - in many web design situations this is a necessity. In web pages, fonts as images will be around for forever, no matter how good the "native" font rendering gets.

@stephen rapp
Thanks. Every little bit helps.

@Bleisester
Will follow your links. Thanks.

@kentlew
I was willing to bet money you were going to comment on this, and I would have won! If you didn't I was going to email you.
Thinking out loud:
You're of course correct about the internal naming. And platforms, too. And then there's the complication of the author of the web page having the option of naming the font anything they want, pretty much. And what if that name conflicts with a font in the OS? One question is starting to beg another.
I was thinking of Georgia, too, because I know that Microsoft is putting Georgia and Arial through a major renovation.
So soon it will be: which Georgia? Not just for you but for everybody.
I'm starting to come away with the impression that this is more than a "might affect one in a million users" thing.
Worth nailing down, for sure. Thanks.

Rich

Hudson? Luecke? Anybody?

Maybe we're about to enter a new era of fontname cybersquatting.

> And then there’s the complication of the author of the web page having the option of naming the font anything they want, pretty much. And what if that name conflicts with a font in the OS?

Maybe I'm not understanding the @font-face implementation adequately, but my understanding is that any author name designation is just a convenient handle within the CSS. It is then associated with a URL source, which is what gets downloaded and stored in cache for rendering the page(s). In this case, the URL is identified with the specific [external] file name.

If the author makes use of the "local" attribute, then the name is going to have to be the same as whatever name the system utilizes (right?) in order for the browser to accept that the font is available locally and not bother to download the URL-linked source.

I don't see how an author-attributed handle can conflict with a font in the OS. What am I missing?

So soon it will be: which Georgia?

Soon? Here is a trace on my mac using an Apple fonttool command (on my MacBook pro with OS X 10.5.8)


ftxinstalledfonts -f -l | grep -i georgia
77 65668 Georgia Bold Italic /Library/Fonts/Georgia Bold Italic.ttf
78 65669 Georgia Bold /Library/Fonts/Georgia Bold.ttf
79 65670 Georgia Italic /Library/Fonts/Georgia Italic.ttf
80 65671 Georgia /Library/Fonts/Georgia.ttf
201 65792 Georgia /Library/Fonts/Microsoft/Georgia
202 65793 Georgia Bold /Library/Fonts/Microsoft/Georgia
203 65794 Georgia Italic /Library/Fonts/Microsoft/Georgia
204 65795 Georgia Bold Italic /Library/Fonts/Microsoft/Georgia


So, which Georgia? if I type


chalet:~ boyer$ which fontforge
/opt/local/bin/fontforge


I can know which fontforge but for fonts, is there a "font path"? On my Powerbook, I had to deactivate Microsoft fonts to browse, else some diacritics would come out completely out of place.

Michel

So soon it will be: which Georgia? Not just for you but for everybody.

Unless an update to a font introduces changes that would affect existing documents set in the older version of the font, e.g. changing widths or kerning such that lines reflowed, updates do not usually involve a change of name. In this case, you have to check the version string to know ‘which Georgia’.

I'm not sure what browsers are expected to do in this regard. Probably this is an issue to raise on the W3C list. Consider, for example, if a web author has used @font-face to specify e.g. Cambria to display some Ingushetian text in Cyrillic characters. This requires the version of the font that ships with Windows 7; earlier versions of the font do no support these characters. Presumably the web author has arranged web serving of the appropriate version of the font, but what happens with font fallback in browsers that do not support the served font, or which might want to default to a local copy of the font to save bandwidth? If the local font is an earlier version than the served one, it might not support the text; on the other hand, it might.

In this case, you have to check the version string to know ‘which Georgia’.

The version string for /Library/Fonts/Georgia.ttf tells me that it is version 5.00x. The version string of /Library/Fonts/Microsoft/Georgia tells me that it is version 2.05. My guess is that version 2.05 was installed with Microsoft Office 2008 (the installation was performed by our "computer services"). As sii said in the thread http://typophile.com/node/63794 "Office fonts are installed as system wide resources so can be used in the Adobe apps you mention. which doesn’t make a lot of sense." and he adds "Typically we see graphic designers, especially those on the Mac picking up end user licenses for fonts like Calibri from Ascender, just to stay safe, and have licenses that are more like typical font EULAs." That means that those fonts may not be used by other applications, yet may interfere with their proper functioning.

@kentlew
I was thinking out loud about possible points of confusion for someone using @font-face.
For example, if this appears:
@font-face{
font-family:georgia;
src: yadda, yadda...
}
In this case, you're absolutely right - the georgia is the georgia specified in the src URI.
But what happens if the font fails to download for some reason? What georgia do we have then? Or does the browser just tick down one in the font stack and use that?
What does IE do? What does FF do? What does Webkit (Safari/Chrome) do? It can get crazy but I can think of situations where this would be important to know.

JH>but what happens with font fallback in browsers that do JH>not support the served font, or which might want to JH>default to a local copy of the font to save bandwidth?

Yes. We need to know. To serve those who speak Ingushetian or any language.

@michel boyer
Now you've really got my head spinning. But it's all quite relevant. Thanks.

@all
One of the really, really good things that's come out of Microsoft finally putting its muscle behind standards with IE8 is the generation of test pages. Thousands of them.
Unfortunately, because @font-face was frozen in place - even in IE8 - I'm not aware of any relevant test pages. In the absence of that, the developer community will have to generate such pages and test on its own.

@all

I wasn't expecting to find an example of this problem so early on in the life of @font-face but I did today.
I'm now convinced that this is a phenomenon that will become more and more likely the more @font-face is used. I can't see it any other way.

The font involved is Museo by Jos Buivenga.

This page:
http://www.giordanopiazza.com/candybox/web-fonts-embedding/
names the font in the local() descriptor as this:
src:local("Museo 500"),local("Museo-500"),
url("Museo500-Regular.ttf") format('truetype');

The file is a 29 kb TTF.

This page:
http://nicewebtype.com/fonts/museo-and-sans/
names the font in the local() descriptor as this:
src:local("Museo 500"),local("Museo-500"),
url("type/Museo500-Regular.otf") format("opentype");

But it's a 42kb OTF.

Named the same but ain't the same:

With all of the slicing and dicing and subsetting and whatnot that @font-face will bring forth, in a year's time there might be a thousand Museo 500's floating around.
Some of them might be more popular and see more use than the original, "authentic" font by Jos Buivenga.
And some of them will undoubtedly be installed in the OS.
And so, writing this: local("Museo 500"), becomes a bit of a crap shoot.
(It won't be the first time unforeseen conditions brought on by actual usage render useless what seemed at the time like a smart feature.)

One of the promises of @font-face was that it would - in the context of web design - change fonts from variables into constants. It's supposed to take the guesswork out of adding fonts to web pages, not add to it.

I'm not quite ready to say, "Best practice is to avoid the local() descriptor in all but exceptional cases" but it's sure starting to shape up that way.

In the words of the old quiz show, What's My Line:
"Will the real Museo 500 please stand up?"

Regards,

rich

Seems like the differences you're showing have more to do with the rasterization of the two different formats, rather than differences in the font version or design. But that doesn't negate your point or your concern.

Tracking this thread.

@kent

Yeah, think you're right. Looks like something happened in a conversion from OTF to TTF.
Jos's files are OTF.

@tim

Garrick Van Buren confirms that this is an issue he ran into early on with Kernest:

“In my early experiments w/ Chank Diesel - he sent over some tweaked fonts, and he obviously has his own fonts installed on his system - so if the CSS I wrote matched a font installed on his system - it loaded the local font, rather than the hosted, tweaked one.”

At first, this might seem like a fluky situation. But soon enough, how are you going to know who's got what "tweaked" version of what on their system?
Call it what you want - authenticity, provenance - it *will* be an issue going forward.

(BTW - The Kernest service does *not* use the local() declaration when it feeds the style sheet.)

Ya catch 'em as you can as they whiz by...

rich

This is definitely a real problem. I'm starting to agree that the local() declaration needs to go. Web fonts are being sliced and diced for particular applications (yes, I will take some credit for that) and are NOT the same as the originals. Not only that but CFF OT and TTF render very differently in Windows. Currently CFF OTs get grayscale anti-aliased where TTFs get ClearType.

Maybe Font Squirrel should add a short snippet to the Version string in the name table showing that it touched the font? Would that be wrong?

@ethan (fontsquirrel):

Yeah, I think local() has to go. Glad we're moving toward consensus.
It's one of those things that sounds great in theory - save a download, render everything quicker - but there's a gotcha that was unforeseen and that's only going to get worse.
It comes down to a decision over how many users you're willing to screw up just to give the majority a quicker loading page. And, unless it's a widely installed font like Cambria or Constantia or something like that, only on rare occasions will it make a difference, anyway. Is it worth the doubt and confusion?
Is it worth screwing up one in a hundred, one in ten thousand, one in a million users? What's acceptable?
I said to Garrick Van Buren - corporate consulting taught me that whenever there's a doubt, invariably, the guy you end up screwing is always the Vice-President of something or other and then you're toast!
Take a day to think about it, Ethan. Maybe send a draft of the changes around to the @font-face irregulars like me and stk and Paul, et al...

"With great responsibility....' (you know the rest). Hah!

Regards,

rich

I don't really understand.

Multiple versions floating around are because they're getting subsetted, sometimes autohinted as developers tweak them for optimal use as a webfont.

If those files actually end up being installed on a users machine, it's because a user took that webfont-optimized file rather than downloading the legitimate version from the designer.

And that's the audience we're going to optimize the experience for??? I for one would be happy to have a little built in "what the fuck did you thing you were doing" hanging out in the webfont.

Are there any cases where we would see a tweaked font installed locally that we'd consider "legitimate" aka it SHOULD be installed as a system font ?

My initial thought is that webfonts should probably be differently named from user installed fonts. There are many legitimate reasons why the version of a font served to a website might be different from the version of a font that might be installed on a user's system, and this may affect everything from character set support to outline/hint format to OpenType Layout capabilities. Simply put, if a web developer wants to be reasonably sure that the content of a site will be displayed correctly using a served font, then it is necessary to ensure that the served font, and not a local version, is used.

Ergo, if I were selling licenses for webfonts, I would ship those fonts with different names from the existing desktop versions of the same design, e.g. 'MyFont WF' instead of 'MyFont', or even with a name that links the font to the customer in some way.

John, that sounds really wise. Seems like a more appropriate solution for this problem.

@all

There's an unstated secondary technical consideration at work here that should be stated for anyone who drops by and simply says, "Well, if it's a problem, why don't you just not use the local() descriptor?".
Unfortunately it's not as simple as that and it has to do with Internet Explorer's legacy behavior.

Some months ago it was discovered that, when presented with CSS syntax like this:

@font-face{
font-family: somefont;
src: url(‘http://mysite.com/fonts/somefont.eot’);
src: url(‘http://mysite.com/fonts/somefont.ttf’) format(‘truetype’);
}

Internet Explorer attempts to find a font file by resolving all the text between the opening and closing parens in the second "src:" rule as something like this:

“http://mysite.com/fonts/somefont.ttf)formattruetype”

This wastes time and ends up with Internet Explorer getting sent a "404" from the server. Worse, the second "src:" rule overwrites the previous rule so that in Internet Explorer “font-family: somefont” has no font associated with it at all.

At that time, I came up with a workaround: a dummy IE “blocker” rule that gets listed first in the ruleset.
Like this:

src: url('//:') format('IE-No404'),url(‘somefont.ttf’)format(‘truetype’);

Which works fine to prevent IE's unwanted behavior and does not require using the local() descriptor if you don't want to.
I posted about it to the W3C web fonts mailing list:
http://lists.w3.org/Archives/Public/www-font/2009JulSep/1361.html
and also my blog:
Mo' Bulletproofer @Font-Face CSS Syntax

These contain all the reasons why I felt it was preferable to just deal with IE's peculiarities and stay away from using local(). (There were also some issues with getting that syntax to work with the Opera browser at that time.)
This was all well before the problems with font naming became as clear as they are now.

However, prior to my suggestion, another syntax suggested by Paul Irish – more elegant-looking and less suspicious of local() than mine - had already begun making the rounds. Paul’s been blogging a lot longer than me, gets higher search rankings I'm sure, and it's a fair bet he's in contact with a lot more people in the web development community than I am.
So Paul’s suggested syntax has seen more use than mine – including the demo pages provided with FontSquirrel’s @font-face packages.
It looks like this:

@font-face{
font-family: somefont;
src: url(‘somefont.eot’);
src: local(‘Somefont Sans 500’),
local(‘SomefontSans-500’),
url(‘somefont.ttf’) format(‘truetype’);
}

Using this syntax, the local() descriptor acts in two capacities. One is obvious and standard compliant, and the other is hidden and non-standard.
The first capacity is as a mechanism to query the local operating system to see if it has a font named “Somefont Sans 500” or, on the Mac, “SomefontSans-500”. If found, the installed font with that name is used instead of the font specified in the “src” URI. This, of course, is exactly the intended purpose of the local descriptor. It’s how it was designed to work as per the standard.
However, the second, hidden and non-standard capacity is as a mask so that, once again, Internet Explorer skips the second "src:" rule and does not waste time looking for a non-existent resource on a server that returns a 404. Internet Explorer encounters: "src:local(......)" and skips the entire rule.
In this fashion, the local() descriptor does double-duty. But you *must* include local whether it does any good or not.
(BTW - Paul and I have communicated quite frequently. We're not strangers.)

So back then, I considered Paul's recommended syntax and mine as pretty much six of one, half a dozen of the other. Although I can't say I didn't still feel like the local()/font-naming thing didn't feel like a time bomb to me. Intuitively and intellectually, it just did.
And that's why I started this thread - to first, ask the experts and get their opinion. But now, facts unfolding on the ground are making things much clearer.

Now we’re discovering that local() has serious drawbacks. If there was no other concern, the answer would be to simply not use it.

Like this:

src: url(‘somefont.eot’);
src: url(‘somefont.ttf’) format(‘truetype’);

But as has just been discussed, that won’t work for Internet Explorer.

So, we’re back now to using this masking rule:

src: url('//:') format('IE-Mask')

And the question is whether to continue to combine the rules for Internet Explorer with the rules for all other browsers like this:

@font-face{
font-family: somefont;
src: url(‘somefont.eot’);
src: url(‘//:’)format(‘IE-Mask’),
url(‘somefont.ttf’) format(‘truetype’);
}

Or accept some redundancy and split the rules for Internet Explorer off into their own corner, like this:

@font-face{
font-family: somefont;
src: url(‘somefont.eot’);
}
@font-face{
font-family: somefont;
src: url(‘//:’)format(‘IE-Mask’),
url(‘somefont.ttf’) format(‘truetype’);
}

To make the long story short, there are arguments for and against either approach which I won't go into here.

To sum up - that's the complicating technical backdrop behind this discussion of whether or not using local() is a good idea.

@paulirish

Paul,

I'm not understanding you on this at all. Do you see this as a "user freedom" issue of some kind? And, while a smart thing to do I think, how does John's suggestion solve the problem? It doesn't.
Please explain, I'm befuddled by your comments.

@Paul-

I don't think the issue is that manipulated web fonts are getting installed on user machines (which would be a bad thing, I agree). It is more like this:

A user purchased the Museo Sans family from Exljbris. These are CFF OT fonts with OT features. Now, the Museo 500 weight is free and allows @font-face, so a budding web designer dumps it into the Font Squirrel Generator and generates a web-ready version. The new fonts are subset, converted to TTF and have hinting applied.

When the user who has Museo Sans installed on his machine looks at the site in Win FF he will see the original CFF OT fonts which are rendered in grayscale anti-aliasing. Everyone else will see the font in TTF and will render in ClearType.

I'm not convinced that this is a big issue yet, but could be. I'm sure there are some unforeseen consequences to using the local() approach. @john's idea of renaming the font is a good one.

Anyway, designers are always clamoring for as much control as they can get. I see local() dying as more and more of them get on board and use @font-face in real life.

http://www.typophile.com/node/63992

fontsquirrel -- A user purchased the Museo Sans family from Exljbris. These are CFF OT fonts with OT features. Now, the Museo 500 weight is free and allows @font-face, so a budding web designer dumps it into the Font Squirrel Generator and generates a web-ready version.

Museo 500 is free and allows @font-face use. But this does not imply that it may be converted. Go to
http://new.myfonts.com/fonts/exljbris/museo-sans/500/buy.html
and click "commercial" to see the license. It allows @font-face ("4. Embedding") but does not allow modification ("5. Modifications").
For exactly this kind of wrong conclusion, I cannot say that I am particularly happy about the Font Squirrel Generator. It makes people think: It's there, so let's use it with whatever font we got. After all, and upcoming web font has not changed anything about this, if you license a font (whether paid-for or not) you do not owe it and are not allowed to do with it whatever you want ...

Jos' EULA by the way is pretty concise and straight-forward. "It's legalese" is not an excuse here.  ;-)

* * *

Back to local(), I do not see the big problem.
If a font comes in two formats, like CFF-OTF and TT-OTF (or TTF), then metrics and everything should still be the same. Rasterization will differ, but that's about it. A more important issue are different font versions since these may have different character sets. Read: may, not: need to.

It seems that to make sure that a site looks as expected -- which is not the case anyway across different browsers and platforms -- one better avoid local(), for potentially different font versions. I do not see any merit in using local() with fonts that are not among the safe web fonts. -- Not even if the fonts in question are "for free" and may have been downloaded by the user who in this case is the website viewer.

“A decision is a judgment. It is a choice between alternatives. It is rarely a choice between right and wrong. It is at best a choice between "almost right" and "probably wrong" - but much more often a choice between two courses of action neither of which is provably more nearly right than the other.”

      - Peter Drucker

@fontsquirrel

I’m not convinced that this is a big issue yet, but could be. I’m sure there are some unforeseen consequences to using the local() approach.

The problem is, how long does one wait for more anecdotal evidence to pile up before acting? Isn't there enough now to extrapolate, weigh probabilities, and reassess?

In my mind, the issue of "best practice" - a basic default approach to a CSS @font-face syntax is now clear.
One course absolutely does invite problems - we already know this. Maybe big problems, maybe small. The other course avoids problems and has no downside. Choosing which one to use is now a no-brainer.

Miscellaneous Considerations/Observations:

1) local() is not an option for Internet Explorer users. The font downloads and is used whether it exists locally or not. This is a condition which will persist for many years.
(Me arse was unavailable for comment, JH.)

2) Using the IE mask hack does not preclude using local() for those browsers that support it.
You just write this:
 @font-face{
  font-family: somefont;
  src:local(‘Somefont Sans 500’),
  local(‘SomefontSans-500’),
  url(‘//:’)format(‘IE-Mask’),
  url(‘somefont.ttf’) format(‘truetype’);
    }

No big deal.
Plus this would presumably include IE9. Which means that, in all probability, the @font-face rules for IE<9 will be roped off within conditional comments. This weighs towards using the "redundant declaration" approach I wrote about.

3) I suspect that resistance to the IE mask hack is a part of the resistance among many in the web development community (but certainly not all) to *anything* that appears to accomodate Internet Explorer users.
Personally, I can't fathom a philosophy that says it's OK to deliver a less than optimal experience to 60%+ of web users, not because there is no way to do so, but simply because they're not using the browser you prefer. But that's me. I like to stay as employable as possible.

4) Lastly, the whole point of @font-face is to give web authors control over typefaces and typography. What's the point of it if you're going to cede control back to the operating system by querying with local()?
The only upside is, if there is a font by that name found, there is no download of the font and there's a quicker rendering of the page.
Now, there may be instances where that's a fair bargain: taking the chance that the font installed locally is in some way deficient in exchange for avoiding a huge font download.
And that's fine - but that's the exception, not the rule. And in those situations where that seems like a fair bargain, local() can be used. Sort of like a credit card - you take it out when you've found something you want to buy and you're at the register - you don't take it out in the parking lot and walk around the store with it in your hand.
Since there's an alernative that doesn't disable IE, the default approach should be no "local()".

Regards,

rich

BTW - I am curious about how this might impact offline browsing. I have to test.
It's just the beginning, folks!

It’s just the beginning, folks!

Rich, I am in 100% agreement with that comment!

I know I happened to notice the font "Washington" in an old specimen book - and now a similar font is called Mephisto, while Washington is the name of completely different fonts.

For a more famous case, Oxford - the Ronaldson Roman No. 1 revival - was given a name already in use by an ATF display font which became Oxford No. 2.

@billdavis

>It’s just the beginning, folks!

Yes. The beginning of the beginning. You guys selling licenses for WOFF yet? ;)

Factoid: I follow this issue closely as you know, but I have yet to see anyone comment that Firefox 3.5 won't print when @font-face fonts are involved. It's a known bug.
Hasn't anyone tried to print out a page? What's going on?
And I'd say that's a rather significant shortcoming, wouldn't you? (I haven't checked to see if it's fixed in FF 3.6 Beta.)
Inch by inch. It's like pulling teeth. But it *must* happen.
Most people think of screen technology as digital publishing's equivalent of paper. I disagree.
I think *browsers* are to digital publishing what paper is to print publishing. I think that's a more accurate mapping.
Worth some effort to get it right.

ciao, rich

@quadibloc

I understand what you're saying - there's a lot of recycling of old fonts from the print era that get digitized and renamed. However, what I was asking about here was sort of the opposite - the same name applied to fonts that are demonstrably different - even if they are similar. Two fonts can both be named "Minion" and look very similar but they can have different character sets, different kerning pairs, hinting, etc... but yet the browser calls the font from the operating system using only a name which can be the same for both fonts.

@fontsquirrel
I don’t think the issue is that manipulated web fonts are getting installed on user machines (which would be a bad thing, I agree).
Ethan - if you're still tuned in - Why is this a bad thing?
(I'm not saying it's a good thing. But to me, it's neither good nor bad. It's just another thing to be taken into account. But why bad?)

@k.l.
It seems that to make sure that a site looks as expected — which is not the case anyway across different browsers and platforms — one better avoid local(), for potentially different font versions. I do not see any merit in using local() with fonts that are not among the safe web fonts. — Not even if the fonts in question are “for free” and may have been downloaded by the user who in this case is the website viewer.
Agreed. That anyone would put more trust in the font installed in the operating system is, I think, a holdover from fifteen years of having no other choice but to trust the font installed in the operating system. When you've been imprisoned for so long, freedom can be a bewildering thing. It's like we're out on parole and living in a "halfway" house.
It will take awhile for the mindset of the average web author to change from "fonts are an OS thing and I have no choice but to accept what it gives me" to "fonts are a server thing and I make the choices".

@all

More variations on the Museo theme.
This one is the presumably up-to-the-minute authentic one from the Museo 500 page at Myfonts.com:

This makes it three versions of Museo 500 floating around. As web authors, which ones are installed on who's machine, we can never know for certain. All we can know for certain is what font file is on our web server.

Found two different versions of Museo Sans as well:
This one from the Museo Sans 500 page at Myfonts.com:

And this one from Jonathan Snook's article Becoming A Font Embedding Master

rich

Richard: I want to start by saying what follows is an opinion, and I don't want to disrespect the fine work that you have done which led you to your "src:url(//:)" solution. It is definitely clever.

However, you also describe your solution as not standards compliant - if so, this may cause problems in future web browsers besides Opera (who knows how IE9 may handle this - IE lately has not been known for it's backward-compatible-ness). We may be introducing something that may cause greater problems than the ones you describe.

I believe that the local directive has drawbacks, but using it in the way Paul Irish does solves a lot of problems, and it is also seems to be more future-proof. The problem you describe, I believe, would be best solved today by changing the standard. This wouldn't help us right now, but maybe we should be suggesting to the W3C that @font-face should be augmented with an additional directive, like "signature", which would have an MD5 signature of the font file with the given URL (or some other hash function). This signature could be used to identify a font to ensure that the "Droid Sans" is the right version of "Droid Sans". For example:

@font-face{
font-family: "Droid Sans";
src: url(‘DroidSans.eot’);
src: local(‘Droid Sans Regular’),
local(‘Droid Sans-Regular’),
url(‘/fonts/droidSans.ttf’) format(‘truetype’),
signature('a6107b3cb60d990767c464bf15264d14');
}

Therefore, the browser could check "does my OS have the right version of Droid Sans? If so, I'll use it, otherwise, I'll download it".

I know this doesn't help right now, but I'd rather work right now to fix the problem correctly then to use something that is not standards-compliant that may not work correctly later on down the line (I am going by comments made earlier that it isn't - I have not read the spec in detail).

My $0.02 right now. I will read on to see if I can be convinced otherwise. :-)

Regards,
Zoltan

You mentioned Droid Sans. I noticed from a brochure describing it that it uses Simplified Chinese characters... even when used to display Kanji for the Japanese language. Oops. Kanji mostly follow the forms of Traditional Chinese characters, but there are a few characters with uniquely Japanese modified forms. While simplified forms of characters may be desirable for legibility in a low-resolution environment, it doesn't help matters if you need to be an expert in a foreign language to know which character you're looking at.

@zoltan

Thanks for accepting my invitation to comment.

you also describe your solution as not standards compliant
Not true. I didn't say that anywhere. And thanks for kind of proving my point that anything that clearly appears to accomodate IE - which is my intention - is automatically viewed as "non-standard" and somehow dirty and unclean. (Hah! ;)

Syntactically speaking, there's nothing non-standard about this:

  src:url('//:')format('IE-Mask'),

It's an unparseable or "null" URI followed by a custom format hint. That the URI points "nowhere" and the format is made-up and therefore unsupported is irrelevant.
It's syntactically standards-compliant - unless I'm misreading the CSS3 specification. (If I'm wrong, please come back and show me. I'll gladly retract.)
To me, using local() strictly because it blocks IE's attempt to parse the rule and make a request to the server is what's non-compliant. It makes local() an unstated requirement rather than an option. It makes it non-removable and that's non-standard.

I believe that the local directive has drawbacks, but using it in the way Paul Irish does solves a lot of problems
It solves only one problem and in a non-standard way - it blocks IE's legacy behavior. (What other ones get solved?) And, as we're just beginning to see, it brings back the very problem @font-face is designed to solve.
All I care about is getting @font-face to work with as few hiccups as possible. This ain't a pissin' contest.
local() is for edge cases. I have trouble conceiving a scenario where it would make sense - except in the "humongous" file scenario I described earlier. There may be others, but I don't see them right now.

I think we agree that the specification, as it now exists, feels like it's missing something as far as accurately identifying the font version. But in a world where font mash-ups are ordinary - and if the web of the recent past is any guide, that's where we're headed - I don't easily see how an identifier can remain reliable.
Plus, I don't even see why, for purposes of web design, it should be. Do we check for the latest "version" of an image before the browser requests it?
No. It is what it is - and it's under our control so what's the problem?
(But I don't mean to dismiss your idea/sample - it's worth more thought and discussion, most definitely. I want all the tools I can get.)

Thanks again!

Regards, rich

@quadibloc: Thanks for the heads up about Droid Sans and Kanji. I occasionally code in Japanese, and if you're right, it is of interest to me.

@richard:

I hope my response has not been taking as a "pissing contest" - it wasn't meant as such. :-) I, too, care about getting @font-face to work today. I just have Concerns (TM).

I seem to have misinterpreted an earlier post in this thread as stating it was non-standard syntax - my apologies on that. That said, I am still not 100% convinced that your "null URL" is valid. From what I understand, RFC 3986 states that the scheme, or protocol part of the URL, must "consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-")." So it must have a letter at the beginning, which your URLs doesn't have. (The RFC can be read at http://tools.ietf.org/html/rfc3986).

You state that "that the URI points nowhere and the format is made-up and therefore unsupported is irrelevant." I am just concerned that using this syntax will break something in the future (throwing an error, halting the load of a page, or some other unexpected problem), which I believe is relevant (browsers have done silly things like this in the past).

Am I being too paranoid? I wouldn't disparage anyone who makes that claim, and would wholly support you if you made it. :-) But there is method in my madness: serving up non-standard code to accommodate Internet Explorer has caused problems for me (and others) in the past - how many hacks that make IE6 work breaks in IE7 and 8? The company I work with today is trying to clean this expensive mess up right now ... with me being head janitor. :-)

At the same time, I don't believe that "anything that clearly appears to accommodate IE is automatically viewed as “non-standard” and somehow dirty and unclean". Conditional comments, for example, are a way to accommodating IE, but I use them because I don't think they will break anything down the road. And they don't, as far as I can see, break a standard.

Your comment about using "local() an unstated requirement rather than an option" is valid, and I am with you in that I hate to use it for anything but it's intended purpose. But since using local() is syntactically valid, I feel more comfortable using it at the moment. Is it ideal? No, but nothing that accommodates a buggy browser usually is. And I would like to be able to handle the "two fonts named the same" issue that you raise. I would also like to fix local() - the "humongous" file scenario is quite relevant for those who design Japanese or Chinese pages, which I have dabbled in.

Totally agree with you on the spec missing something. Hopefully this is something we should be taking to the W3C so they can fix it in an appropriate way. My "solution" is a possible one, which doesn't look for the latest version of a font - just the one the designer intended to use. I don't know whether it is right or wrong - just me thinking out loud.

Forgive me if I seem too opinionated - but I hope my paranoia seems justified. :-)

Z.

@zoltan

Good. Now we're collaborating. I like it.
I had a feeling that src="//:" was bothering you and probably others.
We fear what we do not know.

Where did it come from? Well, I did what I usually do: steal from the smartest people around.
What would you say if I told you that src="//:" appeared for years in jQuery, and is still being used in Javascript libraries like YUI 2 and Dojo today?
Would that give you more confidence? It's absolutely true.
As hacks go, it's about as safe and time-tested as you can get.

Here's the history of using "//:" as a null URL as I understand it:

When using iframes for background Ajax-like requests started in the pre-Firefox days, Internet Explorer had a problem with iframes not containing a src attribute when HTTPS: was used. (And there were situations where you wanted to create the iframe with no real src as yet.)
I believe it was around that time when someone first came up with using src="//:" as a placeholder of sorts so the iframe could have a src attribute. (Another alternative is src="javascript:void(0)". Empty quotes like this: src="" don't work. Browsers don't like it at all.)
From there, a few years later it made it's way into the javascript libraries I mentioned as part of a way to detect the equivalent of the DOMContentLoaded event in Internet Explorer. Instead of an iframe, this time it was needed for the src attribute of a script element containing a "defer" attribute. This was worked out originally by JavaScript geniuses Dean Edwards, John Resig and also Matthias Miller and Diego Perini. (Perini's discovery that polling IE's doScroll method until it didn't return an error could be used to detect the equivalent of IE's DOMContentLoaded event eventually, after some years, supplanted the practice of using document.write to create the script tag. So jQuery no longer uses it - but it has nothing to do with anything being wrong with src="//:".

Here it is at work in the YUI utilities from 2007:

Here it is in Dojo today:

Now, that's the pedigree of the hack.
But it's still a hack. We are still talking about sending the browser on a little bit of a wild goose chase until it says, "The heck with this, there's nothing there, I'm moving on." (It's just that with @font-face, IE<9 considers "moving on" differently than the other browsers and that's why the hack works.)
Using it within a script tag in a test page, Firebug shows me this:

As you can see, it assumes the http: part of the URL and fills in a forward slash. No request is made to the server. Yes, there's a failure to load but the browser doesn't even try. It's not really an "error" any more than a dead link is an error but in that case a request gets made.
Is this more grammatical?
"http://:/"
I haven't tested it but if it works I've got no problem with it.

Let me know if this shines a more favorable light. Or whatever occurs to you.
And then, there's a way of using local() for the same purpose, but without causing any damage, that might be better than this and I'd like to run that through the mill, too.

rich

@zoltan

We might have a winner!

From what I understand, RFC 3986 states that the scheme, or protocol part of the URL, must “consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus (“+”), period (“.”), or hyphen (“-“).” So it must have a letter at the beginning, which your URLs doesn’t have. (The RFC can be read at http://tools.ietf.org/html/rfc3986).

I just tested: src:url("http://:/")format("IE-Mask")

I'm getting exactly the same results as src="//:" and it conforms to the syntax in the RFC.
Beyond reproach and future-proof.
BTW - the format('IE-Mask') part of it is optional, as per the CSS3 spec. I'm just including it as a label, revealing the rule for what it is.
More future-proofing.
So that ten years from now when IE6, 7, and 8 are dead and gone, the next individual charged with janitorial work can recognize it as obsolescent garbage and sweep it away.

I'll be testing it some more but I just can't see any griping about this anymore. Thanks for the RFC reference.

rich

Summing up feels like the thing to do at this point. New Year coming.

1) Going forward, there will be many different variations of the same font, with the same name, but with different file sizes, file formats (TTF/OTF), character sets, and variations in quality.

2) Further, as became clear in Thomas Phinney's thread here on Typophile:
Web fonts, Free fonts, and modification requirements, many "open" licenses which permit derivative works, require the derivative font to be renamed. This means that going forward there will also be many different variations of the same font, but with a different name, different file size, file format, character set, and variations in quality.

3) As the use of @font-face grows, the number of installed fonts on the machines of web designers and developers is sure to grow right along. And it is these people - the authors of web pages - that the use of the local() descriptor is most likely to mislead. And this is most likely to occur during the development process when the font is most likely to be installed, as a convenience, in the operating system. In other words, at the very time when true and accurate results are needed most.

All of this - taken along with the other observations by myself and others on this thread - makes an overwhelming argument against giving preference to the font installed on the local operating system as opposed to the one posted on the web server. A font identifiable only by its name can be anything. The font file posted on your web server is the only one you can trust.

Except in very unusual circumstances, keep away from using the local() descriptor to give preference to a font based solely on its name.

And so, for now, the only CSS @font-face syntax I can wholeheartedly recommend is the one using the "Impossible URL" hack originally presented in Mo' BulletProofer @Font-Face CSS Syntax but amended slightly to conform to the URL naming rules in the RFC cited by Zoltan.

Like so:

 @font-face{ /* for IE */
  font-family: FishyFont;
  src: url(fishy.eot);
 }
 @font-face { /* for non-IE */
  font-family: FishyFont;
  src: url("http://:/") format("No-IE-404"),
  url("fishy.ttf") format("truetype");
 }

I will be doing some renewed testing over the next few weeks and if any hidden "gotchas" show up, I shall return.

Regards,

Rich

.

I think that you guys are still missing a small piece of the puzzle here.

In my testing I have found that:

1)Firefox will use local fonts even if you don't define any, provided the font-family name matches a font on the local system. If the font-family name is identical then no local sources need to be defined for FF to use the local version. So Firefox always prefers local fonts, and the local source parameters seem to just be there to help it find local sources with 'different' names. Not a problem, because you can just define a different name for the font-family. (though I do think that this is not the best behavior and I hope FF will fix it)

2)IE will never use local fonts. IE will also not use custom fonts at all if the font-family name defined by the CSS does not actually match the name of the font. Not the file name, the actual font name. If the font-family name defined in the CSS is different than the actual font name then IE will just go to the next font in the stack.

What this means is that if you use a single rule to serve fonts to both IE and FF then it must use the actual font name (for IE) and FF will use local versions of the font if any version exists with that name.

I determined early on that using local versions of fonts would be problematic. In view of the issues above it would seem that the only solution is to use separate @font-face rules for IE only.

@lampica

In the absence of more clearly defined terms and a look at your test pages, I can't understand much of what you're saying. And that which I think I do understand is, at best, misleading. I don't mean to be rude, it just is.

How did you reach the conclusion that:
"Firefox always prefers local fonts"?
Always prefers local fonts when?
If the CSS contains this:

@font-face{
font-family: verdana;
src:url('crazyfont.ttf')format('truetype);
}

For any page on which this CSS is used, the font Verdana as it's installed locally, does not exist. Wherever else in the document the font-family name Verdana is used in a font stack, Firefox will display the font contained in 'crazyfont.ttf'. *Not* the Verdana font from the OS. The @font-face assignment takes precedence over any font matching the name "Verdana" provided by the OS.
However, if you want the locally installed copy of Verdana to be used as a fallback font in case "crazyfont.ttf" doesn't load or is corrupted in some way, my initial test shows that writing this:

font-family: Verdana, sans-serif;
or
font-family: Verdana, Verdana, sans-serif;

Will display the locally installed Verdana as a fallback in the event the assignment of the name "Verdana" fails in the @font-face rule.

(I have to see what the CSS3 spec has to say on this. And add a test for this to my collection.)

IE will also not use custom fonts at all if the font-family name defined by the CSS does not actually match the name of the font.

This is incorrect. I've tested hundreds of different fonts with IE using a CSS "alias" name in the @font-face rule that does not match any name in the font file's internal name table.

If you have any pages containing examples to back up what you're saying, please post links. That would clear up any misunderstanding.

Rich

Sorry for my delayed response. Just so busy.

Well, I think that my post was perfectly clear, so your confusion must simply be on account of the information conflicting with your own experience. If you are right and I am wrong I will be very happy. Because this was driving me nuts for about a week.

The thing is, I did actually test this forwards and backwards for about a week. All of my results showed IE not using the font if the font-family name in the the @font-face rule wasn't the actual name of the font.

And all my tests showed FF using the local font if the font-family name in the @font-face rule matched a locally installed font, even when no local sources were given.

Perhaps I should point out that I am on Windows XP Pro SP3.

I don't have time at present to jump back into this right now. If I get time in the near future I will redo my tests and link you to the test pages. But I wouldn't hold your breath on that, as I am swamped and busy playing catchup.

Again, I will be overjoyed if you are right, in which case I only lost a week of my life to some bizarre fantasy world which doesn't exist.

Thanks for the reply. I have asked several people about this already but you are the first to confirm or deny my findings. BTW, your name is very familiar to me. Seems like I used to know someone in Port Townsend, about 16 years ago, with the same name.

-Lampica