OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: draw:circle and draw:ellipse issues


The spec for draw:circle says:

  "The svg:r attribute specifies the radius of the circle. If this
   optional attribute are [sic] not set, the position and size
   attributes are used to create circle. [sic]"

Similarly, the spec for draw:ellipse says:

  "The svg:rx and svg:rx attribute specify the horizontal and vertical
   radius of the ellipse. If these optional attributes are not set, the
   position and size attributes are used to create the ellipse."

Currently x, y, width, height, cx, cy, r, rx, and ry SVG attributes
are all optional. Together this can lead to a lot of ambiguity:

- A possible reading of the quoted passages is that if the radius
  attributes are missing, the cx and cy attributes will be ignored in
  favor of the svg:x and svg:y attributes. Is this true?

- What is the size of the circle/ellipse if none of the radius, width,
  or height attributes are present? Is it an error?

- What is the position of the circle/ellipse if none of the cx, cy, x,
  or y attributes are present? Is it an error?

- If the radius of the circle is missing, but the width and the height
  attributes are different lengths, what is the actual radius of the
  circle? For example, is it w, h, max(w,h), min(w,h), avg(w,h), or an
  error?

- If the bounding box implied by the cx/cy/r attributes is different
  from that specified by x/y/width/height, which is used when filling
  the shape (e.g. gradients use % of the shape bounding box).

- etc.

It appears that OpenOffice currently ignores all of the cx/cy/r stuff
and always inscribes the ellipse/circle in the bounding box specified by
x/y/width/height. If the width and height of the circle are different,
it uses the maximum of the two.

I wouldn't be opposed to getting rid of cx/cy/r/rx/ry in the spec and
changing circle and ellipse to require width and height.

Alternatively, it would at least be much better if the spec were changed
to require either x/y/width/height or cx/cy/r, but disallow specifying
both. Not sure this syntax is right, but you get the idea:

  <choice>
      <list>
	  <attribute name="svg:x">
	      <ref name="coordinate"/>
	  </attribute>
	  <attribute name="svg:y">
	      <ref name="coordinate"/>
	  </attribute>
	  <attribute name="svg:width">
	      <ref name="length"/>
	  </attribute>
	  <attribute name="svg:height">
	      <ref name="length"/>
	  </attribute>
      </list>
      <list>
	  <attribute name="svg:cx">
	      <ref name="coordinate"/>
	  </attribute>
	  <attribute name="svg:cy">
	      <ref name="coordinate"/>
	  </attribute>
	  <attribute name="svg:r">
	      <ref name="length"/>
	  </attribute>
      </list>
  </choice>

Additionally, width and height should be required to be the same for
circles, or it should be specified how to resolve any difference.

Thanks,
Chris



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]