Re: Definition of draw:angle in ODF1.2 does not fit to implementation

Hello,

On 01/08/12 22:16, Michael Stahl wrote:
> > >   <svg:linearGradient draw:name="gradient1" svg:spreadMethod="pad" svg:x1="65.9558%" 
> > > svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%">
> > >    <svg:stop svg:offset="0.11" svg:stop-color="#dc143c"/><svg:stop svg:offset="0.473324" 
> > > svg:stop-color="#00ced1"/><svg:stop svg:offset="0.589196" svg:stop-color="#00ff00"/>
> > >   </svg:linearGradient>
> > >   <svg:linearGradient draw:name="gradient2" svg:spreadMethod="pad" svg:x1="0%" 
> > > svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%">
> > >    <svg:stop svg:offset="0" svg:stop-color="#ffffff"/><svg:stop svg:offset="1" 
> > > svg:stop-color="#00ff00"/>
> > >   </svg:linearGradient>
>
> unfortunately it seems that OOo derived suites only support the _other_
> ODF specific gradient element(s) that have this draw:angle attribute.
>
> i don't actually know anything about graphics, so i'll let Armin judge
> whether that SVG stuff in ODF 1.2 is sufficient  :)

There is a little tiny problem in there. The draw:gradient element is
more verbose then the svg:*Gradient semantics. You can express square,
elliptical, axial ... gradients that way. The down-side is that, due to
the implementation in the time of the specification, this allows only
bi-colour gradients.

SVG on the other hand is much less expressive in what the "shape" of the
gradient concerns, but it is allowing a multitude of stops with
different colours. The svg:*Gradient semantics in the ODF specification
is not exactly the corresponding to the SVG fully, but is only a subset
of the features. The specification allows also only 2 colours per
gradient. So first good thing would be to actually adopt the complete
gradient semantics from SVG. This would not be a huge burden for the
implementers I guess and would allow more complicated gradients then
what we have currently.

> > If there is a down-level concern, I would define the new element such that, when it and 
> > <draw:gradient> are both present, the new element pre-empts <draw:gradient> in ODF 1.3 and 
> > beyond.  This way, a down-level implementation will presumably process the <draw:gradient> and 
> > ignore the element introduced in ODF 1.3, since it is not defined down-level.
> >
> > Would that break the knot better?
>
> _if_ something new is needed in ODF then that would be my general
> approach as well: don't change semantics of existing markup in an
> incompatible way, but deprecate it and add new markup as necessary with
> improved semantics.
>
> the advantage is that existing products can then write both
> representations in a new version, and the deprecated markup can still be
> understood by older versions.

Also, one could be pro-active and simply refer to SVG for this stuff.
Since in SVG 2.0, there will be some more gradient types that would be
nice to support if LO drawing application wants to look like a serious
tool to the graphics folks.

Cheers

F.