site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (darwin) 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.apple... This email sent to site_archiver@lists.apple.com