Re: NSGlyph is still a puzzle
Re: NSGlyph is still a puzzle
- Subject: Re: NSGlyph is still a puzzle
- From: Aki Inoue <email@hidden>
- Date: Tue, 22 Jan 2002 23:09:16 -0800
Andy,
As Doug previously responded, the glyph id is only meaningful respect to
the font. They are merely indices into the linear glyph data array in
TrueType sense.
So, in your case, the glyph id you get from NSLayoutManager might not be
for the current font you set up its NSTextStorage with since the font
substitution might have been already kicked-in.
For example, for a Unicode character that's not supported with your
current font, NSLayoutManager returns glyph id, say 10, for the
substituted font. Now, your current font might encode the glyph id 10,
but for an entirely different Unicode character.
So, by commenting out -glyphIsEncoded: comparison, your code ends up
comparing the font attribute for every single character in NSTextStroage
with the current font. That's the best way you can do right now.
I'm not sure I understand this. I guess since I'm iterating over a lot
of code points this will be happening to me... I wouldn't have picked up
from the current documentation that its something I need to handle.
For example, if you try to map the tab character U0009, the glyph id for
that character is always NSControlGlyph.
BTW - are the docs accurate when they say Cocoa/OS X is Unicode 2.0,
not 3.0?
Both Carbon & Cocoa in 10.1 are based on the Unicode 2.x standard with a
few components supporting beyond that.
Note that the surrogate (32bit) specification is actually a part of the
Unicode 2.x standard. It's only that the version 3.1 actually started
assign characters beyond the 16bit range.
Aki
On 2002.01.22, at 22:14, Andy wrote:
Aki Inoue wrote:
Andy,
Exactly what was your problem with -glyphIsEncoded: method ?
The current implementation just checks (glyphID >= 0) && (glyphID <
[font numberOfGlyphs]) since the SFNT specification (which both
TrueType & OpenType are based on) guarantees that (it was interesting
to
check each glyph id in DPS).
Ah, then maybe I'm just misinterpreting the meaning of the method. As
you can see I'm trying to generate every glyph for each code point from
0000 to FFFF in pages of 256 at a time. I can post the whole method, or
indeed I will try to release the whole program + source soon.
For each glyph I get, I was asking the current font -glyphIsEncoded. If
it returns true, I'd render the UniChar in an NSCell set to use that
font. My problem is that in many cases -glyphIsEncoded would return
true, but when the program runs the cell would substitute in a character
from another font (often some special system font called "Last Resort".)
Only when I switched to detecting the fact the font had been substituted
did I get reasonable looking results.
The annoying thing about the loop I have is its a bit indirect. I get a
unichar for a code point, put it into a text storage, generate a glyph,
check if it is encoded (or detect font substitution as I do now). If I
conclude the font can show the unichar, I put that unichar into a string
and set it as the NSCell's title... ie, I end up ignoring the
NSTextStorage - its only used to work out if I think the font can
display the char, not to actually display to the screen.
Now, it is possible that NSLayoutManager contains NSControlGlyph (used
for housekeeping special characters such as tabs, paragraph separator,
attachment, and so on), in that case, [font
glyphIsEncoded:NSControlGlyph] could fail.
I'm not sure I understand this. I guess since I'm iterating over a lot
of code points this will be happening to me... I wouldn't have picked up
from the current documentation that its something I need to handle.
That said, the characters which report false positives include many
"regular" characters.
About disabling the font substitution. You could disable by
subclassing
NSTextStorage & overriding -fixFontAttributesInRange: method (since
NSTextStorage is a class cluster, it's a little bit hard. Refer to the
header comment in NSTextStorage).
I may try this at some point, but its a little more than I need right
now I think.
In any case, your strategy to determine supported Unicode character
point doesn't work.
For example, the Hiragino font family shipped with 10.1 contains
thousands of glyphs that can be accessible only via surrogates (Unicode
code range beyond 16bit). I intend to address the problem in a future
release.
That would be cool. Obv. I'm aware unicode extends beyond 16 bit, but I
guess there's not much I can do about that right now.
BTW - are the docs accurate when they say Cocoa/OS X is Unicode 2.0,
not 3.0?
Thanks for your help.
--
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.