Bug 112450 - FILEOPEN, DOCX 2007 missing lines (but OK if DOCX resaved in MSO) - comment 6 and comment 7
Summary: FILEOPEN, DOCX 2007 missing lines (but OK if DOCX resaved in MSO) - comment 6...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low normal
Assignee: Regina Henschel
Whiteboard: target:7.3.0
Keywords: filter:docx
Depends on:
Blocks: VML-Shapes
  Show dependency treegraph
Reported: 2017-09-17 18:18 UTC by Oliver Sander
Modified: 2021-08-27 12:12 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

The file that triggers the problem (45.77 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-09-17 18:19 UTC, Oliver Sander
The file as rendered by LO (82.41 KB, application/pdf)
2017-09-17 18:19 UTC, Oliver Sander
The file as rendered by MSOffice (69.05 KB, application/pdf)
2017-09-17 18:19 UTC, Oliver Sander
minimial docx file causing the bug (16.15 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-09-27 10:36 UTC, Patrick Jaap
minimal file with 2013 standard (18.81 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-09-28 10:27 UTC, Patrick Jaap

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Sander 2017-09-17 18:18:23 UTC
The attached docx document contains two short horizontal lines near the left border of the page (to show where a printed page may be folded).  These lines are not shown by LO.

Actual Results:  

Expected Results:

Reproducible: Always

User Profile Reset: No

Additional Info:

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Comment 1 Oliver Sander 2017-09-17 18:19:07 UTC
Created attachment 136308 [details]
The file that triggers the problem
Comment 2 Oliver Sander 2017-09-17 18:19:31 UTC
Created attachment 136309 [details]
The file as rendered by LO
Comment 3 Oliver Sander 2017-09-17 18:19:57 UTC
Created attachment 136310 [details]
The file as rendered by MSOffice
Comment 4 Thomas Lendo 2017-09-17 22:22:25 UTC
Confirmed with Version:
Build-ID: 7315f325ff7ada3d6bd85a471058fdaeaff8cdb0
CPU-Threads: 4; Betriebssystem:Linux 4.10; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-17_06:58:21
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

and LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-
Comment 5 Patrick Jaap 2017-09-27 10:36:59 UTC
Created attachment 136563 [details]
minimial docx file causing the bug

This is a minimal version of Bsp2.docx containing only one small line. It is rendered in MSO but not in current master of LO.

The line is encoded by
<w:pict><v:polyline> [....]

That is a good start for debugging, I think.
Comment 6 Patrick Jaap 2017-09-27 10:40:54 UTC
Additional info: Opening the file in Office 2013 and saving it (with 2013 standard) resolves the bug. So it looks like the line is an old docx-feature, which is outdated. In order to create a problematic docx I have to save it in compatibility mode.
Comment 7 Patrick Jaap 2017-09-28 10:27:21 UTC
Created attachment 136579 [details]
minimal file with 2013 standard

the minimal doxc file with the "new" standard (MSO 2013). This is rendered fine by LO. It switched over from a simple "w:pict" to a more complex "w:drawing" command in the xml files.

I noticed that in both minimal files, there is exactly one "SwAnchoredDrawObject" created (and more if I add addional lines). So, the small line is parsed and positioned my LO. I still don't know why one is rendered and the other one not.
Comment 8 QA Administrators 2018-11-21 03:44:36 UTC Comment hidden (obsolete)
Comment 9 Oliver Sander 2018-11-21 06:36:49 UTC
Confirmed in

Build ID: 72e6269b88a32a672e00d2c25f0d0400038d1360
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: kde5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-14_19:34:46
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded
Comment 10 Timur 2019-09-19 07:20:20 UTC
Repro 6.4+. BUt happens only with attached 2007 DOCX. If resaved in MSO, lines are there, as can be seen from DOCX attachment 154280 [details] and as noted in comment 6 and comment 7. So I set to Low.
Comment 11 NISZ LibreOffice Team 2020-10-15 12:36:39 UTC
v:polyline not rendered -> Move to VML-shape meta

@Balazs I thought you might be interested in this one.
Comment 12 Regina Henschel 2021-08-24 12:19:35 UTC
You get the same problem with current applications: Draw a polygon in Writer and export as docx. Because of the fix for tdf#75254 this does not generate a custom shape but only a VML shape. Open the file in Word and add a point to the polygon. Save it in Word. Word converts it to a v:polyline element without adding a custom shape. This does not happen in PowerPoint. I have not tested Excel.

Word writes the values in the attribute "points" with units, e.g. 31.2pt,297.7pt. But the import does not consider units.

The error is in https://opengrok.libreoffice.org/xref/core/oox/source/vml/vmlshapecontext.cxx?r=e12d4c7e#572

Because the token contains the unit, toInt32() returns 0.

If such edited shape is copies from Word to PowerPoint, then it is converted to a custom shape. I don't know whether older PowerPoint versions create v:polyline. It might be necessary do distinguish applications anyway, because of the Twips vs 1/100mm problem. The attribute coordsize, which Word produces, is in Twips, but has no unit. So for Writer the token has to be converted to a number value in Twips to match the coordsize attribute.
Comment 13 Regina Henschel 2021-08-25 00:43:53 UTC
Position and Size are missing too. In contrast to v:shape they are not contained in the 'style' attribute. It seems, that Word writes the size into attribute 'coordsize' in Twips. Position seems to be 0|0 in Word. Does Word write it to coordpos if it is not zero? Size is expected in maWidth and maHeight of maTypeModel, position in maLeft and maTop, all as string with unit.

Mmh, I have looked around a lot already. Perhaps I should try a fix.
Comment 14 Regina Henschel 2021-08-25 00:45:59 UTC
... Does Word write it to 'coordorigin' ...?
Comment 15 Regina Henschel 2021-08-25 19:47:44 UTC
First step (unit tests are missing) for a fix is in https://gerrit.libreoffice.org/c/core/+/121042.
Comment 16 Commit Notification 2021-08-27 11:42:30 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":


tdf#112450 correct points and size for polyline in VML import

It will be available in 7.3.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:

Affected users are encouraged to test the fix and report feedback.