December 2013 - Inkscape Devel

Inkscape and SMIL support
by HadiM 02 Dec '13

02 Dec '13

Hi guys, I wonder to know if you have a mid term plan to add animation support on inkscape (with a nice GUI and all that stuff...). I you do, are you planning to use SMIL or DOM manipulation script ? I saw on your wiki some pages related to animation support but they are all old and do not seems updated. If you don't have time to work on it, could you consider launching an indigogo or kickstarter campaign to raise some funds. I am sure many people will give you money to give that support. In my opinion with HTML5 / CSS3, modern browser, video support and inkscape, animation support in inkscape is the only key missing to be able te replace PowerPoint. I except to see many software based on SVG+animation emerge in the next few years with the HTML5 explosion. It will be sad to see a new proprietary software emerging and becoming the standard in SVG animation. Best, -- HadiM

10 20

SMIL in SVG
by Tavmjong Bah 02 Dec '13

02 Dec '13

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/

4 5

Elliptical arc branch
by Tavmjong Bah 02 Dec '13

02 Dec '13

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

4 7

Re: [Inkscape-devel] SMIL in SVG
by Jelle Mulder 01 Dec '13

01 Dec '13

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. >

3 2

Recent change to ellipse to path conversion method?
by mathog 01 Dec '13

01 Dec '13

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

4 15

Bug in Blend Modes, Please Help
by Martin Owens 01 Dec '13

01 Dec '13

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

4 14