Re: NSGlyph is still a puzzle
Re: NSGlyph is still a puzzle
- Subject: Re: NSGlyph is still a puzzle
- From: Andy <email@hidden>
- Date: Tue, 22 Jan 2002 19:33:52 -0500
Douglas Davidson wrote:
>
>
>
A single NSGlyph corresponds to a single glyph in the font. Exactly how
>
this works in practice depends on the font. If a font contains a single
>
glyph for a composed form like an accented a, then that glyph will
>
probably be used. If a font does not contain a single glyph for that
>
composed form, but instead contains separate glyphs for the a and the
>
accent, then two NSGlyphs will be generated, one for the a and one for
>
the accent, and typesetting will position them properly with respect to
>
each other. You will notice that there are many, many combining
>
characters in Unicode, so it is impossible that composed glyphs should
>
be available for all possible combinations, or even all relevant and
>
useful combinations. This is one of the reasons why conversion between
>
characters and glyphs is many-to-many.
Actually, I've also been writing code that uses NSGlyphs. As I'm working
on a font inspection tool, I've ended up with this fun code, based on
idea I got from this list and much experimention:
i is a loop index, layoutManager is attached to tsCharsOnPage, which is
an NSTextStorage:
glpCurrent = [layoutManager glyphAtIndex: i isValidIndex: &validIndex];
// glyphIsEncoded: is slow and inaccurate...
if (validIndex /*&& [m_currentFont glyphIsEncoded:
glpCurrent]*/) {
//valid so far
currRange.location=i;
title = [[tsCharsOnPage string] substringWithRange: currRange];
actualFont = [[tsCharsOnPage fontAttributesInRange:
currRange] objectForKey: NSFontAttributeName];
//so instead of checking for encoded, just detect
substitution instead
if (title == nil || [title length] <= 0 ||
![m_currentFont isEqual:actualFont]) {
validIndex=NO;
}
As you can see, I've given up on NSFont -glyphIsEncoded: because it is
wildly innaccurate in practice. Infact, it seems to do something akin to
checking if cocoa can support the character, taking into account all
possible font substitutions. While this is certainly a very useful piece
of information, its useless for a font inspector - I want to know if the
font I have encodes the given char!
So as you can see I've taken to detecting cocoa's font substitution
habits after they have been applied and simply discarding any characters
where this has occured.
I'm thinking of filing 2 bug reports. 1 feature request saying "please
let me turn off font substitution where I don't need it like Carbon
ATSUI does" and the other saying "glyphIsEncoded: is broken". Any
thoughts before I do?
--
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