• 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: Font Size Problem in NSTableView
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Font Size Problem in NSTableView


  • Subject: Re: Font Size Problem in NSTableView
  • From: "Michael J. Bergin" <email@hidden>
  • Date: Thu, 4 May 2006 11:41:26 -0400

I tested the example below with a few different fonts, including Ayuthaya 18-72, and it works. The drawInRect:withAttributes method of NSString seems to draw the text positioned with its baseline at the bottom of the rect causing the descenders to be clipped so you have to use drawAtPoint:withAttributes to get the correct positioning.


(Create an NSView subclass and paste this method into the implementation file to see it work.)


- (void)drawRect:(NSRect)aRect
{
	NSLayoutManager		*lm;
	NSFont					*font;
	NSRect					bounds;

	lm = [[NSLayoutManager alloc] init];

	font = [NSFont fontWithName:@"Ayuthaya" size:18];
	bounds = [self bounds];
	bounds.size.height = [lm defaultLineHeightForFont:font];
	[self setFrame:[self convertRect:bounds toView:[self superview]]];

	[NSGraphicsContext saveGraphicsState];

	[[NSColor blueColor] set];
	[NSBezierPath strokeRect:bounds];

	[@"jJpP" drawAtPoint:NSMakePoint(0, 0) withAttributes:
		[NSDictionary dictionaryWithObjectsAndKeys:font, NSFontAttributeName,
			nil]];

	[NSGraphicsContext restoreGraphicsState];
}


- Michael J. Bergin email@hidden Odology, inc. www.odology.com

  Launch any app, anywhere, in under a second
  Launcher by Odology
  www.odology.com/launcher


On May 4, 2006, at 3:23 AM, Mike Wright wrote:


On May 2, 2006, at 12:41, email@hidden wrote:

Message: 14
Date: Tue,  2 May 2006 10:32:13 -0700
From: David Emme <email@hidden>
Subject: Font Size Problem in NSTableView
To: Cocoa-Dev List <email@hidden>
Message-ID:
	<r02010500-1046-9801F338DA0111DA87CA0030653DBC32@[192.168.1.2]>
Content-Type: text/plain; charset=US-ASCII

I have an NSTableView with two text columns, both set to Lucida Grande
11 in IB. The first column is not user-modifiable and the font does not
change. The second column is user-modifiable, via a separate
NSTextField, and the user is allowed to change the font, font size, and
color of these attributed strings.


I am trying to get the NSTableView to respond "properly" to these
attributed strings with differing font properties. I go thru each
attributed string, getting the font information for each range and
computing a row height for that string as MAX(ascender - descender +
leading) (plus 1 for good measure :-). I then send the NSTableView a
setRowHeight: with the largest computed row height (since I can't see
how to set the row heights for individual rows).

This seems (by eye) to produce row heights of an appropriate size.
However, the baseline seems too low for some non-Lucida-Grande rows, and
some fonts, especially those larger than the default 11 point, have
their descenders clipped, while having what seems to be more than enough
white space at the top of the NSTableView cell. The strings with Lucida
Grande 11 stay at the tops of their cells, but those with other fonts
seem to move too far to the bottoms of their cells.


I'm not doing any custom drawing in the problem cells; I'm just setting
the cell contents to the NSAttributedString in a datasource method:


- (id)tableView:(NSTableView *)tableView
objectValueForTableColumn:(NSTableColumn *)column row:(int)row
{
    NSString * identifier = [column identifier];
    Reminder * rem = [reminderDoc reminderAtIndex:row];
    id answer = [rem valueForKey:identifier];
    return answer;
}

Is there something I can do to have these attributed strings drawn
without this clipping?

TIA,
-Dave

It seems that this question didn't really get resolved. There are definitely fonts that appear to place what should be the baseline at the bottom of the font bounding box--or even lower. If anyone doubts this, try Ayuthaya 18 in a text field with a height calculated either by ascender + leading - descender, or by - defaultLineHeightForFont:.


I have an approach that I came up with by trial and error. I use it to calculate table row heights, and it seems to work pretty well. Some fonts, like the aforementioned Ayuthaya 18 (which has zero leading, by the way), draw with the descenders just barely inside the frame, with a big chunk of white above the text, but at least they don't get truncated.

Here's how I calculate row height:

// create new font based on settings, with NSString *fieldsFontName and float fieldsFontSize
NSFont *newFont = [NSFont fontWithName:fieldsFontName size:fieldsFontSize];

// make some adjustment for fonts with low baseline
float ascender = [newFont ascender];
float leading = [newFont leading];
float descender = (-[newFont descender]);
float rowHeight = ascender + descender + leading + (fieldsFontSize / 4.0) + 0.5;

// make sure that we don't end up with something really stupid
float defaultLineHeight = [newFont defaultLineHeightForFont];
if (rowHeight < defaultLineHeight)
rowHeight = defaultLineHeight;

// set the row height
[listTableView setRowHeight:rowHeight];


It's not very pretty, because it doesn't have any theory behind it. I just kept hacking around with it until I got something that consistently produced acceptable results. For standard fonts, this approach produces what I consider to be a reasonable amount of white space above and below the text.

To see how it works, try downloading iData 2.1.8 at <http:// www.idata2.com/download_idata.html> (it will run as a demo for 30 days), open Sample Field Datafile, go to the Format menu, select Set Font for Fields, and try a variety of fonts. 18 points or larger will make the problem clear. Lucida Grande fits nicely, Ayuthaya doesn't. Compare how bad Ayuthaya 18 looks in the Set Font for Fields dialog text field. In fact, you can just click around in the Fonts Panel and watch how the text field baseline shifts for various fonts.

Oddly, if you type "yyy yyy" in the NSTextView below the fields and set part of it to Ayuthaya 18 and part to Lucida Grande 18, the baselines match nicely. This implies that NSTextView knows something that I don't. Anyone know what that might be? (Or could it be that it just knows something that NSTableView and NSTextField don't know?)

Cheers,
Mike Wright
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40odology.com


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: 
 >Re: Font Size Problem in NSTableView (From: Mike Wright <email@hidden>)

  • Prev by Date: Re: Animated split view collapsing
  • Next by Date: Equivalent of isKindOfClass for Foundation Types?
  • Previous by thread: Re: Font Size Problem in NSTableView
  • Next by thread: Re: Font Size Problem in NSTableView
  • Index(es):
    • Date
    • Thread