Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 486734

Summary: [cocoa][10.11] bold/italic system fonts render with baseline too low
Product: [Eclipse Project] Platform Reporter: Markus Keller <markus.kell.r>
Component: SWTAssignee: Platform-SWT-Inbox <platform-swt-inbox>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: a.nesheret, arunkumar.thondapu, ivanooi, lshanmug, luo820802, mikael.barbero, mober.at+eclipse, p.beauvoir, peter, torkildr
Version: 4.5.1   
Target Milestone: 4.7   
Hardware: PC   
OS: Mac OS X   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=495097
Whiteboard:
Bug Depends on:    
Bug Blocks: 482454, 494879    
Attachments:
Description Flags
Screenshot
none
SnippetBold.java
none
Preference view
none
Another Snippet showing this in a Tree none

Description Markus Keller CLA 2016-01-28 10:43:20 EST
Created attachment 259435 [details]
Screenshot

OS X 10.11.3, 4.6.0.I20160127-2000 and 4.5.2.M20160127-1000

The bold and italic versions of the system font render with a baseline that is too low. Baseline should be at the same position as for normal font.

In Trees, this misaligns bold item labels with the triangle and cuts descenders.

Some non-system fonts have cut descenders in Trees all the time (all styles), e.g. Helvetica, Courier. Other fonts are fine, e.g. Monaco.

I think this only started in 10.10 or 10.11.

See bug 436773, bug 436774 for other problems with bold fonts.
Comment 1 Markus Keller CLA 2016-01-28 10:44:04 EST
Created attachment 259436 [details]
SnippetBold.java
Comment 2 Markus Keller CLA 2016-02-01 15:20:06 EST
(In reply to Markus Keller from comment #0)
> I think this only started in 10.10 or 10.11.

10.10 is still fine.

Let's not go to Apple's San Francisco :-(. Apart from making the system font hard to access, they also seem to have missed that different styles of the same font should work together. When I inspect the fonts in /System/Library/Fonts/ with Quick Look (Space key) or the Inspector (Command+Option+I), then the SFNS* fonts show quite some variation in baseline positioning. For normal fonts like Arial and Courier New (in /Library/Fonts/), that's not the case.

I don't really know how to tackle this. SWT's implementation in Font#init(..) looks pretty straightforward.
Comment 3 Lakshmi P Shanmugam CLA 2016-04-23 02:49:22 EDT
May be we should open a bug with Apple.
This needs more investigation and will not be possible in 4.6 time frame.
Comment 4 Arun Thondapu CLA 2016-05-30 15:16:33 EDT
*** Bug 494547 has been marked as a duplicate of this bug. ***
Comment 5 Torkild Resheim CLA 2016-05-30 16:33:57 EDT
Created attachment 262118 [details]
Preference view

I see the same problem using the normal variation of the font. This on:

Eclipse IDE for Eclipse Committers

Version: Neon Release Candidate 2 (4.6.0RC2)
Build id: 20160526-1324

However I only see it in the navigator for the preference view. Not in the "Package Explorer" or the "Project Explorer".
Comment 6 Markus Keller CLA 2016-06-01 14:34:28 EDT
(In reply to Torkild Resheim from comment #5)
> I see the same problem using the normal variation of the font.

That's bug 495097.

> However I only see it in the navigator for the preference view. Not in the
> "Package Explorer" or the "Project Explorer".

The Package Explorer and Project Explorer views use custom draw to render colorized labels. Looks like this only affects native label. Please add your OS X version in bug 495097.
Comment 7 Mikaël Barbero CLA 2016-07-26 04:02:49 EDT
*** Bug 498394 has been marked as a duplicate of this bug. ***
Comment 8 Mikaël Barbero CLA 2016-07-26 04:15:00 EDT
I've tried to remove the call to super.drawInteriorWithFrame_inView in Tree.drawInteriorWithFrame_inView and reuse the logic when "userForeground != null" to draw the text myself. Despite several tests, I did not manage to change the location of the bold text. 

I've also tried to add attribute NSBaselineOffsetAttributeName to the cell's NSAttributedString. Again, no visible effect :(. 

I will try some more things in Obj-C to see how it behaves and check wether the issue is from Apple or the SWT impl.
Comment 9 Mikaël Barbero CLA 2016-07-26 07:51:29 EDT
I've tried an NSOutlineView with bold font directly in a Obj-c Cocoa application, and the issue does not appear with system fonts (OS X 10.11.6 - San Francisco). However, as soon as I switched to another font (e.g. Helvetica Neue), the issue appears. In the native app, the font is set directly on the NSTextFieldCell. I've also tried to do that directly in Tree.drawInteriorWithFrame_inView, with the bold system font, but it does not fix the issue. Like Markus, I don't know how to tackle this.
Comment 10 Phil Beauvoir CLA 2016-10-16 04:55:37 EDT
Created attachment 264877 [details]
Another Snippet showing this in a Tree

Seeing this now in my RCP application for Mac OS X in Trees and Tables.
Comment 11 Lakshmi P Shanmugam CLA 2017-01-27 07:11:12 EST
The problem is bold font is fixed via Bug 481144. The problem with italic font is tracked via 510741

*** This bug has been marked as a duplicate of bug 481144 ***