To recap at a high level:

• Operator Mono uses funky usWeightClass values (300-400) for light to bold, instead of the typical 300-700. This causes Pango to select a font different than the user intends. Pango selects Operator Mono with usWeightClass 400 (named Operator Mono Bold) when the user enters "Operator Mono" since the default weight class is Normal (400).
• Because of this, we have to split weight names off of the "font_face" setting and match the family name first by enumerating families installed, then we enumerate the subfamilies to find the weight the user requested.
• Since "Retina" isn't really a standard weight name, there is no way for us to know that it is a weight name, and thus we look for a family "Fira Code Retina" and a Normal weight.

This only happens with Pango on Linux. Windows and Mac handle the naming fine, as far as I know. The APIs just work better. My tweets explained that the issue is a combination of poor font selection (specifically with Pango) on Linux, combined with a non-standard weight name.

My suggestion was for @kgizdov to modify the font to have a family name of "Fira Code Retina" and a weight class of Normal/Regular/Book. Renaming the font for the entire project would be a whole different level, and I don't suppose to know all of the knock-on effects of that.

The only way for us to solve this, without special-casing, would be to change our font selection logic on Linux to iteratively try different prefixes of the "font_face" as family name when enumerating the families on the system. This is a fair bit of change and work, and isn't super-high priority relative to other things right now. The downside being that users on Linux who want to use "Fira Code Retina" right now are basically out of luck.

Anyway, I just figured I'd chime in with details on where this was coming from and what about Sublime Text and font selection was motivating @kgizdov's request.

Would renaming Retina to Book and keeping font weight at 350 work?

I believe so. Let me make a tweak to the font and confirm it works before having you go down that path.

@wbond wondering if you had time to check this?

I didn't, but thank you for the reminder. I should hopefully be able to do that soon.

@wbond ?

@tonsky I can confirm the pull request to resolve the issue. Renaming Retina to Book and setting the weight to 350 seems to make it work. I have not tested only changing the name or only changing the weight. However, from original comments one or the other only does not seem like a viable solution anyway.

I just noticed Book is 350 (lighter than Regular) while Retina is a bit heavier than Regular. I also noticed IBM Plex Mono uses Text weight for something between Regular and Medium. Would that work too? I really don’t want to make Book weight that is heavier than Regular.

@tonsky Well, I guess it could work. As far as I understand originally, it was a problem of name parsing. So if Fira Code Book exists, then the weight shouldn't really matter. I'm just following up on your original suggestion (Book with 350 weight) and it worked.

@tonsky updated the PR

It’s not that the number matters, it’s the fact that Retina is heavier than Regular and Book by convention is something lighter than Regular that troubles me. I don’t want to break that convention. It’s like making Light weight super-bold. That would be confusing

@tonsky ok, then is there another standard name we could use in this case? Something that will be picked up and not confuse the parser?

That’s my question to @wbond. Will Fira Code Text work in Linux? (instead of Book)?

Well, I'm gonna have to test it. I think @wbond has given up on this.

Hey, sorry, I tend to get lots of notifications on GitHub and sometimes they slip through. When this issue was first open my fifth child was less than a month old, and sometime I just lost track of the issue.

In terms of how Sublime Text deals with the funkiness, our current approach requires stripping the font weight from the name to try and use the pango API to get the correct font. However, that doesn't always works, so we fall back to looking for the family name with a named weight.

I think the issue here is that we haven't run into a weight named "Retina" before. Apparently neither "Text". This is the current list of weights we explicitly handle:

• "book": BOOK
• "regular": NORMAL
• "normal": NORMAL
• "medium": MEDIUM
• "extra heavy": BLACK
• "extra-heavy": BLACK
• "extraheavy": BLACK
• "ultra heavy": BLACK
• "ultra-heavy": BLACK
• "ultraheavy": BLACK
• "heavy": BLACK
• "extra black": BLACK
• "extra-black": BLACK
• "extrablack": BLACK
• "ultra black": BLACK
• "ultra-black": BLACK
• "ultrablack": BLACK
• "black": BLACK
• "ultra": BLACK
• "extra bold": EXTRA_BOLD
• "extra-bold": EXTRA_BOLD
• "extrabold": EXTRA_BOLD
• "ultra bold": EXTRA_BOLD
• "ultra-bold": EXTRA_BOLD
• "ultrabold": EXTRA_BOLD
• "semi bold": SEMI_BOLD
• "semi-bold": SEMI_BOLD
• "semibold": SEMI_BOLD
• "demi bold": SEMI_BOLD
• "demi-bold": SEMI_BOLD
• "demibold": SEMI_BOLD
• "bold": BOLD
• "extra light": EXTRA_LIGHT
• "extra-light": EXTRA_LIGHT
• "extralight": EXTRA_LIGHT
• "xlight": EXTRA_LIGHT
• "ultra light": EXTRA_LIGHT
• "ultra-light": EXTRA_LIGHT
• "ultralight": EXTRA_LIGHT
• "semi light": LIGHT
• "semi-light": LIGHT
• "semilight": LIGHT
• "light": LIGHT
• "ultra thin": THIN
• "ultra-thin": THIN
• "ultrathin": THIN
• "thin": THIN
• "hairline": THIN

The first is the literal string we look for in the name, and the second value is the normalized weight we use internally in some of our code. For everything to work properly, we need an approximate weight to map a weight name to, but the most important part is recognizing that a word is a "weight name".

I can certainly add some more names to our standard mapping. We handle some of the most common, and have a pretty good coverage of CSS weight names, however seeing https://bigelowandholmes.typepad.com/bigelow-holmes/2015/07/on-font-weight.html there are definitely some we should add such as "Text", "Lite", "Dark", etc. The only downside to this is that these will only work properly in future releases of Sublime Text, as opposed to what is out there now.

@wbond it would be great if you could expand the mapping. That would help more broadly with other fonts and users and I'm sure everyone would welcome it. In the case for FiraCode ultra name could be an option, maybe?!

Ultra means the heaviest possible, so that probably wouldn't be a good option.

So no matter what I do with Fira Code, after normalization we will only have the following options:

THIN
EXTRA_LIGHT
LIGHT
BOOK
NORMAL
MEDIUM
SEMI_BOLD
BOLD
EXTRA_BOLD
BLACK

Which means we have nothing to resolve to if we want something between Normal and Medium. Seems like an unfortunate omission. @wbond how about you add TEXT weight and resolve both Text (IBM Plex Mono) and Retina (Fira Code) suffixes to it? Would that work?

BTW congrats on the fifth child! And thanks for getting back to this issue so quickly!

@tonsky Sorry, no, those internal mappings have to do with with mapping to a numeric value and you don't need to worry that there are only a limited distinct number. As I mentioned before, pango has a funky API. It defaults to trying to search using aspects of the font - family name, weight (numeric), etc. When someone sets their font to be "Imaginary Mono Medium", we still need a "bold" version for when a color scheme specifies bold. So we have to strip the Medium weight off to get the family name and then request a weight of the family with bold weight.

We can (properly) match any font that uses a weight in the "big" list, even if the numeric values are atypical (such as with Operator Mono). I've got an internal merge request to add a number of other weight values that will work with future versions of Sublime Text and Sublime Merge. These include:

• Text
• Roman
• Plain
• Standard
• Thick
• Extra Thick
• Dark
• Extra Dark
• Fat
• Lite
• Semi Lite
• Extra Lite
• Ultra Lite
• Demi

I spent some time looking for other names that are used for weights and couldn't find anything, so I think after this change our algorithm should be fairly complete.

So as a result, yes, using the name "Text" for the weight I think is reasonable. Some places consider that slightly lighter than "Normal" or "Regular", more like "Book". One option would be "Thick", though it may imply connotations of possibly being heavier than "Medium" to some users.

I have not found any fonts with Thick but Bigelow and Holmes article suggests it’s exactly between Normal and Medium, so that works too

Great discussion everyone! I learned quite a bit from it so many thanks for that :) Haven't really ventured very far into Typography so enjoying learning more about it.

Fira Code is by far my favorite font for coding and sublime text my favorite place to write that code. Much appreciate everyone getting involved and moving things forward 👍 ❤️

PS. @wbond how do you survive 5 kids? As lovely as they are my two daughters nearly ruined us in their first two years. Like I love them to death but there is simply no way we are having another one. 🤣

@wbond how about adding retina to SublimeText?

Retina is more of a description of a pixel density, whereas all of the other weights (other than book, which has a long history in typography) are words to describe weight or thickness. Because of that, I'm not sure it makes sense to add Retina. For instance, should we add custom weight names for any font that wants to be different?

@wbond this all depends. As far as I can tell, there are other fonts which also use the "weight" Retina.

Let's be honest, there are a lot of idiotic things (which are logically wrong) in IT, because major corporations came up with them. This is not necessarily an excuse, but can be used as one should you not find one yourself. What about Book? You mentioned Book, which did not really represent a weight either but had a long tradition? Who says Retina won't either?
I'm just saying that it might be easier to make the changes in 1 product than N fonts.

@tessus Could you point to those fonts? I'm not keen on adding Retina (or Pupil 🙂) as weight names since they seem like an evolutionary dead end, and I'd really not be special-casing things in the Sublime Text code base for individual fonts.

I should note that the additional weight names I mentioned at #641 (comment) have been shipping in the latest dev build of Sublime Text for a coupe of months.

@wbond

Could you point to those fonts?

Unfortunately not. I don't have any concrete examples, but I think to remember that I came across fonts that used Retina. Anyway, it was just an idea to make things easier. If it's not, never mind.

seem like an evolutionary dead end

Haha. Well, there are still drivers that use crt in their names and not to talk about harddisk drivers that use rotational speed and so on, even though these drivers are mostly used on SSDs these days, .... But I get what you are saying.

@wbond I've tested the latest dev builds that are published online, but I cannot reproduce the support for these new font weights. I'm guessing you had some private builds in mind.

@tonsky I've made a new pull request where I've taken the discussion above and instead of trying to rename things I introduce two new font weights - Book and Thick - Book is a Retina duplicate, Thick is the one discussed above. I've also included the resulting fonts.

With this new PR #1038 I've managed to use "font_face": "Fira Code Book" in Sublime Text successfully. The Thick weight is not resolved by Sublime Text unfortunately.

At least, however, I think the PR will future-proof the font somewhat with two separate options.

Funnily enough I always had FiraCode-Retina working in my sublime. Curious if Fira Code Book will be different

I never noticed this was a Linux specific thing. I am on mac after all...