Re: DR 14-0010 — SML: Attribute textRotation

[MURATA Makoto]

Re: Issue 1/2  Ideally, every condition in prose should be captured by
schemas.
Here is my prposal.

Replace

    <xsd:attribute name="textRotation" type="xsd:unsignedInt"
use="optional"/>

in sml.xsd by

    <xsd:attribute name="textRotation" type="ST_TextRotation"
use="optional"/>

and add

  <xsd:simpleType name="ST_TextRotation">
    <xsd:restriction base="xsd:unsignedInt">
      <xsd:minInclusive value="0"/>
      <xsd:maxExclusive value="360"/>
    </xsd:restriction>
  <simpleType>

Replace

  attribute textRotation { xsd:unsignedInt }?,

in sml.rnc by

  attribute textRotation { sml_ST_TextRotation }?,

and add

sml_ST_TextRotation =
  xsd:unsignedInt { minInclusive = "0" maxExclusive = "360" }

Regards,
Makoto



2015-01-14 9:26 GMT+09:00 Chris Rae <Chris.Rae at microsoft.com>:

> DR is here:
> https://onedrive.live.com/view.aspx/Public%20Documents/2014/DR-14-0010.docx?cid=C8BA0861DC5E4ADC
>
> I've done a bit of investigation into this DR and it seems to definitely
> represent an omission either from the standard or from Microsoft's
> implementer notes. The DR mentions several things:
>
> 1. the actual schema has unsignedInt while the description clearly imposes
> limits;
> 2. an unsignedInt is clearly not restrictive enough in this respect (0 < x
> 359 should be sufficient);
> 3. the value of 255 seems to be specifying different, undefined behaviour
> (ideally this should probably be controlled by a separate attribute). Excel
> at least seems to treat values > 180 as negative.
>
> Issue 1/2: I don't feel strongly on this, although we do have many others
> cases where ranges are specified in prose rather than schema. Rather than
> open that can of worms, I propose not adding this limit to schema.
>
> Issue 3: I've tested this in Microsoft Office, LibreOffice, Open Office
> and Google Docs. Google Docs appears not to support text rotation at all,
> but the other three applications do indeed all treat the value 255 as
> special, and meaning text written downwards. I therefore propose the
> attached changes to the standard to address this.
>
> On Excel's treatment of values >180, it does appear to be slightly odd but
> I don't think this is deliberate and there's no way to recreate it in the
> user interface. As the standard doesn't dictate what to do with invalid
> files, I don't think we need to document this case (and, if we do, I think
> it should be in Excel's implementer notes).
>
> Chris
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150207/7b62ba32/attachment.html>