Bug 1853937 - Auto-hinter ignores non-unicode ligatures (e.g. Lato ti, tt)
Summary: Auto-hinter ignores non-unicode ligatures (e.g. Lato ti, tt)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: freetype
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1906714
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-05 19:42 UTC by James
Modified: 2021-10-01 17:39 UTC (History)
18 users (show)

Fixed In Version: freetype-2.10.4-3.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-01 17:39:11 UTC
Type: Bug


Attachments (Terms of Use)
Sample renderings (11.12 KB, image/png)
2020-07-05 19:42 UTC, James
no flags Details
Sample renderings (10.40 KB, image/png)
2020-09-21 14:43 UTC, James
no flags Details
Sample renderings in Gtk3 font chooser, at 8, 9, 10, 11 and 14 pt (12.73 KB, image/png)
2020-09-21 14:53 UTC, James
no flags Details
My fonts.conf (441 bytes, text/plain)
2020-09-22 13:07 UTC, James
no flags Details
Large point-size expected result (generated in Inkscape) (8.76 KB, image/png)
2020-09-22 13:13 UTC, James
no flags Details
Actual result with the helping line (2.99 KB, image/png)
2020-10-09 04:58 UTC, Akira TAGOH
no flags Details
Rendering from pango-view --markup (5.06 KB, image/png)
2020-10-11 18:21 UTC, James
no flags Details
ftview screenshot (83.07 KB, image/png)
2020-11-12 15:09 UTC, Alexei Podtelezhnikov
no flags Details

Description James 2020-07-05 19:42:27 UTC
Created attachment 1699956 [details]
Sample renderings

Created attachment 1699956 [details]
Sample renderings

The horizontal 't-crossing' strokes of the ti and tt ligatures are rendered slightly below the x-height, in a manner that is more- or less-visible depending on font size. It's most visible at 11pt.

Attached are samples rendered with RGB subpixel anti-aliasing, slight hinting. The issue is visible in the 8, 11 and 14pt samples.

lato-fonts-2.015-9.fc32.noarch
freetype-2.10.1-2.fc32.x86_64

pango-1.44.7-2.fc32.x86_64

Comment 1 Alexei Podtelezhnikov 2020-09-21 13:50:18 UTC
For completeness sake, please add add "f" and "t" to your images.

Comment 2 James 2020-09-21 14:43:47 UTC
Created attachment 1715542 [details]
Sample renderings

Updated as requested

Comment 3 James 2020-09-21 14:47:11 UTC
(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...

Comment 4 James 2020-09-21 14:53:22 UTC
Created attachment 1715546 [details]
Sample renderings in Gtk3 font chooser, at 8, 9, 10, 11 and 14 pt

...this time with the ligatures.

Comment 5 Alexei Podtelezhnikov 2020-09-21 15:50:37 UTC
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.

Comment 6 James 2020-09-21 16:08:50 UTC
The samples are all screenshots from the sample area a Gtk3 font selection box -- such as you can get e.g. in Gedit.

Comment 7 Alexei Podtelezhnikov 2020-09-21 17:13:50 UTC
The glyphs are hinted in the font. It must be Pango which loads them unhinted (FT_LOAD_NO_HINTING). Please reassign to Pango.

Comment 8 James 2020-09-21 19:06:12 UTC
(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?

Comment 9 Peng Wu 2020-09-22 02:52:31 UTC
Could you provide the expected result?

And how do you produce the sample image?

Comment 10 James 2020-09-22 13:07:19 UTC
Created attachment 1715700 [details]
My fonts.conf

Comment 11 James 2020-09-22 13:13:28 UTC
Created attachment 1715702 [details]
Large point-size expected result (generated in Inkscape)

Comment 12 James 2020-09-22 13:15:46 UTC
(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.

Comment 13 Peng Wu 2020-10-09 03:10:52 UTC
Could you use pango-view to produce the actual result?

And use ftview to produce the expected result for comparison.

Comment 14 Akira TAGOH 2020-10-09 04:27:13 UTC
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

Comment 15 Akira TAGOH 2020-10-09 04:58:15 UTC
Created attachment 1720101 [details]
Actual result with the helping line

This would demonstorate the issue

Comment 16 James 2020-10-11 18:21:00 UTC
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.

Comment 17 James 2020-10-11 18:25:56 UTC
(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.

Comment 18 Akira TAGOH 2020-10-12 06:30:27 UTC
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.

Comment 19 James 2020-10-12 13:27:49 UTC
(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.

Comment 20 Peng Wu 2020-10-15 03:48:44 UTC
Right, I think we need to use similar settings in hb-view for comparison.

Comment 21 Peng Wu 2020-11-11 02:29:09 UTC
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"

Comment 22 Alexei Podtelezhnikov 2020-11-12 15:09:16 UTC
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.

Comment 23 Alexei Podtelezhnikov 2020-11-13 14:09:18 UTC
Fedora comes with FreeType without HarfBuzz [https://savannah.nongnu.org/bugs/?59452]. So there is a fix but it is a circular dependency.

Comment 24 James 2020-11-13 14:22:49 UTC
(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.

Comment 25 James 2020-11-13 18:35:37 UTC
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?

Comment 26 Akira TAGOH 2020-11-16 12:01:01 UTC
We may need some tweaks in the spec file to enable bootstrap. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping

Comment 27 Akira TAGOH 2020-11-20 11:35:41 UTC
Created a testing package with harfbuzz enabled.

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

Indeed, the result of ftview looks good to me.

Comment 28 James 2020-11-20 11:50:02 UTC
I confirm your SRPM builds for me on Fedora 33 and works as expected.

Comment 29 Akira TAGOH 2021-01-26 08:45:01 UTC
Moving this to rawhide. we are planning to fix this there.

Comment 30 Marek Kašík 2021-02-05 13:57:26 UTC
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.

Comment 31 Ben Cotton 2021-02-09 16:16:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 32 James 2021-03-10 01:16:36 UTC
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?


Note You need to log in before you can comment on or make changes to this bug.