Re: [XaraXtreme-dev] Xara's feature

["bulia byak" <buliabyak@xxxxxxxxx>]

On 2/19/07, Alex Bligh <alex@xxxxxxxxxxx> wrote:
> You can't simulate an arbitrary mesh with a single level of transparency
> (clearly). However, many uses (including most of the photorealistic uses,
> which gradient fills simulate), can also be simulated using graduated
> transparency (and/or blends, which are really useful here).

Indeed, blends can be used to emulate almost anything photorealistic,
and for many years they were used for this purpose. At Inkscape,
however, we realized from the start that simple blur provides most of
the same capabilities in a much more natural way, and so worked to
implement it first.

> Indeed. In Xtreme a "blur" (or other live effect - it could be sharpen,
> posterize, whatever) is (essentially) something you apply on top of other
> objects, as opposed to a property each object has (a conventional
> attribute). The Xtreme mechanism is thus more general in this respect.
> You have a "live effects stack" of effects applied to given object(s).

There's no intrinsic difference here I believe. In SVG, filter effects
are also something "applied on top" of rendered bitmap. It's only that
we consciously chose in our UI to treat one of these effects, blur, as
something really basic and always-on. But of course this does not
preclude us from implementing all the other effects and a complete SVG
effects stack - which is actually richer than that of Xara because
it's not just a linear "stack" but an arbitrary "expression" of
filters where each one can work on the output of any other (and not
only its predecessor).

> That (file size) not a problem if you calculate the interpolations between
> the major divisions on the fly, like blends.

And here we come to something that can be perceived as a disadvantage
of SVG: since there are no live blends in the standard, Inkscape must
save into SVG all the intermediate shapes. So the blend will be "live"
only in Inkscape; in any other renderer it will be just a group of
shapes.

However, in my opinion, this approach actually brings more good than
bad. Now, those who wish to display SVG can do so just by implementing
the SVG standard itself and do not need to concern themselves with
complex and often ambiguous things like path blending algorithms. At
the same time, Inkscape and other SVG editors can build arbitrarily
complex editing behaviors, object types, and algorithms on top of the
"display layer" of pure SVG, thus retaining full compatibility with
all the SVG rendering software out there.

This layered architecture is, in my opinion, a much more elegant
approach than the "monolithic" formats like XAR. When a format has to
reflect all of the features of
a program, it necessarily becomes complex, difficult to implement, and
very much a "moving target" that changes along with its program.
Probably this is the main reason why exchanging vector artwork between
drawing programs has never been a trivial task. SVG holds a huge
promise here.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org