• 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: NSFont reports different -capHeight in 10.4.4 than in previous OS versions?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSFont reports different -capHeight in 10.4.4 than in previous OS versions?


  • Subject: Re: NSFont reports different -capHeight in 10.4.4 than in previous OS versions?
  • From: Aki Inoue <email@hidden>
  • Date: Mon, 20 Feb 2006 15:17:39 -0800

Izidor,


Anybody knows whether this new behaviour is a bug or will it stick and we need to workaround it ourselves ?
In short, yes, this new behavior is a result of fixing long standing issues in the way NSFont query basic metrics, and will stick going forward.

Historically -[NSFont capHeight] was just returning -[NSFont ascender] (now it returns what the rest of system uses for the cap height).

Aki

Hello!

It has been brought to my attention that our application using NSFont behaves differently in 10.4.4 (and 10.4.5) than in previous OS X versions.

That causes trouble, since if documents created on one computer are later edited on other computer with different OS version, all kinds of problems emerge...

The application calculates the area for text box using (among others) -[NSFont capHeight]. Documents created on Mac with OS X version 10.4.3 (we are told) or earlier (also Panther - this we have verified ourselves) have different bounding boxes for text than documents in 10.4.4 (and 10.4.5).

I have done some brief testing (NSLog-ing) and it turns out that NSFont's capHeight is returning different values now than it did previously. E.g. for Helvetica 12pt, it is now 9.00, and in Panther it was 9.24. The changes are also for custom (non-system) fonts.

If you search with google "mac os x helvetica capheight", you get some PostScript documents with /Ascent 770 and /CapHeight 0, which just about explains capHeight 9.24 if you take /Ascent for its substitute (0.77 * 12 = 9.24). How this became 9.00 in 10.4.4 we have no idea...

Anybody knows whether this new behaviour is a bug or will it stick and we need to workaround it ourselves ?

Thanks for any info,

izidor

P.S. Not all is bad with 10.4.4 - it has a corrected [NSFont fontWithName:matrix:] behaviour. Thanks for that. But this new capHeight is not good at all.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >NSFont reports different -capHeight in 10.4.4 than in previous OS versions? (From: Izidor Jerebic <email@hidden>)

  • Prev by Date: Re: Sorting array of strings by string length
  • Next by Date: Custom object in core data.
  • Previous by thread: NSFont reports different -capHeight in 10.4.4 than in previous OS versions?
  • Next by thread: Universal Binary build problem
  • Index(es):
    • Date
    • Thread