Download it now!
Bug 122037 - FILEOPEN: content in table is not completely displayed (extraneous cell padding)
Summary: FILEOPEN: content in table is not completely displayed (extraneous cell padding)
Status: RESOLVED DUPLICATE of bug 77796
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2018-12-12 09:18 UTC by Michael
Modified: 2020-01-10 11:16 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
original .docx source (29.39 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-12-12 09:19 UTC, Michael
Details
converted document (Pages) (59.87 KB, application/pdf)
2018-12-12 09:20 UTC, Michael
Details
converted document (Word) (59.54 KB, application/pdf)
2018-12-12 09:20 UTC, Michael
Details
converted document (LibreOffice) (43.52 KB, application/pdf)
2018-12-12 09:20 UTC, Michael
Details
Comparison LibreOffice 6.3 Master and MSO 2010 (44.58 KB, image/png)
2018-12-13 11:38 UTC, Xisco Faulí
Details
Screenshot of the document in Word and current Writer master side by side (141.22 KB, image/png)
2019-11-17 09:17 UTC, NISZ LibreOffice Team
Details
Screenshot of the document in recent 6.5 master (82.16 KB, image/png)
2020-01-10 08:16 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael 2018-12-12 09:18:38 UTC
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:
Comment 1 Michael 2018-12-12 09:19:18 UTC
Created attachment 147458 [details]
original .docx source
Comment 2 Michael 2018-12-12 09:20:04 UTC
Created attachment 147459 [details]
converted document (Pages)
Comment 3 Michael 2018-12-12 09:20:28 UTC
Created attachment 147460 [details]
converted document (Word)
Comment 4 Michael 2018-12-12 09:20:55 UTC
Created attachment 147461 [details]
converted document (LibreOffice)
Comment 5 Durgapriyanka 2018-12-12 17:22:48 UTC
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
Comment 6 Xisco Faulí 2018-12-13 11:38:39 UTC
Created attachment 147494 [details]
Comparison LibreOffice 6.3 Master and MSO 2010
Comment 7 Xisco Faulí 2018-12-13 11:42:21 UTC
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...
Comment 8 Xisco Faulí 2018-12-13 11:43:53 UTC
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
Comment 9 Michael 2018-12-13 14:44:08 UTC
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.
Comment 10 NISZ LibreOffice Team 2019-11-17 09:17:23 UTC
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
Comment 11 NISZ LibreOffice Team 2019-11-17 09:21:59 UTC
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.
Comment 12 NISZ LibreOffice Team 2020-01-10 08:16:51 UTC
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.
Comment 13 NISZ LibreOffice Team 2020-01-10 11:16:39 UTC
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 ***