Bug 157348 - Allow medium/full hint style for truetype fonts in LO >= 7.5
Summary: Allow medium/full hint style for truetype fonts in LO >= 7.5
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.5.6.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2023-09-20 11:33 UTC by Frank Steiner
Modified: 2023-11-25 17:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Libreoffice 7.4.7, interpreter-version 35 (7.81 KB, image/png)
2023-09-20 11:33 UTC, Frank Steiner
Details
Libreoffice 7.4.7, interpreter-version 40 (7.97 KB, image/png)
2023-09-20 11:35 UTC, Frank Steiner
Details
Libreoffice 7.5.6, interpreter-version 35 and 40 (7.81 KB, image/png)
2023-09-20 11:36 UTC, Frank Steiner
Details
Libreoffice 7.4.7, interpreter-version 35 (correct version) (7.41 KB, image/png)
2023-09-20 11:37 UTC, Frank Steiner
Details
apro.png: AnonymousPro font with interpreter version 35 and 40 (5.63 KB, image/png)
2023-10-02 13:04 UTC, Frank Steiner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Steiner 2023-09-20 11:33:32 UTC
Created attachment 189711 [details]
Libreoffice 7.4.7, interpreter-version 35

Starting with  7.5 (I compared 7.6.1, 7.5.6 and 7.4.7 as those can be downloaded from the homepage) LibreOffice no longer respects the FREETYPE_PROPERTIES="truetype:interpreter-version=35" setting.

This is how arial looks like in  LO 7.4.7 with FREETYPE_PROPERTIES="truetype:interpreter-version=35":
Comment 1 Frank Steiner 2023-09-20 11:35:34 UTC
Created attachment 189712 [details]
Libreoffice 7.4.7, interpreter-version 40
Comment 2 Frank Steiner 2023-09-20 11:36:01 UTC
Created attachment 189713 [details]
Libreoffice 7.5.6, interpreter-version 35 and 40
Comment 3 Frank Steiner 2023-09-20 11:37:48 UTC
Created attachment 189714 [details]
Libreoffice 7.4.7, interpreter-version 35 (correct version)
Comment 4 Frank Steiner 2023-09-20 11:44:25 UTC
Sorry, I messed things up trying to attach the first attachment while opening the bug. Please ignore the " Libreoffice 7.4.7, interpreter-version 35" attachment, it shows the wrong file. The three correct attachments are:

Libreoffice 7.4.7, interpreter-version 35 (correct version): 
This shows how arial font looks like with  FREETYPE_PROPERTIES="truetype:interpreter-version=35". You can see that the font is slim and that's how it used to be in all versions before 7.5.6.

Libreoffice 7.4.7, interpreter-version 40:
That's how aria looks like with FREETYPE_PROPERTIES="truetype:interpreter-version=40". Too bold for our users, that's why we've been using the interpreter-version=35 for years.

Libreoffice 7.5.6, interpreter-version 35 and 40:
In LO 7.5.6 and 7.6.1 arial looks like this, no matter if FREETYPE_PROPERTIES is set to interpreter-version=35 or 40. So there is no way to get the slim version of many fonts back.

These bolder fonts really don't look nice to our users in most of our documents, so it would be great if libreoffice could restore support for the FREETYPE_PROPERTIES="truetype:interpreter-version=35" setting.
Comment 5 Buovjaga 2023-10-02 06:59:55 UTC
Can the difference be seen in any non-Microsoft font? I could not see a difference in 7.4 with Liberation Sans. Would be easier to test, if you provided the information.
Comment 6 Frank Steiner 2023-10-02 13:02:46 UTC
It shows with all Microsoft fonts (Andale, Arial, Times New Roman etc.),  that we use most of the time due to the exchange of documents with our Windows users.

Apart from those I've found only one other font:

/usr/share/fonts/truetype/AnonymousPro-Regular.ttf

which is from google-anonymouspro-fonts.rpm. This font can be downloaded either from  https://www.marksimonson.com/fonts/view/anonymous-pro or from https://fonts.google.com/specimen/Anonymous+Pro, and although the font files are different in both downloads, they look the same.

The difference between interpreter version 35 and 40 is not as remarkable as with the Microsoft fonts, but it is visible, see apro.png
Hope that helps!
Comment 7 Frank Steiner 2023-10-02 13:04:05 UTC
Created attachment 189956 [details]
apro.png: AnonymousPro font with interpreter version 35 and 40
Comment 8 QA Administrators 2023-10-03 03:16:52 UTC Comment hidden (obsolete)
Comment 9 Buovjaga 2023-10-07 18:21:48 UTC
Tried 35 and 40 with Anonymous Pro in the oldest of Linux 7.4 bibisect repository, but there is no difference. So I can't compare it with the present state. Hopefully someone else is able to do it.
Comment 10 Frank Steiner 2023-10-07 21:13:07 UTC
I just tested with the 7.4.7 you can download from https://www.libreoffice.org/download/download-libreoffice/
Anyway, the effect is way more visible with the microsoft fonts, so maybe your distro has a package for fetching those. "fetchmsttfonts" on opensuse or ttf-mscorefonts-installer on ubuntu for example.
Comment 11 Frank Steiner 2023-10-07 21:36:21 UTC
Just realized that it also depends on your fontconfig settings. On my system, a file in in /etc/fonts/conf.d set the autohint mode to "false" for Arial. When I change that to true, Arial looks bold even with interpreter-version=35.

So, the sharper and leaner display for Arial (and all other MS fonts and Anonymous Pro) is used only with autohinter disabled and interpreter-version=35 

Maybe Libreoffice > 7.4.7 has decided to enforce autohinter mode to all truetype fonts no matter what the fontconfig settings are?
Comment 12 Eric99 2023-10-13 14:16:22 UTC
Je rencontre le même souci sous Ubuntu Mate 20.04 avec Libreoffice 7.5.7. C'est la même chose sur la version 7.6.2
Cordialement,
Eric99
Comment 13 Eric99 2023-10-13 14:43:53 UTC
I have the same problem on Ubuntu Mate 20.04 with Libreoffice 7.5.7. It's the same on version 7.6.2.
Best regards,
Eric99
Comment 14 Buovjaga 2023-10-13 15:26:59 UTC
Frank: you might try bibisecting this with the Linux 7.5 repository:
https://wiki.documentfoundation.org/QA/Bibisect
https://wiki.documentfoundation.org/QA/Bibisect/Linux
https://bibisect.libreoffice.org/linux-64-7.5
Comment 15 Frank Steiner 2023-10-19 14:31:43 UTC
There is no need to do that as the reason for this changed rendering has become clear in the meantime. After asking at the developers list I was pointed to the file vcl/unx/generic/gdi/cairotextrender.cxx

After anaylzing the code it is obvious that as long as one cannot disable subpixel positioing in cairo (and there seems to be no way to do that in Linux) the code enforces CAIRO_HINT_STYLE_SLIGHT as hint style if it has been set to MEDIUM or FULL by the user.

But for rendering Microsoft fonts like Arial in their thin version one needs either CAIRO_HINT_STYLE_MEDIUM or CAIRO_HINT_STYLE_FULL. This can be set in Linux via ~/.Xresources, using "Xft.hinting: hintmedium/hintfull" (fontconfig will not work for this), but the code in cairotextrender.cxx reverts it to hintslight, and that causes Arial etc. to become bolder.

So, either there has to be a way to disable subpixel positioning in Linux, or the LO code must be changed to accept the users choice of hintmedium/hintfull.

I asked on the list if devs might consider to change the code accordingly to allow the user to choose the hinting style again (is was before 7.5.x) but didn't get an answer yet.
Comment 16 Frank Steiner 2023-11-02 13:05:24 UTC
Change the title because the problem is not caused by ignoring the interpreter version but by ignoring hint settings.

The relevant code part in cairotextrender.cxx is this:

// always true because pFontOptions is set and bSubpixelPositioning is true
   if (pFontOptions || bDisableAA || bSubpixelPositioning)
     {
       // sets eHintStyle to the value of Xft.hintstyle=... from ~/.Xdefaults
       // If none is defined there, pFontOptions has CAIRO_HINT_STYLE_MEDIUM set
       cairo_hint_style_t eHintStyle = pFontOptions ? cairo_font_options_get_hint_style(pFontOptions) : CAIRO_HINT_STYLE_DEFAULT;

       // with bSubpixelPositioning=true, this is true for Xft.hintstyle=none/slight and false otherwise
       bool bAllowedHintStyle = !bSubpixelPositioning || (eHintStyle == CAIRO_HINT_STYLE_NONE || eHintStyle == CAIRO_HINT_STYLE_SLIGHT);

       // always true if bSubpixelPositioning=true
       if (bDisableAA || !bAllowedHintStyle || bSubpixelPositioning)
       {
         ...
         // bAllowedHintStyle is false if Xft.hintstyle=medium/full
         if (!bAllowedHintStyle) {
           // so Xft.hintstyle=medium/full is reset to slight
           cairo_font_options_set_hint_style(pOptions, CAIRO_HINT_STYLE_SLIGHT);
         }


When changing the last line to
    cairo_font_options_set_hint_style(pOptions, CAIRO_HINT_STYLE_MEDIUM);
and recompiling libreoffice, Arial etc. will be shown in their thin version again. So it would work when setting "Xft.hinting: hintmedium" if this wasn't changed to CAIRO_HINT_STYLE_SLIGHT in this last line.

I hope one of the devs will take a look at this and reconsider the decision to force CAIRO_HINT_STYLE_SLIGHT when subpixelpositioning is enabled. I really don't see why this would be neccessary...
Comment 17 Frank Steiner 2023-11-25 17:14:09 UTC
This can be considered solved as I wrote a patch that re-enables the use of medium/full hint style and Caolán McNamara was kind enough to give me some hints and support so that the patch was accepted.
So, in the next LO release it should be possible to set the new environment variable SAL_ALLOW_DEFAULT_HINTING to some arbitrary value (it's just checked that it is not undefined) and then the hinting style defined "outside" of libreoffice will be used. E.g. in Linux you would set via X resources, e.g. define the line

Xft.hintstyle:            hintmedium

in $HOME/.Xdefaults for medium hinting and call "xrdb -merge $HOME/.Xdefaults" (or just log out and in again). 
I don't know how to do that in macOS or Windows, but Google should help here.
Comment 18 Buovjaga 2023-11-25 17:24:56 UTC
Commit message lacked tdf# ID, the commit is: 9137bd2dd3ab66ffa783fc15a1add1e9cf541460
Comment 19 Frank Steiner 2023-11-25 17:37:26 UTC
Sorry! Thanks for adding it!