Bug 11211 - Editor font picks the first weight not the selected weight
Summary: Editor font picks the first weight not the selected weight
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: 4.0.2
Hardware: Macintosh Mac OS
: Low normal
Target Milestone: 4.2.3 (from master)
Assignee: Michael Natterer
Depends on:
Reported: 2013-03-17 08:57 UTC by Nic Wise
Modified: 2014-01-06 05:40 UTC (History)
8 users (show)

Tags: gtk
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Nic Wise 2013-03-17 08:57:04 UTC
Full description and shots here


I use Source Code Pro as my dev font. It comes in a load of styles. Extra Light, Light, Normal etc etc.

I choose Regular. XS4.0.1 used to display Regular.

Now (4.0.2, Mono3), it picks the first one on the list - which is ultralight. Not overly readable, but not a show stopper either.

See screenshots in the forum post

REGRESSION. I assume it's a GTK issue?
Comment 1 Mike Krüger 2013-03-17 09:51:23 UTC
But you can pick the regular font style and the editor takes that ?
Comment 2 Nic Wise 2013-03-17 09:54:42 UTC
I used to be able to.

I could pick any font face + style and it'd take it (mono 2.11.x + XS 4.0.1)

Now, I can pick any, but it only ever uses the first one (Ultralight) in the editor. If I pick any others, it just uses Ultralight (the first one in the list)
Comment 3 Mikayla Hutchinson [MSFT] 2013-03-18 10:27:34 UTC
XS 4.0.1 did not run on Mono 2.11.x, do you mean 2.10.11?

Do you have the problem if you run XS 4.0.2 on Mono 2.10.11?
Comment 4 Nic Wise 2013-03-18 10:38:46 UTC

how do I do this? apparently, I still have them installed - is there a commandline incantation to run it?
Comment 5 Mikayla Hutchinson [MSFT] 2013-03-18 10:40:24 UTC
Change the /Library/Frameworks/Mono.framework/Versions/Current symlink to point to /Library/Frameworks/Mono.framework/Versions/2.10.11
Comment 6 Mike Krüger 2013-03-18 10:41:14 UTC
mhutch: it's the font picker dialog - it has always the problem.
Comment 7 Nic Wise 2013-03-18 10:53:41 UTC
Thanks. Just tried it. Confirmed that I was running in 2.10.11 in the about

Still shows the Ultralight style regardless of what I pick.Get the Face right,
but not the Style. Except for italic.

Stranger, using the default font (Menlo)

I pick -> it shows:

Menlo Regular -> Menlo Regular
Menlo Italic -> Menlo Italic
Menlo Bold -> Menlo Regular
Menlo Bold Italic -> Menlo Italic

This is the same for Helvetica Neue and any others I try.

Note that the list above is in the order they appear in dialog. The order
Comment 8 Nic Wise 2013-03-18 10:54:08 UTC
Oh, and the small line of text at the bottom of the font picker shows it correctly. Its just the editor window which is wrong.
Comment 9 Mike Krüger 2013-03-18 11:01:36 UTC
It's not a very big bug btw. it's always possible to select the regular font and it's only affecting some fonts like the Source  Code Pro.

btw. I wouldn't recommend it as source code font - it's the first non mono spaced 'source code' font I've seen. Some features are built for mono spaced fonts.
Comment 10 Nic Wise 2013-03-18 11:05:13 UTC
So far, it's not allowing me to select a regular style - only the first style, which in this case isn't regular.

I will go back to Menlo I think, but I use Source Code Pro everywhere else at the moment - according to Adobe (who made is), it is monospace:


Or am I missing something here?
Comment 11 Mikayla Hutchinson [MSFT] 2013-03-18 11:51:06 UTC
Mike, what exactly is the problem with the chooser? Is GTK+ giving is back an incorrect font string or something?
Comment 12 Mike Krüger 2013-03-18 12:14:18 UTC
Suggested fix:
The font style sorting should always sort regular at the 1st variant.

Atm when selecting source sans pro the wrong variant is choosen - by fixing the sorting in the font chooser that wont happen.
Comment 13 Nic Wise 2013-03-18 18:37:45 UTC
If it's any help, I just upgraded to the stable release (4.0.2 and 2.10.12?) and I have  the super-light font. Going to switch back to menlo....
Comment 14 George 2013-03-19 13:30:33 UTC
Just wanted to add that if you uninstall the variations of the Source Code Pro Font that appear in the list *before* "Regular" (which are Extra Light, Light, etc.) then with "Regular" listed first in the dialog it will work. (See bug 11265)
Comment 15 George 2013-03-19 13:40:50 UTC
Source Code Pro is monospaced.  However, it can be confused with it's non-monospaced parent font "Source Sans Pro" which is not monospaced.
Comment 16 Alexander Jochum 2013-04-22 17:07:52 UTC
I've the same problem using Xamarin Studio 4.0.4 and Mono 2.10.12.
Using MonoDevelop 3.1.1 with Mono 2.10.12 displays the selected font correctly.

Status is NEEDINFO so what info is necessary to get this bug fixed?
Comment 17 PJ 2013-11-19 17:04:53 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 18 Nic Wise 2013-11-19 17:19:42 UTC
This works fine for me with 4.2 (current beta channel)

Suggest it's closed.
Comment 19 Nischal 2014-01-06 05:40:15 UTC
We have checked this issue and now it is working fine. Hence updating bug status as verified.

Screencast for this:

Build Info:
XS 4.2.3 (build 24)