Please do not mix handling of ODF with problems in OOXML import and export.

ODF is very clear, how draw:style="square" should look. Read section 19.218.2<draw:gradient>, item 'square',
"square: defines a gradient that produces a square blend, imitating the visual perspective in a corridor or the aerial view of a pyramid. Also known as "box gradient" and "pyramidal gradient". The center of the square is defined with the draw:cx and draw:cy attributes. The width and height of the square is the minimum value of either the width or the height of the filled area. The outside of the square is filled with the end color."

LibeOffice shows it correctly in most cases. Only transparent gradient in presentation mode is wrong. The names in the UI are wrong for en-US. In German the gradients in Area dialog have the correct "Quadratisch" for draw:style="square" and "Rechteckig" for draw:style="rectangle", but German is wrong in the other cases too.

I think, not the drawing is wrong, but the naming in the UI.


OOXML import and export should be an own issue, but nevertheless a comment: OOXML has only the gradient types 'linear' and 'path based'. For 'path' it has the values 'circle', 'rect' and 'shape'. So there exists no direct mapping for ODF draw:style="square". Read annex L.4.8.4.2, and section 20.1.10.38 ST_PathShadeType, and section 20.1.8.33 gradFill; all in ECMA-376, 4th Edition; Office Open XML File Formats — Fundamentals and Markup Language Reference; December 2012. The nearest mapping would be to 'rect' and calculate its corner positions based on the current shape in a way, that the gradient area is a square.

Created attachment 119249 [details]
master vs 3.3

(In reply to Regina Henschel from comment #1)
> ODF is very clear, how draw:style="square" should look. Read section
> 19.218.2<draw:gradient>, item 'square',
> "square: defines a gradient that produces a square blend, imitating the
> visual perspective in a corridor or the aerial view of a pyramid. Also known
> as "box gradient" and "pyramidal gradient". The center of the square is
> defined with the draw:cx and draw:cy attributes. The width and height of the
> square is the minimum value of either the width or the height of the filled
> area. The outside of the square is filled with the end color."

If the ODF was very clear, calligra and MSO would show it the same way as LO currently shows it. When i read this, "The width and height of the square is the minimum value of either the width or the height of the filled area.", LO doesnt seem to follow this, as it doesnt alter the minimum square to the minimum width or height, as seen in the attached screenshot. It keeps the square as large as the maximum value of either the width or height.

> OOXML import and export should be an own issue, but nevertheless a comment:
> OOXML has only the gradient types 'linear' and 'path based'. For 'path' it
> has the values 'circle', 'rect' and 'shape'. So there exists no direct
> mapping for ODF draw:style="square". Read annex L.4.8.4.2, and section
> 20.1.10.38 ST_PathShadeType, and section 20.1.8.33 gradFill; all in
> ECMA-376, 4th Edition; Office Open XML File Formats — Fundamentals and
> Markup Language Reference; December 2012. The nearest mapping would be to
> 'rect' and calculate its corner positions based on the current shape in a
> way, that the gradient area is a square.

Would be great if you could provide a link to this, so i could read more about it. Word 2010 imports both ODF draw:style="square" and draw:style="rectangular" as rectangular gradient.

Information about support of ODF 1.2 in Word, Excel and PowerPoint are available from https://msdn.microsoft.com/en-us/library/gg548604%28v=office.12%29.aspx. It is document [MS-OODF3]. (The other files might interest you too.)

ECMA-376 is available from http://www.ecma-international.org/publications/standards/Ecma-376.htm. You need part 1.

ISO/IEC 29500 is available from http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html. The ISO version is not on version 4th, but on version 3rd.


> If the ODF was very clear, calligra and MSO would show it the same way as LO
> currently shows it.

ODF 1.1 does not have such clear description, therefore applications have varied in the implementation. As LO claims to support ODF1.2, it should follow the standard.


> LO doesnt seem to follow this, as it doesnt alter the minimum square to the
> minimum width or height, as seen in the attached screenshot. It keeps the
> square as large as the maximum value of either the width or height.

You are right. LO does not render it as specified.

Tested with Version: 6.5.0.0.alpha0+ (x64)
Build ID: 800b6f095f95ccfb8a7ba9755292332bf97f97ad
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded

Problems still not solved:
1. Wrong name in the English UI. File format draw:style="square" should be named "square" in the UI, and file format draw:style="rectangular" should be named "rectangular" in the UI.
2. The gradient with file format draw:style="square" is not drawn as specified in ODF 1.2.
3. The gradient with file format draw:style="square" is drawn different in edit mode and presentation mode.

I have created an issue for the ODF TC, to add sample images to the specification. Till that is resolved, we should not change the current rendering.

There is no interoperability problem with MS Office, because MS Office does not distinguish "rectangular" and "square", which means, it is currently not able to evaluate the attribute. There is no interoperability problem with Apache OpenOffice, because it renders the same as LibreOffice.

Tested with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL

The problem has been discussed in the ODF TC, https://lists.oasis-open.org/archives/office/202112/msg00029.html

The ODF TC sees differences in all application and considers to add further attributes to allow applications to draw the gradient as they used to do.

Open question is for example, whether the area of the gradient is related to the rectangle given by the svg:width and svg:height attributes or is related to the bounding rectangle of the shape. 

The old, version 3.5, way of drawing gradient "Gradient 4" of the example document, that has in file the attribute draw:style="square", is wrong. A square is defined to have same length for width and height and that is not the case in the old way of rendering. The new way has a square, but it does not follow the specification [1], that the _minimum_ of width and height has to be used as size.

The way of drawing gradient "Gradient 5" of the example document, that has in file the attribute draw:style="rectangular", is wrong too. According specification the gradient ends in the center given by draw:cx and draw:cy. That means that the gradient ends in a _point_, but in LibreOffice it ends in a line segment.

[1] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1417216_253892949

Next step is to discuss, which kinds of gradient LibreOffice really wants and which additional attributes in file format are needed to describe the desired gradients unmistakably.