Re: Fonts in TableView
Re: Fonts in TableView
- Subject: Re: Fonts in TableView
- From: Quincey Morris <email@hidden>
- Date: Sat, 05 Nov 2016 23:18:07 -0700
- Feedback-id: 167118m:167118agrif8a:167118sP_XYQLTjA:SMTPCORP
On Nov 5, 2016, at 21:44 , Gerriet M. Denkmann <email@hidden> wrote:
>
> NSRect boundingRect = tableFont.boundingRectForFont;
> self.outlineView.rowHeight = ceil( boundingRect.size.height )
This is probably a poor choice, for reasons that probably will seem illogical:
1. The bounding box height supposedly reflects the actual glyphs of the font, and this may not be the intended (designed) inter-baseline distance for a multiline passage of text. (It’s for a multiline passage because that’s what the designer is supposed to design for.) It may not be intended because of outlier glyphs whose dimensions were never intended to affect line spacing.
2. In any case, the bounding box stored in the font might be a lie. It might be the bounding of a subset of the glyphs (to avoid including the outlier shapes), or it may have been flat-out adjusted for historical reasons. (It’s not clear whether Apple font technology reports the bounding box stored in the font, or tries to recalculate the bounding box exactly.)
3. The stored bounding box might be family-wide, rather than face-wide.
4. Even if the bounding box height is near-enough correct for the font design, it matters where the baseline is placed within the height. That in turn, depends on values stored in the font, and/or assumptions made by the software using it. (To be specific, where in the row height the table view decides to put the origin of the text field.)
5. It’s rather indeterminate what glyphs the bounding box should reflect. In particular, in digital typography using Unicode characters, a font as perceived by the user may be a composite of multiple actual fonts. For example, there’s likely code in the text system that provides a Euro glyph for every font that doesn’t have it.
There is probably no perfect strategy that works for every font. However, for the kinds of design decisions that Apple made when it started doing typography properly (in the early 1990s, the days of the Font Wars between Apple and Microsoft), I recommend you use the following calculation to compute the line height of text:
line height = font ascender + font descender + font leading
using the 3 values reported by the NSFont. (I can’t remember, the descender may be negative, in which case you’d invert the sign.) Depending on your goals, you might also add some margin above and below the line height (1 or 2 points top and bottom) to prevent your rows from looking cramped.
Alternatively, it is possible to use auto-layout to determine the height of the cell without caring specifically about the cell’s structure. (I mean a cell view, not a NSCell.) I’ve done this for dynamically sizing rows, but the same strategy could be used to find out the height once, at table view setup. You'd end up with whatever NSTextField would do, which is presumably acceptable regardless of font.
_______________________________________________
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