Problem description: Chinese font names appear in English, for example the font TW-Kai (called 全字庫正楷體 in Chinese), on Debian Linux. Chinese font names appear in Chinese on Windows. 全字庫正楷體 appears as 全字庫正楷體 on Windows. Save a file with the font name TW-Kai on Debian Linux. Then, this font is _not_ recognized on Windows. (Save a file with the font name 全字庫正楷體. Then, this font is _recognized_ on Debian Linux.) Steps to reproduce: 1. The operating system used is Linux debian 2.6.32-5-686 #1 SMP Mon Feb 25 01:04:36 UTC 2013 i686 GNU/Linux. 2. The LibreOffice version involved is: Version 4.0.2.2 (Build ID：4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) 3. Type and select some Chinese text. 4. Select the font TW-Kai on Debian Linux. (The font name 全字庫正楷體 is missing.) 5. File -> Save 6. Open the file on Windows (having installed the font mentioned) 7. The font mentioned is _not_ recognized. Compare: 1. Type and select some Chinese text on Windows. 2. Select the font 全字庫正楷體 on Windows. (The font name TW-Kai is missing.) 3. File -> Save 4. Open the file on Debian Linux (having installed the font mentioned) 5. The font mentioned is _recognized_. Current behavior: LibreOffice on Windows does not recognized the Chinese font name in English in the sample Linux file. Expected behavior: LibreOffice on Windows should recognize the Chinese font name in English in the sample Linux file. Related: https://bugs.freedesktop.org/show_bug.cgi?id=59055
Created attachment 77296 [details] File saved on Debian Linux
Created attachment 77297 [details] File saved on Windows
Confirm the same issue. In addition, all Chinese font names are affected, i.e. Chinese font names are shown in English in the Font Name list. Chinese font names in English are treated as different fonts. Chinese font names in English are not the same as Chinese font names in Chinese. --- LibreOffice Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
I tried this with 4.0.6 and 4.2.5 on Linux Mint and wasnt able to reproduce this using text pulled from < http://zh.wikipedia.org/wiki/LibreOffice > and pasted without formatting and then setting them to the Simsun font and then loading them in LibO on Windows 7. Can you please try a newer version of LibreOffice and see if this still happens. There is a chinese forum for LibreOffice users that recently started and i thought you might be interested in checking it out < http://libreofficechina.org/forum.php >
*** Bug 81964 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Message generated on: 2015-02-18
What more information do you have? All multilingual names of font is contained in each font file.
@Kevin, @Matthew: can you guys have a look at this one.
The result for attachment 77297 [details] is the same on both Linux and OSX - the "全字庫正楷體" font shows in the font selector as having been substituted (italic text) (On Linux it looks to me as though the correct font has actually been used, but the interface still indicates substitution, so I'm not sure if this was intentional or just because it was an available Chinese font) To reproduce on Windows you would need to install the font in question. I can't see it through the original link, but it is available here: http://file.magiclen.org/index.php?file=54572d4b61692e726172 (click the large link and wait) On the basis that for interoperability between users with different languages, we should really recognise all the font names defined in a font, setting -> NEW
This is not just for Chinese fonts, it affects any font that changes name based on your system locale, such as Japanese fonts. Calls to CreateFont on Windows will always accept the English name of any font, but the actual font name that you see in font dialogs and such will often be the localized name instead of the English name. It depends on the system's locale settings. LibreOffice should always allow the English name, just like Windows itself does. Given an English font name, it's not very hard to use a few Win32 API calls to get its localized name. I was testing out LibreOffice on Japanese locale. The major fonts are MS Gothic and MS Mincho, spelled "ＭＳ ゴシック" or "ＭＳ 明朝" when using Japanese locale. I was unable to type "MS Gothic" into the font selector, since it changed the ASCII characters into fullwidth characters as I was typing. But I was able to copy-paste that font name in. Even though it says that the font name is unrecognized, it still displayed using that font, probably since the Windows font mapper always recognizes the English font names.
I also encounter the same problem.My system is windows 10 English version, Chinese locale,current language for non-Unicode programs:Chinese(Simplified, China). In the font drop down list the Chinese font names are blank,and only the Symbol preview is shown.
Sorry, I have LibreOffice 5.0.2.2 installed.
** 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-20161108
Created attachment 136859 [details] Windows Registery items (In reply to ftj from comment #11) > I also encounter the same problem.My system is windows 10 English version, > Chinese locale,current language for non-Unicode programs:Chinese(Simplified, > China). In the font drop down list the Chinese font names are blank,and only > the Symbol preview is shown. Windows Registery has the following path for this, LibreOffice can add codes to load font from here to specified fallback fonts if a document including non-English font names: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontMapperFamilyFallback
** 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 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
Dear webofht-libreofficebugs002, 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 https://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
Dear webofht-libreofficebugs002, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 107484 has been marked as a duplicate of this bug. ***
*** Bug 80812 has been marked as a duplicate of this bug. ***
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5257ad4ec11bafcc2765ef5bb3e8cfb37ac7742c tdf#63011 vcl: Use localized font family names as aliases It will be available in 26.8.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.
LibreOffice now understands font names from other languages, in addition to the current UI language. We handle this ourselves, so it will work the same way on all platforms. The GUI also no longer says these fonts are substituted.
*** Bug 170319 has been marked as a duplicate of this bug. ***
*** Bug 154571 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3b43be508d5f2ac1bd76051924e960c0be9bfafd Revert "tdf#63011 vcl: Use localized font family names as aliases" It will be available in 26.8.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.
I think this should queries font names from font files, rather than calling system APIs. For OpenType fonts, these could be retrieved from 'name' table. https://learn.microsoft.com/en-us/typography/opentype/spec/name
(In reply to Commit Notification from comment #24) > Xisco Fauli committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 3b43be508d5f2ac1bd76051924e960c0be9bfafd > > Revert "tdf#63011 vcl: Use localized font family names as aliases" > > It will be available in 26.8.0. Reopening due to revert.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c93a99c3a14af276f9e43cd0bd68be89fd3e3db8 Reapply "tdf#63011 vcl: Use localized font family names as aliases" It will be available in 26.8.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.
The Windows CI build took 54 minutes to run with this new version, so the build time regression seems to be resolved.