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
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.
Hello Dieter, Sorry I forget this element. It's a paragraph style. If you need other information, I'm available Have a nice Sunday
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
Created attachment 159423 [details] 1226567_shadowBorder.odt: example document with a large/far shadow
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"]
(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.
*** Bug 35266 has been marked as a duplicate of this bug. ***