Open core-ai-bot opened 3 years ago
Comment by peterflynn Thursday Dec 04, 2014 at 09:00 GMT
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.
Comment by redmunds Thursday Dec 04, 2014 at 15:32 GMT
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.
Comment by peterflynn Thursday Dec 04, 2014 at 18:24 GMT
@
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.
Comment by MarcelGerber Wednesday Dec 10, 2014 at 19:57 GMT
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
Comment by JeffryBooher Wednesday Dec 10, 2014 at 20:10 GMT
@
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
Comment by arrbie Monday May 04, 2015 at 15:59 GMT
@
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.
Comment by nethip Monday May 04, 2015 at 17:21 GMT
@
arrbie See my comment https://github.com/adobe/brackets/issues/11013#issuecomment-98784180
Issue by peterflynn Thursday Dec 04, 2014 at 08:19 GMT Originally opened as https://github.com/adobe/brackets/issues/10083
In the new CEF, text seen in the editor is spaced noticeably farther apart:
(1547) (2171)
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:
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.