Bug 72042 - Font names are not localized (Mac OS X)
Summary: Font names are not localized (Mac OS X)
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.3.2 release
Hardware: Other macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA target:4.3.0
Keywords: possibleRegression
: 117751 (view as bug list)
Depends on:
Blocks: CJK Fonts
  Show dependency treegraph
 
Reported: 2013-11-26 16:05 UTC by Tomofumi Yagi
Modified: 2019-10-20 14:15 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen shot 1:Basic_Fonts(Asian) 4.1.x or later (208.84 KB, image/png)
2013-11-26 16:08 UTC, Tomofumi Yagi
Details
Screen shot 2:Basic_Fonts(Asian) 4.0.x (190.48 KB, image/png)
2013-11-26 16:09 UTC, Tomofumi Yagi
Details
Screen shot 3:Formatting toolbar 4.1.x or later (195.83 KB, image/png)
2013-11-26 16:12 UTC, Tomofumi Yagi
Details
Screen shot 4:Formatting toolbar 4.0.x (167.83 KB, image/png)
2013-11-26 16:13 UTC, Tomofumi Yagi
Details
0001-fdo-72042-workaround.patch (1.42 KB, patch)
2014-02-11 07:18 UTC, Tomofumi Yagi
Details
workaround patch 2(for analysis on chinese locale) (16.06 KB, patch)
2015-06-14 03:14 UTC, Tomofumi Yagi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomofumi Yagi 2013-11-26 16:05:03 UTC
Problem description: 
"Arial Unicode MS" is selected as initial Basic font(Asian) in Japanese environment(Mac OS X).

Steps to reproduce:
1. Start Writer.
2. Open Preferences.
3. Show Options -> LibreOffice Writer -> Basic Fonts(Asian).

Current behavior:
Basic fonts(Asian) are Arial Unicode MS(LibreOffice 4.1.x or later).

Expected behavior:
Basic fonts(Asian) are Hiragino Mincho ProN W3(LibreOffice 4.0.x).


In addition, I notice that japanese font name is not localized in formatting toolbar on LibreOffice 4.1.x or later.
It is localized on LibreOffice 4.0.x.

              
Operating System: Mac OS X
Version: 4.1.3.2 release
Comment 1 Tomofumi Yagi 2013-11-26 16:08:39 UTC
Created attachment 89844 [details]
Screen shot 1:Basic_Fonts(Asian) 4.1.x or later
Comment 2 Tomofumi Yagi 2013-11-26 16:09:36 UTC
Created attachment 89845 [details]
Screen shot 2:Basic_Fonts(Asian) 4.0.x
Comment 3 Tomofumi Yagi 2013-11-26 16:12:04 UTC
Created attachment 89846 [details]
Screen shot 3:Formatting toolbar 4.1.x or later
Comment 4 Tomofumi Yagi 2013-11-26 16:13:34 UTC
Created attachment 89847 [details]
Screen shot 4:Formatting toolbar 4.0.x
Comment 5 Maxim Monastirsky 2013-11-27 10:29:42 UTC
Hi,

Looking at the default font list for Japanese (http://cgit.freedesktop.org/libreoffice/core/tree/officecfg/registry/data/org/openoffice/VCL.xcu#n213) shows that they stored in their localized form. So basically one bug causes the other: LibreOffice checks for the localized form, and because it can't be found it uses the fallback font 'Arial Unicode MS'.
Comment 6 Tomofumi Yagi 2013-11-27 13:42:24 UTC
(In reply to comment #5)

Thank you.

I'm think so,too.

In version 4.1.x, implementation for the Core Text seems to have been changed. 
I'm guessing it is the cause of this bug. 

It might not been able to get localized font names from the system.
Comment 7 Robinson Tryon (qubit) 2013-12-19 10:25:44 UTC
Whiteboard: PossibleRegression
Comment 8 retired 2013-12-22 16:31:39 UTC
I'm hesitant to set my OS to japanese to test this. Also I think more complex and exact repro steps are required assuming non japanese OS X to start with.
Comment 9 Fuminobu TAKEYAMA 2014-01-13 10:39:38 UTC
The following file:
http://cgit.freedesktop.org/libreoffice/core/tree/vcl/quartz/ctfonts.cxx#n306
calls CTFontDescriptorCopyAttribute to get a family name of pFD.

But that function does not retun a localized name. To get a localized name, we must use CTFontDescriptorCopyLocalizedAttribute.

sample code is here
https://gist.github.com/ftake/8397208


An adhoc fix is replaceing CTFontDescriptorCopyAttribute with CTFontDescriptorCopyLocalizedAttribute. This problem can be resolved under Japanse environment, at east.

However, using only localized family names for font matching is not good idea. I have not confirmed yet, but that function may returns English name under English environment. This approach also problematic when some applications write English family names into *.odt files, and users open them with LibreOffice.


LibreOffice should keep all the localized names of a font and use them for matching. Or it should delegate font matching to a system font matcher provided by CoreText, fontconfig, ...


CJK users should not use 4.1.x and 4.2.x until this problem is fixed because most of CJK fonts have localized names.
Comment 10 Kohei Yoshida 2014-02-07 01:44:14 UTC
Per Comment 9, I'll get this bug report at least confirmed.
Comment 11 Kohei Yoshida 2014-02-07 02:01:56 UTC
I also received a few more acks from the Japanese ML. So this is definitely confirmed.
Comment 12 Tomofumi Yagi 2014-02-11 07:18:45 UTC
Created attachment 93838 [details]
0001-fdo-72042-workaround.patch

A workaround patch is here.
This patch has 2 changes,and this will restore the behavior of 4.0.

(1) If possible, DevFontFromCTFontDescriptor() will return the localized fontname.

(2) We will use kCTFontDisplayNameAttribute instead of kCTFontFamilyNameAttribute, when calling CTFontDescriptorCopyLocalizedAttribute()/CTFontDescriptorCopyAttribute() function.
Comment 13 Maxim Monastirsky 2014-02-11 07:26:53 UTC
@Tomofumi Yagi: It's better to submit patches to gerrit, see https://wiki.documentfoundation.org/Development/gerrit. Devs usually don't look for patches in bugzilla.
Comment 14 Tomofumi Yagi 2014-02-11 07:47:04 UTC
(In reply to comment #13)
> @Tomofumi Yagi: It's better to submit patches to gerrit, see
> https://wiki.documentfoundation.org/Development/gerrit. Devs usually don't
> look for patches in bugzilla.

Very thanks for your advice.
I will submit the patche to gerrit.
Comment 15 Tomofumi Yagi 2014-02-15 13:32:46 UTC
(In reply to comment #12)

> A workaround patch is here.
> This patch has 2 changes,and this will restore the behavior of 4.0.
(snip)
>
> (2) We will use kCTFontDisplayNameAttribute instead of
> kCTFontFamilyNameAttribute, when calling
> CTFontDescriptorCopyLocalizedAttribute()/CTFontDescriptorCopyAttribute()
> function.

I noticed that (2) is bad approach,and it is not necessary in now.

We finally want to resolve the problem that the fallback font is 'Arial Unicode MS',but we must first solve the problem of "Font names are not localized".

I pushd a new patch to gerrit.

https://gerrit.libreoffice.org/#/c/8071/
Comment 16 Commit Notification 2014-02-18 06:43:43 UTC
Tomofumi Yagi committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cda903f83831341f44833b94e7d38e598f5a7198

fdo#72042: Fix for "Font names are not localized (Mac OS X)"



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 17 Kohei Yoshida 2014-03-06 16:35:38 UTC
Adding Khaled on CC.  I'm told he is the expert on Mac CoreText API.
Comment 18 Matthew Francis 2015-02-12 06:29:20 UTC
Despite the commit in comment 16, font names still seem not to be localised on LibreOffice 4.4.0.3 / OSX 10.9.5 (desktop and LO both set to Chinese locale)
Comment 19 Tomofumi Yagi 2015-06-13 02:56:36 UTC
(In reply to Matthew Francis from comment #18)
> Despite the commit in comment 16, font names still seem not to be localised
> on LibreOffice 4.4.0.3 / OSX 10.9.5 (desktop and LO both set to Chinese
> locale)

Thank you.

I have confirmed on LibreOffice 5.0.0.0.beta1+ / OSX 10.10.3 (desktop and LO both set to Chinese locale) 

Third parameter 'language' for CTFontDescriptorCopyLocalizedAttribute() is incorrect on chinese locale.
CTFontDescriptorCopyLocalizedAttribute() needs "The language identifier will conform to the RFC 3066bis standard."

https://developer.apple.com/library/mac/documentation/Carbon/Reference/CTFontDescriptorRef/#//apple_ref/c/func/CTFontDescriptorCopyLocalizedAttribute

We need to use correct language identifer.
In addition, we probably need to convert the language identifer to acceptable for CTFontDescriptorCopyLocalizedAttribute(), too(e.x. from "zh-CN" to "zh-Hans").

I will try to fix,if possible.
Comment 20 Tomofumi Yagi 2015-06-14 03:14:36 UTC
Created attachment 116510 [details]
workaround patch 2(for analysis on chinese locale)

This is a patch for workaround and analysis on chinese locale.
This patch can be used for LibreOffice 5.0 and master.
Comment 21 Björn Michaelsen 2015-07-06 16:11:01 UTC
(In reply to Tomofumi Yagi from comment #14)
> (In reply to comment #13)
> > @Tomofumi Yagi: It's better to submit patches to gerrit, see
> > https://wiki.documentfoundation.org/Development/gerrit. Devs usually don't
> > look for patches in bugzilla.
> Very thanks for your advice.
> I will submit the patche to gerrit.

Please consider this for all patches: gerrit is much better to handle changes, its much easier to see what a patch is build against, if its already included etc.. If there is trouble with using gerrit, dont hesitate to ask to #libreoffice-dev on freenode IRC -- we will be happy to help out.
Comment 22 Tomofumi Yagi 2015-08-04 15:57:29 UTC
(In reply to Björn Michaelsen from comment #21)
> (In reply to Tomofumi Yagi from comment #14)
> > (In reply to comment #13)
> > > @Tomofumi Yagi: It's better to submit patches to gerrit, see
> > > https://wiki.documentfoundation.org/Development/gerrit. Devs usually don't
> > > look for patches in bugzilla.
> > Very thanks for your advice.
> > I will submit the patche to gerrit.
> 
> Please consider this for all patches: gerrit is much better to handle
> changes, its much easier to see what a patch is build against, if its
> already included etc.. If there is trouble with using gerrit, dont hesitate
> to ask to #libreoffice-dev on freenode IRC -- we will be happy to help out.

Thank you for your advice.
I have submitted the patch(work in progress) to gerrit.

https://gerrit.libreoffice.org/#/c/17507/1
Comment 23 Tomofumi Yagi 2015-11-23 07:20:17 UTC
(In reply to Matthew Francis from comment #18)
> Despite the commit in comment 16, font names still seem not to be localised
> on LibreOffice 4.4.0.3 / OSX 10.9.5 (desktop and LO both set to Chinese
> locale)

Dear Matthew Francis,
I'm analizing this problem with Chinese locale and writing a patch. 
However, It seems that it will take more time. 
If you want to fix in a hurry, it is better that you write a patch.
Best regards,
Yagi
Comment 24 Robinson Tryon (qubit) 2015-12-09 18:31:34 UTC Comment hidden (obsolete)
Comment 25 QA Administrators 2017-01-03 19:40:43 UTC Comment hidden (obsolete)
Comment 26 Adolfo Jayme Barrientos 2018-05-24 00:57:58 UTC
*** Bug 117751 has been marked as a duplicate of this bug. ***
Comment 27 QA Administrators 2019-05-25 02:56:18 UTC Comment hidden (obsolete)
Comment 28 Tomofumi Yagi 2019-06-02 02:09:32 UTC
I'm sorry for too late response.
I have confirmed that this bug isn't present in LibReOffice 6.2.3 in the Japanese UI.
If necessary, I would like you to create a new bug report for the other UI and locale.