Frame border is missing after DOCX export
Steps to Reproduce:
1. open attachment 170412 [details]
2. Save as DOCX
3. File reload
Border missing (moving frame has it's own ticket)
Border present (as before)
User Profile Reset: No
Version: 22.214.171.124.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
Version: 126.96.36.199.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
but not in
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.
*** 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":
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:
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.