Description: Frame border is missing after DOCX export Steps to Reproduce: 1. open attachment 170412 [details] 2. Save as DOCX 3. File reload Actual Results: Border missing (moving frame has it's own ticket) Expected Results: Border present (as before) Reproducible: Always User Profile Reset: No Additional Info: Found in 7.2 not in Version: 7.0.0.0.alpha1+ (x64) Build ID: 574c57090642347980d2395e1e183cc7b5c171ad CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Reproduced in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: d7ed130f537a81b900c55d222004cc9e88c0b355 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded but not in Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
LO 7.0 commit dd117712bd5692f7bf3870ba91572a0bab54ab86 Author: Armin Le Grand on Mar 5 19:24:30 2020 +0100 tdf#124848 partial refactor hairline logic With the handover of transformations to line draw calls it is no longer feasible to detect and prepare LineWidth stuff when the old office definition for hairlnes is used, a line width of zero. It was managed in the system-independent part, but now may have to be prepared in logic and not discrete (pixel) coordinates. To do so, find and cleanup all places where 1/1.0 was used as hairline line width. Adapt all seven graphic subsystems to handle the line width == 0/0.0 cases accordingly. Test as good as possible. https://cgit.freedesktop.org/libreoffice/core/commit/?id=dd117712bd5692f7bf3870ba91572a0bab54ab86 CC'd Armin
*** Bug 139144 has been marked as a duplicate of this bug. ***
ODT -> DOCX: emulation converting a frame-with-text to a textbox. Works with RTF and DOC which emulate differently. DOCX version loads OK in Word 2003 showing border, which suggests this is a file import issue. Re-confirmed by exporting from 6.4 - and master barely shows any borders on that one either - while 6.4 shows a border on the file master round-tripped. It is worth noting that the frame border is not actually missing. It is there and visible, but just seems to be somewhat transparent. If I use the UI to change the line width from 0.00 to 0.01 and then back again to 0.00, then the line is displayed as expected. I can't see anything in the UI that gets changed. So it seems like there is no regression here - just that perhaps emulation might be a bit better. The issue seems to be the width passed to <a:ln w="635">. If the width is not specified (as happens when you reset the width to zero), then the defaults look fine. Proposed export fix at https://gerrit.libreoffice.org/c/core/+/135674.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0332ab4bbbad2c4fad08650d62bf7addec0d2dd7 tdf#140967 docxexport: hairline is default and not a specific value 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.
Mike suggested a coding change to make it slightly cleaner looking, so no intention to backport the patch as is.
One could claim that this bug is not yet fully resolved. MS Word doesn't show such a thin line as we did, so perhaps there is a minimum width that LO is dropping below. Probably not worth investigating that unless we find such a document created by MS Word.