Can someone describe Typekit to a luddite?
Typophile
What is Typekit?
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.
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?
Sounds like it's embedding the font in that particular web site - is that correct?
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).
I don't know what "@ font face" or "EULA" means. I'm not being devil's advocate. I'm actually a luddite.
"@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.
And for anyone else on the fringes:
This is some good basic reading too ...
http://opentype.info/blog/2009/07/29/why-webfont-services-are-the-future...
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?).
Galette seems to work, Mentone does not. IE7 on Vista.
> 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.
. . .
Bert Vanderveen BNO
@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.
Cheers, Si
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.)
Given the target audience is web designers/developers, perhaps camel case would have been more appropriate. ;)
And the logo is all lowercase - so I say anything goes :-)
How about... TyPeKıT!
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:
@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.
>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?
Are they using their own service anywhere on thir own site?
Cheers!
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.
>...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!
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.
>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
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.
>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!
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.
>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.
@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?
> 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.
Firefox in Windows XP just shows me Verdana...
Go to options / internet / fonts / and unclick "IKEA"
@ Fink (in joke. you had to be there): Do you have an online bio?
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...
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...
CFF -> TTF -> EOT conversion process
Si, is this conversion something that should not be tried at home?
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.
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.
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.
The triple play!
>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.
In terms of delivery mechanism it seems as if there's some convergence around the Let-Tal-Error proposal as a long term solution and a compatibility format based on EOT.
Rendering consistency, the strength of Flash, seems to be the Achilles-heel, perhaps the long term solution here might be a property in the font that makes recommendations about how the font should be rendered, or perhaps CSS properties that define rendering style?
>So where is the OpenType in eot?
If you mean CFF, then the answer is Windows 7, and with a bit of luck in a service pack for older versions of Windows.
David: So where is the OpenType in eot?
In a TTF-flavoured OT font? In a TTF with optional OTL tables? In a TTF that contains table versions and fields that are not part of any format spec except OT?
One might also ask where's the OpenType in CFF?
Duh!!! as if TT wasn’t invented for a reason!?
TT was invented for a number of reasons, but I presume you are referring to why the TT hinting model was designed to be different from the PS model. Very good reasons c.1990. Very good reasons in black and white pixel display. But when we're spending weeks producing VTT hint sources for fonts targeted at ClearType, whose results in ClearType are >95% identical to FontLab autohinting, and in WPF are almost identical to no hinting at all, how relevant are those reasons?
@john hudson, sii, karsten, et al...
Love these threads that veer off unexpectedly into the heart of the matter. There is much to mull over here and assertions to confirm (including my own). John - I'll try to get clarification on the capabilities of the IE8 rendering engine.
And Christopher, I hope you now understand what Typekit is!
@sii
"Rendering consistency, the strength of Flash, seems to be the Achilles-heel, perhaps the long term solution here might be a property in the font that makes recommendations about how the font should be rendered, or perhaps CSS properties that define rendering style?"
Yeah, there's got to be a switch to flip somewhere along the line.
Some people participating in this thread might be familiar with an alternative font-linking technique called Cufón. In Windows, Cufón renders headline-sized text beautifully. With Flash-like antialiasing and features. You can get gradients, shadows - very nice stuff. It relies on JavaScript alone.
In IE, Cufón uses VML (Vector Markup Language) and in Firefox and Safari is uses the Canvas tag.
It has drawbacks, problems with text-selection and such, but based solely on the way the text looks, it begs the question, "Why can't I just specify that a block of text be rendered this way and have the browser take it from there?" After all, if you can get smooth, good looking curves with VML, it's obvious the browser is capable of it. It can be done, period.
A CSS property perhaps, like visibility:vector or somesuch.
@davidberlow
>You think you don’t know what “I’m talking about” and need a course in Berlow-speak
There is a big difference between my "not knowing what you're talking about" due to your inimitable writing style, and my thinking that you don't know what you're talking about.
In case anyone gets the wrong idea from your reply to me,
it's the former, not the latter, and I assume that anyone who writes as uniquely as you do is quite aware of what he's doing and is fully prepared for some good-natured ribbing, which is all I intend. Plus, telling anybody "you don't know what you're talking about" is rude and counter-productive. If I have offended you, I apologize.
@ Fink: Pretty clear. Lots of good answers. Re the rest of your post, well put.
SII>If you mean CFF, then the answer is Windows 7, and with a bit of luck in a service pack for older versions of Windows.
I think we're done counting on the H.MS. Luck coming in on this. ;)
SII>the long term solution here might be a property in the font that makes recommendations about how the font should be rendered
Not enough, too late I'm afraid. Server-based UFO to TT-only OFF Lite Plus will work for this and all else though. Any puny human formats that need to be dumbed down from there will be easy enough.
John>But when we’re spending weeks producing VTT hint sources for fonts targeted at ClearType, whose results in ClearType are >95% identical to FontLab autohinting, and in WPF are almost identical to no hinting at all, how relevant are those reasons?
Getting 95% of FL hints for 40% of the needed TT instructions, for ıoo% of the users doesn't help, if you know what I mean.
There is a 'growing community' of full instruction needers.
But I didn't realize hinting was an issue, EOT's users rely entirely on ignoring most TrueType Instructions, don't they?
And Richard, I do not consider it counter productive to tell people who don't know what they are talking about the truth. It's takes too much time otherwise. I didn't mean to insult you, but I'm not always talking to everyone. On the other hand, when 'our problem' is a 'readable web', it seems counter-productive for you to tell people you don't know what I'm talking about.
I'll try this though; the average text font cannot interoperate where such simple operations as sizing, scaling and rendering is happening in a non-standard way(s)... particularly when the text font style is being defined before the font's 'size'. What's Typekit got to do with it?
Cheers!
@david berlow
"But I didn’t realize hinting was an issue, EOT’s users rely entirely on ignoring most TrueType Instructions, don’t they?"
No. Untrue. EOT is just a wrapper around a TT file. When the browser receives the font data, it's processed exactly the same as if it had come from a font installed in the operating system. No instructions lost, none added. No visual difference in rendering at all.
@all
In an earlier post on this thread I mentioned Cufón text replacement. I've been revisiting it, playing around with sub-setting and trying to solve the problem of making the replaced text selectable, cross-browser. (With some good results,too.)
Factoid: Cufón works quite well with CFF fonts. Unlike EOT, Cufón ignores, because it doesn't rely on, hinting instructions in TT files.
The real screen dump of my test page in IE6/Win XP is here. A .ttf rendering of Galette can be seen here. I think that the column on the left is the new .ttf, the right column seems to have the old linespacing (still the same .otf).
David: If you were serious about something lighter, Galette Light is there.
John Hudson: Thanks for the TT autohinting list!
Does it render any better on Vista, please?
RIch >No. Untrue.
What I said was joke Richard.
> No visual difference in rendering at all.
>If you were serious about something lighter,
See last paragraph of last post.
Cheers!
[[http://typophile.com/user/108|Tiffany]] just posted this demo of "Typotheque" on facebook.
Is this the same sort of service as Fontkit?
If so, I think I understand even more. This is very interesting.
@dberlow
Irony can be tough to spot sometimes. It's gotten me in a lot of trouble, too. I've tried to swear off it on the net.
I did have trouble believing you didn't know an EOT was just a regular font file rendered the regular way but how about the newbie who might wander upon this thread and think otherwise?
So for that poor schm-ck, I played it straight.
@christopher
Yes, Typotheque is offering the same kind of thing as Kernest and Typekit.
>I did have trouble believing you didn’t know an EOT was just a regular font file [a wrapper around a TT file].
Oh, "regular' in what way? Forgetting that it's not 'embeddable', would it not be even more "regular" for EOT to be a wrapper around an OT file?
>rendered the regular way ...
Oh? "regular" in what way?
> Typotheque is [] the same kind of thing as Kernest and Typekit.
Oh? and what "same kind of thing" is that? I'm not hearing about you building cross platform/browser fonts and cross platform/browser sites, so I'm thinking to show you more. Or maybe not.
> But when we’re spending weeks producing VTT hint sources for fonts targeted at ClearType, whose results in ClearType are >95% identical to FontLab autohinting...
Who's we? Proof please.
Cheers!
@davidberlow
>Oh? “regular” in what way?
OK. Point taken.
> But when we’re spending weeks producing VTT hint sources for fonts targeted at ClearType, whose results in ClearType are >95% identical to FontLab autohinting...
I, too, would like to see proof of this, please.
rich
Oh, call me on my hyperbole, why don't you, David. Fair enough.
We, in this case, is Ross, who actually does the hinting and, sensibly and non-hyperbolically, estimates:
If it were a sans serif, or perhaps a slab serif, you might approach 85-90%. Otherwise I would put it closer to 60-70%, overall (italics, or something like Gabriola more in the range of <50%). This accounts for simple glyphs which may need no further instructions added in VTT as well as those in which FL is simply unable to isolate features of anatomy that do require more instructions, or indeed fixing instructions that FL adds that make no sense, or that are redundant/conflicting etc.
These is based on an FL -> VTT conversion workflow we developed a couple of years ago that allows us to either leverage FL auto stem hinting or manual PS hints in VTT, avoiding much of the drudge work of drawing spaghetti in VTT.
The larger point I was making was that, in subpixel rendering environments, the reliance on hinting is significantly reduced -- and in Apple's Quartz rendering is, literally, removed completely --, to such a degree that autohinting even on the FL PS->TT model can be effectively leveraged for a lot of purposes. And let me be completely clear about this: this is not always or even mostly a good thing, and I'd like to have more hinting control not less.
But given that people are talking about, apparently without humour, about using CFF OpenType fonts on the web, I think it is entirely valid to point out that half-decent autohinting of those same fonts converted to TTF is going to look better than the CFF versions, at least with today's system PS rasterisers. Will these fonts look as good as carefully designed and hinted native TTFs intended for reading on screen? No. But they will still look better on screen than CFF fonts.
JH> ...reliance on hinting is significantly reduced — and in Apple’s Quartz rendering is, literally, removed completely.
This is because Quartz does (ahem), match the color that the type would normally print very closely. This does not mean however, that the screen matches the 'readability' of that print. Something's going to happen to help that though, because Apple now thinks people do read, after all.
JH>If it were a sans serif, or perhaps a slab serif, you might approach 85-90%. Otherwise I would put it closer to 60-70%, overall (italics, or something like Gabriola more in the range of <50%).
And what if your library contained 50% fonts not close to 'normal' width or 'normal' weight? Sounds a lot like your library could use at least Electronic (PA) Recommendations, even if only 'you' can read them, they'll be informing to 'sales' and to the better gasps on the planet;).
JH>... this is not always or even mostly a good thing, and I’d like to have more hinting control not less.
More? lolTrust me, you'd like to have total hinting control and decide what parts of a 'complete interoperable standard' you need to apply for a particular specification, narrow or broad.
DB>Oh? “regular” in what way?
RF>OK. Point taken.
But how deep? ;)
To bring us back to the topic, we hope this is not Typekit's job alone. ;)
Cheers!
@davidberlow
>Apple now thinks people do read, after all.
Now, that is a funny line. That one's going to morph into a blog headline, and soon. Thanks.
@jh and dberlow
As long as we're talking about such things...
What's up with LED backlit screens? Rendering on my iPhone and my HP Touchsmart tablet is very different from what I get on my "normal" (don't start, David) LCD screens. A crisper, more print-like result. But I haven't been able to find much info about the difference in the technologies.
Any info on that? Does LED in any way cut down on the need to hint?
sorry about the italic horde.
Cheers!
>What’s up with [...] iPhone and my HP Touchsmart tablet [...] I get [...]. A crisper, more print-like result. [...] Does LED in any way cut down on the need to hint?
As a bipod, I have two iPhones, so I know how that works. I don't have a HP Touchsmart tablet, but I do have two 'wireless' HP printers for which I'm looking for wires, if you have any loose. What's Touchsmart's resolution? Dots per inch? Could be the Resolution Fairy... S/he's 'every way' to cut down on the need-to-hint/ability-to-design for readability.
Cheers!
oops
David: Trust me, you’d like to have total hinting control and decide what parts of a ’complete interoperable standard’ you need to apply for a particular specification, narrow or broad.
Yes, sometimes I'd like to have total hinting control. Other times I look at the same typeface printed on two different paper stocks, or from two different laser printers claiming the same resolution, and think that the lack of control that we face in different screen rendering technologies isn't anything new. Then I go back to this
http://www.tiro.com/John/Baskerville-a.jpg
(all taken from a single page) and ask myself whether there is any such thing as a typeface except as a source of limited but uncontrolled variation.
>http://www.tiro.com/John/Baskerville-a.jpg
Myself, I prefer composing in the key of A Flat ♫♪♫
JH>Yes, sometimes I’d like to have total hinting control. Other times I look at the same typeface printed... [] and think that the lack of control that we face in different screen rendering technologies isn’t anything new.
Well, it is something new, if not by percentage of error per feature, then certainly you can imagine a parallel situation in Baskerville's world, where the clients of his type were somehow enabled to reheat type from a letter to whole pages, and let 'whatever' loose on his types, (except perhaps pure ink of any color, and especially not Black)... while the "Baskerville" label remained prominently displayable, and unchanged for all to see?
As many unfounders confirmed to my ears in Mexico , there is a 'rendering problem" on the web as a result of there being a difference between hot metal's inadvertent glyph variation spectrum, and the web's, (ahem) glyph variation spectrum at the bottom of the resolution spectrum.
Imagine all of our surprise, to maintain thread integrity, including of course Typekit,;)
Cheers!
Captured from web.archive.org on 20 Sep 2019. view this capture