Bug 116592 - FILEOPEN DOCX: 3D and flat is exchanged in some borders
Summary: FILEOPEN DOCX: 3D and flat is exchanged in some borders
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX Borders
  Show dependency tree / graph
 
Reported: 2018-03-23 23:31 UTC by Regina Henschel
Modified: 2023-08-01 13:04 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Collection of frames around paragraphs (47.13 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-03-23 23:31 UTC, Regina Henschel 		Details
screenshot of Word 2016 (62.38 KB, image/png)
2018-03-23 23:32 UTC, Regina Henschel 		Details
Comparison, Left side LO 5.4, right side LO 6.1 master (207.20 KB, image/png)
2018-03-30 07:36 UTC, Bartosz 		Details
Screenshot from 6.0.2 (125.54 KB, image/png)
2018-03-30 07:42 UTC, Buovjaga 		Details
The issue also exists in .doc format (29.50 KB, application/msword)
2018-03-30 09:23 UTC, Bartosz 		Details
this is how it looks in 7.3 (207.38 KB, image/png)
2021-07-31 08:20 UTC, BogdanB 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2018-03-23 23:31:32 UTC 
Created attachment 140836 [details]
Collection of frames around paragraphs

A border gets a 3D appearance, if a line with two colors is used e.g in this way: The top and left border lines have the light color on the outer side and the dark color at the inner side. The bottom and the right border lines have it the other way round, the light color is at the inner side and the dark color is at the outer side. To get a "flat" border the color at the inner side of the frame has to be the same at all four sides.

Word generates a "flat" appearance by using a line, which has the colors the other way round for the bottom and right edge. That is hidden from the user, you have to read the file source to see it. OOXML has an attribute w:frame="true" for the same effect. That works in Word too, but Word has no UI for it.

The attached frame has a collection of frames around paragraphs. The attached image is a screenshot of the appearance in Word. Compare the paragraphs "21" and "22" in its "flat" and in its 3D versions with the screenshot. Notice that the bottom and right lines are wrong.
The paragraphs "23" and "24" have the same problem, but the frame styles "inset" and "outset" are broken in Word at least since Word 2003.
The other asymmetric borders "09", "10", "12", and "13" have the problem too, but it is harder to be seen.
Comment 1 Regina Henschel 2018-03-23 23:32:24 UTC 
Created attachment 140837 [details]
screenshot of Word 2016
Comment 2 Buovjaga 2018-03-29 14:13:24 UTC 
Confirmed 21/22.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 9c459fd919cb8199a69fc2d630742930e533285b
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 29th 2018
Comment 3 Bartosz 2018-03-29 15:51:16 UTC 
Description of paragraph borders are available at:
http://www.datypic.com/sc/ooxml/e-w_pBdr-1.html
Comment 4 Bartosz 2018-03-29 16:11:50 UTC 
The mapping of the Word to Writer is available at file:
writerfilter/source/dmapper/ConversionHelper.cxx:240

It seems that MS Word it treating colors differently, and it is depends on position.

void MakeBorderLine( sal_Int32 nLineThickness,   sal_Int32 nLineToken,
                                            sal_Int32 nLineColor,
                                            table::BorderLine2& rToFill, bool bIsOOXML )
{
    static const sal_Int32 aBorderDefColor[] =
    {
        // The first item means automatic color (COL_AUTO), but we
        // do not use it anyway (see the next statement) .-)
        0, COL_BLACK, COL_LIGHTBLUE, COL_LIGHTCYAN, COL_LIGHTGREEN,
        COL_LIGHTMAGENTA, COL_LIGHTRED, COL_YELLOW, COL_WHITE, COL_BLUE,
        COL_CYAN, COL_GREEN, COL_MAGENTA, COL_RED, COL_BROWN, COL_GRAY,
        COL_LIGHTGRAY
    };
    //no auto color for borders
    if(!nLineColor)
        ++nLineColor;
    if(!bIsOOXML && sal::static_int_cast<sal_uInt32>(nLineColor) < SAL_N_ELEMENTS(aBorderDefColor))
        nLineColor = aBorderDefColor[nLineColor];

    sal_Int32 nLineType = lcl_convertBorderStyleFromToken(nLineToken);

    // Map to our border types, we should use of one equal line
    // thickness, or one of smaller thickness. If too small we
    // can make the deficit up in additional white space or
    // object size
    SvxBorderLineStyle const nLineStyle(
            ::editeng::ConvertBorderStyleFromWord(nLineType));
    rToFill.LineStyle = static_cast<sal_Int16>(nLineStyle);
    double const fConverted( (SvxBorderLineStyle::NONE == nLineStyle) ? 0.0 :
        ::editeng::ConvertBorderWidthFromWord(nLineStyle, nLineThickness,
            nLineType));
    rToFill.LineWidth = convertTwipToMM100(fConverted);
    rToFill.Color =
Comment 5 Bartosz 2018-03-30 07:36:04 UTC 
Created attachment 140971 [details]
Comparison, Left side  LO 5.4, right side LO 6.1 master

It seems it is an regression in LibreOffice for borders number: 9 - 17
Please see attached screenshot (Left side  LO 5.4, right side LO 6.1 master)

Could you please check if the issue is present with LibreOffice 6.0?
Comment 6 Buovjaga 2018-03-30 07:42:11 UTC 
Created attachment 140973 [details]
Screenshot from 6.0.2

Looks different, but messy.

Arch Linux 64-bit
Version: 6.0.2.1.0+
Build ID: 6.0.2-1
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Comment 7 Bartosz 2018-03-30 09:23:06 UTC 
Created attachment 140976 [details]
The issue also exists in .doc format
Comment 8 Xisco Faulí 2018-04-03 11:27:01 UTC 
We're talking about 2 different issues here:
1. The problem with 23 and 24
2. The problem with 9 to 17 which has been identified as a regression.

@Bartosz do you plan to fix both issues at once or should we have 2 different reports?
Comment 9 Bartosz 2018-04-05 20:06:01 UTC 
(In reply to Xisco Faulí from comment #8)
> We're talking about 2 different issues here:
> 1. The problem with 23 and 24
> 2. The problem with 9 to 17 which has been identified as a regression.
> 
> @Bartosz do you plan to fix both issues at once or should we have 2
> different reports?

Please split these issues into two ticket. The bibisection will be very useful to fixing second issue.
Comment 10 Xisco Faulí 2018-04-06 10:36:15 UTC 
(In reply to Bartosz from comment #9)
> (In reply to Xisco Faulí from comment #8)
> > We're talking about 2 different issues here:
> > 1. The problem with 23 and 24
> > 2. The problem with 9 to 17 which has been identified as a regression.
> > 
> > @Bartosz do you plan to fix both issues at once or should we have 2
> > different reports?
> 
> Please split these issues into two ticket. The bibisection will be very
> useful to fixing second issue.

Created here -> bug 116843
Comment 11 Xisco Faulí 2018-04-09 19:58:28 UTC 
@Regina, based on your comment https://bugs.documentfoundation.org/show_bug.cgi?id=116843#c3, should be close this one ?
Comment 12 Regina Henschel 2018-04-09 20:42:57 UTC 
No, the error with exchange of 3D and flat is not fixed.
Comment 13 QA Administrators 2019-04-14 02:50:13 UTC Comment hidden (obsolete)
Comment 14 Regina Henschel 2019-04-14 12:05:05 UTC 
The error still exists in Version: 6.3.0.0.alpha0+ (x64)
Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded
Comment 15 QA Administrators 2021-04-14 03:37:32 UTC Comment hidden (obsolete)
Comment 16 Regina Henschel 2021-04-14 09:21:13 UTC 
The 3D error still exists in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 7c6605bd2c1b27c12c4a492921e537eb4bf5a98e
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL
Comment 17 BogdanB 2021-07-31 08:20:21 UTC 
Created attachment 173986 [details]
this is how it looks in 7.3

Tested in Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 5aa74aa1e6fac571f99146ebcb6adc9feb1459ad
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-28_19:35:14
Calc: threaded
Comment 18 QA Administrators 2023-08-01 03:16:25 UTC Comment hidden (obsolete)
Comment 19 Regina Henschel 2023-08-01 13:04:17 UTC 
Some 3D borders are still wrong in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: cf8f7b91f41821b79495c0388359c4cb1156ea67
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL threaded