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

Reply via email to