[maxdamantus]

I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully.

Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted).

In case anyone's wondering what properly hinted text looks like, here's a screenshot [2]. This currently relies on setting the environment variable `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, possibly some other configuration through fontconfig, and using a font with good hinting instructions (eg, DejaVu Sans and DejaVu Sans Mono in the screenshot).

My suspicion is that Windows moved away from font hinting after XP because it's very hard to create fonts with good sets of hinting instructions (aiui, OTF effectively only allows something like "autohinting"), so in the modern world of designer fonts it's easier to just have everyone look at blurry text. Some other minor reasons would be that UI scaling in Windows sometimes (or always?) introduces blurring anyway, and viewing raster images on screens of varying resolutions also introduces scaling blur.

[0] Windows still has a way to enable it, but it disables antialiasing at the same time. This is using an option called "Smooth edges of screen fonts" in "Performance Options"). This basically makes it look like XP, which imo is an improvement, but not as good as FreeType which can do hinting and antialiasing at the same time.

[1] https://freetype.org/freetype2/docs/hinting/subpixel-hinting...

[2] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[AndriyKunitsyn]

>In case anyone's wondering what properly hinted text looks like, here's a screenshot

I'm not an expert, but - I'm sorry, it's not.

The point of hinting is to change the shape of the glyphs so the rasterized result looks "better". What "better" is, of course, purely subjective, but most people would agree that it's better when perceived thicknesses of strokes and gaps are uniform, and the text is less blurry, so the eye can discern the shapes faster. I don't think that your rendering scores high points in that regard.

I'll take a phrase from your rendering: "it usually pays" [0]. I don't like it, I'm sorry. The hinter can't make up its mind if the stroke width should be two pixels wide, or three pixels with faint pixels on the sides and an intense one in the center - therefore, the perceived thicknesses vary, which increases eye strain; "l"s are noticeably different; "ys" at the end clumped together into one blurry thing; and there's a completely unnecessary line of faint pixels on the bottom of the characters, which hinting should have prevented.

The second line is how it looks on Windows on 150% scale. Verdana is a different font, so it's an unfair comparison (Verdana was designed specifically to look good on low resolutions), and the rainbows can be off-putting, but I still think the hinter tucks the shapes into pixels better.

Maybe I don't understand something, or maybe there's a mistake.

[0] https://postimg.cc/cKCQR60F

[maxdamantus]

I'm not entirely sure how you got that first line, but if it's derived from my image, your system must be scaling the image, which introduces blur. Since you mentioned a 150% scale, I'm guessing your image viewer is rendering each pixel in my image as 1.5 pixels (on average) on your screen, which will explain the scaling/blurring, making it difficult to demonstrate proper hinting on your screen with raster images (I alluded to this in my previous post).

Here's an updated version of your image, with the actual pixel data from my image copied in, at 8x and 1x scale [0]. It should be possible to see the pixels yourself if you load it into a tool like GIMP, which preserves pixels as you zoom in.

It should be fairly clear from the image above that the hinting causes the outlines (particularly, horizontal and vertical lines) to align to the pixel grid, which, as you say, both makes the line widths uniform and makes the text less blurry (by reducing the need for antialiasing; SSAA is basically the gold standard for antialiasing, which involves rendering at a higher resolution and then downscaling, meaning a single physical pixel corresponds to an average of multiple pixels from the original image).

Out of interest, I've done a bit of processing [1] to your image to see what ClearType is actually doing [2], and as described in the FreeType post I linked, it seems like it is indeed using vertical hints (so the horizontal lines don't have the colours next to them—this is obvious from your picture), and it seems like it is indeed ignoring any horizontal hints, since the grey levels around the vertical lines are inconsistent, and the image still looks horizontally blurry.

I might as well also link to this demo I started putting together a few years ago [3]. It uses FreeType to render with hinting within the browser, and it should handle different DPIs as long as `devicePixelRatio` is correct. I think this should work on desktop browsers as long as they're scaling aware (I think this is the case with UI scaling on Windows but not on macOS). Mobile browsers tend to give nonsense values here since they don't want to change it as the user zooms in/out. Since it's using FreeType alone without something like HarfBuzz, maybe some of the positioning is not optimal.

[0] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[1] After jiggling the image around and converting it back from 8x to 1x, I used this command to show each RGB subpixel in greyscale (assuming the typical R-G-B pixel layout used on LCD computer monitors):

    width=137; height=53; stream /tmp/image_1x.png - | xxd -p | sed 's/../&&&/g' | xxd -r -p | convert -size $((width*3))x$((height)) -depth 8 rgb:- -interpolate nearest-neighbor -interpolative-resize $((100*8))%x$((300*8))% /tmp/image_8x_rgb.png

[2] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[3] https://maxdamantus.eu.org/ftv35-220719/site/

[AndriyKunitsyn]

>I'm guessing your image viewer is rendering each pixel in my image as 1.5 pixels

Gosh, you are right, I'm so sorry, it really was my PC. Yes, it really is much nicer once I looked at the real pixels of your screenshot. Thank you for the answer.

[raggi]

I really want hinting, subpixel and anti-aliasing available on all systems, and i want to pick the appropriate set of techniques based on the dpi and font size to minimize error, fuzzy excesses, and balance computation cost. Obviously we still don't all have high DPI all the time and likely won't for a long while. Apple dropping support was a disaster, and I currently run Apple devices plugged into to regular DPI screens with a slightly downsized resolution to trick it into rendering in a sane way, but it's a bonkers process that's also expensive and unnecessary for non-font paint work.

That said, one of the horrors of using the old font stacks, and in many ways the very thing that drove me away from fighting Linux desktop configurations for now about 10y of freedom from pain, was dealing with other related disasters. First it's a fight to even get to things being consistent, and as seen in your screenshot there's inconsistency between the content renders, the title, and the address bar. Worse though the kerning in `Yes` in your screenshot is just too bad for constant use for me.

I hope as we usher in a new generation of font tech, that we can finally reach consistency. I really want to see these engines used on Windows and macOS as well, where they're currently only used as fall-back, because I want them to present extremely high quality results on all platforms, and then I can use them in desktop app work and stop having constant fights with these subsystems. I'm fed up with it after many decades, I just want to be able to recommend a solution that works and have those slowly become the consistently correct output for everyone everywhere.

[emidoots]

If you want consistency, you only need to convince everyone to switch to a single font renderer (e.g. freetype). That won't happen, though, because OS font renderers have quirks that cause them to render the same things in subtly different ways, and users have come to unintentionally expect those quirks. Even if rendering is 'better' in one app.. if it doesn't match the others or what the user is used to.. then it won't 'feel native'.

Maybe if what freetype is pushing for (fonts are WASM binaries) continues to take hold, and encompass more of fonts, we'll find more consistency over time though

[drott]

Yes, Skrifa executes TrueType hints and has a new autohinting implementation written in Rust. We use these modes in Chrome.

[maxdamantus]

Hmm.. I tried using the "tools/viewer/viewer --slide GM_typeface_fontations_roboto" example in the skia repository earlier (swapping out the Roboto font for DejaVuSans, since the Roboto font doesn't seem to properly hint horizontally [0]), but the result [1] seems to only be hinted vertically, so similar to the FreeType "v40" interpreter, which supposedly ignores horizontal hints.

Admittedly I haven't looked into how the setup is configured, and haven't tried it in Chrome, so maybe it's still possible to enable full hinting as intended by the font somehow.

[0] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[1] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[drott]

In the viewer, press '/' and configure hinting to full, or modify the source in gm/fontations.cpp and call SkFont::setHinting(SkFontHinting::kFull) or kNormal.

[maxdamantus]

Thanks for the reply. I was able to play around with the settings there, but even when enabling full hinting it's still only hinting vertically (I think this is what it was doing by default, as in my screenshot—this is similar to what the FreeType v40 hinter does, which is used by default from 2.7 as mentioned in my first post).

EDIT: looking into the FreeType code, it looks like the v35 mode turns on the `NO_SUBPIXEL_HINTING` flag [0], which might have also been ported over to skrifa [1]? Though there are "(always enabled)" comments throughout the code suggesting that it can't be configured.

Maybe later I'll try forcing the option and see what happens.

[0] https://github.com/freetype/freetype/blob/5d4e649f740c675426...

[1] https://github.com/googlefonts/fontations/blob/f808570ce1939...

[nyanpasu64]

> In addition, before the integration into Chromium, we ran a wide set of pixel comparisons in Skia, comparing FreeType rendering to Skrifa and Skia rendering to ensure the pixel differences are absolutely minimal, in all required rendering modes (across different antialiasing and hinting modes).

I'm hoping (but not sure) Skrifa will support hinting (though I'm not sure how it interacts with fontconfig). I noticed your screenshot uses full hinting (a subjective choice I currently don't use on my machines), presumably with integer glyph positioning/advance which isn't scale-independent (neither is Windows GDI), though this is quite a nonstandard configuration IMO.