Re: glyphWithName: broken on Tiger ?
Re: glyphWithName: broken on Tiger ?
- Subject: Re: glyphWithName: broken on Tiger ?
- From: John Stiles <email@hidden>
- Date: Wed, 1 Jun 2005 15:33:19 -0700
On Jun 1, 2005, at 3:22 PM, Robert Clair wrote:
It sounds to me like you were relying on something that the
documentation clearly stated was not a guarantee, and now you're
being bitten by it and you want to blame someone else.
Sorry, but that's your bug.
Absolutely wrong.
If the docs say that glyph names can be arbitrary, expect the
unexpected.
Please read the docs again.
"Glyph names in fonts do not always accurately identify the glyph"
The way I learned English what the doc is doing is warning me that
the glyph naming of some fonts is flakey, *not* that the routine is
flakey or deprecated or unsupported. Are you suggesting that for a
given font the glyph names are a function of the weather ?
I would absolutely expect to get a -1 or an unexpected glyph for an
arbitrary font. What I do not expect is for it to suddenly stop
working on the *same* font merely because I upgraded.
It doesn't return -1 or the wrong glyph. It now uniformly returns
0, the null glyph, for every font for which it used to work - i.e.
"broken".
Yeah, you should be getting -1, not 0. That's wrong behavior.
But the "guarantee" that I was referring to in my original post is
the idea that the glyph for the letter "A" is named "A". Honestly I'd
have assumed that the glyph name would be "LATIN CAPITAL LETTER A".
That's what the Character Palette shows for the glyph name.
And while I wouldn't suggest that glyph names should change willy-
nilly, it does not shock me that they might change in a major OS
update. And the routine's docs do, in fact, say it's not a recommend
path--"If possible, look up the appropriate glyph on your own"--right
after the sentence you were quoting. So I'd suggest that this is a
poor API to choose for what you want to do, given that there are
alternatives which work better.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden