Bad font rendering makes text hard to read

[arrbie]

Text rendering in Brackets is of very low quality and subpar other text editors. Eyes become tired and you need to increase the text size to compensate for the low readability. To me this is a deal-breaker.

The effect is quite independent of choice of font, and is especially true for the default font 'SourceCodePro-Medium', but also for 'Menlo-Regular' (pics below).

It's as if Brackets weren't even using the Mac's built-in font rendering API:s for text areas. Adobe, are you fiddling on your own with the text rendering algorithms here? I know you are masters of graphics – especially typography – but I think you should trust Apple on this one, and you get it for free. This is NOT a matter of differences in aesthetic opinions. Just follow the system defaults like all other Mac applications do and we'll all be happy. (Already pointed out by drewhamlett at GitHub back in 2013)

See comparison of screen dumps from Brackets (top pic) vs Smultron (bottom pic) running on the same machine. This font is "Menlo-Regular" 11pts (or "px" as Brackets says). Pay attention to the letters in the word "supplied". Every single letter (except the "i", which is actually too thin) is much more unclear, smudged out, and of varying thickness on the Brackets version.

This problem is true not only for the actual text area, but also for all other text inside the Brackets windows, ie sidebar, window title, modal dialogs etc.

Brackets version: Release 1.3 build 1.3.0-16022
OS: Mac OS X 10.10.3
Hardware: MacBook Air 13" (1440-900 px)
Extensions: None (fresh factory install)

[brunnopleffken]

I believe Brackets uses grayscale anti-aliasing instead of subpixel for some reason (performance, maybe)... I agree with you, it's really bad and I use a "CSS injection" extension and do some workarround to solve it.

This is my workarround to get subpixel rendering back:

* {
    -webkit-backface-visibility: visible !important;
    backface-visibility: visible !important;
}
.CodeMirror {
    -webkit-font-smoothing: subpixel-antialiased !important;
}

[arrbie]

@brunnopleffken: Yes, thank brunnopleffken. I also try to easen up on the worst pain by applying similar rendering patches. I've also experimented a little with 98% alpha on the text colors, eg rgba(0, 136, 0, 0.98). It helps a little, but it's still VERY FUZZY compared to normal Mac standards and other text editors.

During the last week I've spoken to five different developers using Macs, and every single one of themhad been ditching Brackets for the same reasons: terribly fuzzy text rendering. One guy said something like: "If the Brackets developers can't even prioritize text quality in their text editor, then I don't entrust them with anything else either. Everything else come second.". And I kind of agree, it's a shame and they will loose a lot of Mac users in this way.

Brackets

BBEdit (same color codes as Brackets' above)

Smultron

[nethip]

@arrbie I have marked this for 1.4 and we need to figure what is the best possible way to disable sub-pixel rendering on Mac. CEF does not give us a flag to disable this out of the box so we may have to tweak our CSS for it. Found an interesting article and it says Apple is tweaking the CSS to disable sub pixel rendering. http://usabilitypost.com/2011/02/08/please-stop-disabling-subpixel-rendering/

[arrbie]

@nethip, thanks for taking this seriously. However, I think you are quite on the wrong track. This is definately not a matter of "disable sub-pixel rendering on Mac". Actually, you seem to have misunderstood completely nethip. Please, read carefully all fixes that have been attempted above – without reaching satisfactory results.

You need to get hold of someone that really uses a Mac as their primary tool and ask for their assistance. It's simply not enough for you to just test a little on a Mac, since clearly you lack the ability to see the real nature of the problem here. The product should never have been released in this state otherwise.

[ryanstewart]

Is this just an issue on non-retina Macs? I'm on a 15" Mac Book Pro and I'm not seeing any obvious text issues.

I definitely notice the differences in the screenshots above. I just don't see those differences on my own machine.

[nethip]

@ryanstewart @arrbie I think this is a problem on all Macs. And it is much worse on non-retina displays. We have being tracking multiple issues with fonts on MAC (#4640, #10083, #2791) for quite some time. And I think actually CEF 2171 made it look a lot worse.

@arrbie I take back what I said about disabling sub-pixel rendering. What I meant was to tweak this attribute to get the desired rendering. And by the way we don't use any custom rendering/layouting (i.e use Core Text or NSText* rendering) on Mac. We use the rendering provided by CEF itself and we completely rely on the CSS to tweak the text rendering on all platforms that we support(Mac/Win/Linux). It is just tweaking CSS to get the desired result.

As mentioned in #10083 (comment), Atom seemed to have fixed some of these issues (to do with kerning and leading) by using one of the blink settings, which we cannot use inside Brackets as we are based out of CEF. It would be great if you can open a PR with your suggestions and we could collaborate on this. We will make sure this PR would indeed be picked up for this release. Please take a note that we have integrated CEF 2171 and the rendering looks a little different to that of the older versions(<=1.0) and that the solution should work for retina(or HiDpi) as well as non-retina displays as attempts were made earlier which was kind of mutually exclusive kind of result.

[nethip]

Also take a look at #10083 (comment) for @peterflynn comment on the same.

[arrbie]

CEF is crap for the Brackets product. I wish Brackets had used the built-in web engine of the OS instead. Brackets is a web-app, right? And since when did a web-app need to carry its own web browser engine anyway?

[arrbie]

Regarding #10083 and @peterflynn's comments:
I think he might be onto something here. I also have noticed strange horizontal shiftings related to the font size. Fractional width is definately part of this problem.

However, as I pointed out in a new comment in #10083, there must be more to it than this since the geometric size of the rendered text is actually correct now (used to be too narrow).

[nethip]

From my previous experience we had problems with fractional widths attributed to AA, only if the AA algorithms are implemented by the renderer rather than by the system, like the text engine used in Fireworks(Check Anti aliased text in Fireworks and you will see jaggered edges, which I have been fighting for ages to figure out how to solve this AA problem as we had to implement the sub pixel rendering by ourselves).

System does an awesome job of using sub pixel rendering along with AA to smoothen the curves in a brilliant way(looks good on LCD and LEDs). So I don't think there is any problem with the fractional widths. The downside of this is that same character may have different rendering, as it is bound to happen with fractional widths, but that is still fine.

I am not sure if chrome uses any line breaking algorithm by themselves. Mac provides CTLine and CTFrame which do a great job in calculating string widths and rendering them good as well. I need to look at chromium's source and figure out what is happening there. I am not sure if they are using any offscreen rendering for particular cases.

While modernising the text engines in other Adobe products (Dreamweaver to be more specific), I found that AA works fine even for font size less than 11pts. The biggest problem with AA is to do with the way scaling is implemented to smoothen the curves and this becomes worse with ligatures and auto kerning (especially on Mac), if not implemented fine or a badly written font. So here is what we need to do

• Disable ligatures
• Use -webkit-font-smoothing: subpixel-antialiased; refer to this article http://www.intridea.com/blog/2014/5/8/better-font-smoothing-in-chrome-on-mac-os-x.
• If the above does not work we need to see if there is any other CSS property, like drop shadow, which is creating a pixelated look.
• Also we could have a media query to enable or disable AA based on screen resolution and pixel density. This we could give it a try.
• Also we need the check if chrome is defaulting to offscreen rendering in certain cases(may be because of some CSS attributes)

[nethip]

• There is another thing I want to add. If there is a scale factor applied to the entire text, it is going to effect the entire text rendering. So another point to look out would be to see if any scale factor is getting applied.

[arrbie]

Already tried the following (in extension and theme), but it didn't help:
• disabling ligatures
• changing all varieties of font-smooting (incl AA off)
• drop shadow nullification (text-shadow, svg-shadow)
• font scaling factors (+/- 0.5 px in steps of 0.01 px)
• text-rendering
• alpha channel on colors
• font-kerning
• text-stroke-width
• font-weight

[ryanstewart]

@arrbie if you're feeling brave, would you mind seeing if this experimental branch of Brackets running on Electron is better?

Here's a side by side comparison on my machine (Black title bar is Brackets normal, grey is with Electron)

[brunnopleffken]

I can't see differences between Brackets-Shell and Electron at all... I believe the main point here is that Brackets doesn't use sub-pixel anti-aliasing for text, it uses greyscale, leading it into fuzzy fonts (basically, the same issue that IE10 and Office 2013 faced in Windows 8 a few years ago) on non-Retina/non-High-DPI displays, lowering the effective resolution...

Enabling sub-pixel rendering will also improve ligatures and font kerning, because it'll use three pixels instead of just one with a single color. On Macs it's even worse, because it doesn't use the "aligned-to-grid" rendering like Windows does.

[nethip]

@brunnopleffken Did you do this comparison on a retina display. If yes it is hard to figure that differences because of high pixel density. May be we might want to compare this on a non retina display.

And you many be right about enabling sub pixel rendering support. Did you get a chance to experiment with -webkit-font-smoothing: subpixel-antialiased;. Does that make the rendering a little better.

[nethip]

@ryanstewart I am not able to distinguish between both the screenshots just by looking at them. I will have to probably do an XOR in Fireworks to figure out the little differences.

[arrbie]

@ryanstewart, nope, I can't see any difference in rendering quality between your two images of Brackets normal and Electron above. Both look good to me.

I will try to install the experimental branch on my MacBook Air 13" (non-retina) and get back to you with results. Now, where do I find the compiled version of this?

[marcelgerber]

@arrbie There's no compiled version available, but it's more or less easy to set up:

1. git clone https://github.com/zaggino/brackets-electron
2. cd brackets-electron
3. git submodule update --init
4. npm install
5. npm start to run

Notice you won't have your usual extensions and themes installed as it's more or less a separate install.

Even if you don't see a difference/improvement immediately, please keep it installed as it's easily configurable and thus, you could test some different configurations.

[nethip]

@brunnopleffken I just saw from your above comment that you have already tried -webkit-font-smoothing: subpixel-antialiased;. Let us then compare then screenshots with this setting on. I will do this first thing tomorrow.

[arrbie]

@marcelgerber, what's npm?

[nethip]

@arrbie npm is a node package manager. Install node and this would get installed along with it

[arrbie]

Sorry, don't do NodeJS yet. Will have to pass on this one.

[marcelgerber]

Oh, ok. It's the Node package manager.
So, Node is a command line tool that lets you run JavaScript locally on your computer (with access to files and so on), and npm is a tool that lets you install modules (similar to pip for Python, gem for Ruby, etc.).

Just saw your answer: You don't really have to have any Node skills for this, just install Node and you're ready. But it's of course also fine to not install it :)

[arrbie]

@marcelgerber, yeah, I know about NodeJS. Just not ready to go there yet. Any way to install Brackets Electron w/o node?

[nethip]

Actually we were deliberate in disabling sub pixel AA. See this #4640 (comment)

After looking at our issues base, I found that the only possible solution for time being is to write an extension or a theme which would either enable/disable sub pixel-anitaliasing. Also we could have more options in this extension to either completely disable AA or just disable sub pixel AA. That way we could give more flexibility to the users. This have been disabled to fix some issues with the animations. If those animation issues indeed come back after enabling back sub pixel AA, then we should be disabling animations in the code view as well, in this extension.

[arrbie]

Here we go again. This animation reason for fiddling with the AA has been discarded in numerous discussion comments. It seems nobody has reported proof of such a connection, but rather the opposite. So we have to conclude that it's simply a myth. Read for ex. drewhamlett (in #4640).

Also – and more importantly – we are not talking about simply switching on or off the subpixel-antialiasing. This has already been tested (in extensions and themes, see the 9-bullet list above), and is not enough to solve the fuzzy text rendering issue. I haven't seen a single CSS command that does that, independently of where it's put.

Since this discussion is clearly going in loops, I suggest we give up and close it unsolved(!)

[nethip]

Here is the link to the chromium bug where there is lot of discussion on the same blurry text issue in CEF.

https://code.google.com/p/chromium/issues/detail?id=152304

[arrbie]

@nethip Thanks, your fix actually did the trick. All text suddenly went crisp and clear. But it does not seem to stay that way after restarting Brackets. Is there a simple way to make it "stick"?

[bobrocke]

@nethip That worked for me, too. After the second command, the text everywhere in the interface looks much better. I assume that change will make it into v1.4 so that it will "stick?"

[ryanstewart]

@arrbie I'll talk to @nethip but this may be something we want to roll an intermediate build on to test performance and how it works on Windows as well.

So short answer: no easy way to make it stick at the moment short of editing the Brackets source code yourself, but hopefully it will be permanent as of 1.4 and we'll also have a test build for people to try where it's permanent.

[arrbie]

@ryanstewart Allright, good enough for me.

[bobrocke]

@ryanstewart Is it an easy fix to the source? I may want to patch mine until the official build is out.

[ryanstewart]

@bobrocke I think (not tested yet) that you'd have to edit this file - https://github.com/adobe/brackets/blob/master/src/styles/brackets.less and then make sure those .less files got recompiled into CSS. And you can see where we've already set those properties so they're easy to find.

There are some instructions here - https://github.com/adobe/brackets/wiki/How-to-Hack-on-Brackets - on how to build things from source. Let me know if that helps!

[zaggino]

Just tested this on my Mac

If you're running Brackets from source according to this guide https://github.com/adobe/brackets/wiki/How-to-Hack-on-Brackets

Only thing you need to change is this line: https://github.com/adobe/brackets/blob/master/src/styles/brackets.less#L58
to subpixel-antialiased

You don't need to recompile anything when running from source. Ping me on https://brackets-slack.herokuapp.com/ if you have any issues.

[ryanstewart]

@zaggino to the rescue!

[zaggino]

Also guys, let us know if you'll see any ill side-effects with this setting, the current value was set in #2665 to fix #1993

[arrbie]

This is what I did to fix the existing Brackets app so that the text crispness stays, without recompiling or running from source:

Closed the Brackets application.

• In Finder, chose Show Package Contents of Brackets and opened folder Contents / www / styles
• Edited brackets.min.css like this…

  Changed the 4th occurance of “-webkit-font-smoothing:auto” => “-webkit-font-smoothing:subpixel-antialiased”
  Changed the only occurance of “-webkit-backface-visibility:hidden” => “-webkit-backface-visibility:visible”

• Saved the file.
• Reopened Brackets.
• Was happy.

[nethip]

@arrbie Yeah that should work too 😄

@arrbie @bobrocke For convenience sake I have kind of packed both the above commands as an extension. This extension also takes care of enabling sub pixel rendering only for retina displays non-retina displays.

Here is the link to the extension https://www.dropbox.com/s/yu6dqt5qm079r3r/EnableSubPixelRendering.zip?dl=0

You could install it by dragging and dropping the zip file onto the extension manager dialog. Let me know if you face any problems with that.

[bobrocke]

@arrbie Cool. Thanks! I'll give that a try.

[gobijan]

Came here because font rendering in brackets is different from all other editors (sublime, choc, textmate etc.). @nethip thx your package solves this in a convenient way.

[mithat]

This isn't a Mac only problem. Awful font rendering also affects Linux. I used nethip's extension but commented out

if (brackets.platform === "mac" && window.devicePixelRatio < 2) {

and the matching closing brace to unconditionally apply subpixel rendering. I then switched the typeface to 'DejaVu Sans Mono'.

Interface text still looks blotchy, but code windows are now usable.

[nethip]

@mithat Thanks for porting my extension. Right now changes relevant to subpixel antialiasing are in the master. It would be great if you can have a look at this and include these changes for linux as well. Thanks!

[mithat]

@nethip I'm happy to test but right now I don't have a lot of time to dig into the code. Can I create a feature request for this? I suspect someone who knows the codebase and who knows how you filter for linux could make the change in about 10 minutes.