On Nov 5, 2016, at 21:44 , Gerriet M. Denkmann <[email protected]> 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 protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
