Re: Bizarre behaviour of NSFontDescriptor and/or NSCharacterSet
Re: Bizarre behaviour of NSFontDescriptor and/or NSCharacterSet
- Subject: Re: Bizarre behaviour of NSFontDescriptor and/or NSCharacterSet
- From: Aki Inoue <email@hidden>
- Date: Tue, 1 Feb 2011 12:33:31 -0800
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 (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
_______________________________________________
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