Description: 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
Created attachment 136308 [details] The file that triggers the problem
Created attachment 136309 [details] The file as rendered by LO 5.4.1.2
Created attachment 136310 [details] The file as rendered by MSOffice
Confirmed with Version: 6.0.0.0.alpha0+ 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-3.3.0.4
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.
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.
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.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Confirmed in Version: 6.2.0.0.alpha1+ 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
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.
v:polyline not rendered -> Move to VML-shape meta @Balazs I thought you might be interested in this one.
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.
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.
... Does Word write it to 'coordorigin' ...?
First step (unit tests are missing) for a fix is in https://gerrit.libreoffice.org/c/core/+/121042.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c56178f0daf69abb362e6216f51b6e1f5aff1777 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.