[CLOSED] Bad font rendering makes text hard to read #9661
Comments
|
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;
} |
|
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 |
|
|
|
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. |
|
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. |
|
As mentioned in adobe/brackets#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. |
|
Also take a look at adobe/brackets#10083 (comment) for |
|
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? |
|
Regarding #10083 and 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). |
|
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 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 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
|
|
|
|
Already tried the following (in extension and theme), but it didn't help: |
|
Here's a side by side comparison on my machine (Black title bar is Brackets normal, grey is with Electron) |
|
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.
|
|
And you many be right about enabling sub pixel rendering support. Did you get a chance to experiment with |
|
|
|
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? |
|
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. |
|
|
|
|
|
|
|
Sorry, don't do NodeJS yet. Will have to pass on this one. |
|
Oh, ok. It's the Node package manager. 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 :) |
|
|
|
Actually we were deliberate in disabling sub pixel AA. See this adobe/brackets#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. |
|
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(!) |
|
There has been some change on Brackets-Shell or something since Brackets v. 1.0? I tested this CSS (using By the way, I never see an animation issue with the anti-aliasing enabled... All I see is a better readability on dark backgrounds on OS X, nothing else! So, I see no reason for disabling it... And by the way # 2: Brackets uses Chromium, it's more like a browser, so I don't know if it's possible to use Mac's native font rendering APIs on it (which is great on Sublime and TextMate), as it is defined by Chromium itself. |
|
I had mentioned in my comment above the actual reason why we have turned this off with the older build of CEF. Now I also mentioned that if and only if we see any degradation at all only then we need to worry about disabling animations, though it has been ruled out in multiple comments.
I understand it could get quite frustrating to see nothing working but hey, you can think this is to be a good learning experience. And as I mentioned above we will be tracking this for 1.4 especially when we are hearing this from multiple users. |
|
Consider switching from CEF to PhoneGap on the Mac distribution of Brackets – if you think that userbase is of value to Adobe. It will make the product behave natively, and make it much leaner (you could save ~75MB of the total 114MB). It would also start up faster. The should require only minor work, and I don't see any reason this product should make hard-coded dependencies on CEF functions anyway. |
|
Still, nearly 3 weeks after the problem was reported here, there isn't even an issue report entered on bitbucket.org/chromiumembedded/cef/ Since this bug has been reported as a Brackets deal-breaker by various Mac users, I can only conclude that the Brackets team don't care about this community anymore. |
Tuesday Apr 28, 2015 at 17:28 GMT
Originally opened as adobe/brackets#11013
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)
The text was updated successfully, but these errors were encountered: