Re: Why do all these methods of measuring string metrics with font attribute fail?
Re: Why do all these methods of measuring string metrics with font attribute fail?
- Subject: Re: Why do all these methods of measuring string metrics with font attribute fail?
- From: an0 <email@hidden>
- Date: Thu, 4 Sep 2008 21:27:39 +0800
On Thu, Sep 4, 2008 at 11:33 AM, Peter Ammon <email@hidden> wrote:
>
> On Sep 3, 2008, at 6:01 AM, an0 wrote:
>
>> I should declare up front that I know there are some arcane ways to
>> measure string metrics using things like NSTextStorage,
>> NSLayoutManager and the kin.
>> Given the string and the font used to render it, it is reasonable
>> there should be some straightforward way to tell the metrics of the
>> string when laid out in one line. Actually, I thought I'd found
>> several after reading through the docs; however, all of them turned
>> out to be very miserable.
>> Here goes what I've tried, with the effects in comments:
Then what about boundingRectForFont? Why is it so large?
>> NSFont *font = [NSFont labelFontOfSize:12]; // I put the string in a
>> label
>> NSRect fontRect = [font boundingRectForFont]; // too large
>
> This is measuring how much space it would take to render any single glyph.
> This isn't what you want for measuring text.
>
>>
>> NSRect glyphRect = [font boundingRectForGlyph:'W']; // too too small
>
> Glyphs are not the same thing as characters, and you cannot pass one in
> place of the other. The ASCII value of a character is not related to its
> glyph value. For example, the glyph corresponding to "W" would be 58 in the
> font you were using.
Using 58 for 'W' seems to make no difference here, the resulting glyph
height is still unreasonably small.
>
> (In fact, you should not think about "glyph value of a character" at all.
> Some characters have no glyphs, like space; sometimes multiple characters
> produce a single glyph, like an fi ligature.)
>
> In order to generate glyphs from characters, you should use the methods in
> NSLayoutManager. However, as you know, this is overkill for simple text
> measurements.
>
>> IMO, the size of a string with font attribute is an intrinsic property
>> determined only by the string and the font(and the layout of the
>> string on the view, but here let's fix the layout to one single line);
>> and the view used to render the attributed string should have a
>> reasonalby bigger size to hold the whole string. In other words, one
>> could have a good guess of the view size from the attributed string
>> size.
>>
>> So, if my understanding of these two metrics is right, how can they
>> differ so much? Was I using the wrong APIs?
>>
>> If my understanding is wrong, can you tell me what's the exact
>> relationship between these two metrics?
>
> You were using the wrong APIs. To find the size of a string, use -[string
> sizeWithAttributes:]. To find the "natural" size of a control whose content
> is some string, use -[[textField cell] cellSize]. As you surmised, the
> control's natural size is often "reasonably bigger" than the content - but
> it may not be, if the control is fixed size (such as a circular button).
>
So, it seems -[string sizeWithAttributes:] is the only API that gives
a reasonable size of string. But I'm wondering what all the other APIs
listed above are for. If they give no useful information for
application programmers, why does Apple expose them to confuse us?
> If you just want a control to be big enough for its content, set the content
> on the control and then call -[control sizeToFit].
>
> Hope this helps,
> -Peter
>
>
_______________________________________________
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