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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
