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: Andy <email@hidden>
- Date: Wed, 06 Feb 2002 22:23:12 -0500
Jody Fairchild wrote:
>
>
i'm looking for the best and easiest way to determine whether a font can
>
display a given glyph ... nothing really fancy, right now i'm only
>
concerned with 7-bit ascii, but it would be cool if the method proved to be
>
generally robust and unicode-clean.
>
Well now, that *is* an interesting question. One I actually spent most
of last night and this morning thinking about, and the last few weeks.
You can see the fruits of my efforts here (INCLUDES SOURCE!):
http://pixel.recoil.org/cocoa/unicodefontinfo.html
I'm also deeply impresses by this (Font Checker):
http://www.wundermoosen.com/wmXFCHelp.html
Especially take a look at the Unicode and FAQ sections.
In short its very hard to get this right for Unicode using the public APIs.
I'm currently having an interesting converstation with the author of
font checker.
His challenge to me: my method of determining which characters are valid
using a layout manager is flawed. (which I agree with). There's a way to
do it 100% accurately which does not use a layout manager at all. All I
have to do is find it...
So, some thoughts about why the problem is hard.
As the link above visually demonstrates, glyphs are not the same thing
as characters.
(I'm not going to try to use correct terminology here, I think strictly
speaking Unicode refers to things like \u0040 as "code points" not
characters). Glyphs are shapes drawn on screen. Some correspond to
characters, but some are not characters, rather they are marks designed
for combining with other glyphs (eg, you could make a e with a grave
accent by combining the glyph for a regular 'e' with a glyph for the
grave (roughly '`' )).
Unicode also has invalid regions, characters (code points) which do not
map to any character. Partly this is because unicode is still evolving,
eg, Apple implement 2.1 in cocoa, but if you go to www.unicode.org
you'll mostly find info on Unicode 3.1. The allocations have moved
around over time.
Some fonts aren't Unicode. eg, Windings. It actually places characters
in regions which are invalid in Unicode 2.1! They shouldn't be there,
but they are.
Then you have 16 bit unicode vs. 32 bit (or any other size). Cocoa
mostly uses 16 bit Unichars. Some glyphs defined in fonts shipping with
Mac OS X (The Hiraganos for one example) have glyphs (combining glyphs
as I mentioned above, I believe) which are only addressable using
Unicode characters above 65526 (ie larger than 16 bit).
Anyway, one thing you should definatey take away is that the numbers
used to represent the Glyphs (NSGlyph) have *no dependable relationship*
to character values (Unicode code points). The second link above gives
many examples, but in short, every font manufacturer has the ability to
assign *ANY* glyph number to any character.
So 'g' (unicode \U0067) might have glyph code 42 in one font and 22345
in another... you can't compare glyphs accross fonts.
You should also know that Cocoa *aggressively* substitutes fonts. If you
set a piece of text (eg, in a text field) to a font which doesn't have
all the characters it needs to display the text, Cocoa substitutes from
other fonts to make it display. You can't turn this off (at least, not
without subclassing).
--
AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside
I think we finally found the killer app for Flash: animated stick men
_______________________________________________
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.