I would describe it as a web font obfuscation service. A layer between browser and font that provides just enough hacking, hiding, along with rights-management, to make (some) type designers comfortable with allowing their fonts to be used with the @font-face linking mechanisms supported by Web browsers.
It's a service. From what I can tell you can't use any font you own, just those that Typekit offers. You could use any font you own with @font-face if the fonts EULA allows it (most won't).
"@fontface" is a declaration in CSS* that allows a specific font which may not be on a viewer's machine to be loaded along with the web page and thus allow a web page to display text rendered in something other than "web-safe" default fonts -- as a font, not as an image.
Different browsers have different implementations of this @fontface declaration, supporting different font formats, etc.
Web designers find it cumbersome and a nuisance to keep track of all the different variations in code and formats to address the idiosyncrasies of different browsers that their viewers may be using. It is also confusing and frustrating for well-intentioned designers to understand which, if any, of the fonts they have or want will allow such a use as part of a font vendor's End User License Agreement (EULA).
On the other side of the equation, most vendors do not have licensing models for allowing use of their fonts for this kind of web "embedding." Most are reluctant to allow this use because some of the current browsers only support @fontface with "naked" fonts (i.e., the same OpenType or TrueType font format that can be installed directly on a desktop machine and used for any other purpose) and the security against these fonts being rather inadvertently or innocently acquired and used elsewhere is minimal.
Enter TypeKit (among others) as a service. They arrange with foundries to offer typefaces for use as web fonts (taking advantage of @fontface to serve up fonts to the web page). They host the font files on their own server and take pains to obfuscate the location and the contents of those files in various ways, to add a layer of security against misappropriation that their partner foundries accept.
Web designers who subscribe to the service select from the fonts on offer and are provided with copy-and-paste code that allows them to utilize these fonts in their web pages via CSS stylesheets, without having to worry about the details of the evolving technology and with confidence that they are correctly licensed. Typekit takes care of making sure that various browsers are served the appropriate formats in such a way that maximum compatibility and consistency is provided for the design.
Essentially TypeKit is building a bridge between web designers and font vendors by taking care of the messy muddle in the middle in terms of both technology and licensing ins and outs.
I hope I've stated this clearly for you and that my understanding does an adequate job of representing the essence of the situation.
Others can correct any oversimplifications or add any essential elements that I've skipped.
-- Kent.
[Edit]: * Sorry, I forgot to explain: CSS stands for Cascading Style Sheets and is used hand-in-hand with HTML for formatting and styling web pages.
You can see the rendering (hopefully) of two of my babies (Galette & Mentone) here. Do not know whether they both work on IE/Win, though (Sii, could you please let me know?).
> You can see the rendering (hopefully) of two of my babies (Galette & Mentone) here.
Cool. First time I had seen type kit in use. And it does work on IE7.0.5 on Windows. A second of display in the default serif, and then it pops into the correct faces. (I wonder if the delay is server related, and if it will grow longer if the service becomes popular.)
@Paragraph: There is a lag of three or four seconds before the ‘real’ fonts kick in. I am on a Mac w OS X 10.5 and Safari 4 (latest release). And in the Netherlands, if that is of consequence.
The lag makes it kind of unusable. Except if it just happens in the first webpage, I guess, IF it caches in some way.
@Paragraph: have you tweaked something? When sii posted, my system (IE6 on Win XP Pro) agreed with his verdict. Mentone seems to show OK for me as well now though. Although the ™ symbol isn't working in the Galette sample.
_______________________________________________
Ever since I chose to block pop-ups, my toaster's stopped working.
TypeKit is one of many web-sites-as-a-service that allows you to put some javascript on your page that, in turn, will automatically load the appropriate javascript and/or css files necessary for you to load typefaces onto your page for use in standard HTML.
They have arisen for a few reasons (IMHO, of course):
- convenience for the web designer...we just add one line to our HTML to set it all up
- perceived protection for the type designer (there's a certain level of obfuscation that many foundries find acceptable over directly uploading fonts to your own server)
- pricing options. It appears that, at least with typekit, there will be a buffet-type pricing scheme.
>Mentone seems to show OK for me as well now though.
Same here. :-)
>The lag makes it kind of unusable.
Very little lag - a second at most on my set up. But any lag makes me think people might start putting Web fonts on the metrics of the core fonts to reduce the reflow-flicker when the fonts load in.
By the way, as it says in the thread title, it's "Typekit," not "TypeKit."
I wouldn't bother mentioning it except I'm just so glad to see a name that's not in "camel case" for a change. (Maybe it's an indication of a trend away from that.)
Thank you all for this, AFAIK the Typekit folk are making the submitted OT fonts compatible with IE right now, perhaps Mentone was just tweaked. How about the rendering? Below is Safari 4.0.3/Mac OSX 10.5.8:
"So it lets a web designer use a font that s/he owns, and a user can see it even if that don’t have it installed?"
Almost. It lets a web designer use a font that s/he licenses for use from the font service, like Typekit, even though the user doesn't have it installed in their operating system.
On a technical level, it works similarly to the way block ads - like the ones for Font Bureau here at Typophile - are included in the page. Similar principal except instead of including a link to block ad images, the link is to font data. Both are handled by Javascript that creates the HTML and CSS necessary to link to the correct resource on the fly as the page loads in the browser.
Maybe I should just shut up. Disclaimer: all rendering mishaps in said Mentone and Galette samples are entirely my fault. The good bits are courtesy AFDKO autohint.
No, but thanks. Why don't you ask them. You have a licensing agreement don't you?
>Kind of depends...
Simon, it depends on whether they are trying to serve some fonts to all IE, or some IE with some fonts, and some IE with other fonts. Is that clear?
That's 'interoperability'. If they or anyone told their foundry clients the whole situation before they made licensing agreements, I'd be pleasantly shocked.
While you're awake 'over there', Simon, can you point me to a web site that serves an Embeddable OpenType font (that is the same as an Embedded Opentype font, except that since it's never embedded, I remain tense correct), with more than 256 glyphs in the EOT?
And I apologize to anyone, 'in-the-know' who knows that EOT does not generally contain any OT if it's going to work in all IE.
But they/we still cannot change the name of EOT fast enough for these discussions. ;)
FWIW Jan, this is what I get in IE/Win:
(Note that it doesn't seem to find your real italics, as well as the poor rendering at some sizes, and the missing ™ in one font but not the other...)
________________________________________________
Ever since I chose to block pop-ups, my toaster's stopped working.
...oh and the sample page prints OK (crisply, but still without the real italics) to a physical printer or to a third-party PDF utility, but not to Acrobat, which complains:
%%[ ProductName: Distiller ]%%
Mentone-Light not found, using Courier.
%%[ Error: invalidfont; OffendingCommand: show ]%%
David, just one last remark, if I may: I do not have enough understanding of these matters to be a worthwhile sparring partner to you. I am attracted to Typekit by their practical approach to the problems you and the others have been discussing at length in the other threads and elsewhere. I like "practical", as I am too daft and old for "theoretical".
Cheers to you too.
Dave, that's pretty bad, back to drawing board ... no smoothing/antialiasing at all? Just a raw bitmap? Simon to the rescue!
By the way, the italics and the trademark render fine in my Firefox, so whatever it is, it's as issue of incompatibility with IE (No surprise there then.) rather than with Windoze.
______________________________________________
Ever since I chose to block pop-ups, my toaster's stopped working.
DB> Simon, it depends on whether they are trying to serve some fonts to all IE, or some IE with some fonts, and some IE with other fonts. Is that clear?
I wasn't thinking of IE or EOT, I was speculating that they might convert to TrueType to give broader support across different platforms - eg. Linux, or versions of Windows that don't support CFF.
DB> While you’re awake ’over there’, Simon, can you point me to a web site that serves an Embeddable OpenType font (that is the same as an Embedded Opentype font, except that since it’s never embedded, I remain tense correct), with more than 256 glyphs in the EOT?
Sorry David, I'm awake but I don't have a clue as to what you're asking.
"I’m certain we can help them adjust their CFF -> TTF -> EOT conversion process to improve the rendering in IE."
This is a big problem that I'm still trying to find answers to. I have spent good money on OTF CFF fonts that look like hell in Windows no matter what I do. And I am not automatically assigning blame to Windows, either. Safari's rendering of body text drives me nuts, so I'm not a big fan of their approach to rasterizing within Windows, either.
John Hudson quite graciously took the time to explain to me the fundamental differences between TT and CFF but how do we bridge the gap with regard to web fonts?
I might email you on this one, Simon, and soon.
What "help" might be on the way?
Actually I think it's the *biggest* problem - once you get the whole licensing thing out of the way.
In Windows CFF fonts are generally rendered using a separate "black-box" PostScript rasterizer licensed from Adobe.
For the Web, what's cool about services like Webkit is that they can serve different fonts to different browsers running on different platforms depending on the rendering style of the browser, type of display etc., Something that's incredibly hard to do on a case-by-case basis for the average web site owner, unless they are working side by side with a font vendor who can provide a set of custom fonts - people like Font Bureau or Ascender.
DB> While you’re awake ’over there’, Simon, can you point me to a web site that serves an Embeddable OpenType font (that is the same as an Embedded Opentype font, except that since it’s never embedded, I remain tense correct), with more than 256 glyphs in the EOT?
Me> Sorry David, I’m awake but I don’t have a clue as to what you’re asking.
I asked around, and we think you're asking if its possible to include more than 256 glyphs in an EOT. The answer is yes, although you probably want to subset a font, that's not required. As a test I took a font with over 600 glyphs and made an EOT, seems to work fine...
Actually nothing to stop you giving this a try. Output TTF from FontLab and try various hinting settings, as well as different weights and styles. Then on a Windows installation you can proof different settings using HTML and IE. Once you've found the optimal settings you can create an EOT using WEFT or the Ascender EOT lite tool. Post the results to your site for peanut-gallery-review.
Rich: John Hudson quite graciously took the time to explain to me the fundamental differences between TT and CFF but how do we bridge the gap with regard to web fonts?
Use the same rendering technology for both outline types?
Top: Windows GDI CFF font rasterisation using Adobe blackbox.
Bottom: Windows WPF CFF rasterisation using ClearType.
I suspect David will say this is bridging the gap by making CFF fonts look bad in the same way as TTF fonts, but there's something to be said for things looking bad in the same way rather than in divergent ways.
Undocumented: how CT rasterisation of CFF interprets CFF hint data.
I'm a little tired, and it's been a few days since I followed this thread but I read through it. Given there's a few acronyms I don't understand, can someone explain the relationships between Typekit and ClearType, TrueType, Black box, Hinting, Fontlab &c or are we talking about different things now (not that that's a problem).
I thought Typekit was a "middle man" between vendors, designers and viewers. Is this correct or am I back to being confused?
•Typekit = Web service that schleps fonts in a way similar to Doubleclick schlepping ads. Yes, it is a middle man.
•Hinting = Instructions in a font that tell software how to render it so that it fits into a pixel grid without looking like a postmodern experimental design.
•TrueType = A font format created by Microsoft and Apple because everyone got pissy about John Warnock enforcing the Postscript patents. TrueType provides an awesome hinting system for rendering type at small sizes, but only ten people know how to use it and nobody else wants to figure it out because TrueType hinting is like watching paint dry. In New Orleans.
•ClearType = Microsoft’s hype, I mean type, rendering engine. It is not especially relevant because it does a poor job of rendering the Postscript fonts that people actually want to use. Because Microsoft doesn’t want anyone to steal their secret, they don’t tell us how it really works so almost nobody knows how to make type look good with ClearType.
•Blackbox = I think John was referring to the Adobe type rendering engine. It sucks, but it sucks consistently across platforms.
•Fontlab = What we’re all stuck using to create fonts until Glyphs is released.
I thought Typekit was a “middle man” between vendors, designers and viewers. Is this correct or am I back to being confused?
That's the basic idea behind sevices like Typekit, Christopher. A middle-way where web designers can use fonts through a subscription. Designers can copy ad paste simple code to their pages and choose wich fonts to use in the service's interface, without having to deal with more complex issues like the highly technical ones exposed here.
I'm giving a try, supplying some few selected display fonts to see how the response of web designers will be for this kind of type design approach.
Thanks for the definitions James. I know what the words mean, I just don't understand how they relate to what Typekit Does. Instinct tells me the that the conversation is becoming somewhat tangential. I'm quite curious to see how Typekit unfolds.
The definitions relate to Typekit because Adobe, Microsoft, and Apple have made it excessively irritating to create type that looks good onscreen and across software and OS platforms. So instead of just being able to license the existing Postscript fonts, everybody has to make and test TrueType hinted fonts to use with services like Kernest, (and if it leaves beta before the PR person spends all the money, Typekit). This is a problem for type vendors who have a lot of high-end text faces, because hinting the fonts for use at text size is going to take a long time and cost a lot of money, especially if it turns out that web designers would really just rather stick with Georgia and Verdana because most people won’t spot much difference at ten pixels anyway.
James: •ClearType = Microsoft’s hype, I mean type, rendering engine. It is not especially relevant because it does a poor job of rendering the Postscript fonts that people actually want to use.
This is incorrect. The (ir)relevance of ClearType to PostScript fonts on the web is that in all current browsers ClearType doesn't render PostScript at all. In GDI, which is the legacy graphics interface still used by almost all Windows apps, PostScript fonts are rendered using a 'black box' system from Adobe. The term 'black box' is used to refer to a piece of software that one company licenses to another for use but without any right to modify or look at the code. Adobe licenses a PS rasteriser to Microsoft.
In the new Windows Presentation Format, ClearType rendering, which in GDI only works for TTF, now renders CFF PS fonts also (not PS Type 1 fonts, though). But very few apps and no browsers use WPF. Which is a pity for a number of reasons, not least WPF's excellent built-in OpenType Layout suppport, and superior ClearType rendering (blending x-direction CT colour antialiasing with y-direction greyscale antialiasing for crisply smooth display type).
Because Microsoft doesn’t want anyone to steal their secret, they don’t tell us how it really works so almost nobody knows how to make type look good with ClearType.
Yeah, that's why they published a book about it.
•Blackbox = I think John was referring to the Adobe type rendering engine. It sucks, but it sucks consistently across platforms.
I was referring specifically to the Adobe PS rasteriser licensed for use in Windows GDI. Adobe have multiple type rendering engines, which they use in their apps, some rather better than others and most newer than the GDI one.
_____
Christopher: I just don’t understand how they relate to what Typekit does.
It relates in a number of ways. Firstly, there is the general issue of what all these different rendering engines, font outline and hint formats, and web font delivery formats actually do with the font when it appears in the browser. This issue is not restricted to Typekit: it affects all use of fonts on the web.
James asserts that 'Postscript fonts [are what] people actually want to use'. This is probably true for a lot of display type, but if people are looking for alternative text types for webpages, I think they're going to find that most PS fonts look like crap on most users' systems. I don't think TrueType is going to cease being the better screen font format any time soon. Adobe have been steadily improving their PS rasterisers over the past decade, but I suspect there are diminishing returns and a fixed limit of how good they can get within the PS hint model.
Secondly, this relates to Typekit because the service they offer includes converting and serving different web format fonts to different browsers, depending on the capabilities of those browsers and the limitations of the web font delivery formats accepted by them. Typekit serves EOT format fonts to Internet Explorer, which because of a bug in Windows (not in the EOT format itself, note) can only handle EOT fonts containing TrueType format outlines and hints. So if you are a font maker and license your fonts for use in the Typekit service, then you need to be aware that the outline format will be converted to TTF before being served as EOT. Personally, if I were licensing through Typekit, I would much rather have control of that conversion process on my end, and deliver TTFs to Typekit to serve as EOTs. [Somewhere on Typophile recently I posted some simple steps to maximise the quality of FontLab TT autohinting, such that it produces pretty good results with ClearType rendering. Controlling y-direction alignment and features has the biggest overall impact in subpixel rendering environments, and this can be controlled relatively easily within FontLab with careful use of alignment zones and standard stem values.]
James: This is a problem for type vendors who have a lot of high-end text faces, because hinting the fonts for use at text size is going to take a long time and cost a lot of money.
Is this optimal? No. But then it also wasn't designed as a screen font, and the autohinting was done quickly.
This also demonstrates that the biggest problem with fonts designed as ‘high-end text faces’ for print when used on screen isn't hinting: it's spacing. In full-pixel rendering environments, TT includes hint instruction of advance widths, making it possible to control spacing on screen independently of spacing for higher resolutions. In ClearType, you lose this ability; with PostScript, you never had it in the first place.
•TrueType = A font format created by Microsoft and Apple because everyone got pissy about John Warnock enforcing the Postscript patents.
Actually, TrueType was created by Apple (only), as a replacement for Type 1, which was costing Apple a lot in licensing fees. Apple was to combine TrueType with Microsoft's TrueImage (a PostScript replacement) so that both Apple and Microsoft could stop paying Adobe so much money. (TrueImage never took off, though.)
John Hudson wrote: Somewhere on Typophile recently I posted some simple steps to maximise the quality of FontLab TT autohinting, such that it produces pretty good results with ClearType rendering. Controlling y-direction alignment and features has the biggest overall impact in subpixel rendering environments, and this can be controlled relatively easily within FontLab with careful use of alignment zones and standard stem values.
I've been searching around, but haven't been able to stumble upon this thread. Does anyone have a link to it? I'd really like to see it! Thanks…
I think TypeKit is great for companies who really "don't want to know" about server software, probably don't want to have "that conversion conversation" with themselves, and want the foundry/customer link to be at least distant from each other, if not a distant memory. And of course, it or any such service, separates the unknowing foundry from the likelihood of profit.
From our Suburban Legends Corrections Department:
>•Hinting = Instructions in a font that tell software how to render it
Not how to render, how to scale. After the glyph is scaled to the upm and perhaps according to the hints, then the rendering happens. Two things.
>•TrueType = A font format created by Microsoft and Apple because everyone got pissy about John Warnock enforcing the Postscript patents.
Apple did it alone, and I remember no patents ever issued to Adobe on this matter. TT was all done on a dare; as in, Adobe said to everybody, "We dare you to make better fonts" and the rest is Hysteria.
..this is actually something you want to recover when your rendering engine fails, your project crashes, and the National Association of Readers want to launch an investigation.
>the biggest problem with fonts designed as ‘high-end text faces’ for print when used on screen isn’t hinting: it’s spacing.
It's a problem with fonts(?) because spacing can't be hinted and work in CT/QTZ/Whatever Adobe calls it now? What is the low res solution, John?
>I suspect David...
I do too. But I know where my EOTs are. How 'bout you?
Curiouser and curiouser. Below is my son's dump in IE6/Win XP, taken tonight in Prague. The italic is fake, and the trademark is missing too, BUT why is the rendering so much better than the one above by Dave?
I think TypeKit is great for companies who really “don’t want to know” about server software, probably don’t want to have “that conversion conversation” with themselves, and want the foundry/customer link to be at least distant from each other, if not a distant memory. And of course, it or any such service, separates the unknowing foundry from the likelihood of profit.
That's your point of view, David. But I don't think that accusing other foundries is a good way to convince consumers. I think they will choose what's best for them in each case.
If all the foundries involved "want the foundry/customer link to be at least distant from each other", there would be no foundries involved discussing here or anywhere. Makes sense for you?
What is the problem about trying a different model, like the ones offered by Kernest, Typekit, Fontdeck, &c? What's the big deal? I don't accept "it's not FontBureau" as a valid argument, even though the geat respect I have for your work.
I think you're correct - zooming in you see the color fringing. Interesting, it kind of looks like WPF. Could it be Windows Safari, doesn't match Firefox?
David: [Spacing is] a problem with fonts(?) because spacing can’t be hinted and work in CT/QTZ/Whatever Adobe calls it now? What is the low res solution, John?
In CT, the solution should be to set a flag that enables x-direction deltas, i.e. to re-enable hinting of widths. It should be possible to hint either to full or to sub-pixel widths.
But that leaves Apple's Quartz rendering which dumps all hints, and Adobe's subpixel rendering, which makes use of at least some hints but isn't documented.
The only cross-platform solution for well-spaced screen fonts is the one you hit on David: ppem size-specific fonts.
Now that @font-face has brought a new awareness and a new level of scrutiny to fonts, people are next going to be wondering why, if a font has been well-crafted, it still doesn't look good.
My biggest beef is that in Windows, at larger sizes, antialiasing stinks. The jaggies are awful. This is true whether it's Safari, Chrome, Firefox, or IE using Windows native rendering engine.
I've already mentioned - in keeping with John Hudson's screen grab - that rendering of OTF CFF fonts stinks at *any* font size.
But I have to ask: If CFF is a simpler format than TrueType, and one that deliberately conveys less hinting information to the rasterizer (do I have this right?), then what exactly is it that Windows is being asked to do? Make it look less bad (which seems the case in Hudson's WPF example) or on a par with a well-hinted TrueType font? And if the answer is, "On a par with TrueType", well, isn't this too much to expect if the information necessary doesn't exist in the font?
And if the aim is only "less bad", that doesn't exactly speak well of CFF as a format suitable for screen-readability, does it?
RE: John Hudson's comparison screen shot...
>Windows WPF CFF rasterisation using ClearType.
My understanding is that IE8 in Standards Mode, renders using a port of WPF. In other words, IE8 is innately capable of this sort of rendering of CFF fonts. If my understanding is correct, a good question is, "Why doesn't it do so?"
@sii
On the Flash Of Fallback Fonts (FOFF):
>Very little lag - a second at most on my set up. But any >lag makes me think people might start putting Web fonts on >the metrics of the core fonts to reduce the reflow-flicker >when the fonts load in.
Designers are going to be bugged by this, no doubt. There may be ways, via JavaScript, to suppress the rendering of the page until all the fonts show up. We'll see if that gets any traction. Matching up the metrics between two fonts can be tricky and it's an additional bother and barrier to adoption. We'll see how this one plays out.
BTW - Safari (on Windows, at least) waits for the fonts to show up.
>Kind of depends if you gave them conversion rights as part >of the license you signed with them.
I'm wondering how this gibes with consumer protection laws. If I bought it and own it and it's broken, do I not have the right to fix it? I'm not so sure the licensing contract would trump local statutes.
@john hudson
>Somewhere on Typophile recently I posted some simple steps >to maximise the quality of FontLab TT autohinting
Obviously we've got gaps in knowledge that need filling. Anything anyone can contribute with regards to making fonts more screen-friendly will have a great impact.
@christopher dean
>Do you have an online bio?
Dude, you're my friend on Facebook! If you need something more formal, message me there.
I went to look at the Mentone test page in Safari on Windows, to check Si's theory that the third Mentone screenshot in this thread might be Safari rendering. For the second time a web page using custom fonts in Safari has crashed my entire system with a blue-screen-o'-death. The first time was with David's Franky test page.
Rich: My understanding is that IE8 in Standards Mode, renders using a port of WPF. In other words, IE8 is innately capable of this sort of rendering of CFF fonts. If my understanding is correct, a good question is, “Why doesn’t it do so?”
Because it still only displays EOT fonts and the Windows bug that limits EOT to TTF font data is still a factor?
Or are you talking about something else?
If you want to test CFF rendering in IE8, you'll need to spec a locally installed font in your CSS.
Rich, where are you getting your information about IE8 using a ‘port of WPF’ in standards mode? This doesn't make a lot of sense to me, since WPF is a graphics imaging environment, i.e. something to which an application might be ported, not something that would be ported to an application.
I've looked at TTF rendering in IE8, and it is using the Vista system rasteriser, not the WPF rasteriser. [The easiest way to distinguish them is to look at larger glyphs and see whether there are y-direction jaggies. WPF uses y-direction greyscale antialiasing, so looks smoother.]
Dan citing John -- Controlling y-direction alignment and features has the biggest overall impact in subpixel rendering environments, and this can be controlled relatively easily within FontLab with careful use of alignment zones and standard stem values.
Unfortunately, partial hinting is not a solution since ClearType is not the only rasterization method at work in Windows. Users may use greyscaling instead -- and then hinting of verticals will be noticably missing.
I wish that Windows would provide something comparable to Apple's rasterization and make it the default at least for unhinted fonts. If fonts are hinted, ClearType or greyscaling may take over for improved results.
The assumption "no rasterization without hinting" however is out of date since at least a decade.* That a font is not hinted is not an excuse any more for rasterizing it poorly.
Richard Fink -- [...] then what exactly is it that Windows is being asked to do? [...] isn't this too much to expect if the information necessary doesn't exist in the font?
To equal up with what Apple is able to deliver without any hints. Even if you do not like it, with unhinted fonts, Apple's rasterization gives better results than both ClearType and greyscaling. ClearType has problems with horizontals and greyscaling is too light.
(P.S. It is only when using IE8 as a "host" for viewing XAML that WPF is at work. Not for rendering HTML.)
Karsten
* Perhaps it is worth citing from Peter Karow's EP/RIDT'98 article (page 271 in the proceedings):
Working at Adobe in 1995, I learned that hints were the major invention with respect to digital typefaces and that they belong to them due to the typefaces' digital nature. Therefore, in general, (gray)scaling without using hints would be a sacrilege despite the comparisons and tests made by their font people which showed that the best results were obtained without hints.
Karsten: Unfortunately, partial hinting is not a solution since ClearType is not the only rasterization method at work in Windows. Users may use greyscaling instead — and then hinting of verticals will be noticably missing.
I wasn't suggesting partial hinting, only noting that y-direction controls have the largest overall impact on quality. You can also autohint vertical stems with fairly good results if you take care to create appropriate standard stem values. Basically, what one is doing in this approach is applying something similar to the PS hinting model within TT: providing fairly basic alignment and stem weight information, and letting the rasteriser make the best it can from this. The quality of the result will depend on the rasteriser more than on the font; again, this is like PS hinting. Black and white rendering is what really needs manual hinting; as soon as antialiasing is invoked, you can start to get reasonable results from carefully set-up autohinting. Optimal results? No. But reasonable and economical.
It is only when using IE8 as a “host” for viewing XAML that WPF is at work. Not for rendering HTML.
Both should be equal, but for some strange reason, Windows are using greyscale mode in FF, even though its configured to use only ClearType.
The question is: Why the f*** is Windows trying to do that?
Testing my fonts in use with Typekit it seems not to be happening (in my tests at least). Although my fonts are intended for big sizes, I forced it to small to see what happens in that situation.
What you are seeing in IE8 is an EOT font containing CFF-to-TTF converted font data, as discussed earlier in this thread. This is rendered using the system ClearType rasteriser.
What you are seeing in Windows Firefox 3.5 is a CFF font, rendered using the Adobe black box rasteriser within Windows.
The ClearType rasteriser under GDI only works with TTF data. So even if you have the system configured to use ClearType, you will still get greyscale for PostScript fonts.
***
The reason why your fonts display with ClearType in Firefox 3.5, Ricardo, is because they are TTF fonts, not CFF.
Bryan from Typekit here. There are a few points here for which I thought I'd provide some info.
>I was speculating that they might convert to TrueType to give broader support across different platforms - eg. Linux, or versions of Windows that don’t support CFF." (Sii)
That is exactly right. We convert the original format (with permission, of course) to make the font work in as many environments as possible. While doing that, we are dedicated to preserving the quality of the font to the largest degree possible. We very much appreciate the help provided by not only partners like Jan (paragraph), but from forums like this.
Additionally, we are talking to Sii and his team at MSFT, as well as helpful folks like Bill Davis at Ascender, to work through these issues. Every day we are developing techniques to improve the interoperability and the quality of type we're delivering.
>There is a lag of three or four seconds before the ‘real’ fonts kick in. (bert_vanderveen)
> Very little lag - a second at most on my set up.(Sii)
It's worth mentioning that we have multiple server locations on each continent, ensuring that any user has the fastest possible connection to the fonts. This gives our service a consistent starting point - it then comes down to an individual user's geography, internet connection, browser and operation system to determine their final experience.
We fully expect the browsers will continue to refine their algorithms for the display of downloaded resources (like images.) Additionally, we're working on some tricks to make the delay/flicker less apparent.
Also, we work hard to use caching to our advantage. The flicker upon load should be significantly reduced when navigating around a site with the same fonts.
>Note that it doesn’t seem to find your real italics (dtw)
Typekit style-links the fonts so that they act/work naturally -- meaning if you specify bold, it renders using the actual bold font file. Currently, IE does not support style-linking with @font-face. As such, we use a single file for that browser, and IE synthesizes bold and italic. We are looking at work-arounds that will allow users to gain increased control by accessing the font weights/styles individually.
>By the way, as it says in the thread title, it’s “Typekit,” not “TypeKit.” (Christopher Slye )
For the record, we are not a fan of camel case. But that's just us.
Thanks again for all your feedback. If there is anyone here that has not seen their invite yet, please drop me a note.
Oooops. My apologies to everyone, he send me the grab as .pdf (here), and I (unwittingly) grabbed it again on my Mac, thereby muddling the issue even more.
>~300 DPI? I’d hazard a guess that’s <5 years away.
No, about two feet away. If you want a higher resolution screen, sit further away.
***
200 dpi screens have been available for about a decade. But how many of them have you seen in use? We will see increases in resolutions on small device screens (cf. the Palm Pre phone at 180dpi), but probably not on desktop or even laptop monitors. The bigger a screen is, the greater the likelihood of a dead pixel during manufacture; there is some percentage of attrition in all screen manufacture, but the percentage goes up as the screen size goes up, since there are more pixels to potentially fail. Obviously the same is true when you increase resolution, so the rate and cost of attrition for large high resolution screens is much higher than for either smaller screens of the same resolution or lower resolution screens of the same size.
Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday - ie. the current installed-base of browsers, rendering environments and OS's.
Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday - ie. the current installed-base of browsers, rendering environments and OS’s.
Thanks to Ascender it is already working, right? :-) But only in IEs and FF test build (not officialy released yet as a new FF version for end-users) for now.
Its a great contribution, specially if other browser makers will want to implement it also.
Thanks Ricardo for the two samples. The differences in the rendering mischief by themselves are remarkable, let alone the fact that neither are acceptable. Thanks John for the "Using Fontlab to hint TrueType fonts for use on Windows for Dummies" list, that's where I'm heading now. I thought that Blue Screen of Death was a thing of the past! Dreadful.
Jonh >It should be possible to hint either to full or to sub-pixel widths.
It should be as you said, but 'the highest levels of MS' are preventing it. Or does your version of 'the hinting tool" allow it? And does windows look at the hdmx table if the instctrl is set to "natural"?
John>the Windows bug that limits EOT to TTF font data
So where is the OpenType in eot?
John>...applying something similar to the PS hinting model within TT
Duh!!! as if TT wasn't invented for a reason!?
Rich>More cans of worms...yeesh.
Really Rich? You think you don't know what "I'm talking about" and need a course in Berlow-speak, but the fact is, you don't know what we're talking about, and I'm just saying it the clearest.;)
SII>Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday -
Simon, come over here to the 'sidelines' and let me know when you all can get to 'tomorrow', where I will be waiting 'patiently' and will then explain to you why there are no 'custom fonts' for the web.
Jonh >It should be possible to hint either to full or to sub-pixel widths.
It should be as you said, but 'the highest levels of MS' are preventing it. Or does your version of 'the hinting tool" allow it? And does windows look at the hdmx table if the instctrl is set to "natural"?
John>the Windows bug that limits EOT to TTF font data
So where is the OpenType in eot?
John>...applying something similar to the PS hinting model within TT
Duh!!! as if TT wasn't invented for a reason!?
Rich>More cans of worms...yeesh.
Really Rich? You think you don't know what "I'm talking about" and need a course in Berlow-speak, but the fact is, you don't know what we're talking about, and I'm just saying it the clearest.;)
SII>Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday -
Simon, come over here to the 'sidelines' and let me know when you all can get to 'tomorrow', where I will be waiting 'patiently' and will then explain to you why there are no 'custom fonts' for the web.
John >It should be possible to hint either to full or to sub-pixel widths.
It should be as you said, but 'the highest levels of MS' are preventing it. Or does your version of 'the hinting tool" allow it? And does windows look at the hdmx table if the instctrl is set to "natural"? and 1/2 pixel hinting only works when OPENTYPE, (the real one), decides it wants to come out and play.
John>the Windows bug that limits EOT to TTF font data
So where is the OpenType in eot?
John>...applying something similar to the PS hinting model within TT
Duh!!! as if TT wasn't invented for a reason!?
Rich>More cans of worms...yeesh.
Really Rich? You think you don't know what "I'm talking about" and need a course in Berlow-speak, but the fact is, you don't know what we're talking about, and I'm just saying it the clearest.;)
SII>Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday -
Simon, come over here to the 'sidelines' and let me know when you all can get to 'tomorrow', where I will be waiting 'patiently' and will then explain to you why there are no 'custom fonts' for the web.
25.Aug.2009 12.35pm
I would describe it as a web font obfuscation service. A layer between browser and font that provides just enough hacking, hiding, along with rights-management, to make (some) type designers comfortable with allowing their fonts to be used with the @font-face linking mechanisms supported by Web browsers.
25.Aug.2009 12.48pm
So it lets a web designer use a font that s/he owns, and a user can see it even if that don't have it installed?
25.Aug.2009 1.11pm
Sounds like it's embedding the font in that particular web site - is that correct?
25.Aug.2009 1.13pm
It's a service. From what I can tell you can't use any font you own, just those that Typekit offers. You could use any font you own with @font-face if the fonts EULA allows it (most won't).
25.Aug.2009 1.18pm
I don't know what "@ font face" or "EULA" means. I'm not being devil's advocate. I'm actually a luddite.
25.Aug.2009 1.43pm
"@fontface" is a declaration in CSS* that allows a specific font which may not be on a viewer's machine to be loaded along with the web page and thus allow a web page to display text rendered in something other than "web-safe" default fonts -- as a font, not as an image.
Different browsers have different implementations of this @fontface declaration, supporting different font formats, etc.
Web designers find it cumbersome and a nuisance to keep track of all the different variations in code and formats to address the idiosyncrasies of different browsers that their viewers may be using. It is also confusing and frustrating for well-intentioned designers to understand which, if any, of the fonts they have or want will allow such a use as part of a font vendor's End User License Agreement (EULA).
On the other side of the equation, most vendors do not have licensing models for allowing use of their fonts for this kind of web "embedding." Most are reluctant to allow this use because some of the current browsers only support @fontface with "naked" fonts (i.e., the same OpenType or TrueType font format that can be installed directly on a desktop machine and used for any other purpose) and the security against these fonts being rather inadvertently or innocently acquired and used elsewhere is minimal.
Enter TypeKit (among others) as a service. They arrange with foundries to offer typefaces for use as web fonts (taking advantage of @fontface to serve up fonts to the web page). They host the font files on their own server and take pains to obfuscate the location and the contents of those files in various ways, to add a layer of security against misappropriation that their partner foundries accept.
Web designers who subscribe to the service select from the fonts on offer and are provided with copy-and-paste code that allows them to utilize these fonts in their web pages via CSS stylesheets, without having to worry about the details of the evolving technology and with confidence that they are correctly licensed. Typekit takes care of making sure that various browsers are served the appropriate formats in such a way that maximum compatibility and consistency is provided for the design.
Essentially TypeKit is building a bridge between web designers and font vendors by taking care of the messy muddle in the middle in terms of both technology and licensing ins and outs.
I hope I've stated this clearly for you and that my understanding does an adequate job of representing the essence of the situation.
Others can correct any oversimplifications or add any essential elements that I've skipped.
-- Kent.
[Edit]: * Sorry, I forgot to explain: CSS stands for Cascading Style Sheets and is used hand-in-hand with HTML for formatting and styling web pages.
25.Aug.2009 1.53pm
And for anyone else on the fringes:
http://typekit.com
http://blog.typekit.com/2009/05/27/introducing-typekit/
25.Aug.2009 3.27pm
This is some good basic reading too ...
http://opentype.info/blog/2009/07/29/why-webfont-services-are-the-future...
25.Aug.2009 4.47pm
You can see the rendering (hopefully) of two of my babies (Galette & Mentone) here. Do not know whether they both work on IE/Win, though (Sii, could you please let me know?).
25.Aug.2009 5.15pm
Galette seems to work, Mentone does not. IE7 on Vista.
27.Aug.2009 5.54am
> You can see the rendering (hopefully) of two of my babies (Galette & Mentone) here.
Cool. First time I had seen type kit in use. And it does work on IE7.0.5 on Windows. A second of display in the default serif, and then it pops into the correct faces. (I wonder if the delay is server related, and if it will grow longer if the service becomes popular.)
27.Aug.2009 7.05am
@Paragraph: There is a lag of three or four seconds before the ‘real’ fonts kick in. I am on a Mac w OS X 10.5 and Safari 4 (latest release). And in the Netherlands, if that is of consequence.
The lag makes it kind of unusable. Except if it just happens in the first webpage, I guess, IF it caches in some way.
. . .
Bert Vanderveen BNO
27.Aug.2009 7.06am
@Paragraph: have you tweaked something? When sii posted, my system (IE6 on Win XP Pro) agreed with his verdict. Mentone seems to show OK for me as well now though. Although the ™ symbol isn't working in the Galette sample.
_______________________________________________
Ever since I chose to block pop-ups, my toaster's stopped working.
27.Aug.2009 7.22am
TypeKit is one of many web-sites-as-a-service that allows you to put some javascript on your page that, in turn, will automatically load the appropriate javascript and/or css files necessary for you to load typefaces onto your page for use in standard HTML.
They have arisen for a few reasons (IMHO, of course):
- convenience for the web designer...we just add one line to our HTML to set it all up
- perceived protection for the type designer (there's a certain level of obfuscation that many foundries find acceptable over directly uploading fonts to your own server)
- pricing options. It appears that, at least with typekit, there will be a buffet-type pricing scheme.
27.Aug.2009 7.56am
>Mentone seems to show OK for me as well now though.
Same here. :-)
>The lag makes it kind of unusable.
Very little lag - a second at most on my set up. But any lag makes me think people might start putting Web fonts on the metrics of the core fonts to reduce the reflow-flicker when the fonts load in.
Cheers, Si
27.Aug.2009 9.24am
By the way, as it says in the thread title, it's "Typekit," not "TypeKit."
I wouldn't bother mentioning it except I'm just so glad to see a name that's not in "camel case" for a change. (Maybe it's an indication of a trend away from that.)
27.Aug.2009 9.30am
Given the target audience is web designers/developers, perhaps camel case would have been more appropriate. ;)
27.Aug.2009 9.45am
And the logo is all lowercase - so I say anything goes :-)
How about... TyPeKıT!
27.Aug.2009 4.56pm
Thank you all for this, AFAIK the Typekit folk are making the submitted OT fonts compatible with IE right now, perhaps Mentone was just tweaked. How about the rendering? Below is Safari 4.0.3/Mac OSX 10.5.8:
27.Aug.2009 9.41pm
@christopher dean
"So it lets a web designer use a font that s/he owns, and a user can see it even if that don’t have it installed?"
Almost. It lets a web designer use a font that s/he licenses for use from the font service, like Typekit, even though the user doesn't have it installed in their operating system.
On a technical level, it works similarly to the way block ads - like the ones for Font Bureau here at Typophile - are included in the page. Similar principal except instead of including a link to block ad images, the link is to font data. Both are handled by Javascript that creates the HTML and CSS necessary to link to the correct resource on the fly as the page loads in the browser.
28.Aug.2009 3.58am
>AFAIK the Typekit folk are making the submitted OT fonts
Prove it.
And the rendering looks great, but do you have something slightly lighter?
And why do the uppercase italic letters look more slanted than the l.c., are they all the same angle or is it something worse?
>http://typekit.com
Are they using their own service anywhere on thir own site?
Cheers!
28.Aug.2009 5.51am
David: if there is anything wrong with the rendering of the fonts, it is my fault, not Typekit's. They serve the stuff, they do not make it.
28.Aug.2009 6.31am
>...if there is anything wrong with the rendering of the fonts, it is my fault...
I know that. All rendering quality depenze on the digital outline font input and the scaling quality.
Do you have something slightly lighter or not!?
>...not Typekit’s.
I never said it was Typekit’s fault.
I asked you to prove that they were serving OT, meaning OpenType, (.otf) fonts converted to EOT to IE users.
Cheers!
28.Aug.2009 6.38am
Well, that one should be simple: I sent them .otf
Is that proof enough?
Lighter? I thought that Mentone Light was already on the too light side at small sizes.
28.Aug.2009 6.45am
>Well, that one should be simple: I send them .otf
>Is that proof enough?
Kind of depends if you gave them conversion rights as part of the license you signed with them.
Cheers, Si
28.Aug.2009 6.57am
Maybe I should just shut up. Disclaimer: all rendering mishaps in said Mentone and Galette samples are entirely my fault. The good bits are courtesy AFDKO autohint.
28.Aug.2009 7.12am
>Is that proof enough?
No, but thanks. Why don't you ask them. You have a licensing agreement don't you?
>Kind of depends...
Simon, it depends on whether they are trying to serve some fonts to all IE, or some IE with some fonts, and some IE with other fonts. Is that clear?
That's 'interoperability'. If they or anyone told their foundry clients the whole situation before they made licensing agreements, I'd be pleasantly shocked.
While you're awake 'over there', Simon, can you point me to a web site that serves an Embeddable OpenType font (that is the same as an Embedded Opentype font, except that since it's never embedded, I remain tense correct), with more than 256 glyphs in the EOT?
And I apologize to anyone, 'in-the-know' who knows that EOT does not generally contain any OT if it's going to work in all IE.
But they/we still cannot change the name of EOT fast enough for these discussions. ;)
Cheers!
28.Aug.2009 7.18am
FWIW Jan, this is what I get in IE/Win:
(Note that it doesn't seem to find your real italics, as well as the poor rendering at some sizes, and the missing ™ in one font but not the other...)
________________________________________________
Ever since I chose to block pop-ups, my toaster's stopped working.
28.Aug.2009 7.20am
...oh and the sample page prints OK (crisply, but still without the real italics) to a physical printer or to a third-party PDF utility, but not to Acrobat, which complains:
%%[ ProductName: Distiller ]%%Mentone-Light not found, using Courier.
%%[ Error: invalidfont; OffendingCommand: show ]%%
28.Aug.2009 7.37am
David, just one last remark, if I may: I do not have enough understanding of these matters to be a worthwhile sparring partner to you. I am attracted to Typekit by their practical approach to the problems you and the others have been discussing at length in the other threads and elsewhere. I like "practical", as I am too daft and old for "theoretical".
Cheers to you too.
Dave, that's pretty bad, back to drawing board ... no smoothing/antialiasing at all? Just a raw bitmap? Simon to the rescue!
28.Aug.2009 7.39am
By the way, the italics and the trademark render fine in my Firefox, so whatever it is, it's as issue of incompatibility with IE (No surprise there then.) rather than with Windoze.
______________________________________________
Ever since I chose to block pop-ups, my toaster's stopped working.
28.Aug.2009 8.36am
DB> Simon, it depends on whether they are trying to serve some fonts to all IE, or some IE with some fonts, and some IE with other fonts. Is that clear?
I wasn't thinking of IE or EOT, I was speculating that they might convert to TrueType to give broader support across different platforms - eg. Linux, or versions of Windows that don't support CFF.
DB> While you’re awake ’over there’, Simon, can you point me to a web site that serves an Embeddable OpenType font (that is the same as an Embedded Opentype font, except that since it’s never embedded, I remain tense correct), with more than 256 glyphs in the EOT?
Sorry David, I'm awake but I don't have a clue as to what you're asking.
28.Aug.2009 8.45am
>Dave, that’s pretty bad, back to drawing board ... no smoothing/antialiasing at all? Just a raw bitmap? Simon to the rescue!
For sure, funnily enough they contacted me for the first time last night. The email had the subject line "EOT, Microsoft, and What the Hell" :-)
I'm certain we can help them adjust their CFF -> TTF -> EOT conversion process to improve the rendering in IE.
28.Aug.2009 11.07am
@sii
"I’m certain we can help them adjust their CFF -> TTF -> EOT conversion process to improve the rendering in IE."
This is a big problem that I'm still trying to find answers to. I have spent good money on OTF CFF fonts that look like hell in Windows no matter what I do. And I am not automatically assigning blame to Windows, either. Safari's rendering of body text drives me nuts, so I'm not a big fan of their approach to rasterizing within Windows, either.
John Hudson quite graciously took the time to explain to me the fundamental differences between TT and CFF but how do we bridge the gap with regard to web fonts?
I might email you on this one, Simon, and soon.
What "help" might be on the way?
Richard Fink
28.Aug.2009 11.25am
> This is a big problem
Actually I think it's the *biggest* problem - once you get the whole licensing thing out of the way.
In Windows CFF fonts are generally rendered using a separate "black-box" PostScript rasterizer licensed from Adobe.
For the Web, what's cool about services like Webkit is that they can serve different fonts to different browsers running on different platforms depending on the rendering style of the browser, type of display etc., Something that's incredibly hard to do on a case-by-case basis for the average web site owner, unless they are working side by side with a font vendor who can provide a set of custom fonts - people like Font Bureau or Ascender.
28.Aug.2009 12.01pm
Firefox in Windows XP just shows me Verdana...
28.Aug.2009 1.11pm
Go to options / internet / fonts / and unclick "IKEA"
28.Aug.2009 1.14pm
http://www.cssquirrel.com/comic/?comic=32
28.Aug.2009 1.35pm
@ Fink (in joke. you had to be there): Do you have an online bio?
28.Aug.2009 1.36pm
They explain the joke in the related blog post.
http://www.cssquirrel.com/2009/08/17/comic-update-typekit-comes-to-font-...
But if you have to explain the joke...
28.Aug.2009 1.44pm
DB> While you’re awake ’over there’, Simon, can you point me to a web site that serves an Embeddable OpenType font (that is the same as an Embedded Opentype font, except that since it’s never embedded, I remain tense correct), with more than 256 glyphs in the EOT?
Me> Sorry David, I’m awake but I don’t have a clue as to what you’re asking.
I asked around, and we think you're asking if its possible to include more than 256 glyphs in an EOT. The answer is yes, although you probably want to subset a font, that's not required. As a test I took a font with over 600 glyphs and made an EOT, seems to work fine...
28.Aug.2009 2.11pm
CFF -> TTF -> EOT conversion process
Si, is this conversion something that should not be tried at home?
28.Aug.2009 2.24pm
Actually nothing to stop you giving this a try. Output TTF from FontLab and try various hinting settings, as well as different weights and styles. Then on a Windows installation you can proof different settings using HTML and IE. Once you've found the optimal settings you can create an EOT using WEFT or the Ascender EOT lite tool. Post the results to your site for peanut-gallery-review.
28.Aug.2009 3.56pm
Rich: John Hudson quite graciously took the time to explain to me the fundamental differences between TT and CFF but how do we bridge the gap with regard to web fonts?
Use the same rendering technology for both outline types?
Top: Windows GDI CFF font rasterisation using Adobe blackbox.
Bottom: Windows WPF CFF rasterisation using ClearType.
I suspect David will say this is bridging the gap by making CFF fonts look bad in the same way as TTF fonts, but there's something to be said for things looking bad in the same way rather than in divergent ways.
Undocumented: how CT rasterisation of CFF interprets CFF hint data.
28.Aug.2009 5.29pm
Keeping the Typekit in mind, BTW, there is a forum with the most common questions and problems involved in the current beta version of their service.
http://getsatisfaction.com/typekit
28.Aug.2009 6.43pm
I'm a little tired, and it's been a few days since I followed this thread but I read through it. Given there's a few acronyms I don't understand, can someone explain the relationships between Typekit and ClearType, TrueType, Black box, Hinting, Fontlab &c or are we talking about different things now (not that that's a problem).
I thought Typekit was a "middle man" between vendors, designers and viewers. Is this correct or am I back to being confused?
28.Aug.2009 7.05pm
•Typekit = Web service that schleps fonts in a way similar to Doubleclick schlepping ads. Yes, it is a middle man.
•Hinting = Instructions in a font that tell software how to render it so that it fits into a pixel grid without looking like a postmodern experimental design.
•TrueType = A font format created by Microsoft and Apple because everyone got pissy about John Warnock enforcing the Postscript patents. TrueType provides an awesome hinting system for rendering type at small sizes, but only ten people know how to use it and nobody else wants to figure it out because TrueType hinting is like watching paint dry. In New Orleans.
•ClearType = Microsoft’s hype, I mean type, rendering engine. It is not especially relevant because it does a poor job of rendering the Postscript fonts that people actually want to use. Because Microsoft doesn’t want anyone to steal their secret, they don’t tell us how it really works so almost nobody knows how to make type look good with ClearType.
•Blackbox = I think John was referring to the Adobe type rendering engine. It sucks, but it sucks consistently across platforms.
•Fontlab = What we’re all stuck using to create fonts until Glyphs is released.
28.Aug.2009 7.45pm
I thought Typekit was a “middle man” between vendors, designers and viewers. Is this correct or am I back to being confused?
That's the basic idea behind sevices like Typekit, Christopher. A middle-way where web designers can use fonts through a subscription. Designers can copy ad paste simple code to their pages and choose wich fonts to use in the service's interface, without having to deal with more complex issues like the highly technical ones exposed here.
I'm giving a try, supplying some few selected display fonts to see how the response of web designers will be for this kind of type design approach.
28.Aug.2009 8.29pm
Thanks for the definitions James. I know what the words mean, I just don't understand how they relate to what Typekit Does. Instinct tells me the that the conversation is becoming somewhat tangential. I'm quite curious to see how Typekit unfolds.
28.Aug.2009 9.18pm
The definitions relate to Typekit because Adobe, Microsoft, and Apple have made it excessively irritating to create type that looks good onscreen and across software and OS platforms. So instead of just being able to license the existing Postscript fonts, everybody has to make and test TrueType hinted fonts to use with services like Kernest, (and if it leaves beta before the PR person spends all the money, Typekit). This is a problem for type vendors who have a lot of high-end text faces, because hinting the fonts for use at text size is going to take a long time and cost a lot of money, especially if it turns out that web designers would really just rather stick with Georgia and Verdana because most people won’t spot much difference at ten pixels anyway.
28.Aug.2009 9.19pm
James: •ClearType = Microsoft’s hype, I mean type, rendering engine. It is not especially relevant because it does a poor job of rendering the Postscript fonts that people actually want to use.
This is incorrect. The (ir)relevance of ClearType to PostScript fonts on the web is that in all current browsers ClearType doesn't render PostScript at all. In GDI, which is the legacy graphics interface still used by almost all Windows apps, PostScript fonts are rendered using a 'black box' system from Adobe. The term 'black box' is used to refer to a piece of software that one company licenses to another for use but without any right to modify or look at the code. Adobe licenses a PS rasteriser to Microsoft.
In the new Windows Presentation Format, ClearType rendering, which in GDI only works for TTF, now renders CFF PS fonts also (not PS Type 1 fonts, though). But very few apps and no browsers use WPF. Which is a pity for a number of reasons, not least WPF's excellent built-in OpenType Layout suppport, and superior ClearType rendering (blending x-direction CT colour antialiasing with y-direction greyscale antialiasing for crisply smooth display type).
Because Microsoft doesn’t want anyone to steal their secret, they don’t tell us how it really works so almost nobody knows how to make type look good with ClearType.
Yeah, that's why they published a book about it.
•Blackbox = I think John was referring to the Adobe type rendering engine. It sucks, but it sucks consistently across platforms.
I was referring specifically to the Adobe PS rasteriser licensed for use in Windows GDI. Adobe have multiple type rendering engines, which they use in their apps, some rather better than others and most newer than the GDI one.
_____
Christopher: I just don’t understand how they relate to what Typekit does.
It relates in a number of ways. Firstly, there is the general issue of what all these different rendering engines, font outline and hint formats, and web font delivery formats actually do with the font when it appears in the browser. This issue is not restricted to Typekit: it affects all use of fonts on the web.
James asserts that 'Postscript fonts [are what] people actually want to use'. This is probably true for a lot of display type, but if people are looking for alternative text types for webpages, I think they're going to find that most PS fonts look like crap on most users' systems. I don't think TrueType is going to cease being the better screen font format any time soon. Adobe have been steadily improving their PS rasterisers over the past decade, but I suspect there are diminishing returns and a fixed limit of how good they can get within the PS hint model.
Karsten's actually done the homework:
http://kltf.de/kltf_notes_raster.htm
Secondly, this relates to Typekit because the service they offer includes converting and serving different web format fonts to different browsers, depending on the capabilities of those browsers and the limitations of the web font delivery formats accepted by them. Typekit serves EOT format fonts to Internet Explorer, which because of a bug in Windows (not in the EOT format itself, note) can only handle EOT fonts containing TrueType format outlines and hints. So if you are a font maker and license your fonts for use in the Typekit service, then you need to be aware that the outline format will be converted to TTF before being served as EOT. Personally, if I were licensing through Typekit, I would much rather have control of that conversion process on my end, and deliver TTFs to Typekit to serve as EOTs. [Somewhere on Typophile recently I posted some simple steps to maximise the quality of FontLab TT autohinting, such that it produces pretty good results with ClearType rendering. Controlling y-direction alignment and features has the biggest overall impact in subpixel rendering environments, and this can be controlled relatively easily within FontLab with careful use of alignment zones and standard stem values.]
28.Aug.2009 9.40pm
James: This is a problem for type vendors who have a lot of high-end text faces, because hinting the fonts for use at text size is going to take a long time and cost a lot of money.
Is this optimal? No. But then it also wasn't designed as a screen font, and the autohinting was done quickly.
This also demonstrates that the biggest problem with fonts designed as ‘high-end text faces’ for print when used on screen isn't hinting: it's spacing. In full-pixel rendering environments, TT includes hint instruction of advance widths, making it possible to control spacing on screen independently of spacing for higher resolutions. In ClearType, you lose this ability; with PostScript, you never had it in the first place.
28.Aug.2009 11.18pm
@ Puckett & Hudson: Thanks for the great answers. Very helpful.
29.Aug.2009 12.45am
•TrueType = A font format created by Microsoft and Apple because everyone got pissy about John Warnock enforcing the Postscript patents.
Actually, TrueType was created by Apple (only), as a replacement for Type 1, which was costing Apple a lot in licensing fees. Apple was to combine TrueType with Microsoft's TrueImage (a PostScript replacement) so that both Apple and Microsoft could stop paying Adobe so much money. (TrueImage never took off, though.)
29.Aug.2009 2.17am
John Hudson wrote:
Somewhere on Typophile recently I posted some simple steps to maximise the quality of FontLab TT autohinting, such that it produces pretty good results with ClearType rendering. Controlling y-direction alignment and features has the biggest overall impact in subpixel rendering environments, and this can be controlled relatively easily within FontLab with careful use of alignment zones and standard stem values.
I've been searching around, but haven't been able to stumble upon this thread. Does anyone have a link to it? I'd really like to see it! Thanks…
29.Aug.2009 5.20am
Yes please, John. I can not find it either and providence knows I need it.
29.Aug.2009 5.31am
I think TypeKit is great for companies who really "don't want to know" about server software, probably don't want to have "that conversion conversation" with themselves, and want the foundry/customer link to be at least distant from each other, if not a distant memory. And of course, it or any such service, separates the unknowing foundry from the likelihood of profit.
From our Suburban Legends Corrections Department:
>•Hinting = Instructions in a font that tell software how to render it
Not how to render, how to scale. After the glyph is scaled to the upm and perhaps according to the hints, then the rendering happens. Two things.
>•TrueType = A font format created by Microsoft and Apple because everyone got pissy about John Warnock enforcing the Postscript patents.
Apple did it alone, and I remember no patents ever issued to Adobe on this matter. TT was all done on a dare; as in, Adobe said to everybody, "We dare you to make better fonts" and the rest is Hysteria.
>•ClearType = Microsoft’s [] rendering engine. ...
...does scaling and rendering.
>•Black box =
..this is actually something you want to recover when your rendering engine fails, your project crashes, and the National Association of Readers want to launch an investigation.
>the biggest problem with fonts designed as ‘high-end text faces’ for print when used on screen isn’t hinting: it’s spacing.
It's a problem with fonts(?) because spacing can't be hinted and work in CT/QTZ/Whatever Adobe calls it now? What is the low res solution, John?
>I suspect David...
I do too. But I know where my EOTs are. How 'bout you?
Cheers!
29.Aug.2009 6.23am
Curiouser and curiouser. Below is my son's dump in IE6/Win XP, taken tonight in Prague. The italic is fake, and the trademark is missing too, BUT why is the rendering so much better than the one above by Dave?
29.Aug.2009 8.19am
In that screen grab ClearType is turned off - that's the default in Windows XP.
29.Aug.2009 8.24am
Well, that's progress for you. Thanks, Si.
29.Aug.2009 8.55am
I think TypeKit is great for companies who really “don’t want to know” about server software, probably don’t want to have “that conversion conversation” with themselves, and want the foundry/customer link to be at least distant from each other, if not a distant memory. And of course, it or any such service, separates the unknowing foundry from the likelihood of profit.
That's your point of view, David. But I don't think that accusing other foundries is a good way to convince consumers. I think they will choose what's best for them in each case.
If all the foundries involved "want the foundry/customer link to be at least distant from each other", there would be no foundries involved discussing here or anywhere. Makes sense for you?
What is the problem about trying a different model, like the ones offered by Kernest, Typekit, Fontdeck, &c? What's the big deal? I don't accept "it's not FontBureau" as a valid argument, even though the geat respect I have for your work.
29.Aug.2009 10.12am
Dan, could it have been this?
29.Aug.2009 10.20am
Thanks! That sounds like it must be right.
29.Aug.2009 10.21am
my son’s dump in IE6/Win XP
In that screen grab ClearType is turned off - that’s the default in Windows XP.
I think it’s not Windows rendering.
29.Aug.2009 11.10am
I think you're correct - zooming in you see the color fringing. Interesting, it kind of looks like WPF. Could it be Windows Safari, doesn't match Firefox?
29.Aug.2009 11.30am
Me thinks it would benefit a Typekit employee to track this thread.
29.Aug.2009 11.49am
David: [Spacing is] a problem with fonts(?) because spacing can’t be hinted and work in CT/QTZ/Whatever Adobe calls it now? What is the low res solution, John?
In CT, the solution should be to set a flag that enables x-direction deltas, i.e. to re-enable hinting of widths. It should be possible to hint either to full or to sub-pixel widths.
But that leaves Apple's Quartz rendering which dumps all hints, and Adobe's subpixel rendering, which makes use of at least some hints but isn't documented.
The only cross-platform solution for well-spaced screen fonts is the one you hit on David: ppem size-specific fonts.
29.Aug.2009 11.51am
Thanks, Karsten. Yes, that's the post.
29.Aug.2009 11.57am
More cans of worms...yeesh.
Now that @font-face has brought a new awareness and a new level of scrutiny to fonts, people are next going to be wondering why, if a font has been well-crafted, it still doesn't look good.
My biggest beef is that in Windows, at larger sizes, antialiasing stinks. The jaggies are awful. This is true whether it's Safari, Chrome, Firefox, or IE using Windows native rendering engine.
I've already mentioned - in keeping with John Hudson's screen grab - that rendering of OTF CFF fonts stinks at *any* font size.
But I have to ask: If CFF is a simpler format than TrueType, and one that deliberately conveys less hinting information to the rasterizer (do I have this right?), then what exactly is it that Windows is being asked to do? Make it look less bad (which seems the case in Hudson's WPF example) or on a par with a well-hinted TrueType font? And if the answer is, "On a par with TrueType", well, isn't this too much to expect if the information necessary doesn't exist in the font?
And if the aim is only "less bad", that doesn't exactly speak well of CFF as a format suitable for screen-readability, does it?
RE: John Hudson's comparison screen shot...
>Windows WPF CFF rasterisation using ClearType.
My understanding is that IE8 in Standards Mode, renders using a port of WPF. In other words, IE8 is innately capable of this sort of rendering of CFF fonts. If my understanding is correct, a good question is, "Why doesn't it do so?"
@sii
On the Flash Of Fallback Fonts (FOFF):
>Very little lag - a second at most on my set up. But any >lag makes me think people might start putting Web fonts on >the metrics of the core fonts to reduce the reflow-flicker >when the fonts load in.
Designers are going to be bugged by this, no doubt. There may be ways, via JavaScript, to suppress the rendering of the page until all the fonts show up. We'll see if that gets any traction. Matching up the metrics between two fonts can be tricky and it's an additional bother and barrier to adoption. We'll see how this one plays out.
BTW - Safari (on Windows, at least) waits for the fonts to show up.
>Kind of depends if you gave them conversion rights as part >of the license you signed with them.
I'm wondering how this gibes with consumer protection laws. If I bought it and own it and it's broken, do I not have the right to fix it? I'm not so sure the licensing contract would trump local statutes.
@john hudson
>Somewhere on Typophile recently I posted some simple steps >to maximise the quality of FontLab TT autohinting
Obviously we've got gaps in knowledge that need filling. Anything anyone can contribute with regards to making fonts more screen-friendly will have a great impact.
@christopher dean
>Do you have an online bio?
Dude, you're my friend on Facebook! If you need something more formal, message me there.
29.Aug.2009 12.08pm
&#$@%!
I went to look at the Mentone test page in Safari on Windows, to check Si's theory that the third Mentone screenshot in this thread might be Safari rendering. For the second time a web page using custom fonts in Safari has crashed my entire system with a blue-screen-o'-death. The first time was with David's Franky test page.
Safari is now on my Dangerous Piece of Sh*t list.
29.Aug.2009 12.12pm
Rich: My understanding is that IE8 in Standards Mode, renders using a port of WPF. In other words, IE8 is innately capable of this sort of rendering of CFF fonts. If my understanding is correct, a good question is, “Why doesn’t it do so?”
Because it still only displays EOT fonts and the Windows bug that limits EOT to TTF font data is still a factor?
Or are you talking about something else?
If you want to test CFF rendering in IE8, you'll need to spec a locally installed font in your CSS.
29.Aug.2009 12.19pm
Rich, where are you getting your information about IE8 using a ‘port of WPF’ in standards mode? This doesn't make a lot of sense to me, since WPF is a graphics imaging environment, i.e. something to which an application might be ported, not something that would be ported to an application.
I've looked at TTF rendering in IE8, and it is using the Vista system rasteriser, not the WPF rasteriser. [The easiest way to distinguish them is to look at larger glyphs and see whether there are y-direction jaggies. WPF uses y-direction greyscale antialiasing, so looks smoother.]
29.Aug.2009 12.43pm
Dan citing John -- Controlling y-direction alignment and features has the biggest overall impact in subpixel rendering environments, and this can be controlled relatively easily within FontLab with careful use of alignment zones and standard stem values.
Unfortunately, partial hinting is not a solution since ClearType is not the only rasterization method at work in Windows. Users may use greyscaling instead -- and then hinting of verticals will be noticably missing.
I wish that Windows would provide something comparable to Apple's rasterization and make it the default at least for unhinted fonts. If fonts are hinted, ClearType or greyscaling may take over for improved results.
The assumption "no rasterization without hinting" however is out of date since at least a decade.* That a font is not hinted is not an excuse any more for rasterizing it poorly.
Richard Fink -- [...] then what exactly is it that Windows is being asked to do? [...] isn't this too much to expect if the information necessary doesn't exist in the font?
To equal up with what Apple is able to deliver without any hints. Even if you do not like it, with unhinted fonts, Apple's rasterization gives better results than both ClearType and greyscaling. ClearType has problems with horizontals and greyscaling is too light.
(P.S. It is only when using IE8 as a "host" for viewing XAML that WPF is at work. Not for rendering HTML.)
Karsten
* Perhaps it is worth citing from Peter Karow's EP/RIDT'98 article (page 271 in the proceedings):
Working at Adobe in 1995, I learned that hints were the major invention with respect to digital typefaces and that they belong to them due to the typefaces' digital nature. Therefore, in general, (gray)scaling without using hints would be a sacrilege despite the comparisons and tests made by their font people which showed that the best results were obtained without hints.
29.Aug.2009 1.06pm
Karsten: Unfortunately, partial hinting is not a solution since ClearType is not the only rasterization method at work in Windows. Users may use greyscaling instead — and then hinting of verticals will be noticably missing.
I wasn't suggesting partial hinting, only noting that y-direction controls have the largest overall impact on quality. You can also autohint vertical stems with fairly good results if you take care to create appropriate standard stem values. Basically, what one is doing in this approach is applying something similar to the PS hinting model within TT: providing fairly basic alignment and stem weight information, and letting the rasteriser make the best it can from this. The quality of the result will depend on the rasteriser more than on the font; again, this is like PS hinting. Black and white rendering is what really needs manual hinting; as soon as antialiasing is invoked, you can start to get reasonable results from carefully set-up autohinting. Optimal results? No. But reasonable and economical.
It is only when using IE8 as a “host” for viewing XAML that WPF is at work. Not for rendering HTML.
Ah. That makes sense. Thanks.
29.Aug.2009 2.55pm
Jan,
This is what I see under Windows IE8:
And this is what I see under Windows Firefox 3.5:
Both should be equal, but for some strange reason, Windows are using greyscale mode in FF, even though its configured to use only ClearType.
The question is: Why the f*** is Windows trying to do that?
Testing my fonts in use with Typekit it seems not to be happening (in my tests at least). Although my fonts are intended for big sizes, I forced it to small to see what happens in that situation.
29.Aug.2009 3.50pm
Re. Mentone:
What you are seeing in IE8 is an EOT font containing CFF-to-TTF converted font data, as discussed earlier in this thread. This is rendered using the system ClearType rasteriser.
What you are seeing in Windows Firefox 3.5 is a CFF font, rendered using the Adobe black box rasteriser within Windows.
The ClearType rasteriser under GDI only works with TTF data. So even if you have the system configured to use ClearType, you will still get greyscale for PostScript fonts.
***
The reason why your fonts display with ClearType in Firefox 3.5, Ricardo, is because they are TTF fonts, not CFF.
Very nice, too.
29.Aug.2009 3.53pm
@k.l.
I wish that Windows would provide something comparable to Apple’s rasterization and make it the default at least for unhinted fonts.
Me too. Since Microsoft likes to copy a lot of things from Apple, I would not be surprised. I would be thankful. ;-)
29.Aug.2009 4.05pm
@ John Hudson
I was imagining that. That's why I tried to use only TTF data. Thanks for the clarification, John.
29.Aug.2009 5.06pm
Bryan from Typekit here. There are a few points here for which I thought I'd provide some info.
>I was speculating that they might convert to TrueType to give broader support across different platforms - eg. Linux, or versions of Windows that don’t support CFF." (Sii)
That is exactly right. We convert the original format (with permission, of course) to make the font work in as many environments as possible. While doing that, we are dedicated to preserving the quality of the font to the largest degree possible. We very much appreciate the help provided by not only partners like Jan (paragraph), but from forums like this.
Additionally, we are talking to Sii and his team at MSFT, as well as helpful folks like Bill Davis at Ascender, to work through these issues. Every day we are developing techniques to improve the interoperability and the quality of type we're delivering.
>There is a lag of three or four seconds before the ‘real’ fonts kick in. (bert_vanderveen)
> Very little lag - a second at most on my set up.(Sii)
It's worth mentioning that we have multiple server locations on each continent, ensuring that any user has the fastest possible connection to the fonts. This gives our service a consistent starting point - it then comes down to an individual user's geography, internet connection, browser and operation system to determine their final experience.
We fully expect the browsers will continue to refine their algorithms for the display of downloaded resources (like images.) Additionally, we're working on some tricks to make the delay/flicker less apparent.
Also, we work hard to use caching to our advantage. The flicker upon load should be significantly reduced when navigating around a site with the same fonts.
>Note that it doesn’t seem to find your real italics (dtw)
Typekit style-links the fonts so that they act/work naturally -- meaning if you specify bold, it renders using the actual bold font file. Currently, IE does not support style-linking with @font-face. As such, we use a single file for that browser, and IE synthesizes bold and italic. We are looking at work-arounds that will allow users to gain increased control by accessing the font weights/styles individually.
>By the way, as it says in the thread title, it’s “Typekit,” not “TypeKit.” (Christopher Slye )
For the record, we are not a fan of camel case. But that's just us.
Thanks again for all your feedback. If there is anyone here that has not seen their invite yet, please drop me a note.
29.Aug.2009 5.39pm
For the record (and I can change the title of the thread) what's the proper capitalization?
a) typekit
b) Typekit
c) TypeKit
29.Aug.2009 6.05pm
I think it’s not Windows rendering.
Oooops. My apologies to everyone, he send me the grab as .pdf (here), and I (unwittingly) grabbed it again on my Mac, thereby muddling the issue even more.
29.Aug.2009 6.06pm
If the owers call it Typekit, it's Typekit.
Damn, I almost called it tYpEkIt... ;-)
29.Aug.2009 7.01pm
Re hinting/anti aliasing/grayscale/ClearType: Aren't these points moot at >~300 DPI? I'd hazard a guess that's <5 years away.
*throws in a wrench*
29.Aug.2009 8.28pm
>~300 DPI? I’d hazard a guess that’s <5 years away.
No, about two feet away. If you want a higher resolution screen, sit further away.
***
200 dpi screens have been available for about a decade. But how many of them have you seen in use? We will see increases in resolutions on small device screens (cf. the Palm Pre phone at 180dpi), but probably not on desktop or even laptop monitors. The bigger a screen is, the greater the likelihood of a dead pixel during manufacture; there is some percentage of attrition in all screen manufacture, but the percentage goes up as the screen size goes up, since there are more pixels to potentially fail. Obviously the same is true when you increase resolution, so the rate and cost of attrition for large high resolution screens is much higher than for either smaller screens of the same resolution or lower resolution screens of the same size.
29.Aug.2009 8.41pm
Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday - ie. the current installed-base of browsers, rendering environments and OS's.
29.Aug.2009 9.28pm
Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday - ie. the current installed-base of browsers, rendering environments and OS’s.
Thanks to Ascender it is already working, right? :-) But only in IEs and FF test build (not officialy released yet as a new FF version for end-users) for now.
Its a great contribution, specially if other browser makers will want to implement it also.
29.Aug.2009 11.21pm
Thanks Ricardo for the two samples. The differences in the rendering mischief by themselves are remarkable, let alone the fact that neither are acceptable. Thanks John for the "Using Fontlab to hint TrueType fonts for use on Windows for Dummies" list, that's where I'm heading now. I thought that Blue Screen of Death was a thing of the past! Dreadful.
30.Aug.2009 5.32am
Jonh >It should be possible to hint either to full or to sub-pixel widths.
It should be as you said, but 'the highest levels of MS' are preventing it. Or does your version of 'the hinting tool" allow it? And does windows look at the hdmx table if the instctrl is set to "natural"?
John>the Windows bug that limits EOT to TTF font data
So where is the OpenType in eot?
John>...applying something similar to the PS hinting model within TT
Duh!!! as if TT wasn't invented for a reason!?
Rich>More cans of worms...yeesh.
Really Rich? You think you don't know what "I'm talking about" and need a course in Berlow-speak, but the fact is, you don't know what we're talking about, and I'm just saying it the clearest.;)
SII>Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday -
Simon, come over here to the 'sidelines' and let me know when you all can get to 'tomorrow', where I will be waiting 'patiently' and will then explain to you why there are no 'custom fonts' for the web.
Cheers!
30.Aug.2009 5.32am
Jonh >It should be possible to hint either to full or to sub-pixel widths.
It should be as you said, but 'the highest levels of MS' are preventing it. Or does your version of 'the hinting tool" allow it? And does windows look at the hdmx table if the instctrl is set to "natural"?
John>the Windows bug that limits EOT to TTF font data
So where is the OpenType in eot?
John>...applying something similar to the PS hinting model within TT
Duh!!! as if TT wasn't invented for a reason!?
Rich>More cans of worms...yeesh.
Really Rich? You think you don't know what "I'm talking about" and need a course in Berlow-speak, but the fact is, you don't know what we're talking about, and I'm just saying it the clearest.;)
SII>Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday -
Simon, come over here to the 'sidelines' and let me know when you all can get to 'tomorrow', where I will be waiting 'patiently' and will then explain to you why there are no 'custom fonts' for the web.
Cheers!
30.Aug.2009 5.35am
John >It should be possible to hint either to full or to sub-pixel widths.
It should be as you said, but 'the highest levels of MS' are preventing it. Or does your version of 'the hinting tool" allow it? And does windows look at the hdmx table if the instctrl is set to "natural"? and 1/2 pixel hinting only works when OPENTYPE, (the real one), decides it wants to come out and play.
John>the Windows bug that limits EOT to TTF font data
So where is the OpenType in eot?
John>...applying something similar to the PS hinting model within TT
Duh!!! as if TT wasn't invented for a reason!?
Rich>More cans of worms...yeesh.
Really Rich? You think you don't know what "I'm talking about" and need a course in Berlow-speak, but the fact is, you don't know what we're talking about, and I'm just saying it the clearest.;)
SII>Webkit (and EOT-lite for the matter) are about making stuff work today - and wherever possible yesterday -
Simon, come over here to the 'sidelines' and let me know when you all can get to 'tomorrow', where I will be waiting 'patiently' and will then explain to you why there are no 'custom fonts' for the web.
Cheers!