Community
Participate
Working Groups
Created attachment 257659 [details] name.baz - issue occurs Beginning with Mac 10.10, the text is lowered in some controls, sometimes to the point that font descenders are cut off. The issue does not occur on Windows or in prior versions of Mac OS X. The issue appeared when we installed our mature RCP applications on Mac 10.10 and Mac 10.11. At first I presumed we were doing something wrong. But I managed to create a SSCCE using the project templates provided by "Eclipse for RCP and RAP developers." == EXAMPLE == This problem is illustrated by the *.png attachments, and reproducible with the corresponding SSCCE plug-in projects mostly generated by "New Plug-in Project" in "Eclipse for RCP and RAP developers" version 4.5.1. * name.foo was generated with the template "RCP 3.x application (minimal)." * name.baz was generated with the template "RCP 3.x Mail Template." The same three preference page classes were added to each, and specified in plug-in.xml. No other changes were made to the projects. In this example, the issue occurs with name.baz, but not with name.foo. * Observe the font descenders in the list of page titles. * Observe the more subtle lowering of the text in the commit buttons. == OBSERVATIONS == * The issue does not occur in the Eclipse IDE. * Our applications are using the Eclipse 3.x compatibility layer. * Our applications continue to work correctly on Windows and prior versions of Mac OS X. * With the SSCCE, the same behavior occurs with both 4.5 and 4.5.1 as targets. * The issue occurs with more than just the controls presented in the example.
Created attachment 257660 [details] name.foo - issue does not occur
Created attachment 257661 [details] name.baz project folder
Created attachment 257662 [details] name.foo project folder
Also visible in 4.6 using the DSL and Parallel packages (and I suspect other packages). I see this behavior only after the *second* time Eclipse is started, and it is visible in the main preference page as well as project preferences. The first time Eclipse is launched, the problem is not apparent. I think this should be made high priority as it makes Eclipse look pretty second rate, IMHO.
Created attachment 263029 [details] Preference page on first launch
Created attachment 263030 [details] Preference page on second launch
I can reproduce in Eclipse Neon, on Mac Os X El Captain. I think the issue makes Eclipse less ergonomic and less aesthetically appealing.
One further question: is the readability improving if you restart Eclipse ?
(In reply to Patrik Suzzi from comment #8) > One further question: is the readability improving if you restart Eclipse ? No. Further restarts do not resolve the problem. Also, if I restart and select a different workspace, the problem persists.
Is this something for SWT ?
I don't know. I've only seen the problem affecting the main tree widget in the preference and properties pages. Other trees within these pages seem to be ok, so I don't know if it's just because these are different somehow, or it's happening higher up than SWT.
Created attachment 264116 [details] Buttons I also see the problem on buttons. The attached screen shot shows the button text slightly lower than it should be.
Created attachment 264117 [details] Import screen Import screen showing issue
Created attachment 264118 [details] Import screen without issue
Interestingly it appears that if you do File -> Switch Workspace then the problem disappears until the next restart. You can see this by comparing the buttons in the following screenshots: https://bugs.eclipse.org/bugs/attachment.cgi?id=264117 https://bugs.eclipse.org/bugs/attachment.cgi?id=264118
A little more analysis. The following always fails: $ ./Eclipse.app/Contents/MacOS/eclipse Select workspace View preferences The following always works: $ ./Eclipse.app/Contents/MacOS/eclipse -data /Users/pwebb/Documents/workspacetest View preferences It appears that when the select workspace dialog is show the problem appears, otherwise it does not.
Perhaps it's related to the new "recent workspaces" pull down that's now on that dialog (and wasn't in Mars)
After quite a bit of investigation the root cause seems to be the construction of a new Font from FontData that has a null nsName. To reproduce with minimal calls: - Edit org.eclipse.ui.internal.ide.ChooseWorkspaceDialog.java as follows: private void createRecentWorkspacesComposite(final Composite composite) { FontData[] fontData = composite.getFont().getFontData(); for (FontData element : fontData) { element.setStyle(element.getStyle()); } Font font = new Font(composite.getDisplay(), fontData); font.dispose(); if (true) return; --- (previous code) - Launch the Eclipse Application (but edit the run config to remove an Loation default) - Make sure the "Switch Workspace" dialog appears - Click OK - Open the preferences dialog to see the issue. For some reason an early call to NSFont.fontWithName(family, size); looking up ".SF NS Text" causes the issue.
*** Bug 496770 has been marked as a duplicate of this bug. ***
*** Bug 495097 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/83175
I've submitted a patch for review at https://git.eclipse.org/r/#/c/83175/ that I think will fix this one and https://bugs.eclipse.org/bugs/show_bug.cgi?id=486734. The problem is pretty interesting and I think it could be considered a bug in Cocoa. It appears that when you call `NSFont.systemFontOfSize` on El Capitan you get back a reference to the "San Francisco" font. This font is not a regular font, it uses the name ".SF NS Text". Rendering of that font always seems fine, it's spaced correctly and looks right. If, however, you start to manipulate it to add a 'bold' trait by using `convertFont` then the resulting font has an odd baseline. Although it renders, the text is always too high. I've noticed this on Eclipse Mars when searching for text in the preference dialog, but never thought much of it. Now the really interesting thing is that calling `NSFont.fontWithName(".SF NS Text")` sometimes returns a good result, and sometimes returns a bad one. As far as I can tell, the result is good up to the point that `convertFont` is called, then it starts returning bad results. In Eclipse Mars, this wasn't a big problem because, luckily, calls were made and Fonts were cached before any bold conversion took place. With the introduction of the new "Select workspace" option on the welcome screen, a bold font is created early and all subsequent fonts are messed up. The way I've worked around the problem is to update the `Font.init` method to work out if it should get a fresh system font, or lookup the font by name. If the `name` starts with "." and matches the system font name that would be returned at the same size, the system font is used in preference. I've also needed to update the logic that applies or removes the "bold" and "italic" traits.
(In reply to Phillip Webb from comment #22) > I've submitted a patch for review at https://git.eclipse.org/r/#/c/83175/ > that I think will fix this one and > https://bugs.eclipse.org/bugs/show_bug.cgi?id=486734. > > The problem is pretty interesting and I think it could be considered a bug > in Cocoa. Would it be a good idea to report this to Apple? (see https://developer.apple.com/bug-reporting/) They have fixed a few issues I reported in the past.
I've submitted the issue to Apple (bug 29072942). I don't expect that they'll get to fixing it soon so it might be nice if my suggested fix could be reviewed for the next Eclipse service release.
It would be great to have this fixed and included in Neon SR2.
New Gerrit change created: https://git.eclipse.org/r/84428
(In reply to Liviu Ionescu from comment #25) > It would be great to have this fixed and included in Neon SR2. Indeed! I have tested the patch and it looks good to me. But I am not a committer on SWT. Can someone help reviewing this? It would be good timing for Neon.2 RC1 on Friday.
Did this make it into Neon SR2? I know it seems like a minor bug but without this fix Eclipse looks so ugly on OSX.
(In reply to Phillip Webb from comment #28) > Did this make it into Neon SR2? I know it seems like a minor bug but without > this fix Eclipse looks so ugly on OSX. Not yet. A committer from SWT would need to look at the patch.
As requested I raised this issue with Apple, they wanted a small sample that replicated the issue which I was unfortunately unable to provide. The last comment from them was as follows: --- snip Engineering has requested the following information regarding your bug report: https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT/cocoa/org/eclipse/swt/graphics/Font.java#L329 -[NSFontManager convertFont:toHaveTrait:] on a font returned by -[NSFont systemFontOfSize:] is working properly, we just confirmed. But since you’re using a Java application and aren’t clear about how exactly does the “rendering” part happen, we can’t provide any help with this. Most likely you are getting the correct font from -[NSFontManager convertFont:toHaveTrait:] but using a wrong one for the actual rendering.
Latest update from Apple: https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT/cocoa/org/eclipse/swt/graphics/Font.java#L329 -[NSFontManager convertFont:toHaveTrait:] on a font returned by -[NSFont systemFontOfSize:] is working properly, we just confirmed. But since you’re using a Java application and aren’t clear about how exactly does the “rendering” part happen, we can’t provide any help with this. Most likely you are getting the correct font from -[NSFontManager convertFont:toHaveTrait:] but using a wrong one for the actual rendering.
According to the release schedule [1] Neon SR2 should be ramping down soon. Is there any way to please get this backported? [1] http://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Neon.2
if not, perhaps support for HiRes should be reverted until a proper solution will be available.
(In reply to Phillip Webb from comment #32) > According to the release schedule [1] Neon SR2 should be ramping down soon. > Is there any way to please get this backported? > > [1] http://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Neon.2 Sorry it is too late for 4.6.2. We first have to put and test the fix in master. We'll make sure it gets into 4.6.3.
Hi Phillip, Thanks for investigating this and providing a patch. I've added comments to your gerrit change.
In case people are coming to this bug looking for a quick solution, here is a quick description of a workaround: When you start Eclipse and you get the workspace prompt, select your workspace as usual but check "Use this as default and do not ask again". Click OK, then when Eclipse is fully started, quit Eclipse then start again. The key to the workaround is to not show the workspace prompt.
Thanks for posting your solution. I tried the workaround described in comment 36 https://bugs.eclipse.org/bugs/show_bug.cgi?id=481144#c36. For my system, this did not work. Mac OS X version 10.12.2 (Sierra). Eclipse: Version: Neon.2 Release (4.6.2) Build id: 20161208-0600 java.runtime.version=1.8.0_101-b13
(In reply to Michael Giroux from comment #37) > Thanks for posting your solution. I tried the workaround described in > comment 36 https://bugs.eclipse.org/bugs/show_bug.cgi?id=481144#c36. > > For my system, this did not work. > Mac OS X version 10.12.2 (Sierra). > > Eclipse: > Version: Neon.2 Release (4.6.2) > Build id: 20161208-0600 > java.runtime.version=1.8.0_101-b13 I tried this on 10.11.6 (El Capitan) and it works for me. Same Eclipse release.
Hi Phillip, It would be good to have this for M5 (which is next week) and then in 4.6.3. Do you plan to work on the gerrit comments?
@Lakshmi Yes, I've been meaning to try and find time to make the requested changes. I'll take a look today.
@Lakshmi I've added some comments to Gerrit. Unfortunately I can't get the `NSFont.boldSystemFontOfSize(size)` call alone to fix the issue.
(In reply to Phillip Webb from comment #41) > @Lakshmi I've added some comments to Gerrit. Unfortunately I can't get the > `NSFont.boldSystemFontOfSize(size)` call alone to fix the issue. Phillip, I don't see any comments in the gerrit patch. (https://git.eclipse.org/r/#/c/84428/)
(In reply to Lakshmi Shanmugam from comment #42) > (In reply to Phillip Webb from comment #41) > > @Lakshmi I've added some comments to Gerrit. Unfortunately I can't get the > > `NSFont.boldSystemFontOfSize(size)` call alone to fix the issue. > What is the testcase you are using to verify the fix. I tested with the Snippet in (https://bugs.eclipse.org/bugs/attachment.cgi?id=259436) from Bug 486734. Also, tested with the eclipse IDE.
New Gerrit change created: https://git.eclipse.org/r/89167
Gerrit change https://git.eclipse.org/r/84428 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=47b959189d2b46210153eb2c3b433e8ad3989ef4
Thanks for the patch Phillip! I've pushed the gerrit patch with a few small changes. Similar problem exists with text with italics style. I'll open a separate bug to track it.
(In reply to Lakshmi Shanmugam from comment #46) > Similar problem exists with text with italics style. I'll open a separate > bug to track it. Opened Bug 510741 to track this.
> Phillip, I don't see any comments in the gerrit patch I have a lot of trouble understanding gerrit, for some reason the comments are marked as draft. I'll paste them here: --- > Looks like this call - NSFont.boldSystemFontOfSize(size) - causes the baseline of the bold font to be set correctly. Having this call and removing the if block that sets the systemFont or boldSystemFont works for me. Can you check? That doesn't appear to work for me. If I comment out the if block I still see the lowered text. To test I : - Changed the run configuration and cleared the workspace location. - Ran the Eclipse (from Eclipse) - Made sure I got the workspace chooser dialog on start. - Selected Eclipse -> Preferences when the workspace was running The preferences tree shows the lowered font. > Do we need to check for name.startsWith(".") or just use the same code for any system font? I think we can drop the ".", I was just trying to minimize the impact of the fix my limiting when it applied.
> What is the testcase you are using to verify the fix. I tested with the Snippet in (https://bugs.eclipse.org/bugs/attachment.cgi?id=259436) from Bug 486734. Also, tested with the eclipse IDE. I just tested with the IDE. I'm not all that familiar with SWT programming so wasn't able to put together an isolated test.
(In reply to Phillip Webb from comment #48) > > Phillip, I don't see any comments in the gerrit patch > > I have a lot of trouble understanding gerrit, for some reason the comments > are marked as draft. I'll paste them here: > After saving the comments, click on Reply.. and then click Post. This will post the comments in gerrit. Verified the fix in build - I20170122-2000. (http://download.eclipse.org/eclipse/downloads/drops4/I20170122-2000/)
The change has only been released to master, but this bug was marked as fixed in 4.6.3. Reopening. An eventual backport should likely include the fix for bug 510741. download.eclipse.org/eclipse/downloads/drops4/I20170122-2000/testresults/html/org.eclipse.swt.tests_ep47I-unit-mac64_macosx.cocoa.x86_64_8.0.html has this new test failure: java.lang.AssertionError: Wrong font height expected:<10> but was:<13> at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_graphics_Font.test_getFontData(Test_org_eclipse_swt_graphics_Font.java:317) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:749) ...
(In reply to Markus Keller from comment #51) > download.eclipse.org/eclipse/downloads/drops4/I20170122-2000/testresults/ > html/org.eclipse.swt.tests_ep47I-unit-mac64_macosx.cocoa.x86_64_8.0.html has > this new test failure: > Fixed the test failure via http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=eb1b7832261ac0b6bdcac875f5b0f830d50e50e0
Pushed the fix to R4_6_maintenance branch --> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_6_maintenance&id=6ebd7c95a5ba339f6c549d8fb3a54caefd9400c5
*** Bug 486734 has been marked as a duplicate of this bug. ***
Although this bug is marked as Resolved, the problem still exists in Neon.3, and more troubling, the problem is still present in Oxygen. See attached screenshot from the preferences menu.
Created attachment 269258 [details] Oxygen preference menu w/ clipped fonts on Mac OS Illustrates that fonts are still being clipped in Mac OS with Oxygen. Mac OS Sierra, version 10.12.5.
(In reply to Michael Giroux from comment #55) > Although this bug is marked as Resolved, the problem still exists in Neon.3, > and more troubling, the problem is still present in Oxygen. See attached > screenshot from the preferences menu. This is unexpected, I don't see this behavior with Oxygen on macOS 10.12.5. Have you changed any font settings? Do you have any other plug-ins installed?
(In reply to Lakshmi Shanmugam from comment #57) > Do you have any other plug-ins installed? None that should be messing with fonts. However, while digging into the configuration to answer your question, I took a look at the Preferences -> General -> Colors and Fonts. I clicked "Restore Defaults" and the problem is resolved. I did not think to record the previous setting, but defaults seem to be working as expected.
(In reply to Michael Giroux from comment #58) > (In reply to Lakshmi Shanmugam from comment #57) > > Do you have any other plug-ins installed? > > None that should be messing with fonts. However, while digging into the > configuration to answer your question, I took a look at the Preferences -> > General -> Colors and Fonts. I clicked "Restore Defaults" and the problem > is resolved. > > I did not think to record the previous setting, but defaults seem to be > working as expected. Thanks for verifying. In-case you are able to reproduce the problem, it would be good if you could find the font settings causing the problem and post it here.
