• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSAttributesString -size is often very innaccurate
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSAttributesString -size is often very innaccurate


  • Subject: Re: NSAttributesString -size is often very innaccurate
  • From: Quincey Morris <email@hidden>
  • Date: Thu, 29 Jan 2009 23:44:37 -0800

On Jan 29, 2009, at 22:46, Graham Cox wrote:

This is a problem because if I mark an area for update based on this bounds, as I frequently do, bits of characters can get left on screen. For example changing a text item's font size from say 24 to 12 with Zapfino, an insufficient area is updated, leaving the edges of the larger font behind. I don't want to update more than I have to so I need a way to figure out the true extent of the drawn marks.

I should mention I'm just drawing isolated attributed strings using - drawAtPoint here, not long runs of laid-out text.

It would be worth finding out if the minY and maxY of the bounding box depend at all on which characters you draw. For example, if you draw only lowercase letters with no ascenders or descenders, are the top and bottom of the bounding box the same as if you draw uppercase letters, or letters with descenders?


In a font API (not necessarily Mac OS X, but in general), you can get weird results for various possible reasons:

-- It might be a documentation bug, and the function actually returns the line layout bounds, instead of the glyph bounds.

-- The text measuring code might use a shortcut (such as using the font's cap height, ascender height and descender depth) to avoid having to calculate the real bounding box of arbitrary glyphs. (In which case, there *might* be a slower, more accurate function you could call.)

-- The API implementation might mis-use font metrics stored in the font itself.

-- The metrics in the font file might be incomplete or inconsistent or incorrect.

Historically, all of these things have been very common.


_______________________________________________

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


References: 
 >NSAttributesString -size is often very innaccurate (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: bind right part of NSPredicateEditor's row to array of strings
  • Next by Date: Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]
  • Previous by thread: Re: NSAttributesString -size is often very innaccurate
  • Next by thread: Serial IO seems to be starving UI
  • Index(es):
    • Date
    • Thread