Brian, The font descriptor here describes a query matching font descriptors containing the character set equals to the supplied set. Since it's unlikely to have fonts with just "0123456789", for example, it should return 0 result.
If you're seeing something different, please file a bug. To what you're trying to accomplish, you can first create a list of all available font descriptors (CTFontCollectionCreateFromAvailableFonts & CTFontCollectionCreateMatchingFontDescriptors or NSFontManager), compare NSFontCharacterSetAttribute to your character set with -isSupersetOfSet:. Aki On 2011/01/31, at 19:08, Brian Schack wrote: > 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/aki%40apple.com > > This email sent to a...@apple.com _______________________________________________ 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com