Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.