Bug 116472 - IMPORT: Page border is invisible in specific DOCX (border color=auto)
Summary: IMPORT: Page border is invisible in specific DOCX (border color=auto)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.4
Keywords: bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Page
  Show dependency treegraph
 
Reported: 2018-03-18 17:21 UTC by Mike Kaganski
Modified: 2018-04-02 13:49 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
A file with borders having w:color=auto (11.43 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-03-18 17:22 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2018-03-18 17:21:28 UTC
Attached DOCX (created with MS Word) has all borders set, with border color = auto. In 6.0.2.1, it shows the borders (with color = 0x00000A); in current master it shows white border (= invisible on white background; border properties say "Automatic").

Reverting commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=fe6da2feb57c3d5e355a36f6b8ac09b48412ff39 brings old behavior back.

The problem seems to be absence of handling of COL_AUTO for borders, which makes it equivalent to white.
Comment 1 Mike Kaganski 2018-03-18 17:22:48 UTC
Created attachment 140688 [details]
A file with borders having w:color=auto
Comment 2 Jacques Guilleron 2018-03-18 18:40:28 UTC
Hi Mike,

I reproduce with
LO  6.1.0.0.alpha0+ Build ID: 8038911866f54f3921f51a2a1e702831c42f02fd
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-03-17_23:12:09
Locale: fr-FR (fr_FR); Calc: CL
but not with
LO  6.1.0.0.alpha0+ Build ID: 0d1479cbd442c3ec3bdd20333c341ea24dcca21e
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-03-10_01:47:26
Locale: fr-FR (fr_FR); Calc: CL
Comment 3 Mike Kaganski 2018-03-18 20:50:18 UTC
I started to prepare a patch that would provide black as displayed auto color, allow auto color to be imported/exported from/to DOC, and also prepare the relevant property tab for this. But now I suppose that since ODF doesn't provide for auto border color (https://www.w3.org/TR/REC-CSS2/box.html#propdef-border mentions simply color; https://www.w3.org/TR/REC-CSS2/colors.html#propdef-color only defines w3c-defined color; and http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#datatype-color defines RGB colors), implementing this would mean that we would have in interface something not supported by ODF.

In this state, the proper fix IMO would be to just import the auto border color as black. Opinions?
Comment 4 Mike Kaganski 2018-03-18 21:00:23 UTC
https://gerrit.libreoffice.org/51518 is the tentative patch that would allow auto color in DOC, correctly handle it in property tab, and use black to show it. Providing it just in case.
Comment 5 Mike Kaganski 2018-03-18 21:16:08 UTC
https://gerrit.libreoffice.org/51519 is the preliminary patch that converts the "auto" border color to black on import. It lacks a unit test, so WIP; also need opinions to continue on it.
Comment 6 Luke Deller 2018-03-19 10:56:54 UTC
Thanks for looking at this Mike.  I like that your second patch preserves the behaviour before commit fe6da2feb57c3d5e355a36f6b8ac09b48412ff39 (except with proper black rather than #00000A).  Also there is some precedent for this:

1. The example you found already in the doc (ww8) import filter:
https://gerrit.libreoffice.org/#/c/51518/1/sw/source/filter/ww8/ww8par6.cxx

2. A similar example I came across is for table cell background colour and fill pattern colour, for which docx "auto" colour is imported as white and black respectively.  See I preserved this behaviour in my change:
https://gerrit.libreoffice.org/#/c/50995/3/writerfilter/source/dmapper/CellColorHandler.cxx

Do you think we might consider backporting these two changes to 6.0 to fix tdf#116179?  The alternative of adding proper COL_AUTO support for borders sounds a bit scarier to backport.

After this though it would be a nice feature to support COL_AUTO for borders properly, at least for better compatibility with Word documents.  Regarding the ability to represent this in ODF, let's CC Regina - perhaps we might ask for an enhancement in the ODF standard, and use an extension in the meantime?
Comment 7 Luke Deller 2018-03-19 12:53:49 UTC
Hi Regina, do you have any suggestion on how to represent "automatic" colour in ODF?

When text colour is set to "automatic" in the LibreOffice UI, this is saved to ODF using the style:use-window-font-color attribute:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#property-style_use-window-font-color

However we cannot use this for other elements like border colour and table cell fill patterns.  Does this need an extension?
Comment 8 Commit Notification 2018-03-19 15:42:57 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9078fbd14be7c2e4f7c830286cceb0003a345472

tdf#116472: import "auto" border color as black

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Mike Kaganski 2018-03-19 15:51:37 UTC
(In reply to Luke Deller from comment #6)
> Do you think we might consider backporting these two changes to 6.0 to fix
> tdf#116179?

Of course; we could do that as follow-up for your backport when it lands I suppose.
Comment 10 Regina Henschel 2018-03-19 17:20:07 UTC
(In reply to Luke Deller from comment #7)
> Hi Regina, do you have any suggestion on how to represent "automatic" colour
> in ODF?

There exists no way to express "automatic" in XSL-fo or CSS and even CSS3 has nothing like "automatic". But I would not worry about that. Translating "automatic" to "black" is fine for borders, because Word itself does not really use "automatic" but has a black border on nearly black background, even in case the "automatic" font color is already white.
Comment 11 Commit Notification 2018-03-20 09:07:46 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=88e22b92bce612f349f8aa38adf69a8806361da3&h=libreoffice-6-0

tdf#116472: import "auto" border color as black

It will be available in 6.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Jacques Guilleron 2018-03-21 09:28:13 UTC
Works with
LO  6.1.0.0.alpha0+ Build ID: dd4f1b1bd31daf080dc0420524712dc244e539b5
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-03-20_23:26:38
Locale: fr-FR (fr_FR); Calc: CL