Use a select to pick the editor font

[simurai]

This issue was hatched from this dicussion: https://discuss.atom.io/t/use-typekit-fonts-in-atom/13807/4

When picking a custom font for the editor, replace the text input with a <select>. This would solve the issue for guessing the spelling of a font name. (Font Name, FontName, font-name). Some more improvements:

• Getting an overview what fonts are available, maybe even limit to mono-spaced fonts?
• Quicker to pick (arguably)
• No misspelling
• No switching to "Times New Roman" when typing too slow

Concerns

• No idea how easy it is to get a list of installed fonts.. might be not easy for all 3 platforms. @abe33 linked to this: http://hasseg.org/blog/post/526/getting-a-list-of-installed-fonts-with-flash-and-javascript/
• Detect when a new font is installed and update the select. Might be fine to do it only once the select gets pressed.

[lee-dohm]

Random thoughts:

• List all fonts, but mono-spaced fonts first with a separator in the list between mono-spaced and proportionally-spaced
• What about installed font weights? I don't like the idea of having a giant list with five to ten variations of each font. Perhaps a separate drop down with just the selected font's available weights?

[simurai]

List all fonts, but mono-spaced fonts first with a separator

👍

What about installed font weights?

I think variations shouldn't be shown at all, just the main fonts. That way themes can decide what parts should be bold, italic etc.

[lee-dohm]

I prefer using Source Code Pro Light rather than Source Code Pro Regular for my editor font. I think it is more readable, especially in a dark theme on a Retina screen. I suppose I can always hand-edit the config.cson so long as the Settings View doesn't revert my edits.

I can currently select the font and weight (though I understand that this isn't possible on Windows or Linux), so I would consider not being able to select the weight a regression ... thought not a critical one.

[simurai]

Ohh.. you're right. Having Light, Regular and Medium would be useful and then bold, italic still should work when defined in themes.

[kevinsawicki]

Relates to #57

[mnquintana]

This package seems to do exactly what we would need, but it's old and unmaintained 😕 - maybe it would be worth trying to take it over?

[drammock]

👍 I have issue atom/atom#2912, and using M+ is a pretty strong requirement for me: I deal a lot with non-ASCII strings (including combining characters and spacing modifier characters) and M+ is the only typeface I've found that has adequate coverage of those codepoints and has a monospaced variant. Until I can select M+ as my editor font (with a selector or otherwise), I can't really use atom for those projects.

edit I eventually figured out that M+ 1m is actually easy to select as the default font, if you surround it in single quotes.

[alexandernst]

Maybe nominate for 1.0? This is, imho, an important feature.

[alexandernst]

I just wanted to develop my previous comment a little bit further. So, why do I think this should be tagged for 1.0? Because fonts are something very important in an editor. The main function of an editor is to show text. And the main things that improve a text area by itself are fonts and colors.

Atom already has an awesome support for "colors" (aka themes/skins, syntax highlight, etc...). Anyways, I feel that the font support is somehow less polished, softly speaking.

There is a simple text input (not even type ahead/suggestions based) instead of a proper font selector, which by itself makes fonts harder to choose. Besides that, the font size field is just another text input (not even numeric input, but text input!).

The line height field is, arguably, not enough either. I'd say Atom should offer a "line spacing" option instead of "line height", which should be auto-detected by the size of the font.

Last, but not less important, there are some fonts that have ligatures. After spending some time searching thru Atom's issues and forums, I found that there is an option one can add in the style config: optimizeLegibility. As this is something related to fonts and as it affects the entire editor, I feel that it should actually be inside the font config area in the settings, in the form of a checkbox.

Just my 2 cents.

[simurai]

Re: text-rendering: optimizeLegibility. Saw this post the other day: http://bocoup.com/weblog/text-rendering/. It might have performance issues. But would need some testing to see if it has an impact when used in Atom.

[grandsong]

I highly advocate auto-completion, which suggests but DOES NOT FORCE a user to select from the font name list.

Otherwise, a drop-down menu will hurt me as well as many users whose natural language is not Western. In my case, Chinese.

---

I wrote a long issue, as @lee-dohm refered just above, to explain:

1. Why is Atom so different from other editors with regard to setting the font?
2. Why is "Font Family" is great for non-Latin users?
3. Why do I advocate auto-completion instead of drop-down menu?

If you are interested, please read the whole issue.

@lee-dohm has closed mine due to duplication, so leave comments here if you want to.

[alexandernst]

I can't really see why/how can non-western users get affected by a dropdown. If you mean that you'll get a non-chinese (in your case) text in the dropdown, that is easily fixable by changing the text of the dropdown according to the language set in the editor.

If you mean something else, can you please tell us how exactly will a dropdown hurt you?

EDIT: Ok, I just read your original issue, and I still can't see where the problem is. The issue you're describing is easily fixable with a dropdown that will display each family per font.

I keep insisting on a dropdown instead of a text input because a dropdown actually lets you see all available fonts, which:

• doesn't enforce you to remember font names
• allows you to preview the font without having to apply it and see how it looks.
• will avoid potential issues that would (and will) happen with an input (an extra letter, missing space, typos, etc...) (this one is arguably fixable with an auto-complete-like input, but still)

[drammock]

@alexandernst I think the worry is that with a drop-down list users could no longer specify a list of fonts / font families, so there would be no fall-back for unmapped glyphs. Users like @grandsong (and me too, in fact) need the ability to do that, so that:

1. ASCII characters will display in a nice monospace font (incl. bold & italic for syntax highlighting)
2. any codepoints not mapped in the first font of the list will still get displayed by falling back to the second font in the list.

Otherwise, users are forced to choose between nice-looking ASCII monospace with everything else displaying as empty rectangles, or getting stuck with the really bad-looking ASCII (often non-monospace, with no bold/italics) that comes with most Chinese fonts.

[alexandernst]

Oh, now I see what you mean. Indeed, a fallback font would be nice to have.

[mnquintana]

In this case, I think rather than a native select, we should use some kind of suped-up select similar to the SelectListViews we currently use for the Command Palette, Symbols View, etc, like this Select2 example: https://select2.github.io/examples.html#multiple

This way you get all of the benefits of a select (with a dropdown), with all the benefits of autocomplete, but you can still specify fallbacks.

[yebyen]

I will be happy as long as the result is also a solution to #374 and atom/atom#2912 -- I don't use Atom because I couldn't select any M+ font family at all. I suspect this is due to the + character in the font name. If the solution to this issue does not address that, I'll be back here pounding my fists about it.

(If it's already fixed some other way, please let me know and I'll try it again!)

I really don't care whether it's a dropdown or an auto-suggest, or if we just figure out whatever the backend escaping issue is that means you can't select this font even when you spell its name correctly. I need 2x 80 character windows side by side on a 1366x768 screen on Linux/X11.

M+ is one of the only fixed-width fonts that is narrow enough to do that at a reasonable point size.

[drammock]

@yebyen does surrounding with single quotes like 'M+ 1m' not work for you?

[drammock]

👍 for @mnquintana 's suggestion, that looks pretty ideal.

[yebyen]

@drammock That does work in the current release. Yes. Thanks! I swear I tried that exactly in a previous version and it didn't work at all.

Although, the atom editor appears to disagree with the rest of my system about what size 14pt is...

I think the terminal is adding bold style to the font I selected, because gnome-terminal in "M+ 2m medium" looks more like Atom's "M+ 2m bold" as well.

Another 👍 for @mnquintana 's suggestion

[grandsong]

@yebyen: I read your issue about "M+" font.

I can explain why you fail and how to do it right.

What did I do successfully?

Before talking about your issue, which I have to guess or assume something about you, let me describe my practice which I am totally certain about.

I downloaded the zip file you provided at the end of your blog article.

After decompression, I got 43 .ttf files.

I chose to install one of them to my Windows 7:

"mplus-2m-regular.ttf"

Then, in [Settings > Settings] of Atom, I filled into the field "Font Family" with:

"M+ 2m", 微软雅黑

Done!

Why did you fail?

You said you've "tried setting it by hand in the config.cson:"

'editor':
  'fontSize': 15
  'fontFamily': 'M+ 2m medium'

4 things are wrong:

"medium" is font weight, not a part of font face name.

"M+ 2m" is the correct full name you should write.

If you write "M+ 2m", you may still fail, if you have only installed "mplus-2m-medium.ttf" but not "mplus-2m-regular.ttf".

"regular" is the normal font weight of a font, while "medium" isn't.

Moreover, don't forget to install "mplus-2m-bold.ttf" as well. Sometimes you will need "bold" weight.

You have to add double quote marks around "M+ 2m".

I will explain why the rule is like this later.

You edited config.cson, probably hoping for things to go better. Unfortunately, things went more complicated.

In 'fontFamily': 'M+ 2m', the single-quotes just mean the value which they surround is a string in the cson.

Changing them into double ones, in case you have tried, won't really change anything.

The corresponding line in my config.cson is:

  fontFamily: "\"M+ 2m\", 微软雅黑"

Somehow, my Atom always forces me to use double quote marks for the string value. So, in the string, there are another pair of marks for "M+ 2m" and they are escaped with \ in order to differentiate from the outer marks.

Don't edit config.cson directly while you can set the font family in Settings. The latter is far more convenient and less prone to errors.

More knowledge

You might feel the rules above unbelievably complex.

So I am going to show why things have to be like those.

About font weight

"M+" family has a file for each font weight.

There are too many weight variations and each file is big (over 1.4M).

If you, like me, don't need them all, you can only install the few most useful files you really need.

I suggest you install "mplus-2m-regular.ttf" and "mplus-2m-bold.ttf". Other variations won't be used in Atom.

(If you insist in "mplus-2m-medium.ttf", I can tell you how to enable it. But I guess "regular" is already good enough.)

---

Some history:

In early years, each font face has only one file which is just "regular". When "bold" weight is called by an application, the OS just draws characters with thicker strokes. That doesn't look very nice.

Later, a font file has two group of data, one for regular and the other for bold.

Nowadays, font faces in high quality have more font weights (such as "medium") than the basic two, based on requirements from publishers.

Big font faces for Chinese (Microsoft YaHei), Japanese (M+), or Unicode (Noto Sans Unicode), have to break down into files for those variations.

About quote marks

As I said in my issue, Atom is using "font family" property of CSS, a web technology.

There is supposed to be an array of font names.

But a value of CSS can not be an array. Instead, a string with , as separators is the solution.

In the CSS of atom.io, the related code is:

font-family: Helvetica,Arial,sans-serif;

If you add "M+ 2m", then it can be like this:

font-family: M+ 2m,Helvetica,Arial,sans-serif;

Hey, why are quote marks needed?

Unfortunately, CSS has a shorthand property "font" for convenience:

font: {font-family} {font-weight} {font-size};

Imagine this:

font: M+ 2m,Helvetica,Arial,sans-serif bold 14pt;

The CSS engine will be confused.

To avoid that, every font name with whitespaces within, must be surrounded by quote marks.

And CSS uses double quote marks. Don't ask me why.

---

At the end of this long post, let me say: "Thank you for reading!" and "M+ is indeed a good font!"

[grandsong]

When I was writing my draft of the above post, you tried something and it works with "medium". I don't understand why it can work but anyway congralutions.

With regard to your font size, you need to add "pt" after "14". There are several types of unit other than "pt", such as "px". If you tells Atom only a number, it will be confused.

[grandsong]

@mnquintana:

Yes, Select2 is definitely better!

Good email applications have similar feature for editing an array of recipients.

And yet of course it is more difficult to implement.

Let Atom dev team decide.

However, I won't get my hopes up too high.

Autocompletion like that in Command Palette is more feasible.

[yebyen]

@grandsong I can tell you that setting 'medium' or 'bold' in the Font Family part of the dialog does indeed have an effect, even if it's not properly part of the font family, entering it into that dialog changes the appearance of the fonts.

However, setting the font size with 'pt' or 'px' or 'em' as in 18pt, I already tried, and it has no effect. I just pick 16 when I mean 14 and it looks approximately correct. Chalk it up to different rendering engines having slightly different behaviors.
This is definitely "down the rabbit hole" though. My issue is fixed, and yours (or, the subject of this ticket) is basically unrelated to that.

[lee-dohm]

@yebyen The units for the font size is pixels, not points. That's why 16 looks approximately like 14points.

[SpainTrain]

bump/ping

Would love to see this feature.

[alexandernst]

Any progress on this?

[equinox]

@mnquintana's suggestion looks the best imo and looks really neat.

Would also stop the occasional issue being opened by people asking about how to change font or facing issues. ;)

Small note: font-manager seems to have been updated since its last mention.

[ErraticFox]

I don't like usually bumping old posts, but it's almost been eight months since an update. So, is this still being worked on?

[damieng]

https://github.com/atom/settings-view/tree/dg-font-picker has a branch that was starting to work but we wanted to go down the route of using autocomplete+ rather than a picker so you can type a bunch of font names etc.

Unfortunately at the time spacepen was interfering with the setup lifecycle of adding autocomplete to a mini editor but a lot of work has happened removing spacepen since then so it may no longer be a problem. The team are now currently working on some higher priority work so I don't know when we can return to this.

[nukeop]

3 years to implement this?

Also when will bitmap fonts be supported?

[damieng]

@nukeop bitmap fonts will never be supported as the underlying Chrome rendering engine does not support them any more.

[50Wliu]

3 years to implement this?

@nukeop Please, feel free to submit a pull request. That is one of the best ways to get a feature like this one implemented.

[damieng]

There is actually a branch I did that has the functionality however people didn't want to lose the ability to type their font of choice or to specify a CSS fallback.

So the solution would likely be enabling autocomplete on the current field with , as separators. The branch should show how to get the actual system fonts in a platform-agnostic way.

[rsese]

@nukeop - your comment was deleted as a violation of the Atom Code of Conduct as it was insulting or derogatory. You may consider this an official warning.

[nukeop]

I don't know how discussion can proceed if even completely harmless comments are being censored.

But asking me to develop myself what a team of developers failed to deliver in 3 years is unreasonable to say the least. I neither have the time nor skill to do that. Even if I had, odds are my pull request would be rejected for not being 'gender identity friendly' or something like that. It undermines the whole idea of feature requests. You can't expect everyone who wants some feature in some program to develop that feature themselves.

[mplewis]

@nukeop, you're not contributing to the discussion or offering solutions. This issue's thread isn't for complaining about Atom development practices – it is for discussion of an editor font selector.

[damieng]

@nukeop We have hundreds of feature requests and bug reports. We don't consider this high-priority as it's really a convenience feature. There are much more pressing issues to be addressed that affect far more people in a more meaningful way.

An issue is not a promise to develop something or an indication that anyone is working on it.

If anyone felt strongly about this issue they would probably have sent a PR. The fact they haven't indicates that most people don't care about it.

[xealgo]

I hate to necro this, but I had to point out that Atom is a completely free editor that offers a ridiculously huge feature set already...