Bug 1853937

For completeness sake, please add add "f" and "t" to your images.

Created attachment 1715542 [details]
Sample renderings

Updated as requested

(In reply to James from comment #2)
> Created attachment 1715542 [details]
> Sample renderings
> 
> Updated as requested

Hold on, ignore those, I had the ligatures turned off...

Created attachment 1715546 [details]
Sample renderings in Gtk3 font chooser, at 8, 9, 10, 11 and 14 pt

...this time with the ligatures.

Curiously, the ligatures outside of Unicode are the ones loaded without hinting. Which program is this? I do not see the issue with ftview from freetype-demos.

The samples are all screenshots from the sample area a Gtk3 font selection box -- such as you can get e.g. in Gedit.

The glyphs are hinted in the font. It must be Pango which loads them unhinted (FT_LOAD_NO_HINTING). Please reassign to Pango.

(In reply to Alexei Podtelezhnikov from comment #7)
> The glyphs are hinted in the font. It must be Pango which loads them
> unhinted (FT_LOAD_NO_HINTING). Please reassign to Pango.

Done. I've changed the title -- does this accurately summarise the situation?

Could you provide the expected result?

And how do you produce the sample image?

Created attachment 1715700 [details]
My fonts.conf

Created attachment 1715702 [details]
Large point-size expected result (generated in Inkscape)

(In reply to Peng Wu from comment #9)
> Could you provide the expected result?
> 
> And how do you produce the sample image?

The sample image was produced by taking screenshots from a Gtk3 font chooser. fonts.conf attached. Using RGB subpixel anti-aliasing with slight hinting.

The expected result is what's seen in the 9pt and 10pt samples: the horizontal stroke of the ti and tt ligatures lines up with that of a single t. Note in the 8pt, 11pt and 14pt samples the horizonal stroke on the ligature is a pixel or so below that on the single t.

I've also attached a rendering of "t ti tt" at large point-size rendered in Inkscape, just to confirm that the glyphs' horizontal strokes do align geometrically.

Could you use pango-view to produce the actual result?

And use ftview to produce the expected result for comparison.

easy to reproduce with this:
pango-view --markup -t "<span font_desc='Lato 8'>8pt t ti fi tt</span>^M<span font_desc='Lato 9'>9pt t ti fi tt</span>^M<span font_desc='Lato 10'>10pt t ti fi tt</span>^M<span font_desc='Lato 11'>11pt t ti fi tt</span>^M<span font_desc='Lato 14'>14pt t ti fi tt</span>"

and

ftview -e unic -m "t ti fi tt" -k5 14 /usr/share/fonts/lato/Lato-Regular.ttf

Created attachment 1720101 [details]
Actual result with the helping line

This would demonstorate the issue

Created attachment 1720732 [details]
Rendering from pango-view --markup

Provided in part fulfilment of the NEEDINFO. This is with pango-1.47.0-1.fc33.x86_64.

(In reply to Akira TAGOH from comment #14)

> ftview -e unic -m "t ti fi tt" -k5 14 /usr/share/fonts/lato/Lato-Regular.ttf

When I tried this, it didn't use the ligatures -- not sure how to make them show up as some of these are non-Unicode ligatures.

Ah, you're right. I'm not sure even if ftview is capable to render the ligatures, but how about this then:

hb-view --text "t ti fi tt" /usr/share/fonts/lato/Lato-Regular.ttf

We can confirm it works on harfbuzz layer.

(In reply to Akira TAGOH from comment #18)
> Ah, you're right. I'm not sure even if ftview is capable to render the
> ligatures, but how about this then:
> 
> hb-view --text "t ti fi tt" /usr/share/fonts/lato/Lato-Regular.ttf
> 
> We can confirm it works on harfbuzz layer.

The renderings from hb-view looks OK to me -- it's difficult to tell because it seems to be using different font size units to pango-view, and I'm not sure it's applying the same anti-aliasing and hinting settings.

Right, I think we need to use similar settings in hb-view for comparison.

It seems this bug is triggered by different hinting style.

I tried with different hinting style like none/medium/full,
the ligatures aligned correctly.

But for hinting style with auto/slight, this bug happens.

Here are the testing command:
$ pango-view --text="t ti fi tt" --hinting=full --font="Lato 8"

Created attachment 1728793 [details]
ftview screenshot

(In reply to Peng Wu from comment #21)
> But for hinting style with auto/slight, this bug happens.

I can confirm that FreeType autohinter ignores non-Unicode ligatures, see attached. Please change the component back to FreeType.

Fedora comes with FreeType without HarfBuzz [https://savannah.nongnu.org/bugs/?59452]. So there is a fix but it is a circular dependency.

(In reply to Alexei Podtelezhnikov from comment #23)
> Fedora comes with FreeType without HarfBuzz
> [https://savannah.nongnu.org/bugs/?59452]. So there is a fix but it is a
> circular dependency.

Understood -- I just rebuild the freetype RPM locally with harfbuzz enabled in the spec and the ligatures look correct.

Couldn't this be worked around by creating a package like freetype-nonharfbuzz built without HarfBuzz, use that purely as a builddep for the harfbuzz package in the Fedora buildsystem, and then build a freetype package depending on harfbuzz?

We may need some tweaks in the spec file to enable bootstrap. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping

Created a testing package with harfbuzz enabled.

https://copr.fedorainfracloud.org/coprs/tagoh/freetype-harfbuzz/

Indeed, the result of ftview looks good to me.

I confirm your SRPM builds for me on Fedora 33 and works as expected.

Moving this to rawhide. we are planning to fix this there.

I've verified that the new freetype with harfbuzz support enabled fixes the issue. I've used the pango-view command from the comment #14 for that.
I'm closing this.
Thank you all for your help.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Seems fixed on my F34 box running freetype-2.10.4-3.fc34.x86_64, harfbuzz-2.7.4-3.fc34.x86_64 -- OK to close as fixed?