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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Fwd: Re: Fwd: [office] gradient proposal

----------  Forwarded Message  ----------

Subject: Re: Fwd: [office] gradient proposal
Date: Friday 13 June 2003 22:33
From: "Rob Buis" <rwlbuis@xs4all.nl>
To: "David Faure" <faure@kde.org>


I have some small comments on this proposal.

> gradientUnits="userSpaceOnUse|objectBoundingBox": This attribute does
> not exist in the OOo XML spec, but the behavior is like
> gradientUnits="objectBoundingBox". This equals to the default value of
> SVG.

IMHO the boundingBox approach is more intuitive. I dont think the
other method is needed.

> gradientTransform="<transform-list>" : This attribute does not exist in
> the OOo XML spec. However, very simple transformations can be achieved
> by the draw:angle attribute.

This is a difficult one. Obviously this is very useful if one wants to
animate the gradient (for instance rotate it) independent of the shape itc
contained in. I dont know if the OO presentation app would like to offer
such functionality. Also it could be used I think to compensate for the
lack of userSpaceOnUse mode.

> x1, x2, y1, y2="<coordinate>": These attributes are not supported by the
> OOo XML spec. Instead of this, draw:style="linear|axial" and draw:angle
> can be used to specify the gradient direction.

This is slightly more powerful in that the color vector can be positioned
anywhere. I assume in OO currently the start and end have to be aligned to
the bounding box.

> spreadMethod="pad|reflect|repeat" : This attribute is not supported by
> the OOo XML spec, but the behavior is like spreadMethod = "pad", that is
> also the SVG default.

I think this is a very useful mechanism, and artists will want to use it.
Especially the reflect one can give visually appealing results, and though
I am not an artist, I think there are real-life situations where they are
very practical and efficient.

> <radialGradient>
> ----------------

> r="<length>: This attribute is not supported by the OOo XML spec. The
> radius is calculated based on the target objects width and height, and
> the gradient's center. The details need to be clarified. However, the
> SVG specification also seems not to specify clearly how for instance
> r="50%" is interpreted if applied to a real rectangle.

I think there is some mention of providing an extra transform when the
boundingBox is not a rectangle :

http://www.w3.org/TR/SVG11/pservers.html#RadialGradients :

When the object's bounding box is not square, the rings that are
conceptually circular within object bounding box space will render as
elliptical due to application of the non-uniform scaling transformation
from bounding box space to user space.

> fx, fy="<coordinate>": These attributes are not supported, but the
> behavior is like fx=cx and fy=cy. This equals to SVG's defaults.

This is a finetuning parameter. I am not sure if artists want this.

> Missing Features
> ================
> - All OOo XML gradients have a name. This name is required to be
> referencable from a graphics style.

Svg gradients also have a name, the id parameter.




David FAURE, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
Qtella users - stability patches at http://blackie.dk/~dfaure/qtella.html

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