Finally had the opportunity to play around with Chrome and figure this out. They disable subpixel positioning by default for seemingly no reason. Building a patched version of Chromium with it enabled fixes the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=824153#c7

There was also a patch proposal for Cairo at the end of last year which added subpixel positioning (https://lists.cairographics.org/archives/cairo/2018-November/028796.html), but it didn't get any traction because it broke some tests. The original dev of the patch stepped away and no one picked it up since. I might pick it up, but given that it took me half a year to carve out some time to rebuild Chromium and fixing Cairo would not be as simple as commenting out a few lines, I wouldn't bank on it. It would make for a fantastic and rather impactful GSoC project proposal.

From the parent discussion on Chromium's bug tracker (https://bugs.chromium.org/p/chromium/issues/detail?id=740385#c18), it looks like kerned glyphs get non-integer advance widths, which in turn get rounded in a way that breaks kerning and this results in the original issue I reported here. Subtracting a near-whole pixel in these cases (flooring instead of rounding) actually does make it look better, but I don't know if that would break other use cases in FreeType. If someone can point me towards files/functions to play around with, I would be happy to do so.

How many whole pixels would you like to remove in ftdiff/ftstring rendering? At what whole ppem value?

If you do not have a concrete answer, this is not a FreeType problem. Simple as that.

You do agree that removing the whole pixel between "Aud" and "iting" is too much, don't you? You what to remove like half a pixel. Right? This is called subpixel positioning. I thought that Chrome actually implements it, but I do not know how to enable it.

I am glad that you like vanilla autohinting - use it then. Again, I doubt that this is FreeType issue. Please open the bug with Chrome and continue the layout discussion there.

PS. I glanced at the Infinality patch. It is wrong at least in applying gamma correction to the coverage/alpha map. Gamma correction applies to colors. Whoever wrote it does not understand the basics of blending. Please do not use it.

Not all Infinality patches were integrated: https://github.com/archfan/infinality_bundle/blob/master/01_freetype2-iu/0001-infinality-2.9.1-2018.06.21.patch

Anyway, that's not relevant to this discussion. I built clean FreeType, removed fontconfig-infinality, removed my own tweaks and rebooted to confirm the issue on a clean setup prior to reporting it. I also used that for my screenshots. This is why a retake at 72dpi had to wait - I am avoiding doing something stupid or cutting corners here.

Is v40 not already supposed to ignore x-direction hinting based on https://www.freetype.org/freetype2/docs/subpixel-hinting.html ?

I would also argue that this is less about "like" and more about "right". "Aud" and "iting" almost look like two separate words in that web page and this only occurs on the FreeType's TrueType hinting interpreter, even on Liberation fonts. Doesn't occur on the autohinter (except for a single weird case at fractional sizes), doesn't occur without hinting, doesn't occur on the Windows hinting interpreter.

72dpi retake attached.

My original screenshots have red boxes to point out the precise letter pairs that are broken.

For example, spacing between "d" and "i" in "Auditing Binaries" looks like too much in ft-diff, like there is an extra vertical 1px line between them. I added a zoomed-in ftdiff screenshot with the extra 1px removed compared to v40 and the autohinter. Looks like v40 (and v35, and v38) indeed inserts a near-white vertical line of pixels on the rightmost end of "d", which results in this artefact.

With +0.2px letter-spacing applied in Chrome the additional perceived whitespace between these letters sticks out like a sore thumb. Other examples may be less obvious, but clearly visible in side-by-sides with the autohinter and Windows in my previous screenshots nonetheless:

Willing
   ^^

going
  ^^

enough
 ^^

Auditing Binaries
  ^^        ^^

Vulnerability Discovery
^^     ^^

Toolkit Prep
  ^^

Operational Tradecraft
       ^^

Switching to 72dpi puts me on fractional ppems (18.67 instead of 19) while 96dpi doesn't. I am on Infinality patches and custom set of fontconfigs as my daily driver so a 72dpi retake of demos will have to wait until the weekend when I get a moment to move the packages and configs around to their vanilla state and back again. I don't think it will make a difference though.

As a side note, since this is where I don't know what I'm talking about: if it provides much better outputs, would the Windows approach to integer ppems not make more sense? Otherwise I would be happy to follow it up with projects up the rendering stack if that is where the fix needs to be applied, as long as it solves the actual problem.

On that page, font-size is set to 16px for the main copy and 14px for the left-hand menu.

The results vary at different sizes. 14pt/19ppem in ftdiff definitely gives me the same issue, except for the extra letter spacing that makes it more apparent on the web page, so it's less obvious.

With ftdiff I found that auto-hinter suffers from the same problem at 13.5pt (18ppem) using 96dpi, while the unhinted version always renders correctly.

With v40, 12.0pt/16ppem at 96dpi renders correctly, so does 13.0pt/17ppem and 13.5pt/18ppem, even though at this point the font suddenly becomes bold. The issue becomes visible at 14pt/19ppem, then disappears again at 20.

On the web page, playing around with font-size and letter-spacing properties makes the issue go away with letter-spacing:0px up until font-size:19px, where it re-appears again. With letter-spacing:0.2px the issue appears seemingly at any font-size value, I've tried 8px to 16px. I also tried playing with the font-family and observed similar behavior on Tahoma, Verdana, Ubuntu and even Liberation Sans (v2) font, so I think it is a general issue with the hinting engine rather than MS giving us a headache with Arial. There is no such behavior on Windows: with and without additional 0.2px letter-spacing you get two different outputs, but both render correctly.

Could it be that some small calculation or approximation error accumulates, remains invisible until 19ppem, but additional letter-spacing amplifies it enough to make it visible at all ppems?

I thought this might be a subpixel rendering problem, so I compiled FreeType without it and still ended up with the same issue. I have now tested this on the git version and there is no change in this behavior.

First of all: For hinted TrueType fonts, the ppem value is always an integer.  In your large image, the main font size is 16ppem.

`ftview' is not the right tool to check good font layout; you should rather use `ftdiff' instead.

Attached is the left column output of

  ftdiff -w 1800 -h 600 -s 12 -r 96 -f txt arial.ttf

I've used the current git of FreeType (built with `make devel; make'.

As you can see, there isn't any issue with the font, and the result very closely resembles the Windows output in your image (except the slightly different width of the word spaces).

Please give more details and images so that we are exactly using the same environment.  Note that I've tried with a very old and quite recent version of arial.ttf; it doesn't make a visual difference for the given example, AFAICS.

As per the attached image, v35, v38 and v40 all result in broken glyph widths. The issue is not present in the autohinter or with hinting disabled, but both have even worse results (bold and blurry fonts respectively).

Latest Chrome was used in all cases. Vanilla Windows 7 Chrome rendering was used as a reference since the font is Arial (I don't have Helvetica installed). FreeType version is 2.9.1 with subpixel rendering, table validation and TT engine selection enabled. Arial TTFs were copied over from that same Windows 7 instance, so it is the exact same font file in all cases.

Fontconfig used:

<match target="font">
    <edit name="hinting" mode="assign">
        <bool>true</bool>
    </edit>
    <edit name="hintstyle" mode="assign">
        <const>hintfull</const>
    </edit>
    <edit name="antialias" mode="assign">
        <bool>true</bool>
    </edit>
    <edit name="embeddedbitmap" mode="assign">
        <bool>false</bool>
    </edit>
    <edit name="autohint" mode="assign">
        <bool>false</bool>
    </edit>
    <!-- Italic variants look jagged without forcing the DPI. Default DPI of FreeType is 72. Verify with `fc-match` if in doubt. -->
    <edit name="dpi" mode="assign">
        <int>96</int>
    </edit>
</match>

Something felt weird about rendering of the standard web fonts and I finally hunted it down when I came across a GitBook page that slightly widens letter-spacing (by 0.2px), which makes it strikingly obvious what is wrong.

The same can be reproduced with ftview using Arial at 14 ppem and 96dpi. It appears that strength of the artefact varies with different DPI settings at different ppems. For example, with 72dpi issue is much more apparent at 19ppem instead of 14.

ftview -w 800 -h 600 -e unic -r 96 -m "Auditing Binaries" 14 /usr/share/fonts/windows/arial.ttf

Alternatively, just open any GitBook in Chrome with full v40 hinting enabled for Arial. One used in the example is https://trailofbits.github.io/ctf/.