interpretation of rotate= attribute

In both 1.1 and 1.2 Mobile draft, the rotate= attribute on text
elements is described thus:

----------
      The supplemental rotation about the alignment-point that will be
applied to all of the glyphs corresponding to each character within
this element.
      If a comma- or space-separated list of <number>s is provided,
then the first <number> represents the supplemental rotation for the
glyphs corresponding to the first character within this element or any
of its descendants, the second <number> represents the supplemental
rotation for the glyphs that correspond to the second character, and
so on.
----------

Here, the first paragraph seems to apply to the case when rotate= has
a single number, and seems to specify that in this case, _all_
characters in an element are rotated by that angle.

But this is hard to reconcile with the second paragraph. Indeed if a
single value is considered a list of length one, then it naturally
must apply only to the first character, not to all characters. So if
we follow the spec literally, then in

<text rotate="30">ABC</a>

C is rotated, whereas in 

<text rotate="30 30">ABC</a>

it's not. This is terribly inconsistent. It becomes even worse if you
consider the "if not specified for this char, inherit from ancestors"
provision.

As a result of this confusing requirement, there's already a
discrepancy among implementations: Batik renders all letters rotated
when rotate= has a single value, whereas the Adobe SVG plugin rotates
only the first one. I think Adobe's interpretation makes a lot more
sense, but it seems to be contradicted by the spec.

Could you please make sure this is sufficiently clarified in the 1.2 draft?

Received on Monday, 18 April 2005 21:20:45 UTC