Created attachment 183225 [details] Miriam font names and properties Description: Incorrect font name is used in UI font list and in saved file.The font "Miriam CLM" (attached) has names in both en_US and he_IL locales (see screeenshot miriam_properties.png). The Hebrew name is used in English UI Steps to Reproduce: 1. Install attached fonts MiriamCLM-Book.ttf and MiriamCLM-Bold.ttf 2. Set UI language to en_US 3. Open Libreoffice Writer 4. Open drop-down list of fonts Actual Results: In the list of fonts the Miriam font is listed as "מרים" at the end of the list(see screenshot font_list.png) Expected Results: In the list of fonts the Miriam font should be listed as "Miriam" in the appropriate alphabet-based place Reproducible: Always Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: he-IL (he_IL.UTF-8); UI: en-US Calc: threaded
Created attachment 183226 [details] Font list screenshot
Created attachment 183227 [details] Miriam fonts - regular and bold
There might be some design rationale to this... let's ask other people.
(In reply to Eyal Rozenberg from comment #3) > There might be some design rationale to this... let's ask other people. Don't think so. If the font provides an English name it should be shown. The expanded list does it at least for Noto Naskh Arabic and similar showing the Arab name next to it. Same for utkal and Veberteysch in the screenshot. Wonder what makes those fonts different. How does the font info look like for a working example?
Created attachment 183407 [details] Properly displayed with an LO 7.5 dev build on Linux I have to say I can't reproduce this bug - neither with LO 7.4.12 nor with a recent 7.5 dev build. Attaching what I see in the font family drop-down list.
(In reply to Eyal Rozenberg from comment #5) > Created attachment 183407 [details] > Properly displayed with an LO 7.5 dev build on Linux > > I have to say I can't reproduce this bug - neither with LO 7.4.12 nor with a > recent 7.5 dev build. Attaching what I see in the font family drop-down list. This is strange. Eyal, could you please paste the entire build info? If you are using 7.4.2.3 appimage, it could be great.
(In reply to Maxim Iorsh from comment #6) Version: 7.4.1.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Debian package version: 1:7.4.1-1
It seems that displaying localized font names is tied to the locale being used and not the UI language. I find this questionable choice, but IIRC Windows does this as well, so may be there is a good rational for this or may be users of certain locale expect it? I think this is a FontConfig issue, though: $ fc-match "Miriam CLM" MiriamCLM-Book.ttf: "Miriam CLM" "Book" $ LC_ALL=he_IL LANG=en_US fc-match "Miriam CLM" MiriamCLM-Book.ttf: "מרים" "קל" $ LC_ALL=en_US LANG=he_IL fc-match "Miriam CLM" MiriamCLM-Book.ttf: "Miriam CLM" "Book" FontConfig seems to be returning the localized name depending on the locale not the language.
(In reply to خالد حسني from comment #8) > It seems that displaying localized font names is tied to the locale being > used and not the UI language. I find this questionable choice, but IIRC > Windows does this as well, I don't remember seeing this on Windows. At least - not when I browse fonts, and not when I select fonts in MSO. Can you be more specific? > so may be there is a good rational for this or > may be users of certain locale expect it? I doubt that a user, who has chosen a certain UI language for an app, expects drop-down list items to use the locale language instead. Not to mention the fact that many/most Hebrew and probably Arabic fonts don't even include a translation of the name.
(In reply to Eyal Rozenberg from comment #9) > (In reply to خالد حسني from comment #8) > > It seems that displaying localized font names is tied to the locale being > > used and not the UI language. I find this questionable choice, but IIRC > > Windows does this as well, > > I don't remember seeing this on Windows. At least - not when I browse fonts, > and not when I select fonts in MSO. Can you be more specific? That was years ago, so I’ll need to test it again. But I had built a font that had Arabic localized name entries, and it would show the Arabic names even on systems with English UI language. > > so may be there is a good rational for this or > > may be users of certain locale expect it? > > I doubt that a user, who has chosen a certain UI language for an app, > expects drop-down list items to use the locale language instead. Not to > mention the fact that many/most Hebrew and probably Arabic fonts don't even > include a translation of the name. Different user communities have different expectations, for example Chinese names for Chinese fonts seem to be common.
(In reply to خالد حسني from comment #8) > It seems that displaying localized font names is tied to the locale being > used and not the UI language. I find this questionable choice, but IIRC > Windows does this as well, so may be there is a good rational for this or > may be users of certain locale expect it? > > I think this is a FontConfig issue, though: > > $ fc-match "Miriam CLM" > MiriamCLM-Book.ttf: "Miriam CLM" "Book" > > $ LC_ALL=he_IL LANG=en_US fc-match "Miriam CLM" > MiriamCLM-Book.ttf: "מרים" "קל" > > $ LC_ALL=en_US LANG=he_IL fc-match "Miriam CLM" > MiriamCLM-Book.ttf: "Miriam CLM" "Book" > > FontConfig seems to be returning the localized name depending on the locale > not the language. The behavior of fontconfig is correct, because LC_ALL overrides LANG. The issue seems to be that UI language is not necessarily reflected in any environment variable, Libreoffice even allows to set it explicitly in settings. Maybe the correct solution is to call fontconfig with custom environment which depends on use case. I'd suggest the following: For UI: Set LC_ALL=<UI locale>; call fontconfig For file save: Set LC_ALL=C; call fontconfig In this way each user will see font name tailored to their UI, but the font name used inside file read/write will be stable across all systems.
(In reply to Maxim Iorsh from comment #11) > (In reply to خالد حسني from comment #8) > > It seems that displaying localized font names is tied to the locale being > > used and not the UI language. I find this questionable choice, but IIRC > > Windows does this as well, so may be there is a good rational for this or > > may be users of certain locale expect it? > > > > I think this is a FontConfig issue, though: > > > > $ fc-match "Miriam CLM" > > MiriamCLM-Book.ttf: "Miriam CLM" "Book" > > > > $ LC_ALL=he_IL LANG=en_US fc-match "Miriam CLM" > > MiriamCLM-Book.ttf: "מרים" "קל" > > > > $ LC_ALL=en_US LANG=he_IL fc-match "Miriam CLM" > > MiriamCLM-Book.ttf: "Miriam CLM" "Book" > > > > FontConfig seems to be returning the localized name depending on the locale > > not the language. > > The behavior of fontconfig is correct, because LC_ALL overrides LANG. The > issue seems to be that UI language is not necessarily reflected in any > environment variable, Libreoffice even allows to set it explicitly in > settings. > > Maybe the correct solution is to call fontconfig with custom environment > which depends on use case. I'd suggest the following: > > For UI: Set LC_ALL=<UI locale>; call fontconfig > For file save: Set LC_ALL=C; call fontconfig > > In this way each user will see font name tailored to their UI, but the font > name used inside file read/write will be stable across all systems. Sorry, that was red-herring indeed. The issue is in LibreOffice code, in particular this code that uses process locale instead of the UI language: https://git.libreoffice.org/core/+/refs/heads/master/vcl/unx/generic/fontmanager/fontconfig.cxx#445 The best person to comment about this code is Caolán McNamara, but this code have been like this since ~forever.
@Caolán, could you please review this issue and express your opinion?
my comment there was "possible to-do, sort by UILocale instead of process locale" so we can simply do that instead
*** Bug 107485 has been marked as a duplicate of this bug. ***
bot didn't work for some reason, so: https://git.libreoffice.org/core/commit/645f8038df617275e65e05bba0b165a1c52ce59b Resolves: tdf#151722 use UI Language for localized font names It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. backport to 7-4 is in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/ef557f0742b6111827982f5e10bc2f44fb553f78 Resolves: tdf#151722 use UI Language for localized font names It will be available in 7.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 186179 [details] Bug present in 7.5.1.2 - English font name not shown
Created attachment 186180 [details] Bug present in 7.5.1.2 - Hebrew font name is shown, but shouldn't be I can still reproduce the issue - see screenshots Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: he-IL (he_IL.UTF-8); UI: en-US Calc: threaded
looks like the use of the localized name got disabled back with https://bz.apache.org/ooo/show_bug.cgi?id=111108 as commit cc93f06f93eeaaee5811588d90929ebc72bf9724 Date: Fri Apr 23 12:28:26 2010 +0200 #i111108# do not prefer fontconfig familyname because of i79878
Was it reverted intentionally or by coincidence? I don't see contradiction between using classic family name (as per 111108) and retrieving it from fontconfig with the correct locale.
Checked the "Miriam CLM" font in question, it uses the classic family nameid 1, not 16
Looks like that was done not to disable translated names, but to disable "newer" names. Without the name set from what fontconfig reports then we read it ourself, so it seems that code is the one that needs adjustment rather than the fontconfig one. Attempt #2 with https://gerrit.libreoffice.org/c/core/+/149542
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/45da2754222d1fd6ffb02636b8568b4ac6472979 tdf#151722 restore use of localized font name It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
looks good to me in trunk, but I thought that before, backport to 7-5 in gerrit
(In reply to Caolán McNamara from comment #25) Thanks, Caolan, for the quick fix. ... if only the font-family-names-from-PDFs issue could be fixed this smoothly :-P (bug 143095)
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/521ba951d3b983b58f7772fe62d19b07efa19881 tdf#151722 restore use of localized font name It will be available in 7.5.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.