OTF Devanagari glyphs suffer vertical distortion at small font sizes when hinting is active

[ss141309]

When rendering the glyphs at a small size (< 20pt), some of them appear to be vertically disjointed from the surrounding characters. This issue disappears when the hinting is turned off.

Incorrect rendering of "ङ्क" and "छ" as can be seen in emacs at 16pt.

Steps to Reproduce:

1. Open the font such as "TiroDevaHindi-Regular.otf" in ftinspect: ftinspect TiroDevaHindi-Regular.otf
2. Go to the "Continuous View" tab and select the Text Source field to "Text String"
3. Type in something like, "कछ" and then start decreasing the size you will notice the incorrect rendering
4. If the hinting is turned off in the left pane, the issue disappears

Screencast_20260303_032736.webm

System Info:
Operating System: CachyOS Linux
KDE Plasma Version: 6.6.1
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Freetype Version: 2.14.1
Kernel Version: 6.19.5-3-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics
Memory: 16 GiB of RAM (13.5 GiB usable)
Graphics Processor 1: AMD Radeon Graphics
Graphics Processor 2: NVIDIA GeForce GTX 1650

[tiroj]

Thanks for the detailed report.

This is bizarre in a few ways:

The .otf font is a CFF-flavour font using Adobe’s hinting model. That model uses some vertical alignment zones and stem values, and stem hints, that are interpreted by the rendering engine. Within that model, the hints themselves do not have control over the kind of distance shown in your image. [Even in the more explicit model used in the traditional TrueType instruction set, shifting a glyph by more than a pixel isn’t trivial or usual.]

The build process for this font uses autohinting libraries, which generally do a pretty good job. I have not observed the reporrted behaviour in local test environments, including apps using Adobe’s own rendering engines.

I have taken a look at how the vertical alignment zones are written in the CFF table, and don’t see any problem. There is a 13 unit top alignment zone beginning at 620 units, which is the common height of the top of the Devanagari head stroke shared by all the letters and conjuncts. There’s nothing I can see in the font that would be causing the top of some such glyphs to be alligned differently than others.

[ss141309]

Hi John,
I think there is an issue with the font itself, rather than the font renderer.
While debugging the issue I came across the Type 1 Font specification which states (under the "Blue Values" heading:
The first pair is the baseline overshoot position and the base- line. This is a bottom-zone
This should apply to FamilyBlues also.

Now the Blues values in the TiroDevaHindi-Regular.otf are:

<Private>
        <BlueValues value="-20 0 473 492 620 633 699 717 755 755"/>
        <OtherBlues value="-16 1 -259 -242 302 314"/>
        <FamilyBlues value="458 473 516 526 566 579 692 704 750 757 848 858"/>
        <FamilyOtherBlues value="-262 -248 -199 -195 -17 1 326 334 368 381"/>
        <BlueScale value="0.047619"/>
        <BlueShift value="7"/>
        <BlueFuzz value="1"/>
      ..... other values
</Private>

The First pair in the FamilyBlues array (458, 473) does not seem to be a bottom-zone. This causes a mismatch between the BlueValues and FamilyBlues values.

Some glyphs such as ङ्क (glyph id 969) have hint values like (410, 482) that gets mapped to the pair (516, 526) even though it should match to (458, 473). This causes the (545, 620) hints to never apply for these glyphs.

I then tried inserting the pair (-20, 0) at the first position in the FamilyBlues array, this largely fixed the issue except at sizes 14 and 16px.

You can read more of my analysis here:
https://gitlab.freedesktop.org/freetype/freetype/-/issues/1391#note_3375658

What do you say, am I correct?

Thank You.

[tiroj]

Thanks. I will check and fix alignment of BlueValues and FamilyBlues in the sources, but FamilyBlues shouldn’t be a factor at all what in what you are showing, as only one weight/style is present. FamilyBlues are supposed to be used to align different members of a font family, and shouldn’t be affecting a single font.

If the issue remains in sizes 14 and 16px, something else is a factor, and I am still not able to reproduce the issue in other environments.

[ss141309]

Thanks. I will check and fix alignment of BlueValues and FamilyBlues in the sources, but FamilyBlues shouldn’t be a factor at all what in what you are showing, as only one weight/style is present. FamilyBlues are supposed to be used to align different members of a font family, and shouldn’t be affecting a single font.

Even when only a single weight variant is present, the FamilyBlues values does get applied. See

If the issue remains in sizes 14 and 16px, something else is a factor

If I change the FamilyBlues to have the exact same values as the BluesValues, the issue disappears for all sizes (There may be something broken which my eyes fail to see)

and I am still not able to reproduce the issue in other environments.

I had installed a win11 VM and tried the font in Adobe Illustrator, I could see the issue there too.

[tiroj]

I have pushed v1.65, which fixes some obvious incompatibilities in the source blue zones for all the fonts. However, note that the -20 0 value showing up at the beginning of the local font BlueValues is not in the sources. This seems to be being written by one of the tools used to compile the font. The actual baseline zone in the fonts is the -16 1 value listed in the OtherBlues set (which captures the flex of the Latin baseline serifs).

Please re-test with the new 1.65 release and let me know if the display issue remains.

[ss141309]

In the new release, everything seems to be in order, except at 13px.

[tiroj]

Thanks. I have been discussing some aspects of the CFF hinting model with colleagues, including people from Adobe, and have a few more things to investigate. There may be a tool issue involved, as well as a necessary changing in how the hinting zones are specified in the source.

[ss141309]

Great! Whatever happens, do keep me posted, I have also grown interested in this issue.

Also, ig the freetype side of the issue should be closed now?