<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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.<br>
</p>
<p><b>§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</b></p>
<p>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). </p>
<p><b>§19.3.1.23, §20.1.2.2.22, §20.5.2.18, §21.3.2.14 grpSpPr
(@bwMode) (complex type: CT_GroupShapeProperties)</b></p>
<p><b>§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)</b></p>
<p>
</p>
<p>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. <br>
</p>
<p>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:</p>
<p>- The description of the attribute in the standard is incorrect,
since colors other than "stark black and stark white" can be
specified by @bwMode.</p>
<p>- The default value of @bwMode for a shape is 'clr', unless
specified on an ancestor element.</p>
<p>Is this interpretation consistent with Office?</p>
<p><b>§20.1.2.2.24 ln (@algn) (complex type: CT_LineProperties)</b></p>
<p>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.</p>
<p><b>§20.1.2.3.33 sysClr (@lastClr) (complex type: CT_SystemColor)</b></p>
<p>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:</p>
<blockquote>
<p>Specifies the color value that was last computed by the
generating application. <u><font color="#6666cc"><u>I</u>t is
recommended that this attribute be specified, to <u>promote
interoperability with</u><u> consuming applications</u> <u>that
do not </u>support named system colors.</font></u></p>
</blockquote>
<p><b>§20.1.8.33 gradFill (@flip, @rotWithShape) (complex type:
CT_GradientFillProperties)</b></p>
<p>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.</p>
<p>NOTE: The images in the value table in §20.1.10.86
ST_TileFlipMode don't appear to make any sense.</p>
<p>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? <br>
</p>
<p><b>§20.1.8.38 headEnd, §20.1.8.57 tailEnd (@len, @type, @w)
(complex type: CT_LineEndProperties)</b></p>
<p>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.<br>
</p>
<p><b>§20.1.8.41 lin (@ang, @scaled) (complex type:
CT_LinearShadeProperties)</b></p>
<p>MS-OI29500 does not mention this element. This element doesn't
make sense without there being explicit or implicit values for
these attributes.</p>
<p>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.<br>
</p>
<p><b>§20.1.8.46 path (@path) (complex type: CT_PathShadeProperties)</b></p>
<p>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.</p>
<p>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.</p>
<p>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%'.</p>
<p><b>§20.1.8.47 pattFill (@prst) (complex_type:
CT_PatternFillProperties)</b></p>
<p>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?</p>
<p><b>§20.1.8.48 prstDash (@val) (complex type:
CT_PresetLineDashProperties)</b></p>
<p>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)?</p>
<p><b>§20.1.8.58 tile (@algn, @flip, @sx, @sy, @tx, @ty) (complex
type: CT_TileInfoProperties)</b></p>
<p>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?</p>
<p><b>§21.1.2.2.2 defPPr (@defTabSz, @lvl) (complex type:
CT_TextParagraphProperties)</b></p>
MS-OI29500, Section 2.1.1367(a) states that Office ignores the
element defPPr.<br>
<p>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.</p>
<p>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..."</p>
<p><b>§21.1.2.2.3 endParaRPr (@baseline, @cap, @noProof) (complex
type: CT_TextCharacterProperties)</b></p>
<p>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. <br>
</p>
<p>A default value for @baseline is needed, but might vary between
implementations. I propose that this should be specified in prose
as implementation-defined.<br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>I shall deal with the remainder of this DR in separate emails.
This is enough for immediate discussion.</p>
<p>Francis<br>
</p>
</body>
</html>