<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I have annotated my earlier email to
reflect the results of discussion at the WG4 meeting earlier today
(2018-06-08). Aarti suggested that it might be helpful to split
this DR into several new DRs, so as to be able to resolve easier
items more quickly. I propose the following:<br>
<br>
Items in DR 16-0005 that have been considered and where a
resolution has been agreed should stay in this DR.<br>
<p>DR 18-AAAA: New DR concerned only with elements using @bwMode.</p>
DR 18-BBBB: New DR concerned with items requiring further testing.
I will carry out further tests, but I'm happy to receive offers of
help!<br>
<br>
DR 18-CCCC: New DR concerned with items that don't require further
testing, but we need input/responses from MS experts. I will draft
questions for Aarti to forward to the appropriate experts.<br>
<br>
Items in DR 16-0005 not yet considered should also be reviewed and
some distributed to additional new DRs.<br>
</div>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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). <br>
</p>
</blockquote>
WG4 meeting: We agreed that the behavior should be specified to be
implementation-defined. Text needs to be added to the specification.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We added §19.3.1.21 to the list of elements that use
@bwMode. I will search for other uses of @bwMode that I have missed.
We notice that the full range of values in ST_BlackWhiteMode are not
valid in all uses of the attribute. We need to ask MS experts what
constraints there are on the enumerated values in different
contexts. Move to new DR 18-AAAA.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We agreed in principle to add this default value to the
schema, subject to a final review by WG4.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We agreed to ask experts if this additional wording
would be helpful. Move to new DR 18-CCCC.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We agreed that I should carry out further tests on the
omission of @rotWithShape before asking questions of experts. As
with the previous use of @rotWithShape, the default value may need
to be implementation-defined, but this should probably be checked
with MS experts. Move to new DR 18-CCCC.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<p> </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>
</blockquote>
WG4 meeting: We agreed that more testing is needed before asking
questions of MS experts. Move to new DR 18-BBBB.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<p> </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>
</blockquote>
WG4 meeting: We agreed that more testing is needed before we ask
questions of MS experts. Move to new DR 18-BBBB.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<p> </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>
</blockquote>
WG4 meeting: We agreed that more testing needed before we ask
questions of MS experts. Move to new DR 18-BBBB.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We looked at the content model for pattFill and can see
that there may be an edge case in which preset pattern is specified.
I will draft a question on this for MS experts. Move to DR 18-CCCC.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We agreed that this question should be forwarded to MS
experts. Move to DR 18-CCCC.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We noted that we have already added default="none" to
the schema definition of @flip, as a result of resolving another DR.
It looks as if defaults for other attributes might be
implementation-defined, but this needs to be checked with MS
experts. Move to DR 18-CCCC.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We agreed that we should ask MS experts to confirm what
is stated in MS-OI29500, Section 2.1.1367(a). Move to DR 18-CCCC.
[Rex, we did not discuss the minor editorial nit, so please could
you make a note of this?]<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<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>
</blockquote>
WG4 meeting: We agreed to add default values for @noProof and @cap
to the schema. We do not believe that this will break any existing
implementations.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<p>I shall deal with the remainder of this DR in separate emails.
</p>
</blockquote>
WG4 meeting: We should distribute more difficult items (requiring
testing and/or input from MS experts) to new DRs. I'll suggest a
possible distribution.<br>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<p> This is enough for immediate discussion.</p>
</blockquote>
<blockquote type="cite"
cite="mid:2b00cef3-cc7a-1ea7-1389-a1432a155b2e@franciscave.com">
<p>Francis<br>
</p>
</blockquote>
<p><br>
</p>
</body>
</html>