| Summary: | Font names are not localized (Mac OS X) | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Tomofumi Yagi <yagit> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | dr.khaled.hosny, ikuya, momonasmon, qubit |
| Version: | 4.1.3.2 release | ||
| Hardware: | Other | ||
| OS: | Mac OS X (All) | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=77971 https://bugs.freedesktop.org/show_bug.cgi?id=77972 |
||
| Whiteboard: | BSA PossibleRegression target:4.3.0 | ||
| i915 platform: | i915 features: | ||
| Attachments: |
Screen shot 1:Basic_Fonts(Asian) 4.1.x or later
Screen shot 2:Basic_Fonts(Asian) 4.0.x Screen shot 3:Formatting toolbar 4.1.x or later Screen shot 4:Formatting toolbar 4.0.x 0001-fdo-72042-workaround.patch |
||
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] [review] 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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