| Summary: | EXPORT: DOCX: DOC: border shadow color/distance not kept, and border distance value changed | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | pytolux <joachim.magnin> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED NOTABUG | ||
| Severity: | normal | CC: | dgp-mail, jluth, shumisha |
| Priority: | medium | ||
| Version: | Inherited From OOo | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=129522 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 107830, 107833, 108760 | ||
| Attachments: | 1226567_shadowBorder.odt: example document with a large/far shadow | ||
|
Description
pytolux
2019-07-26 15:36:57 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. 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. |