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
Created attachment 89844 [details] Screen shot 1:Basic_Fonts(Asian) 4.1.x or later
Created attachment 89845 [details] Screen shot 2:Basic_Fonts(Asian) 4.0.x
Created attachment 89846 [details] Screen shot 3:Formatting toolbar 4.1.x or later
Created attachment 89847 [details] Screen shot 4:Formatting toolbar 4.0.x
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'.
(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.
Whiteboard: PossibleRegression
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.
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.
Per Comment 9, I'll get this bug report at least confirmed.
I also received a few more acks from the Japanese ML. So this is definitely confirmed.
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.
@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.
(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.
(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/
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.
Adding Khaled on CC. I'm told he is the expert on Mac CoreText API.
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)
(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.
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.
(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.
(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
(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
Migrating Whiteboard tags to Keywords: (possibleRegression)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
*** Bug 117751 has been marked as a duplicate of this bug. ***
Dear Tomofumi Yagi, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.