Created attachment 100087 [details] ODS file in which cell A1 is formatted as [NatNum5] Description: The attached ods file has "[NatNum5]General" formatting in A1. When save as XLSX, this format is lost. Steps to reproduce: 1. Open the attached ods file with Calc. Notice that A1 is showing "壹佰贰拾" (which means ONE HUNDRED AND TWENTY). 2. Save as XLSX, then reopen with Calc. Notice that A1 is showing "120" rather than "壹佰贰拾". (The reason maybe because LibreOffice uses "[NatNumX]" format, but Microsoft Office uses "[DBNumX]" format.)
Reproducible with OS:Fedora 20 x86_64 Version: 4.2.4.2 Build ID: 4.2.4.2-8.fc20 and OS:Fedora 20 x86_64 Version: 4.3.0.0.beta1 Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f OS:Windows XP SP3 Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Comment on attachment 100087 [details] ODS file in which cell A1 is formatted as [NatNum5] Fixing MIME TYPE
Please note: In order for A1 to show as "壹佰贰拾", your OS should have zh_CN locale installed, because [NatNumX] and [DBNumX] are locale related.
** 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 (4.4.3 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-06-08
(In reply to QA Administrators from comment #4) This bug still exists in Version: 5.0.0.1 Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e Locale: zh-CN (zh_CN)
This does not seem to have ever worked. I tested many versions of LibO (down to 3.3.0) and AOO (4.1.2) and OOo (3.3.0, 3.0.1), and always reproduced the bug. Same for XLS or XLSX formats.
Apart from that the export from NatNumX to DBNumY isn't implemented, there is no mapping from NatNum5 (Korean: formal upper case text) to any DBNumY value. In fact LibreOffice knows 11 Korean NatNum values but Excel only 4 different DBNum values and "formal upper case text" is not among those. So which should we map to? In any case, reloading from .xls or .xlsx the original NatNum mode will be lost and DBNum could only be a substitute. See http://api.libreoffice.org/docs/idl/ref/namespacecom_1_1sun_1_1star_1_1i18n_1_1NativeNumberMode.html for available mappings.
Laurent Balland-Poirier committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ab98c81e1c4913aac3ce6453aa95c581dd582058 tdf#79398 Export to XL DBNum codes It will be available in 5.3.0. 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c82f7d762907c4bf9387bd2bc0680a58c1e2ca1 use SvNumberNatNum::IsComplete() instead of IsSet(), tdf#79398 follow-up It will be available in 5.3.0. 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.
(In reply to Eike Rathke from comment #7) > Apart from that the export from NatNumX to DBNumY isn't implemented, there > is no mapping from NatNum5 (Korean: formal upper case text) to any DBNumY > value. Darn, that comment is moot, it's about Chinese NatNum5 that maps to DBNum2, sorry for fuzz.
Actually this is not fixed, there's more to it as the format string to be exported is converted to an en-US format string because of possible locale dependent keywords, see SvNumberFormatter::GetFormatStringForExcel(), and during that conversion under SvNumberFormatter::PutandConvertEntry() the new SvNumberNatNum loses the original locale's context. Excel's locale support within number format works differently and we'll probably have to write the locale information into the format code as well. That likely was the reason why the MapNatNumToDBNum() code was #ifdef THE_FUTURE ;-)
So, two things to do: 1. maintain the locale information for the converted SvNumberNatNum during PutandConvertEntry(), but probably only if the original format's locale was not LANGUAGE_SYSTEM 2. write the locale information in SvNumberformat::GetMappedFormatstring() similar to what is done in the special case for the Thai locale
Laurent Balland-Poirier committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a70cd77e44797d07a348993277b44a062868e9f tdf#79398 Add LCID with DBNum during export to XL It will be available in 5.3.0. 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.
Laurent Balland-Poirier committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d7ce684cae03e97b23f916a90db55e49f17a1601 tdf#79398 Add qa unit test It will be available in 5.3.0. 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.
Laurent Balland-Poirier committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=662f5a5a16339ecda071ea6b95afefeea63c4fe9 tdf#79398 Insert LCID in the correct sub-format It will be available in 5.3.0. 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.
Laurent Balland-Poirier committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b193670284a4129aea04fa62c965663551d609de tdf#79398 Add qa unit test for sub-format It will be available in 5.3.0. 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.