Download it now!
Bug 126567 - EXPORT: DOCX: DOC: border shadow color/distance not kept, and border distance value changed
Summary: EXPORT: DOCX: DOC: border shadow color/distance not kept, and border distance...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 35266 (view as bug list)
Depends on:
Blocks: DOCX-Paragraph Writer-Styles-Paragraph DOCX-Styles
  Show dependency treegraph
 
Reported: 2019-07-26 15:36 UTC by pytolux
Modified: 2020-04-24 07:04 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
1226567_shadowBorder.odt: example document with a large/far shadow (10.22 KB, application/vnd.oasis.opendocument.text)
2020-04-08 10:40 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pytolux 2019-07-26 15:36:57 UTC
Description:
Under WRITER.

When I create a style into a .docx file the configuration of style doesn't save correctly

Expl :
I create a style with this configuration :

Background : grey
Border : black / 0,80 pt
Shadow of border : grey 3 / 0,20 cm

After I save the file and close it, I open it a new time.

But the style configuration have change :
Background : grey
Border : black / **0,75 pt**
Shadow of border : **black** / **0,05 cm**

I don't have this problem with .ODT file.


Environnement test :
Ubuntu 18.04
2 version of libre office
- 6.0.??? (i forget sorry)
- 6.2.5.2




Steps to Reproduce:
1.With a .docx file, Create a style with shadow of border and specific configuration (color/blod of shadow)
2.Save and close the file
3.Open the File 

Actual Results:
The style configuration is change

Expected Results:
The style configuration doen't change between the close and the opened .docx file


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 6.2.5.2
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
Threads CPU : 4; OS : Linux 4.18; UI Render : par défaut; VCL: gtk3; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded


Sorry for my bad english
Comment 1 Dieter 2019-07-28 04:29:48 UTC
Thank you for reporting the bug. It i not clear to me, if it is a paragraph style or a page style. Could you please specify?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information is provided.
Comment 2 pytolux 2019-07-28 12:13:26 UTC
Hello Dieter,

Sorry I forget this element.

It's a paragraph style.

If you need other information, I'm available 

Have a nice Sunday
Comment 3 Dieter 2019-07-28 18:11:10 UTC
I confirm it with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 8f98a7c4e5b1f0b249c026577805a378b8a533d5
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-23_00:30:19
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

The only difference I have is 0,10 cm shadow of border
Comment 4 Justin L 2020-04-08 10:40:17 UTC
Created attachment 159423 [details]
1226567_shadowBorder.odt: example document with a large/far shadow
Comment 5 Justin L 2020-04-08 10:56:02 UTC
I'm not too worried about a 0.80 changing into a 0.75. That can easily be due to rounding when converting back and forth from twips or whatever.

From everything that I can see, MS Word basically does not support any kind of 
shadow configuration. It is an on/off option.  Therefore anything like colour or distance simply cannot be specified when saving into a Microsoft format.

I can be convinced otherwise if you can provide a Word-authored document where these features are not round-tripped by LibreOffice. (for example, it sounds like a red border ought to create a red shadow, and perhaps a very thick border creates a very big shadow....)

shadow (Border Shadow)
Specifies whether this border should be modified to create the appearance of a shadow. For the right and bottom borders, this is accomplished by duplicating the border below and right of the normal border location. For the right and top borders, this is accomplished by moving the border down and to the right of its original location.
If this attribute is omitted, then the border is not given the shadow effect.
[Example: Consider a top border which must appear with a shadow effect, resulting in the following WordprocessingML:
<w:bottom w:shadow="true" ... />
This frame's val is true, indicating that the shadow effect must be applied to the border.

The possible values for this attribute are defined by the ST_OnOff simple type (§22.9.2.7).

[yes, Microsoft's documentation specifies the bottom border when "considering a top border"]
Comment 6 Mike Kaganski 2020-04-08 11:12:05 UTC
(In reply to Justin L from comment #5)
> I'm not too worried about a 0.80 changing into a 0.75. That can easily be
> due to rounding when converting back and forth from twips or whatever.

Actually it's because in OOXML, the border size is measured in 1/8th of a point. Citing description of "sz" attribute of CT_Border (ECMA-376 Part 1 sect. 17.3.4):

> If the border style (val attribute) specifies a line border, the width of this border is
> specified in measurements of eighths of a point, with a minimum value of two (onefourth
> of a point) and a maximum value of 96 (twelve points). Any values outside this
> range can be reassigned to a more appropriate value.

The type of the attribute is ST_EighthPointMeasure, which is an unsigned integer.

So a value of 0.80 pt is rightfully brought to the closest multiple of 1/8th of a point (sz=6, i.e. 0.75 pt). The other possible value (sz=7) is 0.875 pt, which is less accurate.
Comment 7 Justin L 2020-04-24 07:04:07 UTC
*** Bug 35266 has been marked as a duplicate of this bug. ***