Fractional scales, fonts and hinting

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 &#x2F; 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 different parts of the GUI are scaled disproportionatily. Sloppy apps ignore this, but the devs are quickly notified. 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%. Haiku has had this since the beginning (even BeOS in the 90’s had this). By 2024, almost all non compliant apps have been fixed and support this.<p>What Haiku needs is font setting per screen&#x2F;resolution for multimonitor support. This way you can support mismatched monitors with different factors.

These are good news! I think this was a tough ride for the Gtk developers. Thanks!<p>Background:<p><a href="https:&#x2F;&#x2F;gitlab.gnome.org&#x2F;GNOME&#x2F;gtk&#x2F;-&#x2F;merge_requests&#x2F;6190" rel="nofollow">https:&#x2F;&#x2F;gitlab.gnome.org&#x2F;GNOME&#x2F;gtk&#x2F;-&#x2F;merge_requests&#x2F;6190</a><p>Basically <i>gtk-hint-font-metrics=1</i> was needed with <i>Gtk4</i> on non-HiDPI displays to get crisp text. Thanks to the change from 6190 above it is already <i>automatically</i> applied, when appropriate depending on which display is used. Mixed setups with multiple displays are common and Gtk4 cares about. The whole topic caused a heated issue before - because it depends on your own vision, taste and hardware.<p>Apple avoids trouble and work by always using HiDPI displays. Attach a MacMini to a non-HiDPI display and you could recognize that the font rendering is awkward.

As a long-time developer against GTK (I started using it back in the 1.x days in the late 90s) this is really awesome to see.<p>I enjoyed the side-by-side comparisons of the old vs new renderer, and especially the idea of homing in on particular letters (&#x27;T&#x27; and &#x27;e&#x27;) and extracting them, that really made the improvement clear.<p>Cool stuff, and many thanks to the developers who keep pushing the GTK stack forwards.

I&#x27;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 &#x2F; WRBG displays? There&#x27;s a good thread on the topic here[0], with some people referring to it as &#x27;ClearType 2&#x27; on the MS side [1]. On the oss side I know FreeType theoretically supports this[2], but I can&#x27;t quite figure out how relevant the FreeType backend is to this most recent work.<p>This is great work btw.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;snowie2000&#x2F;mactype&#x2F;issues&#x2F;932">https:&#x2F;&#x2F;github.com&#x2F;snowie2000&#x2F;mactype&#x2F;issues&#x2F;932</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;PowerToys&#x2F;issues&#x2F;25595">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;PowerToys&#x2F;issues&#x2F;25595</a><p>[2]: <a href="https:&#x2F;&#x2F;freetype.org&#x2F;freetype2&#x2F;docs&#x2F;reference&#x2F;ft2-lcd_rendering.html#ft_library_setlcdgeometry" rel="nofollow">https:&#x2F;&#x2F;freetype.org&#x2F;freetype2&#x2F;docs&#x2F;reference&#x2F;ft2-lcd_render...</a>

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&#x2F;after images forces them to be scaled down from an otherwise correct width of 600px to 598px.<p>While not solving the blurriness completely it, removing the border with the inspector helps a lot.<p>I think the remaining blurriness comes from the images using grey scale hinting rather than subpixel hinting (the hinted pixels are not colored)

And still no proper gamma correction.. wich makes the whole thing useless, specially on low-DPI screens<p>Nobody does it properly on linux, despite freetype&#x27;s recommendations.. a shame..<p><a href="https:&#x2F;&#x2F;freetype.org&#x2F;freetype2&#x2F;docs&#x2F;hinting&#x2F;text-rendering-general.html" rel="nofollow">https:&#x2F;&#x2F;freetype.org&#x2F;freetype2&#x2F;docs&#x2F;hinting&#x2F;text-rendering-g...</a><p>It&#x27;s even worse for Light text on Dark backgrounds.. text becomes hard to read..<p>GTK is not alone<p>Chromium&#x2F;Electron tries but is wrong 1.2 instead of 1.8, and doesn&#x27;t do gamma correction on grayscale text<p><a href="https:&#x2F;&#x2F;chromium-review.googlesource.com&#x2F;c&#x2F;chromium&#x2F;src&#x2F;+&#x2F;5332813&#x2F;1..2&#x2F;skia&#x2F;BUILD.gn" rel="nofollow">https:&#x2F;&#x2F;chromium-review.googlesource.com&#x2F;c&#x2F;chromium&#x2F;src&#x2F;+&#x2F;53...</a><p>Firefox, just like Chromium is using Skia, so is using proper default values but ignores it for grayscale text too..<p><a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1882758" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1882758</a><p>A trick that i use to make things a little bit better:<p>In your .profile:<p><pre><code> export FREETYPE_PROPERTIES=&quot;cff:no-stem-darkening=0 autofitter:no-stem-darkening=0 type1:no-stem-darkening=0 t1cid:no-stem-darkening=0&quot;</code></pre>

I don’t have anything expert to add here except this is somehow a shockingly difficult problem.<p>When I boot into windows, the fonts especially in some applications look horrible and blurry because of my high DPI monitor. Windows has like 10 settings you can try to tweak high dpi fonts and man none of them look good. I think my Linux boot on the same machine has much better font smoothness and of course the MacBook is perfect.<p>Somehow most windows systems I see on people’s desks now look blurry as shit. It didn’t use to be this way.<p>I really don’t understand why high dpi monitors cause (rather than solve) this problem and I suspect windows has some legacy application considerations to trade off against but man - windows used to be the place you’d go to give your eyes a break after Linux and now it’s worse!<p>I realize I am ranting against windows here which is the most cliched thing ever but really come on it’s like right in your face!

I wonder if we&#x27;ll ever abandon resolution-based rendering for screens, instead using a PPI&#x2F;DPI vector-based system?<p>Since the 80s I&#x27;ve been wishing for a 300&#x2F;600dpi resolution-independent screen. Sure, it&#x27;s basically like wishing for a magic pony, but I was spoiled by getting a Vectrex[1] for a birthday in the 80s, and I really liked the concept. I know the Vectrex was a different type of rendering to the screens we use today, but I still find it fascinating.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Vectrex" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Vectrex</a>

These comparisons should be presented with a dynamic switching of identically sized images with identically placed text instead of placing slightly different images side by side

When got my first Mac I was astounded when I saw the font rendering there. It&#x27;s really the thing I am missing in my home Linux laptop

The new renderer definitely looks better, but the letters still have something fuzzy about them. They don&#x27;t feel crisp. Is this due to the font or due to the rendering?

For some reason, FreeType broke proper grid-fitting and now requires environment variable FREETYPE_PROPERTIES=truetype:interpreter-version=35 to activate it.

&gt; The idea is that we just place glyphs where the coordinates tell us, and if that is a fractional position somewhere between pixels, so be it, we can render the outline at that offset just fine. This approach works—if your output device has a high-enough resolution (anything above 240 dpi should be ok).<p>So it just requires 6x more memory, GPU power and HDMI&#x2F;DP bandwidth and prevents usage of large monitors ...

This is fantastic work - there&#x27;s a huge difference here for my eyes at least.

Font rendering in GTK 3 was pretty good, then they broke it in GTK 4, and even with new renderers fonts are not up to par with good old GTK 3.

Have the patents expired?

Honestly I&#x27;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&#x27;s native resolution. (So my &quot;3008x1692&quot; 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.

How does KDE (or is it Qt) font rendering compare?

The Year of Linux on Desktop.

I don&#x27;t understand this.<p>It seems that they:<p>- Fail to properly position glyphs horizontally (they must obviously be aligned to pixels horizontally and not just vertically)<p>- Fail to use TrueType bytecode instead of the autohinter<p>- Fail to support subpixel antialiasing<p>These are standard features that have been there for 20 years and are critical and essential in any non-toy software that renders text.<p>How come GTK+ is so terrible?<p>EDIT: they do vertical-only rather than horizonal-only. Same problem, needs to do both.