Member pau… Posted July 29, 2009 Share Posted July 29, 2009 This topic was imported from the Typophile platform I was reading about Typotheque's forthcoming webfont delivery service here: http://www.typotheque.com/site/news_details.php?id=164 And the author states that 'The @font-face rule is supported by Firefox 3.5, Safari 3.1, Opera 10, Chrome 2.0 and Internet Explorer 4.0 and later. Our system is thus compatible with more than 95% of all browsers in use.' I don't believe that Chrome or IE do support the @font-face rules. Does anyone have more information on this? Link to comment
Member Ral… Posted July 29, 2009 Share Posted July 29, 2009 Overview of browser @font-face support: http://webfonts.info/wiki/index.php?title=%40font-face_browser_support IE does support it since version 4.0. Chrome could support it (since it's built on the Webkit framework), but it's currently disabled. The fonts are even downloaded ... Link to comment
Member pau… Posted July 29, 2009 Author Share Posted July 29, 2009 Hmmm, i'm surprised by IE! Any clues why it's blocked in Chrome? More: But IE only supports EOT, can that really be considered @font-face support? Link to comment
Member Ral… Posted July 29, 2009 Share Posted July 29, 2009 can that really be considered @font-face support? People often mix up @font-face, EOT and "raw fonts". @font-face is the general technology; EOT, TTF, OTF, SVG and so on are possible formats which can work with @font-face depending on the browser support. (Similar to GIF/JPG/PNG and the IMG tag) Link to comment
Member pau… Posted July 29, 2009 Author Share Posted July 29, 2009 yes, i know that @font-face is just a css rule. the confusing things is that each of the browsers only supports certain font formats with this rule. to me it almost makes no sense to speak of @font-face support in general then. If speaking about @font-face support it would make more sense to differentiate between @font-face embedding for 'raw' or 'naked' fonts and @font-face embedding for encrypted font formats, ie EOT. Link to comment
Member Ral… Posted July 29, 2009 Share Posted July 29, 2009 would make more sense to differentiate between @font-face embedding for ’raw’ or ’naked’ fonts and @font-face embedding for encrypted font formats, ie EOT. The line is hard to draw. You could also built an EOT font without URL-binding and compression and obfuscate a "raw" font, so it's not really raw any more ... And it's getting more complicated now that new formats are being proposed. Some more information:http://opentype.info/blog/2009/07/29/why-webfont-services-are-the-future... http://ilovetypography.com/2009/07/20/web-fonts-—-where-are-we/http://new.typographica.org/2009/on-typography/audio-from-the-web-fonts-... Link to comment
Member Joh… Posted July 29, 2009 Share Posted July 29, 2009 Paul: the confusing things is that each of the browsers only supports certain font formats with this rule. to me it almost makes no sense to speak of @font-face support in general then. Certainly talk of @font-face support needs to carry this caveat, that different font formats are required to display @font-face linked fonts in different browsers. But in terms of recognising @font-face in CSS and doing something with that information, one can say that all these browsers support it. Services like Typotheque's, Typekit and Kernest serve different file formats to different browsers as appropriate, while trying to provide some measure of server-side or in-font obfuscation to naked font data to make it uninstallable on desktop systems. So they can claim to support ‘95% of all browsers in use’ even though those browsers support @font-face in different ways. From a type foundry perspective, considering whether to sign up for any of these services, a key question is whether the methods of obfuscation of naked font data provided are sufficient. You probably also want to make sure that your web font license and your contract agreement with these service providers specifies that such methods are a requirement, i.e. that naked font data should not be served without such measures. Link to comment
Member Dun… Posted July 29, 2009 Share Posted July 29, 2009 I think it would make more sense for everyone to stop using the terms embedding and @font-face when discussing web fonts and be specific about what font formats browsers support. Many web designers aren’t even writing code, they have production staff for that, so talking about a specific CSS rule isn’t very helpful. I do think those designers can handle an explanation of what font formats are supported, which might lead to designers leaning on Microsoft to support raw linking and lean on all browser makers and the W3C to get a good web font standard defined and implemented. Link to comment
Member pau… Posted July 29, 2009 Author Share Posted July 29, 2009 James, your first sentence more clearly explains my own thinking. Thanks for piping up. Link to comment
Member Ric… Posted July 29, 2009 Share Posted July 29, 2009 @james puckett "Many web designers aren’t even writing code, they have production staff for that, so talking about a specific CSS rule isn’t very helpful." Huh? I'm not getting this. What kind of web designer doesn't have some working knowledge of CSS? What do you mean by web designer, then? I hardly think of CSS as "writing code". Straighten me out on this. Link to comment
Member alu… Posted July 29, 2009 Share Posted July 29, 2009 "I’m not getting this. What kind of web designer doesn’t have some working knowledge of CSS?" The bad ones. ;) Link to comment
Member Dun… Posted July 29, 2009 Share Posted July 29, 2009 It’s not uncommon for graphic designers to have little or no knowledge knowledge of XHTML/CSS and to handle web design by mocking up sites in Photoshop or InDesign. The design is then passed on to production staff who handle all of the HTML/XHTML/CSS/backend setup. Link to comment
Member Ber… Posted July 29, 2009 Share Posted July 29, 2009 Well. I am a graphic designer and did a week long course on webdesign when HTML 2.0 was hot, and I am confounded by all this @font-face stuff… But I am quite sure that after the clouds of warfare have settled things will become a lot clearer. In other words: most designers will wait out the font wars and get into the game when some semblance of consensus has been achieved. . . . Bert Vanderveen BNO Link to comment
Member Mig… Posted July 29, 2009 Share Posted July 29, 2009 > Any clues why it’s blocked in Chrome? Because of security concerns, apparently: http://lists.w3.org/Archives/Public/www-font/2009JulSep/0823.html Link to comment
Member Joh… Posted July 30, 2009 Share Posted July 30, 2009 JP: ...which might lead to designers leaning on Microsoft to support raw linking So far, the only pressure I've seen from web designers/authors has been on the other browsers to support EOT Lite, because it is the only format that offers a significant measure of backwards compatibility with well over 50% of browsers in current use. And I think the chances of MS supporting raw linking are now close to nil. ...and lean on all browser makers and the W3C to get a good web font standard defined and implemented. That we're working on. Link to comment
Member pet… Posted August 2, 2009 Share Posted August 2, 2009 Paul, I understand this is indeed confusing, especially since Internet Explorer has supported @font-face for a very long time, but very few people took advantage of this. But in a way, this is not so much different from another basic HTML code: <img src="url" /> Not every browser supports all image formats (e.g. PNG, BMP), the designer has to choose the format that is best for the purposes. Hopefully, we'll soon have one font format that works in all browsers, so we don't have to specify two or more* font formats per single web page. Peterhttp://www.typotheque.com * It is a fact that right now, we deliver subsetted and obfuscated TTF for some browsers, and the same font wrapped in EOT for other browsers. But because we aim for multilingual support, we realise that even this may not be enough, as Apple requires AAT fonts for correct shaping of some non-Latin scripts. I am just playing with Devanagari fonts, and while on Windows this sample (http://www.typotheque.com/hindi.html) is rendered correctly in all browsers, on Mac the conjuncts are not correctly rendered. The sample is in fact Nepalese, not Hindi. Link to comment
Member sam… Posted August 2, 2009 Share Posted August 2, 2009 Does anyone have any inside info on the status of TypeKit? There hasn't been an update for quite a while now. In the meantime, I've had decent luck with the Font Squirrel website. they've organized the their fonts into @font-face kits complete with the proper CSS syntax. Pretty decent selection, too. Link to comment
Member pau… Posted August 3, 2009 Author Share Posted August 3, 2009 Peter, Thanks for chipping in. The Devanagari sample is quite interesting. For your own information, I am on Win XP and getting Fedra Devanagari in Firefox (3.5.1) and IE (6), but Mangal in Chrome (2.0.172.39) and Safari (4.0.2). Link to comment
Member pet… Posted August 3, 2009 Share Posted August 3, 2009 I know that current version of Chrome doesn't support @font-face, but I wonder what's up with Safari 4.0.2? I suppose you see other @font-face pages there? Is it Devanagari issue only? Sorry I have no Win machine at the moment. Peterhttp://www.typotheque.com Link to comment
Member pau… Posted August 3, 2009 Author Share Posted August 3, 2009 Interesting... I just checked again and the correct font is now showing in both Safari and Firefox. Perhaps the browser wasn't properly downloading the font earlier? In any case it seems to be working correctly now. p Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now