Description: When creating new tabs in the ruler with the data aligned based on the decimal point, this works with odt files and doc files, but if the document is saved as a docx file, is closed, and is then re-opened, all of the columns now appear misaligned. Steps to Reproduce: 1. Create tabbed column of numerical data using decimal point tab in ruler 2. Save as docx file 3. Reopen file Actual Results: Column is misaligned upon reopening the file Expected Results: Column should be unaffected upon reopening Reproducible: Always User Profile Reset: Yes Additional Info:
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 154918 [details] Screenshot showing how decimal points are not properly aligned but offset when saving, closing, then reopening a docx file in LibreOffice Writer
Created attachment 154919 [details] The docx file from which the screenshot was taken
David, please add the original odt-file, to make the difference clear. Please also make sure, that you're using an actual version of LO (please paste informations from HELP => About LibreOffice => NEEDINFO
This bug pertains to docx files, so there is no "original odt file." My version: Version: 6.1.5.2 Build ID: 1:6.1.5-3+deb10u5 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; Locale: en-US (en_US.UTF-8); Calc: group threaded
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
(In reply to David K from comment #5) > My version: > Version: 6.1.5.2 > Build ID: 1:6.1.5-3+deb10u5 > CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; > Locale: en-US (en_US.UTF-8); Calc: group threaded David, could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
This bug is still present in Version: 6.4.4.2.
I tried this issue as explained in the step to reproduce, but nothing happen, I mean, no misaligned columns after i reopen the DOCX document. Versi: 6.4.5.2 ID Build: 1:6.4.5-1 Thread CPU: 12; OS: Linux 5.7; Render UI: baku; VCL: kf5; Locale: id-ID (id_ID.UTF-8); Bahasa-UI: id-ID Calc: threaded
(In reply to David K from comment #5) > This bug pertains to docx files, so there is no "original odt file." Regarding to your steps in the bug decription, there is an odt-file after step 1 and you save it as docx in step 2. Correct?
No, so a new file is created and then later on is saved as a docx file.
(In reply to David K from comment #11) > No, so a new file is created and then later on is saved as a docx file. But the new file is an odt-file, until you save it as docx, isn't it?
I mean to produce the error, I only save the file once as a docx file.
(In reply to David K from comment #13) > I mean to produce the error, I only save the file once as a docx file. So please save it as odt instead of docx and add it as attachment.
Created attachment 163838 [details] <spam>
Created attachment 163839 [details] <spam>
Setting status to NEEDINFO per Dieter's comment.
This is a tricky situation. The decimal tabulator can have an arbitrary decimal separator set in Writer. Word on the other hand does not have such a feature, so docx format does not support at save time storing the arbitrary decimal separators set in Writer. What happens at export time is that the separators are not saved at all, and at import time they are imported as comma. The difference in display is also locale-specific when comparing editing a new file. The default decimal separator used for decimal tabulators matches the locales default: usually dot (English) or comma (such as German or Hungarian). This makes the editor align the numbers to the decimal tabulator if they contain the locale-default separator, which is intuitive. With locales using dot the docx save and reload messes up the layout, since reopening the file changes the separator to comma. If they used numbers with dot as separator, that is now left-aligned since it does not contain the expected comma. Word on the other hand does not support custom decimal separator, what it does is that it supports all kinds of non-number character separators for decimal type tabulators. So whether a Writer-saved docx file originally aligned numbers to a dot or comma does not matter in Word, it will align both variation to the decimal tab. I'll attach a few example files and screenshots to document what's going on.
Created attachment 168593 [details] Decimal tabulator made with English locale
Created attachment 168594 [details] Decimal tabulator made with English locale, saved as docx by Writer
Created attachment 168595 [details] Decimal tabulator made with English locale, in odt and docx in Writer
Created attachment 168596 [details] Decimal tabulator made with English locale, odt in Writer and docx in Word
Created attachment 168597 [details] Decimal tabulator made with Hungarian locale
Created attachment 168598 [details] Decimal tabulator made with Hungarian locale, saved as docx by Writer
Created attachment 168599 [details] Decimal tabulator made with Hungarian locale, in odt and docx in Writer
Created attachment 168600 [details] Decimal tabulator made with Hungarian locale, odt in Writer and docx in Word
Created attachment 168601 [details] Decimal tabulator made with Word 2013
Created attachment 168602 [details] Decimal tabulator document from Word in Writer and Word side by side
This is a regression from commit c0b6aadedc9429eee4f4df85957e00e29ccb0c8f "(related: fdo#81033) writerfilter: default tab fill character is space".
Created attachment 181377 [details] en_US document with currency number format usage with thousand separator , E.g. "45,454,435.00 USD". Formatting can be handled by Writer correctly, depending on the locale. But the reported regression resulted bad decimal alignment, related to the comma, as fixed decimal separator for all languages.
Number formats with thousand separators are handled by text tables in Writer, see Table->Number format..., see attached test document "en_US document with currency number format usage with thousand separator", It seems, we could only fix the import based on the locale settings of LibreOffice, solving the original bug report by partial revert of commit c0b6aadedc9429eee4f4df85957e00e29ccb0c8f, removing this line: writerfilter/source/dmapper/DomainMapper_Impl.hxx: DecimalChar = ','; Note: The "ugly" problem mentioned in that commit doesn't occur any more.
Tünde Tóth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f224cdfb3c264a339d3148c7c2936f3202015f7d tdf#120972 DOCX: fix import of decimal tabulators It will be available in 7.5.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.
Tünde Tóth committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/7e93946fc5252a2437f05400dba02dd5bf5140c5 tdf#120972 DOCX: fix import of decimal tabulators It will be available in 7.4.1. 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.