Yes, if you remove "use font smoothing" the font weight gets lighter and closer to other OSes rendering. Big Sur gets rid of this option, but I don't know if the underlying option is still on or not.
Maybe technically, but unless you strip every screw on your way into the machine, they won't know you ever had the cd drive disconnected. Just put it back when you take it in for service.
Are you sure that X220 is similar enough to an Air, it doesn't look like an air and the design specs are quite bulkier:
MacBook Air 11 inch:
Height: .68
Weight: 2.38
MacBook Air 13 inch:
Height: .68
Weight: 2.96
X220 12 inch:
Height: 1.25
Weight: 3.6
I don't think it matters that you spec'ed it out to be slightly faster, I bet many of the people who want an Air-like notebook want the thinnest, cleanest, lightest notebook that can still perform very close to a traditional fat notebook, the X220 probably isn't what they're looking for.
It would be nice if Apps allowed you to adjust the text size of the entire UI to enlarge it. On a related note iOS has a Zoom feature in the Accessibility options which will make the entire OS larger (you just pan around using three fingers).
I agree with that. I'm sure that they would rather have their own syncing app that simply works with the iTunes library rather than masquerading as an iPod and leaving it up to iTunes to do all the work. That's just plain crazy if you think about it, but in their rush to market this was probably the easiest way. Surely there is a team at Palm working on a standalone app as we speak. Other handset manufacturers use their own applications for the sync and simply utilize the iTunes library data, in time Palm will too.
These tools (like YSlow) are oh so interesting when your clients install them in their browser and examine the site you built for them. Now, I'll get to hear complaints that we used too many inefficient CSS selectors (and that we're incompetent), ignoring the fact that a .0003 millisecond makes no difference to the client's website. It's not Google's fault, but I just had to sigh when I saw some of the rules (I'll expect a call by tomorrow haha). :-)
Those text replacement techniques (sIFR/cufon) have downsides though. You can't manipulate the replaced text as you would normally, you lose some functionality because you've replaced text with flash/canvas/image etc., and you won't see anyone replace entire body text using those techniques.
Using the standard @font-face css technique instead of a text replacement hack allows your custom fonts to have all the same benefits of standard browser text.
You can already embed fonts easily without using a service such as this site will provide. The problem is of course the license to do so. There are a lot of fonts out there that are free and allow website embedding, but the majority of fonts from major type foundries are not included. So assuming Typekit gets more of the type foundries onboard that would be useful.
The question is what will make these foundries jump onboard if Typekit isn't introducing a new DRM or other protections? I think this is how it might work:
1.) Check the site referrer to ensure that fonts from Typekit are only delivered to websites that have purchased the font (or are signed up for the free fonts).
Of course since there aren't any drm protections, you can simply take the font file and put it on your own site, which leads to....
2.) They might have custom Typekit versions of well-known fonts, so that if any website is self-hosting a font file that is from Typekit, it's plainly obvious they're doing it illegally. Also, if a type foundry only licensed their font to Typekit for web embedding, then any hosting of their font on a site other than Typekit is forbidden.
This is different than how it would work now, because let's assume that a type foundry licensed fonts for embedding on websites. It becomes very hard for them to search the web finding their embedded fonts and then checking their records to make sure the person who created the site actually purchased a license. This would take a lot of time and effort that these type foundries don't have. However, if the font is only licensed to be hosted by Typekit, then Typekit can do the checking and accept reports of other sites infringing, etc. It just makes the whole effort easier because only one website will have the license to self-host that font.
So to me, the biggest downside is that you have to have your font files hosted on a 3rd party service. Also, they claim you'll embed the fonts via javascript, whereas if you were self-hosting your own fonts there's no need for javascript at all.
I wish the type foundries would just get over the fact that some people may commit copyright infringement on their fonts. Instead they should just provide all of us honest people the ability to purchase a license to embed fonts on our websites instead of constantly trying to find drm'ish ways of fighting it.
I agree, the main issue here is that they're not using SSL during these steps, and the second is that they don't recommend changing your password from the generated default.
"If the apps on the category charts are doing those sorts of numbers, what do you think the rest of them are doing?"
What if Board Games and Social Networking aren't popular categories? Just because an app makes it on the chart of an un-popular sub-category of games (board games) doesn't mean the apps charting in more popular categories are doing equally as bad.
And there are easy ways that Google could track people with javascript turned off. I always thought they would add this as a 'Pro' feature and charge money for that option. So you'd have to pay for the complete stats, most personal sites wouldn't care about non-javascript stats, while most commercial sites would gladly pay the fee.