RE: DR 17-0022 — DML: wMode and yMode are unclear

[Francis Cave]

I've been playing around with charts in Excel and in Word. The use of element <c:manualLayout> is slowly emerging from the fog, and with it, the use of <c:x> etc. 

Maybe the DrawingML team thought that, by trying to answer our questions, they would be opening up a can of worms...! Actually, I'm not convinced it's that bad.

A chart typically contains several "chart elements", such as Chart Title (<c:title>), Plot Area (<c:plotArea>) and Legend (<c:legend>). Each of these contains a <c:layout> element. If the user doesn't adjust the layout of the chart elements within the chart, the element <c:layout/> is empty. However, if the user manually adjusts the size or position of a chart element, the <c:layout> element contains <c:manualLayout>, and this contains manual positioning and sizing information. Note that the content model of <c:layout> (complex type CT_Layout) allows for <c:extLst> inside <c:layout>, which I presume is to allow for future extensions to the chart layout mechanism.

There are four DML elements that specify the position and dimensions of a chart element, as specified in the content model of <c:manualLayout> (complex type CT_ManualLayout). The element <c:layoutTarget> contains a choice of values "inner" or "outer", which only apply to certain types of chart element. I haven't investigated the use of <c:layoutTarget>, as it's not immediately relevant to this DR.

In investigating this, I have looked at the example in 29500:2016 Part 1, §L.4.13.3, page 4914-4916. This example contains. additional child elements of <c:layout>: <c:lastLayoutOuter> and <c:lastLayout>, neither of which is specified either in Part 1 or in Part 4! Maybe these were replace by <c:layoutTarget> at a late stage in the drafting of §21.2? Or maybe they ran out of time and put in <c:extLst> in the schema and normative prose instead.

Back to chart elements. When the layout of a chart element is adjusted manually, the position and dimensions are specified in terms of height (<c:h>), width (<c:w>), horizontal position (<c:x>) and vertical position (<c:y>). How the values of these elements is interpreted and the range of allowable values are specified by the corresponding "mode" elements: <c:hMode>, <c:wMode>, <c:xMode> and <c:yMode>. The standard specifies that the values of each of these elements can be either "factor" or "edge", and also allows these values to be specified independently of one another in a chart instance. But in practice, Office will only store one value for each of these four model elements:

- <c:hMode> will always contain "factor" on storage, indicating that the value of <c:h> is the factor to be multiplied by the overall height of the chart (i.e. the vertical dimension of the chart area) to obtain the height of the chart element.
- <c:wMode> will always contain "factor" on storage, indicating that the value of <c:w> is the factor to be multiplied by the overall width of the chart (i.e. the horizontal dimension of the chart area) to obtain the width of the chart element.
- <c:xMode> will always contain "edge" on storage, indicating that the value of <c:x> is the factor to be multiplied by the overall width of the chart (i.e. the horizontal dimension of the chart area) to obtain the offset of the LEFT-hand edge of the chart element from the LEFT-hand edge of the chart.
- <c:yMode> will always contain "edge" on storage, indicating that the value of <c:y> is the factor to be multiplied by the overall height of the chart (i.e. the vertical dimension of the chart area) to obtain the offset of the TOP edge of the chart element from the TOP edge of the chart.

Bizarrely, the standard specifies what is meant by "factor" in the case of both <c:x> and <c:y>, despite the fact that Office doesn't store the value "factor" in these cases, and doesn't specify what is meant by "edge", even though this is the only value stored by Office applications!

Office expects "edge" values to be between 0 and 1 and will ignore values outside this range and will give the chart element its default size and position. This makes sense, given the above interpretation, although it could be argued that it is a bit restrictive: it means that chart elements cannot be placed outside the chart area. But since the same effect could be achieved by enlarging the chart area and adjusting the size and position of chart elements, I suppose it can be argued that it is not too burdensome a restriction.

Office will apparently read charts that contain the values that they don't store. I have not tested this, but I interpret the standard and implementer notes as follows:

- If <c:xMode> (or <c:yMode>) contains "factor", this indicates that <c:x> (or <c:y>) specifies a value relative to the "default" position of the chart element. The default position is presumably implementation-specific. According to the implementer notes in MS-OI29500, 2.1.1566 and 2.1.1568 on page 567, the value must be between -1 and +1, which I take to mean that the value is interpreted as a proportion of the default horizontal (or vertical) offset of the chart element from the left-hand (or top) edge of the chart area, a negative value indicating to the left of (or above) and a positive value being to the right of (or below) the default position.
- If <c:hMode> (or <c:wMode>) contains "edge", this indicates that <c:h> (or <c:w>) specifies the position of the RIGHT-hand (or BOTTOM) edge of the chart element. According to the implementer notes in MS-OI29500 2.1.1468 on page 545 and 2.1.1564 on page 566, the value must be between 0 and 1, which I take to mean that the value is interpreted as a proportion of the height (or width) of the chart area.

We should discuss this, but we might be in a position to draft some new text after all.

I attach a couple of test documents containing manual layout of chart elements.

Francis



-----Original Message-----
From: Charlie Clark [mailto:charlie.clark at clark-consulting.eu] 
Sent: 01 March 2018 19:00
To: SC 34 WG4 <e-SC34-WG4 at ecma-international.org>
Subject: Re: DR 17-0022 — DML: wMode and yMode are unclear

Am .03.2018, 17:41 Uhr, schrieb MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

> But I do not think that these changes make Charlie happy.  I am afraid 
> that I do not understand either.

No, because there is no explanation of the different modes and implied mutual exclusivity of the different modes. It should be fairly straightforward for someone who already knows but it really is incomprehensible otherwise.

Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chart test.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 25565 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20180301/d1ecdedb/attachment-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chart test.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 13899 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20180301/d1ecdedb/attachment-0001.xlsx>