DR 16-0005: questions for MS experts

[Francis Cave]

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:

Items in DR 16-0005 that have been considered and where a resolution has 
been agreed should stay in this DR.

DR 18-AAAA: New DR concerned only with elements using @bwMode.

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!

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.

Items in DR 16-0005 not yet considered should also be reviewed and some 
distributed to additional new DRs.
>
> 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).
>
WG4 meeting: We agreed that the behavior should be specified to be 
implementation-defined. Text needs to be added to the specification.
>
> *§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?
>
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.
>
> *§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.
>
WG4 meeting: We agreed in principle to add this default value to the 
schema, subject to a final review by WG4.
>
> *§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._
>
WG4 meeting: We agreed to ask experts if this additional wording would 
be helpful. Move to new DR 18-CCCC.
>
> *§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?
>
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.
>
> *§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.
>
WG4 meeting: We agreed that more testing is needed before asking 
questions of MS experts. Move to new DR 18-BBBB.
>
> *§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.
>
WG4 meeting: We agreed that more testing is needed before we ask 
questions of MS experts. Move to new DR 18-BBBB.
>
> *§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%'.
>
WG4 meeting: We agreed that more testing needed before we ask questions 
of MS experts. Move to new DR 18-BBBB.
>
> *§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?
>
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.
>
> *§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)?
>
WG4 meeting: We agreed that this question should be forwarded to MS 
experts. Move to DR 18-CCCC.
>
> *§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?
>
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.
>
> *§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..."
>
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?]
>
> *§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.
>
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.
>
> I shall deal with the remainder of this DR in separate emails.
>
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.
>
> This is enough for immediate discussion.
>
> Francis
>

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