Description: Converting the attached .docx to a .pdf using libreoffice 6.1.3.2 results in a .pdf which misses certain numerical characters. To be specific; certain cells of the third column of the second table are missing a trailing 0 character for some reason. When converting the same .docx using Pages these characters are not missing. I've also tried libreoffice 5.4.7.2 and 4.4.7.2 and they give the same erroneous result. I've attached the original .docx, a .pdf version generated with Pages and the fault .pdf version generated with libreoffice6.1.3.2 for reference. Steps to Reproduce: 1. Use the attached .docx document as the source for the pdf conversion. The command used was: `libreoffice --headless --convert-to pdf --outdir test.pdf Actual Results: A .pdf is produced that is missing the numerical character 0 in some cells of a table Expected Results: The missing 0 characters should have been rendered on the final .pdf Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 147458 [details] original .docx source
Created attachment 147459 [details] converted document (Pages)
Created attachment 147460 [details] converted document (Word)
Created attachment 147461 [details] converted document (LibreOffice)
Thank you for reporting the bug. I can confirm that the bug is present in Version: 6.1.3.2 Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 2; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group threaded
Created attachment 147494 [details] Comparison LibreOffice 6.3 Master and MSO 2010
The problem is not while exporting to PDF, if you make the third column wider, the numbers will be displayed. The problem is at import time, see the screenshot. While MSO 2010 displays the whole value, LibreOffice does not...
Also reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.15; Render: default; Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Thank you both for confirming. Would this be something that is in the scope of being fixed by LibreOffice? We can work around it by increasing the column width as suggested, but it is not an ideal situation.
Created attachment 155889 [details] Screenshot of the document in Word and current Writer master side by side The problem is that a 0.19 cm left and right padding appears in Writer, while there is none in Word for that second table. Reducing that value to 0 fixes the display problem. Verzió: 6.5.0.0.alpha0+ (x64) Build az.: 7e09d08807b5ba2fd8b9831557752a415bdad562 CPU szálak: 4; OS: Windows 6.3 Build 9600; Felületmegjelenítés: alapértelmezett; VCL: win; Területi beállítások: hu-HU (hu_HU); Felület nyelve: hu-HU Calc: CL
Another nitpick: in the first table the "Licentie 1) Eenmalig" and "Jaarlijks 2)" cells have the 1) and 2) set as bold, italic and superscript but in Writer they do not seem to have smaller font size. This makes them unreadable as they don't fit in the cells as seen on attachment #147494 [details]. Turning off and on the superscript setting fixes this.
Created attachment 157053 [details] Screenshot of the document in recent 6.5 master The cell paddings are no longer a problem after fixing bug #77796 in: Version: 6.5.0.0.alpha0+ (x64) Build ID: d122a9d12d970d55f4dc9e4268e0681fd2e6786f CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL The table heading still has oversized numbers in superscript. We might keep this alive for that problem.
The cell padding part of this was fixed by bug #77796 The elevated subscript characters part lives on in bug#129920 *** This bug has been marked as a duplicate of bug 77796 ***