why just 50 points? :)

I guess nobody wants my points. Perhaps I should offer a "real" prize?

Why not load both fonts into FontLab and do a manual 'diff'? Or drop Mr Bigelow a mail and ask him?

I believe the answer will be "no real difference" unless Apple needed to mess with vertical metrics for UI purposes.

Cheers, Si

My guess would be it is a legal loophole that had to be danced for differing platforms. Maybe Bigelow & Holmes cut a different deal with Apple and MS.

ChrisL

There are more differences in character sets than just Arabic and Thai. Lucida Grande has many more characters that Lucida Sans Unicode is missing (I'm comparing Lucida Grande version 5.0d8e1 with Lucida Sans Unicode version 2.03). Lucida Sans Unicode is pretty old and my guess is that Microsoft did not get it updated recently. So Lucida Grande supports some Unicode ranges that were not yet assigned at the time when Lucida Sans Unicode was built, for example Latin Extended Additional (starting with U+1E00 Ḁ). L. Grande has polytonic Greek, many more historical and Asian Cyrillic characters (e.g. U+0468 Ѩ), many more Latin Extended-B characters (e.g. U+0222 Ȣ). The design of some characters has been corrected or updated, e.g. the commaaccent characters (e.g. U+0137 ķ), the phonetic U+0251 (ɑ), the Cyrillic U+0444 (ф) and U+046A (Ѫ), and many others.

The hinting differs greatly: the stems in Lucida Sans Unicode turn into two pixels at 15 ppem while in Lucida Grande they only do so at 18 ppem. The 17 ppem size of Lucida Grande uses 1-pixel stems plus antialiasing, which does not at all work well in the normal Windows 2000/XP rasterizer. This is evidence that the font has not been hinted with Windows in mind but was specifically hinted for Mac OS X where it works great. However, in Windows XP ClearType, it is Lucida Grande that performs better than Lucida Sans Unicode, which evidently has been "overhinted" and displays a weird high linear contrast up to 24 ppem, while the stems in Lucida Grande appear pleasantly equalized already from 18 ppem on.

These would be the first quick observations from my side.

A.

> hinted for Mac OS X

Huh? I thought we established that OSX very rarely supports
hinting, and apparently in no case for anything above 12 PPEM.

hhp

Hrant,

The 12 ppem threshold is customizable.

A.

But 12 is the max! And the default (which virtually nobody will change) is... 8!

hhp

Unfortunately, Lucida Grande does not support italics, whereas Lucida Sans does!

Mark

>Unfortunately, Lucida Grande

If Mac OS does not use italics in the UI, then there was likely no incentive for Apple to license the italic verison of the font from Bigelow and Holmes.

Only problem with this approach is that third-party apps may not follow that convention and you'll get fake italics - unless MacOS is clever enough to block this.

It pains me that there are no italics. Microsoft consistently bests Apple in the typography realm, the very thing Steve claims to have revolutionized for the computer. It's sad.

So far, Adam wins the ham. But can anyone tell me why the name difference?

There may have been issues around the Unicode trademark, or maybe Apple just wanted to think different with respect to the name, but most likely I think the name relates to Peter Lofting's Starbucks preference.

another ham goes to sii for being a ham

Si is going to have a large pig roast with all that ham you keep sending :-)

ChrisL

On a fully unrelated note: we have Warnock Pro now. When can we expect Gates Premier, Bullmer Ultra or Jobs Pro?

A.

>or Jobs Pro?

As mentioned elsewhere iFont is already taken, not that would stop Apple ;-)

sii said: "Only problem with this approach is that third-party apps may not follow that convention and you’ll get fake italics - unless MacOS is clever enough to block this."

In Mac OS X, as far as I am aware, this is indeed true.
By default in Cocoa apps, and Carbon apps that use ATSU (which is about 99% of them these days), if the current face has no italic/oblique or bold available, the respective menu items/buttons will be dimmed.
Nonetheless, software can programmatically request a closest match for a face that has no italic, which will return an italic face from similar font family that has the same traits (proportional, serif, same weight, &c.). The app can then accept this alternative, or reject it and have an oblique algorithmically generated instead.
For apps that use QuickDraw for text (BBEdit < version 8, maybe others?) oblique is always generated if one doesn't exist.