Bizarre behaviour of NSFontDescriptor and/or NSCharacterSet
Bizarre behaviour of NSFontDescriptor and/or NSCharacterSet
- Subject: Bizarre behaviour of NSFontDescriptor and/or NSCharacterSet
- From: Brian Schack <email@hidden>
- Date: Mon, 31 Jan 2011 20:08:12 -0700
I have a small application that exhibits behaviour so strange that I
can't even begin to explain what bug might possibly be responsible for
it. I'm thinking of submitting a bug report to Apple, but first I'd
like someone else to take a look at it to see if I haven't made some
silly mistake or assumption.
The application in question finds the set of fonts that can represent
the characters in a string (ie, 'give me all the fonts that can display
these characters: "0123456789"'). The core function is:
NSArray *fontsWith(NSString *str)
{
NSCharacterSet *cset =
[NSCharacterSet characterSetWithCharactersInString:str];
NSDictionary *attributes =
[NSDictionary dictionaryWithObjectsAndKeys:cset,
NSFontCharacterSetAttribute, nil];
NSFontDescriptor *descriptor =
[NSFontDescriptor fontDescriptorWithFontAttributes:attributes];
return [descriptor matchingFontDescriptorsWithMandatoryKeys:nil];
}
The function usually behaves as I'd expect. If I give it a short
string, it returns a large number of fonts. As I add characters, it
finds fewer fonts that have glyphs for those characters.
The following is a list of strings passed in and number of fonts
returned from fontsWith() (where x and y vary depending on the number of
fonts on your system, and y < x):
@"." => x fonts
@".z" => y fonts
As you would expect, including two dots instead of one makes no
difference:
@".." => x fonts
@"..z" => y fonts
Now, for the strangeness. Consider the following two strings:
@"................................................................"
@"...............................................................z"
Each is 64 characters long. You would expect to get exactly the same
answers with them as you would with @"." and @".z". And you do, but
*only* if you run the program separately for each string. If the
program has two consecutive calls to fontsWith(), here's what you get:
@"................................................................" => x
@"...............................................................z" => x
Both return the same answer! And if I reverse the calling sequence:
@"...............................................................z" => y
@"................................................................" => y
I get y and y, instead of y and x!
Note that if I remove one dot from each of the strings, making them 63
characters long, then I get the proper results. There seems to be
something magical about that 64th character, but I have no idea what it
is. Remember that the string is converted to a character set. I've
checked the sets, and they report that they contain exactly one
character (".") for the first string, and two ("." and "z") for the
second. The original length of the string should have absolutely no
effect on the result returned by fontDescriptorWithFontAttributes, but
it seems to.
I've run the program on two different systems, and had the same results.
I've searched the net but found no other reports of this problem. Can
anyone explain what is going on?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden