Bug 140967 - Frame border is missing after DOCX export
Summary: Frame border is missing after DOCX export
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Justin L
Whiteboard: target:7.5.0
Keywords: bibisected, filter:docx
: 139144 (view as bug list)
Depends on:
Blocks: DOCX-Frames
  Show dependency treegraph
Reported: 2021-03-12 08:01 UTC by Telesto
Modified: 2022-06-24 14:43 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-03-12 08:01:49 UTC
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

not in
Version: (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
Comment 1 Xisco Faulí 2021-03-18 17:34:35 UTC
Reproduced in

Version: / 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

Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 2 Justin L 2021-03-26 16:51:09 UTC
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.


CC'd Armin
Comment 3 Aron Budea 2021-05-29 23:27:53 UTC
*** Bug 139144 has been marked as a duplicate of this bug. ***
Comment 4 Justin L 2022-06-15 13:50:11 UTC
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.
Comment 5 Commit Notification 2022-06-20 14:03:47 UTC
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.
Comment 6 Justin L 2022-06-20 14:28:09 UTC
Mike suggested a coding change to make it slightly cleaner looking, so no intention to backport the patch as is.
Comment 7 Justin L 2022-06-20 14:31:21 UTC
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.