DR 16-0005: questions for MS experts

Fri Jun 8 00:34:08 CEST 2018

I have an action to propose questions to DrawingML experts at Microsoft, 
which would help us to resolve this DR. I have reviewed what MS-OI29500 
has to say about some of these attributes, and am able to propose 
resolutions in some cases. In others further testing is needed before we 
finally formulate specific questions to the experts.

*§19.3.1.4, §20.1.8.14, §20.2.2.1, §20.5.2.2, §21.3.2.2 blipFill 
(@rotWithShape) (complex type: CT_BlipFillProperties*

The example in §21.3.2.2 shows the element blipFill without 
@rotWithShape. Are we correct in deducing that, if the shape (a 
rectangle in the example) were rotated, the image filling the shape 
would also be rotated? If so, this would imply that the default value of 
@rotWithShape is 1 (true).

*§19.3.1.23, §20.1.2.2.22, §20.5.2.18, §21.3.2.14 grpSpPr (@bwMode) 
(complex type: CT_GroupShapeProperties)*

*§19.3.1.44, §20.1.2.2.35, §20.2.2.6, §20.5.2.30, §21.2.2.197, 
§21.3.2.23, §21.4.3.7 spPr (@bwMode) (complex type: CT_ShapeProperties)*

The standard specifies that the presence of the @bwMode attribute 
indicates that a shape should only be rendered in black and white: "No 
gray is to be used in rendering this image, only stark black and stark 
white" (for example, see description of attribute in §21.3.2.14). Yet 
the simple type ST_BlackWhiteMode includes many options involving gray 
and color as well as black and white.

MS-OI29500, section 2.1.1351(c), states that "Office uses this attribute 
to specify how the (group) shape should be rendered when in black and 
white mode". This all suggests the following:

- The description of the attribute in the standard is incorrect, since 
colors other than "stark black and stark white" can be specified by @bwMode.

- The default value of @bwMode for a shape is 'clr', unless specified on 
an ancestor element.

Is this interpretation consistent with Office?

*§20.1.2.2.24 ln (@algn) (complex type: CT_LineProperties)*

MS-OI29500, section 2.1.1203(a) states that Office uses a default value 
of 'ctr'. I propose that this be added to the schema.

*§20.1.2.3.33 sysClr (@lastClr) (complex type: CT_SystemColor)*

MS-OI29500, section 2.1.1233(a) states: "In Office, the lastClr 
attribute stores the RGB value of the last sysClr used". This suggests 
that Office might always specify this attribute, but this isn't 
completely certain. §20.1.10.58 states: "Applications shall use the 
lastClr attribute to determine the absolute value of the last color used 
if system colors are not supported". We cannot assume that all 
implementations specify this attribute, although we could recommend that 
new implementations do so for interoperability reasons. I therefore 
propose that the description of @lastClr be modified as follows:

    Specifies the color value that was last computed by the generating
    application. __I_t is recommended that this attribute be specified,
    to _promote interoperability with__consuming applications_ _that do
    not _support named system colors._

*§20.1.8.33 gradFill (@flip, @rotWithShape) (complex type: 
CT_GradientFillProperties)*

MS-OI29500, section 2.1.1288(a) states: "In Office the flip (Tile flip) 
attribute is ignored and flip mode xy is used". The attribute @flip is 
only relevant if the shape contains tiled areas (specified by the 
element tileRect), so clearly it should be omitted if tileRect is not 
present and no default value is implied. On this basis I propose no 
change to either the schema definition or the prose description of @flip.

NOTE: The images in the value table in §20.1.10.86 ST_TileFlipMode don't 
appear to make any sense.

The prose of the description of @rotWithShape makes no sense, since it 
relates to @flip. The diagrams relate to @rotWithShape, and seem to 
imply that a value for @rotWithShape is required. However, this is not 
consistent with what seems to be implied in the case of blipFill (see 
above). If @rotwithShape is omitted in this element, what is the 
behavior of Office?

*§20.1.8.38 headEnd, §20.1.8.57 tailEnd (@len, @type, @w) (complex type: 
CT_LineEndProperties)*

MS-OI29500 does not mention either of these elements. What are the 
default values of these three attributes? These elements don't make 
sense without there being explicit or implicit values for these attributes.

*§20.1.8.41 lin (@ang, @scaled) (complex type: CT_LinearShadeProperties)*

MS-OI29500 does not mention this element. This element doesn't make 
sense without there being explicit or implicit values for these attributes.

Tests suggest that in Office the default value of @ang is '0' and the 
default value of @scaled is '1'. Is that correct? While an 
implementation might choose different defaults to these, they are the 
most logical choices.

*§20.1.8.46 path (@path) (complex type: CT_PathShadeProperties)*

MS-OI29500 does not mention this element. The element path makes no 
sense without @path being specified, unless there is an explicit or 
implicit value for this attribute.

My impression is that the elements lin and path are poorly specified in 
the schema. They both appear in EG_ShadeProperties, which looks 
badly-written: a choice between two optional elements, each of which 
contains optional attributes. It looks as if the schema designer 
couldn't decide what to make optional, so made everything optional.

In passing, I note that the examples in §20.1.8.31 have incorrect values 
in the attributes @l, @r, @t and @b of the element fillToRect. These 
values should be of type ST_Percentage, e.g. '50%'.

*§20.1.8.47 pattFill (@prst) (complex_type: CT_PatternFillProperties)*

MS-OI29500 does not mention this element. The element pattFill makes no 
sense without @prst being specified, unless there is an explicit or 
implicit value for this attribute. None of the values in 
ST_PresetPatternVal suggests itself as a default value. Does Office 
require that this attribute be specified?

*§20.1.8.48 prstDash (@val) (complex type: CT_PresetLineDashProperties)*

MS-OI29500 does not mention this element. The element prstDash makes no 
sense without @val being specified, unless there is an explicit or 
implicit value for this attribute. Does Office require that this 
attribute be specified, or is a default value assumed ('dash', maybe)?

*§20.1.8.58 tile (@algn, @flip, @sx, @sy, @tx, @ty) (complex type: 
CT_TileInfoProperties)*

MS-OI29500 does not mention this element. The omission of any of these 
attributes makes no sense unless there are implicit or explicit default 
values. However, different implementations might choose different 
default values, e.g. 'tl' or 'ctr' for @algn. Does Office assume default 
values for these attributes?

*§21.1.2.2.2 defPPr (@defTabSz, @lvl) (complex type: 
CT_TextParagraphProperties)*

MS-OI29500, Section 2.1.1367(a) states that Office ignores the element 
defPPr.

Regarding @defTabSz, MS-OI29500, Section 2.1.1390(e) states: "Office 
uses a default value of 914400 EMUs". Other implementations might choose 
a different default value. The default value therefore appears to be 
implementation-defined.

I note a minor editorial nit in the first paragraph of 21.1.2.2.2: "If 
this attribute is omitted..." should be "If this element is omitted..."

*§21.1.2.2.3 endParaRPr (@baseline, @cap, @noProof) (complex type: 
CT_TextCharacterProperties)*

MS-OI29500, Section 2.1.1383(c) says that, if attributes are not 
specified, they "shall have their values determined by inheritance. 
Attribute values will be resolved using an applicable ancestor element 
of the same type as this element". Default values are only used if there 
is no inheritable value. There is no default value specified in the 
standard or in MS-OI29500 for @baseline.

A default value for @baseline is needed, but might vary between 
implementations. I propose that this should be specified in prose as 
implementation-defined.

MS-OI29500, Section 2.1.1383(f) states that Office uses a default value 
of '0' (false) for @noProof, which I believe is the only reasonable 
default value, so I propose that this be added to the schema.

MS-OI29500, Section 2.1.1383(g) states that Office uses a default value 
of 'none' (i.e. no capitalization) for @cap. It is unlikely that other 
implementations would choose a different default value, but might they? 
It might be safer to specify in prose that the default is implementation 
-defined.

I shall deal with the remainder of this DR in separate emails. This is 
enough for immediate discussion.

Francis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20180607/c8dc18d7/attachment-0001.html>