Bug 108243 - semicolon separated fonts substitution not working (bug in Linux FontConfig integration code)
Summary: semicolon separated fonts substitution not working (bug in Linux FontConfig i...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 161373 (view as bug list)
Depends on:
Blocks: Font-Substitution Font-Fallback-Lists
  Show dependency treegraph
 
Reported: 2017-05-30 11:35 UTC by Kevin Suo
Modified: 2024-09-10 10:34 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
test document showing the bug (10.25 KB, application/vnd.oasis.opendocument.text)
2017-05-30 11:35 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2017-05-30 11:35:09 UTC
Created attachment 133722 [details]
test document showing the bug

It is advertised in the help that LibreOffice supports font substitution with a list of semicolon separated fonts:

> https://help.libreoffice.org/Common/Font_Name
> You can enter several fonts, separated by semicolons. LibreOffice uses each named font in succession if the previous fonts are not available.

However, this is not working.

Steps to Reproduce:

1. In Writer, enter some text, and apply with semicolon separated fonts. (e.g., "abadfont;Times New Roman" where the font "abadfont" never exists and "Times New Roman" is available in my system.)

2. In a new paragraph, enter the same text and apply with the font which do exist in the system (e.g., "Times New Roman")

--> The text shown in step 1 should use the "Times New Roman" font which should be the same as shown in step 2, but they are showing different. 

See also the test document to observe the bug.

Version: 5.3.3.2
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 2; OS Version: Linux 4.10; UI Render: default; VCL: gtk2; Layout Engine: new; 
Locale: zh-CN (zh_CN.UTF-8); Calc: group

Fedora 25 x64.
Comment 1 Yousuf Philips (jay) (retired) 2017-05-30 21:19:27 UTC
Confirmed and this doenst occur on Windows. Would assume this has to do with Linux's underlying font substitution thingy. @Maxim, @Khaled: Any thoughts?
Comment 2 ⁨خالد حسني⁩ 2017-06-02 01:34:44 UTC Comment hidden (obsolete)
Comment 3 Kevin Suo 2017-06-02 08:16:48 UTC Comment hidden (obsolete)
Comment 4 Yousuf Philips (jay) (retired) 2017-06-02 13:31:13 UTC
Yes i tested 3.3 and it wasnt working there, which is why i set it to inherited from OOo. Tested 3.6, 4.2, 5.2 and AOO 4.1.2 just now and it didnt work in these versions as well.
Comment 5 ⁨خالد حسني⁩ 2017-06-03 13:45:19 UTC Comment hidden (obsolete)
Comment 6 Yousuf Philips (jay) (retired) 2017-06-03 14:18:31 UTC
(In reply to Khaled Hosny from comment #5)
> Does it work in old releases if you disable fontconfig (by setting
> SAL_DISABLE_FC_SUBST env var to 1)?

Yes this solved it against 3.3.0 and 5.1.6.2.
Comment 7 ⁨خالد حسني⁩ 2017-06-04 00:25:02 UTC
OK, so it is a bug in our FontConfig integration code. If someone is interested in fixing this, grep for SAL_DISABLE_FC_SUBST in 5.3 branch (it was removed in 5.4) and follow the code from there and try to figure out what the non-FontConfig code is doing that is missing from FontConfig one.
Comment 8 QA Administrators 2018-06-05 02:38:27 UTC Comment hidden (obsolete)
Comment 9 Kevin Suo 2019-05-16 03:02:53 UTC Comment hidden (obsolete)
Comment 10 Kevin Suo 2022-09-14 15:04:51 UTC
Still reproducible on current 7.3 branch and trunk.
Comment 11 Buovjaga 2024-09-09 13:17:20 UTC
*** Bug 161373 has been marked as a duplicate of this bug. ***
Comment 12 Eyal Rozenberg 2024-09-09 18:29:45 UTC
Following the side-discussion in the now-duped bug 161373, linking to a bug regarding the ODF specification of which separator we should use.
Comment 13 Julien Nabet 2024-09-10 10:34:46 UTC
On pc Debian x86-64 with master sources updated today, I reproduced this.

After some gdb debug, I noticed that notosans was used after this block in
PhysicalFontCollection::FindFontFamily:
1054         if (FindMetricCompatibleFont(rFSD) ||
1055             (mpPreMatchHook && mpPreMatchHook->FindFontSubstitute(rFSD)))
1056         {
1057             aSearchName = GetEnglishSearchFontName(aSearchName);
1058         }

See https://opengrok.libreoffice.org/xref/core/vcl/source/font/PhysicalFontCollection.cxx?r=40dde438#1054

and FindFontSubstitute has a different behavior depending on the env, see:
https://opengrok.libreoffice.org/search?project=core&full=&defs=FindFontSubstitute&refs=&path=&hist=&type=&xrd=&nn=1&si=full&si=full

In Linux, the pb is in PrintFontManager::Substitute
See https://opengrok.libreoffice.org/xref/core/vcl/unx/generic/fontmanager/fontconfig.cxx?r=6dfac38b#973

Here's part of the calling bt:
#0  psp::PrintFontManager::Substitute (this=0x5555577552a0, rPattern=..., rMissingCodes="") at vcl/unx/generic/fontmanager/fontconfig.cxx:1079
#1  0x00007fffeea817f3 in GetFcSubstitute (rFontSelData=..., rMissingCodes="") at vcl/unx/generic/fontmanager/fontsubst.cxx:67
#2  0x00007fffeea81370 in (anonymous namespace)::FcPreMatchSubstitution::FindFontSubstitute
    (this=0x7fffef0de6b0 <SalGenericInstance::RegisterFontSubstitutors(vcl::font::PhysicalFontCollection*)::aSubstPreMatch>, rFontSelData=...) at vcl/unx/generic/fontmanager/fontsubst.cxx:129
#3  0x00007fffee81196a in vcl::font::PhysicalFontCollection::FindFontFamily (this=0x55555c008190, rFSD=...) at vcl/source/font/PhysicalFontCollection.cxx:1065