Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

[CEF 2171] Code editor font has considerably looser spacing / kerning #10083

Open
peterflynn opened this issue Dec 4, 2014 · 7 comments
Open

Comments

@peterflynn
Copy link
Member

In the new CEF, text seen in the editor is spaced noticeably farther apart:

cef-1547-text (1547)
cef-2171-text (2171)
cef-text-comparison

It's subtle -- 39 chars in new CEF take up the same space as 40 chars in the old one -- but it definitely jumps out at me in the overall visual impression every time I switch between the builds.

That might beg the question how a fixed-width font can change size by an increment that's not a multiple of the number of characters (i.e. increase every char's width by 1px, or none of them). The answer is that glyphs are now fractional width in the new CEF:

cef-1547-zoomed
cef-2171-zoomed

Notice how in the first image (1547), the subpixel AA looks the same for every copy of the character. But in the second image (2171), the AA gradually "shifts phase" in a cycle of 5 chars -- so over the course of 5 chars, the char shifts over one full pixel.

In other words: in the old CEF chars were exactly 7px wide; in the new CEF, they're 7.2px wide.

@peterflynn
Copy link
Member Author

It's not clear that there's much we can do about this, short of trying to roll a new version of SourceCodePro with different hinting. There's no way in CSS to turn off subpixel positioning (fractional char sizes) without also turning off subpixel AA -- even though at the OS level they can definitely be controlled independently. (For more on the Chromium side, see this comment and this possibly related bug).

OTOH, native code editors all seem to consistently disable subpixel positioning (while keeping subpixel AA) -- Sublime, Visual Studio, Notepad++, and even Notepad do this. It's a bummer that we can't, but it may well be a fact of life for now.

@redmunds
Copy link
Contributor

redmunds commented Dec 4, 2014

We could try updating default font size so width is an integral value, and also try to adjust increase/decrease font size amount so it stays on integral width values (though that may create the same problem for height). Of course, all bets are off if someone specifies a custom font size in Theme dialog.

@peterflynn
Copy link
Member Author

@redmunds Duh, good point! If we change the font size to 11.666666667px, then for all practical purposes it will consistently stay integer-sized. That is slightly tricky with preferences, which currently assume a platform-agnostic default font size, but it may be worth looking into anyway.

@marcelgerber
Copy link
Contributor

I took a look at Atom (as they have to deal with the same issue) and saw that they disable subpixel font scaling directly in Blink: https://github.com/atom/atom-shell/blob/b6b6fc3bfd38c4f5bba91b5f58c11c8331f60047/atom/renderer/atom_renderer_client.cc#L220

cc @JeffryBooher

@JeffryBooher
Copy link
Contributor

@marcelgerber CEF doesn't give us access to blink settings unfortunately; we would need to add this to the serttings API and then submit this back to the core of CEF

@arrbie
Copy link

arrbie commented May 4, 2015

@peterflynn, I measured the exact same line of rendered text (same glyphs, same font, same size) in Brackets 1.3.0-16022 and BBEdit, or any other text editor on a Mac. And they all came out the exact same geometric width. However, it was much more fuzzy and nearly unreadable in Brackets. So there's more to this problem than just "fractional horizontal text bloating".

Rendered in Menlo Regular 11px => 875 px width in both text editors.
screen shot 2015-05-04 at 17 55 56

@nethip
Copy link
Contributor

nethip commented May 4, 2015

@arrbie See my comment #11013 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants