SMIL in SVG
by Tavmjong Bah
Hi,
The Inkscape and SMIL thread is getting pretty long so I am starting a
new thread on if SMIL is the right solution for animation in Inkscape.
I personally think SMIL is quite useful, but you should be aware that
Microsoft has been quite forthright that they will not support SMIL in
Internet Explorer. They don't want to support a second declarative
animation model, the first being CSS Animations[1]. CSS Animations does
have some problems, namely at the moment you can only animate style
properties (things that you can set using the 'style' attribute). You
cannot animate attributes (such as rectangle 'width'). This is suppose
to be resolved at some point.
Having said that, the other browsers do support SMIL and SMIL is not at
risk of being dropped from SVG 2 (as was SVG fonts last week).
(Although, I know of at least one Chrome developer who might be happy to
see SMIL go.) If there is enough demand from designers for SMIL,
Microsoft has been known to change its mind (they weren't going to
implement SVG filters at first). But this is someone of a chicken and
egg problem. There is the "FakeSmile" JavaScript library that can be
used with IE so lacking native support in IE may not be that big of a
deal.[2]
There is precedence for Inkscape to lead the way. I've had one person
who has been around SVG for a long time tell me that without Inkscape
SVG would not now be part of HTML5.
BTW, I have a page where I created the same animation using SMIL, CSS
Animations, and JavaScript.[3] Note that browser support for declarative
animation, either via SMIL or CSS Animations is full of little quirks so
the tests may or may not work correctly depending on which version of
which browser you use.
Tav
[1] http://www.w3.org/TR/css3-animations/
[2] http://leunen.me/fakesmile/
[3] http://tavmjong.free.fr/SVG/ANIMATION/
9 years, 2 months
Elliptical arc branch
by Tavmjong Bah
Hi,
The current Inkscape code converts an elliptical arc to a Bezier curve
via converting it first to an SBasic curve. This leads to some loss of
accuracy to the curve (noticeable now that we are using SVG <circle> and
<ellipse> elements where possible) and control over where the resulting
nodes will be placed. lib2geom has been patched (r2122) to fix the
accuracy problem. Is there a reason this patch hasn't been applied to
the copy of lib2geom in Inkscape? (If no, I can apply the patch.)
Even with this patch, it might be better to provide a direct route to go
from an elliptical arc to a Bezier curve bypassing the SBasic step to
have better control over where nodes are placed. I have made a first
pass at providing a direct route. At the moment, one Bezier curve is
created if the arc is less than pi/2 in length. If it is longer, extra
nodes are placed on the major and minor ellipse axes. Can the lib2geom
experts have a look? I am sure I have not done things in a lib2geom
sanctioned way. The branch is available at:
lp:~inkscape.dev/inkscape/elliptical_arc
I've attached a test file where the red ellipses/arcs are drawn using an
"ideal" conversion to Bezier curves (with four per circle/ellipse) and
the blue curves are test arcs. (The Cairo routines convert the arcs to
Beziers for display as Cairo/PostScript/PDF do not have a native
elliptical arc path segment so just rendering arcs on screen tests the
code.)
One obvious bug is that the flash path when using the node tool is
wrong.
Thanks,
Tav
9 years, 2 months
Re: [Inkscape-devel] SMIL in SVG
by Jelle Mulder
Hello all,
I for one applaud this incentive. It's a long standing desire of the whole
SVG community to have Inkscape support animation I think.
I did a web design course in 2012 in which I made my design students
create a website in SVG using Inkscape, notepad++ and Opera 11. One of the
assignments was to add animation using SMIL and I made this simple example
of how to create a repeating frame based animation. It works in Opera 9.5
- 12.16, but not in their Blink versions. Firefox works fine as well.
Blink has a nasty bug/regression/security issue? that prevents external
files to be <use>d.
http://pjmulder.home.xs4all.nl/svg/exanples/frame_anim/anim.svg
Based upon my experience teaching I would like to address the following
points.
1. One of the things it does which is currently not supported by Inkscape
is to use external SVG files. I would really be a great addition to the
functionality of Inkscape if it did. The new Symbol manager already opens
external files but then copies content from these file rather than linking
them. I'd love to see that as an option to link externally, much like we
do with bitmap images. It would make files a wee bit cleaner. There also
would need to be an option to collect all linked files into a single
whopper for portability. More difficult it would be but quite interesting,
to be able to disassemble files into multiple ones again.
2. SMIL is a really easily understandable format for all. ECMAscript is
unintelligible for the non coder, but I managed to teach each and every
student how to move objects around using SMIL. CSS is a work in progress
and to be honest I think it is an ugly way of doing anything really. It
always feels like engineering your graphics, much like Postscript editing
before the invention of Pagemaker, but then without knowing the context of
your objects. CSS is too abstract for most people.
3. If however the SMIL code is just plunked into the overall SVG graphics
file, the readability becomes zero. I therefore made them separate the
SMIL logic from the graphic content. This has two advantages, they could
easily edit the graphics content of their animation, reposition objects in
their scene files and all that without influencing the logic code. SMIL
also allows for editing the content at two levels. You can either edit the
resource file or the <use>
4. Based upon this I would suggest for animation there to be a project
file structure rather than single files. It would be useful for normal
Inkscape projects too as you often want to separate images from your files
rather than have them bloat the whole file and want to be able to use
placeholders and replaceable content.
Regards,
Jelle Mulder
On Sun, 01 Dec 2013 06:24:30 +0800,
<inkscape-devel-request(a)lists.sourceforge.net> wrote:
> Send Inkscape-devel mailing list submissions to
> inkscape-devel(a)lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> or, via email, send a message with subject or body 'help' to
> inkscape-devel-request(a)lists.sourceforge.net
>
> You can reach the person managing the list at
> inkscape-devel-owner(a)lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Inkscape-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: SMIL in SVG (Susan Spencer)
> 2. Re: Inkscape and SMIL support (Susan Spencer)
> 3. Re: SMIL in SVG (Martin Owens)
> 4. Re: Inkscape and SMIL support (Martin Owens)
> 5. Re: Inkscape and SMIL support (Susan Spencer)
> 6. Re: Inkscape and SMIL support (Susan Spencer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 30 Nov 2013 15:28:15 -0600
> From: Susan Spencer <susan.spencer@...400...>
> Subject: Re: [Inkscape-devel] SMIL in SVG
> To: Tavmjong Bah <tavmjong@...8...>
> Cc: "inkscape-devel(a)lists.sourceforge.net"
> <inkscape-devel(a)lists.sourceforge.net>
> Message-ID:
> <CAFi3o2UOgK+AJFTm2g_DWhyK_m9ONQZmhtXb34STWegoTV+j_g@...401...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Should IE's lack of support prevent Inkscape from incorporating SMIL?
>
> There should be some consensus on this.
>
9 years, 2 months
Recent change to ellipse to path conversion method?
by mathog
Earlier today I found one small bug related to images written to WMF
files and posted it in launchpad. But while working on that noticed
that there was also another binary change in the output that didn't
correspond to anything I could see in the images. A careful byte by
byte comparison of EMF and WMF output from the lp988601 and current
trunk branches showed that outside of my code there has been a change,
where the paths returned on ellipse to path conversions are not as they
once were. In emf-print.cpp in the print_simple_shape() routine a print
statement was added after the call to
pathv_to_linear_and_cubic_beziers() and the loop which adds up nodes,
lines, and curves. For the exact same ellipse (long axis aligned with
x, short with y, axis ratio about 2:1) this is what was found:
nodes lines curves
lp988601 5 0 4
trunk 9 0 8
They start at the same point, but differ from there. Tried it again
with perfect circles and got the same result.
The strange thing is that there is no change at all to the geom.cpp
file, where pathv_to_linear_and_cubic_beziers() is coded.
I also checked to see if anything similar could be seen in the GUI, and
it sort of could be. Select the ellipse, select "stroke to path", then
edit points. The points on the ellipse are in different places in the
two branches, and there are different numbers of points. For lp988602
there is one point on the end of each axis plus one point in roughly the
center of each quadrant. For trunk there are the same points on the ends
of the axis, plus two points within each quadrant, and these are
clustered towards the "sharp" ends of the ellipse.
Is this change intentional???
Thank you,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 2 months
Bug in Blend Modes, Please Help
by Martin Owens
Hey Devs,
Blocking bug lp:850992 [1] is proving impossible to get a handle on for
different devs who are not familiar with the blend code base and it's
resisting attempts to let us learn about it.
We could do with a heavy-hitting genius who hopefully knows something
about the blend modes for layers to figure this out. I'm betting it's a
single line fix when the little worm is rooted out.
To reproduce: Make a new layer with a blend mode other than normal.
Group any objects together.
Grouping fails to refresh, ungrouping works as expected. The area isn't
being cleared by the redraw method like the text bug (I checked), the
redraw is simply failing to happen at all. Tracing the update events is
what's causing some headaches since both upstream and downstream tracing
just seems to vanish.
Thanks for your help.
Best Regards, Martin Owens
[1] https://bugs.launchpad.net/inkscape/+bug/850992
9 years, 2 months
