Re: NSGlyph is still a puzzle
Re: NSGlyph is still a puzzle
- Subject: Re: NSGlyph is still a puzzle
- From: Andy <email@hidden>
- Date: Wed, 23 Jan 2002 01:14:36 -0500
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