Re: determining availability of a given glyph via NSFont
Re: determining availability of a given glyph via NSFont
- Subject: Re: determining availability of a given glyph via NSFont
- From: email@hidden
- Date: Wed, 6 Feb 2002 10:08:09 -0800
Can't help you with your main problem; that will require a reply from
someone more knowledgeable about fonts. I can, however, help you with
two of your questions:
cool! i tried this and it seems to work for my purposes so far, but ...
of course it's "undocumented", which makes me a little uneasy, and it
generates compile-time warnings about how "`NSFont' does not respond to
`_rawDefaultGlyphForChar:'" ... so my questions are:
1) is there anything better that i should be using instead?
2) are there any real reasons _not_ to use _rawDefaultGlyphForChar:?
3) an easy way to get rid of the warnings?
To get rid of the warnings, simply declare a category on NSFont which
you never implement. Like:
@interface NSFont (ApplePrivateStuffThatIWantToUse)
- (NSGlyph)_rawDefaultGlyphForChar:(unichar)uch;
@end
I don't know whether that's the right signature, that's just an
example. This lets the compiler know the method exists. You will not
get any complaint from the linker, because ObjC is a fully dynamic
language -- for all the linker knows, _rawDefaultGlyphForChar: is
getting implemented via -doesNotRecognizeSelector: or some such.
As for "real" reasons not to use it, the big ones are:
1. Its behavior may change at any point in the future with no warning
2. It may simply go away completely in the future with no warning
3. It may have undesirable side effects that you are not aware of
That said, I'm a big fan of using undocumented APIs. I think Apple
doesn't make APIs public a lot of the time for a simple reason: they
believe in keeping public APIs clean and simple. Until they perceive a
need for a given method, they don't want to clutter things up
unnecessarily. I personally think they are a bit too conservative in
this department, but I would have to admit that, with a few glaring
exceptions, the APIs in Cocoa *are* quite clean. So to help Apple along
in this process, make sure you log a bug on them whenever you need an
API that doesn't seem to have been made public. They need to hear from
developers like us.
Ben Haller
Stick Software
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.