Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fractional scales, fonts and hinting

blog.gtk.org

Post reply on HN
Print view View original

21–30 of 117 posts

Re: Fractional scales, fonts and hinting

#21

Post by WhyNotHugo »

smallstepforman wrote: post #14

Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so…

This sounds very much like using `em` units in CSS. 1em = the width of the letter "m". So it scales proportionally to font size.

Relative units like this are usually considered best practice, because of the exact reasons that you've listed.

Re: Fractional scales, fonts and hinting

#22

Post by darkwater »

onli wrote: post #7
ho_schi wrote: post #4

These are good news! I think this was a tough ride for the Gtk developers. Thanks! Background: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 Basically gtk-hint-font-metrics=1 was needed with Gtk4 on non-HiDPI displays to get crisp text. Thanks to the change from 6190 above it is already automatically applied, when appropriate depending on which display is used. Mixed setups with multiple displays are commo…

Reading it up, heated issue is putting it midly. That was a complete shitshow, with two gnome devs - and one from redhat specifically - not accepting the obviously awful font rendering as an issue and continuinously insulting the reporters. God I hate those type of Foss devs. And then on the other hand you have finally a seemingly great solution, despite their sabotage. So, yeah gnome?

Mmmh do you mean https://gitlab.gnome.org/GNOME/gtk/-/issues/3787 ? Because the mentioned MR [1] discussion seems calm?

[1] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190

Re: Fractional scales, fonts and hinting

#23

Post by ben0x539 »

robinsonb5 wrote: post #9
onli wrote: post #7

Earlier quoted context omitted.

Reading it up, heated issue is putting it midly. That was a complete shitshow, with two gnome devs - and one from redhat specifically - not accepting the obviously awful font rendering as an issue and continuinously insulting the reporters. God I hate those type of Foss devs. And then on the other hand you have finally a seemingly great solution, despite their sabotage. So, yeah gnome?

I read the post using Firefox on Windows, and even though I've been aware of the font rendering controversy for a while, I was actually shocked by just how huge the difference was between the crisp, properly rendered text in the article and the font rendering in the "before" screenshot.

Yeah it's definitely an improvement, but even with the "after" screenshot I can't imagine voluntarily using this % scaled rendering. I'm going to turn into a bitmap font absolutist.

Re: Fractional scales, fonts and hinting

#25

Post by black3r »

Honestly I'd love it if Linux just implemented a solution similar to what Apple does, which is rendering everything at 2x and then downscaling it to screen's native resolution. (So my "3008x1692" on a 4K screen is actually rendered at 6016x3384). Modern GPUs are strong enough to do this without breaking a sweat, and the result is very crispy and functional. Fractional scaling could still exist as a fallback for older systems.

Re: Fractional scales, fonts and hinting

#26

Post by Someone »

smallstepforman wrote: post #14

Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so…

> So you end up with text larger but GUI widgets can grow dis-proportionatily, so you can fine tune what is 125%, 150%, etc. Eg. ScrollBar can be 125%, toolbar 150%, text 233%

Who’s the “you” in here? If it’s the end user, I don’t think it’s a better solution for the general population.

Re: Fractional scales, fonts and hinting

#27

Post by grandinj »

smallstepforman wrote: post #14

Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so…

This is a very good idea

Re: Fractional scales, fonts and hinting

#28

Post by jeppester »

I was a bit puzzled that the images were so blurry compared to the surrounding text. Then I realized that the 1px border around the before/after images forces them to be scaled down from an otherwise correct width of 600px to 598px.

While not solving the blurriness completely it, removing the border with the inspector helps a lot.

I think the remaining blurriness comes from the images using grey scale hinting rather than subpixel hinting (the hinted pixels are not colored)

Re: Fractional scales, fonts and hinting

#29

Post by jsheard »

boomskats wrote: post #20

I'm curious - when you were doing research into the mechanics of hinting options, did you stumble onto any relevant discussion around allowing custom pixel geometries to be defined, to enable hinting on modern OLED / WRBG displays? There's a good thread on the topic here[0], with some people referring to it as 'ClearType 2' on the MS side [1]. On the oss side I know FreeType theoretically supports this[2], but I can'…

AIUI the trend has been towards GUI frameworks dropping support for subpixel AA altogether, since that simplifies so many things[1], so I'm not holding my breath for the current limitations around unusual subpixel layouts being fully resolved on any platform. Apple made the switch to greyscale-only AA years ago, Microsoft is mid-transition with their newer GUI toolkits ignoring the system Cleartype setting and always using greyscale AA, and the GTK renderings in the OP are greyscale too. They're assuming that people will just get a HiDPI display eventually and then greyscale AA is good enough.

[1] https://faultlore.com/blah/text-hates-you/#anti-aliasing-is-...

Re: Fractional scales, fonts and hinting

#30

Post by Someone »

WhyNotHugo wrote: post #21
smallstepforman wrote: post #14

Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so…

This sounds very much like using `em` units in CSS. 1em = the width of the letter "m". So it scales proportionally to font size. Relative units like this are usually considered best practice, because of the exact reasons that you've listed.

In user dialogs, Windows does/used to do that, too. https://learn.microsoft.com/en-us/windows/win32/api/winuser/...:

“The horizontal base unit returned by GetDialogBaseUnits is equal to the average width, in pixels, of the characters in the system font; the vertical base unit is equal to the height, in pixels, of the font.

The system font is used only if the dialog box template fails to specify a font. Most dialog box templates specify a font; as a result, this function is not useful for most dialog boxes.

For a dialog box that does not use the system font, the base units are the average width and height, in pixels, of the characters in the dialog's font. You can use the GetTextMetrics and GetTextExtentPoint32 functions to calculate these values for a selected font. However, by using the MapDialogRect function, you can avoid errors that might result if your calculations differ from those performed by the system.”

Post reply on HN