Bug 1545149 - OTF/CFF conts no longer hinted horizontally
Summary: OTF/CFF conts no longer hinted horizontally
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: freetype
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-14 11:25 UTC by Pierre Ossman
Modified: 2022-06-08 00:05 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-08 00:05:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
rendering comparison (28.64 KB, image/png)
2018-11-05 15:16 UTC, Pierre Ossman
no flags Details
Comparison shot (657.86 KB, image/png)
2018-11-07 21:09 UTC, Nikolaus Waxweiler
no flags Details
fedora 29 example (52.70 KB, image/png)
2019-04-15 14:07 UTC, Pierre Ossman
no flags Details

Description Pierre Ossman 2018-02-14 11:25:41 UTC
I upgraded from Fedora 26 to Fedora 27 and all of a sudden OTF/CFF fonts such as Cantarell are no longer hinted horizontally, making them appear blurry and out of focus.

A similar change was done for TTF fonts previously, but that could be reverted by setting "FREETYPE_PROPERTIES=truetype:interpreter-version=35".

Is there a similar setting hidden for this latest change? The normal font hinting settings have no effect on this.

Comment 1 Nikolaus Waxweiler 2018-11-03 12:47:43 UTC
OTFs weren't hinted horizontally before, what was turned off was stem darkening. If you prefer a thicker look, try

FREETYPE_PROPERTIES="truetype:interpreter-version=35 cff:no-stem-darkening=0"

See https://www.freetype.org/freetype2/docs/text-rendering-general.html#disabled-stem-darkening-for-the-autohinter-and-adobes-cff-otf-engine.

Comment 2 Pierre Ossman 2018-11-05 15:04:46 UTC
Hmm... I don't think that was it.

Crap. I can't really reproduce any issue. I should have taken screen shots back in February.

Perhaps there was something wrong with the auto-hinter that got fixed? Right now Cantarell looks like shit with the standard hinting. But the autohinter sorts that out, and it most definitely does some horizontal hinting, at least for Cantarell.

Comment 3 Pierre Ossman 2018-11-05 15:16:13 UTC
Scratch that, even with the auto hinter it still is pretty bad when you actually start using it. And fortunately I found an old screen shot of how it used to render. So please see the attachment for a comparison. In the old version it used to hint horizontally very aggressively.

Comment 4 Pierre Ossman 2018-11-05 15:16:39 UTC
Created attachment 1501958 [details]
rendering comparison

Comment 5 Nikolaus Waxweiler 2018-11-05 22:30:03 UTC
Interesting. I can't immediately find which FreeType F26 shipped with, your F26 image however looks like you had full hinting and autohinting active at the same time. Try adding this to your fontconfig config:

  <match target="font">
    <test name="family">
      <string>Cantarell</string>
    </test>
    <edit mode="assign" name="hinting">
      <bool>true</bool>
    </edit>
    <edit mode="assign" name="autohint">
      <bool>true</bool>
    </edit>
    <edit mode="assign" name="hintstyle">
      <const>hintfull</const>
    </edit>
  </match>

(Not sure if you need to use 'match target="font"' or '...="pattern"')

If that doesn't match what you had before, another possibility was that your FT was using the previous CFF renderer before Adobe contributed the one in current use. I don't think you can select the old one through fontconfig, it's a compile time option iirc.

Comment 6 Pierre Ossman 2018-11-07 15:30:48 UTC
(In reply to Nikolaus Waxweiler from comment #5)
> Interesting. I can't immediately find which FreeType F26 shipped with, your
> F26 image however looks like you had full hinting and autohinting active at
> the same time. Try adding this to your fontconfig config:
> 
> ...
> 

I already had such a file to force the autohinter. But the other additions had no effect.

But I was already enabling full hinting through gnome tweak tool. Anything other than full hinting gives blurry text almost by definition.

> 
> If that doesn't match what you had before, another possibility was that your
> FT was using the previous CFF renderer before Adobe contributed the one in
> current use. I don't think you can select the old one through fontconfig,
> it's a compile time option iirc.

I doubt it. Fedora 26 uses 2.7 according to the Fedora repo. And the Adobe engine was added in 2.5 if I understand things correctly.

Comment 7 Pierre Ossman 2018-11-07 15:36:00 UTC
Aha! I think I found the missing detail to test this. You need to enable subpixel hinting as well. Apparently I disabled that somewhere along the line of finding a workaround for this issue.

So:

 * Forced autohinter for Cantarell
 * Full hinting
 * Subpixel hinting

Then compare Fedora 28 and freetype-2.7.1-10.fc26. You'll see sharp stems with the 2.7.1, and fuzzy ones with 2.8.

You can test this directly on your Fedora 28 machine. Just download the old RPM here:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1045246

Unpack it using rpm2cpio, and then point at it using LD_LIBRARY_PATH. Then you can easily compare then new and old stuff.

Comment 8 Nikolaus Waxweiler 2018-11-07 21:07:23 UTC
Do you mean subpixel rendering?

This is interesting. In ftview from that build, If I enable normal anti-aliasing (A) and forced autohinting (f) and switch to subpixel rendering (C) and forced autohinting, some glyphs seems to glitch by being a pixel or so wider at 16px (e.g. i, j, doubles quotes). Aside from that, nothing changes significantly?

In the newest ftview from git, I can't seem to enable full autohinting with subpixel rendering.

Comment 9 Nikolaus Waxweiler 2018-11-07 21:09:05 UTC
Created attachment 1503145 [details]
Comparison shot

Upper left: ftview 2.7.1 with normal grayscale rendering plus forced autohinting
Lower left: ftview 2.7.1 with RGB subpixel rendering plus forced autohinting
Upper right: ftview git master with normal grayscale rendering plus forced autohinting

Comment 10 Nikolaus Waxweiler 2018-11-07 21:17:20 UTC
Going on a limb here, have you tried enabling warping? Only available in slight autohinting mode.

Comment 11 Pierre Ossman 2018-11-14 15:28:41 UTC
instead. (In reply to Nikolaus Waxweiler from comment #8)
> Do you mean subpixel rendering?
> 

Right, sorry. ftview does its own thing, so I started simply comparing GTK applications. The setting I was referring to here is "Antialiasing: Subpixel" in GNOME Tweaks.

> This is interesting. In ftview from that build, If I enable normal
> anti-aliasing (A) and forced autohinting (f) and switch to subpixel
> rendering (C) and forced autohinting, some glyphs seems to glitch by being a
> pixel or so wider at 16px (e.g. i, j, doubles quotes). Aside from that,
> nothing changes significantly?
> 

ftview's rendering doesn't seem to be representative of what GTK does, so it might not be the best test case. Your image does show a bit of the tendencies though as there are a lot of single pixel wide stems in the lower left example.

(and the glitch is mentioned on bug 1035486 comment #36)

> In the newest ftview from git, I can't seem to enable full autohinting with
> subpixel rendering.

Isn't that the problem though? Neither ftview nor GTK is able to get that mode fully working.

(In reply to Nikolaus Waxweiler from comment #10)
> Going on a limb here, have you tried enabling warping? Only available in
> slight autohinting mode.

It seems to have some effect, but it doesn't even compensate for the extra blur caused by going from full hinting to slight.

Comment 12 Ben Cotton 2018-11-27 13:34:21 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 Jens Petersen 2019-04-09 03:10:51 UTC
I am assuming this also affects F29 and F30?

Comment 14 Nikolaus Waxweiler 2019-04-11 10:54:30 UTC
Probably. Although I honestly don't see this as much of a deal, full (both directions) autohinting usually produces sub-par results no matter what you do (the comparison shot posted further up looks ghastly to me). The only way to get Cantarell to look fully "sharp" and good at the same time is for someone to sit down and professionally hint Cantarell in both directions, which, imho, is unlikely to happen (it can easily cost 5 figures).

Comment 15 Pierre Ossman 2019-04-11 12:26:51 UTC
As a user I do consider this to be a big deal. But it's not because I want fonts to look "good", even though that is also nice. The point is that the blur makes text difficult to read and can be very straining and exhausting for some (like myself).

I can understand that correct shapes is the default. But completely removing the ability to get sharp stems is going to far IMO.

Comment 16 Nikolaus Waxweiler 2019-04-11 14:18:26 UTC
It is possible that this is a bug in FreeType, you may want to send a mail there (https://www.freetype.org/contact.html) and point to this bug report.

On the subject of "removing the ability to get sharp stems": I can see your point, but sub-par autohinting can impair reading just as well by making text look very uneven. There is unfortunately no silver bullet here. Actually, there is no way for a user to tell a font how she'd like the rendering to be. Neither TTF nor OTF hinting have the notion of user adjustability (OTF maybe more so than TTF, but nothing of that is implemented in FreeType), what you see as an options in FreeType/fontconfig are misnamed switches and the choice you get is largely incidental. The thing to keep in mind is that there is a lot of familiarization baked into font rendering discussions, i.e. if you surround yourself with mscorewebfonts and DejaVu and crank hinting to full, the rendering in the shot above will stick out like a sore thumb -- and vice versa.

Comment 17 Pierre Ossman 2019-04-11 14:36:01 UTC
Freetype has (unfortunately) rather publicly declared that they are in the "correct shapes" camp, so I have my doubts that this would be considered a bug. Just see the TTF interpreter issue mentioned in the initial description.

Freetype seem to be waiting for the Linux graphical stack to start doing gamma aware alpha blending, and until then everyone will just have to suck it up and live with font rendering issues...

Comment 18 Nikolaus Waxweiler 2019-04-11 15:04:25 UTC
I am part of the "correct shapes" camp and helped declare it, but this might be some bool bug somewhere. It was never my intention to make existing functionality unreachable. Your second paragraph is unfortunately true and has been so even before the changes in FreeType :/

Actually, it may be better to file an issue over at https://savannah.nongnu.org/bugs/?group=freetype instead of writing a mail.

Comment 19 Matthias Clasen 2019-04-12 12:33:33 UTC
"waiting for the linux text stack to do gamma" is a self-defeating position. If you want changes to happen there, you need to get involved.

Comment 20 Pierre Ossman 2019-04-15 11:55:25 UTC
Reported upstream here:

https://savannah.nongnu.org/bugs/index.php?56140

Comment 21 Alexei Podtelezhnikov 2019-04-15 12:57:51 UTC
Pierre, subpixel rendering is finally functional in default Fedora 29 and up. Use it. It is impossible to optimize FreeType for a single user of a single font, please accept that.

Comment 22 Pierre Ossman 2019-04-15 14:07:20 UTC
Created attachment 1555261 [details]
fedora 29 example

A single user is exaggerating a bit. I'm perfectly fine with the fact that most prefer correct shapes and that is the default. But I will insist that there are enough of us who prioritise sharpness and contrast to keep that as a secondary option. And again, I do not consider this an aesthetic choice but rather one of usability and comfort. I am not persisting here for the sake of arguing. :)

As for Fedora 29, I've attached a screen shot of the current state of things. This is with subpixel rendering enabled, and with the default Cantarell UI font. Not a sharp stem anywhere. It might be pretty, but I'm sorry to say that I would consider this to be a step backwards in usability.

And please note that this was a regression, and not a request for something that never existed. I can fully understand the difficulty of prioritising. But please try to give us a way to re-enable features no longer deemed suitable to be on by default. :)

Comment 23 Alexei Podtelezhnikov 2019-04-15 14:22:24 UTC
https://www.freetype.org/freetype2/docs/reference/ft2-properties.html#hinting-engine

Is CFF_CONFIG_OPTION_OLD_ENGINE set in Fedora? If it was, you could get the old engine by default and switch between them using:

FREETYPE_PROPERTIES=cff:hinting-engine=freetype
FREETYPE_PROPERTIES=cff:hinting-engine=adobe

So there is a path backwards...

Comment 24 Pierre Ossman 2019-04-15 14:24:32 UTC
Great. I'll try to play around with that tomorrow and see if it helps. Thanks!

Comment 25 Pierre Ossman 2019-04-16 07:56:58 UTC
I'm afraid I can't find any different between the hinting engines, so it seems that option is not set. :/

How is that option set? Build logs should be here:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1157851

I take it there is no setting for the change introduced in 2.8? As far as I understand it the Adobe engine was already default before that, so it isn't the engine change that introduced this?

Comment 26 Alexei Podtelezhnikov 2019-04-16 11:05:53 UTC
The option to compile the old engine and make it default, CFF_CONFIG_OPTION_OLD_ENGINE, is set in include/config/ftoption.h. You should rebuild your FreeType with it enabled.

Comment 27 Ben Cotton 2019-05-02 19:40:42 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 28 Pierre Ossman 2019-05-06 09:33:45 UTC
Is this a change that could be made in the Fedora package?

Comment 29 Ben Cotton 2019-10-31 19:23:09 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 30 Pierre Ossman 2019-11-13 15:02:42 UTC
I haven't seen any indication that this option has been enabled in the Fedora package, so moving to Fedora 31.

Comment 31 Ben Cotton 2020-11-03 15:00:30 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 32 Akira TAGOH 2020-11-05 11:58:38 UTC
just built a testing package on copr, with enabling CFF_CONFIG_OPTION_OLD_ENGINE.

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

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

Comment 34 Ben Cotton 2022-05-12 16:14:36 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 35 Ben Cotton 2022-06-08 00:05:43 UTC
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.


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