- Inkscape Devel - Inkscape Mailman

Problem compiling nr-filter-slot.cpp
by LucaDC 05 Sep '11

05 Sep '11

I'm getting this error when compiling under Windows XP SP3: Make error line 289: problem compiling: src/display/nr-filter-slot.cpp: In constructor 'Inkscape::Filters::FilterSlot::FilterSlot(Inkscape::DrawingItem*, Inkscape::DrawingContext*, Inkscape::DrawingContext&, const Inkscape::Filters::FilterUnits&)': src/display/nr-filter-slot.cpp:38: internal compiler error: in add_phi_arg, at tree-phinodes.c:391 Please submit a full bug report, with preprocessed source if appropriate. See <http://www.tdragon.net/recentgcc/bugs.php> for instructions. Please, can anyone tell me what to do to fix this problem? I don't know where to start from. Thanks. Luca -- View this message in context: http://old.nabble.com/Problem-compiling-nr-filter-slot.cpp-tp32379265p32379… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

6 15

Inkscape to Synfig Studio: update
by Nikita Kitaev 05 Sep '11

05 Sep '11

Hi everyone. I've been running my svg2sif converter through a semi-automated tester using a huge archive from openclipart, and now I have testing results. I fixed all of the major bugs I could find and it works correctly on a large number of SVG files. There are still cases where it fails, but almost all of them are caused by SVG files that don't originate from Inkscape. What stability should I aim for before it becomes a possibility to have it shipped with Inkscape? The kind of unsupported features I'm talking about include: viewBox attribute in <svg> tag gradients defined in the body of the document rather than in the defs section node having no id unicode<>ascii conversion error (If anyone knows I place where I can get a large number of Inkscape-only SVG files, that would help.) ~Nikita

4 4

bug in pdf export ?
by Wilfried Kirschenmann 01 Sep '11

01 Sep '11

Hi ! The following svgz file : http://dl.free.fr/hYWUU9wMI can be correctly viewed by inkscape or any web browser. However, when I try to export it as a pdf, the plots diseappears. Hence, I can't use the pdf+Latex export... I have tried Inkscape 0.48.1 on Windows 7 and Inkscape 0.48.0 on debian 6.0 This file is generated with gnuplot 4.4 pl 3. I d'ont know if this svg file is well formed (and there is a bug in inkscape) or not (and there is a bug in gnuplot). Any idea on how to export this file to pdf+Latex would be appreciated. ----- Cordialement, Wilfried Kirschenmann "An expert is a person who has made all the mistakes that can be made in a very narrow field."* *Niels Bohr - *Danish physicist (1885 - 1962)*

3 5

Circle animation in SVG
by Johan Engelen 01 Sep '11

01 Sep '11

Hi all, Some animated artwork you may like. I decided to transfer an old Pascal project into SVG. If you use Firefox: http://tostiband.nl/circles_small.svg If you use Chrome or Opera: http://tostiband.nl/circles.svg http://tostiband.nl/circles_bw.svg http://tostiband.nl/circles_rgb.svg http://tostiband.nl/circles_vertical.svg It's my first script attempt/copy-paste-fest, so probably I animate the circles in a dumb way, and that is why it is slow in Firefox. All comments are welcome of course. It is really nice to be able to hit a key to "maintain" the wave it is showing, i.e. all circles start rotating with the same speed but with the current phase difference. Then if you hit the key again, the program continues with the different circle speeds and rotates through all kinds of waves. Maybe if I feel like it, I will add this, but... it would be nifty if someone could give me some code that I could copy-paste for that :P :P Ciao, Johan

2 1

Re: [Inkscape-devel] linked offsets
by Jasper van de Gronde 31 Aug '11

31 Aug '11

On 25-08-11 21:51, Adonis Papaderos wrote: > It apears that the work I have done with linked offsets to make them > behave as linked offsets have the side-effect of breaking compatibility > with old drawings that rely on the old behavior. (see bug #817907 > https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit > 10109 should be revoked and the attached bugs marked as won't fix (since > I don't see any other way of fixing these). > > What do you think? It might be better to discuss this on the developers mailing list (instead of sending it to everyone in the inkscape developers group). As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run. Obviously going with the "new and improved" behaviour will cause some problems with existing material, but I'm afraid it's impossible to always avoid this. Now, if you want to be really friendly towards people with existing material there are a couple of possible courses of action: 1. Detect version of Inkscape that file was saved with and automatically convert linked offsets. 2. Supply an extension that can "fix" linked offsets from older versions. 3. Provide details for manual migration (what's the easiest way to get people's linked offsets to behave like they used to). 4. Make the behaviour optional (per file), possibly in combination with version detection. 5. Create a new way to achieve linked offsets so that it does not affect old linked offsets. Personally I'm not a big fan of 4 (extra code, extra complication). Option 1 is kind of nice in some cases, but in this particular setting it could prove to be a hassle if files move between people with different versions. All in all I would recommend option 2 or 3, and possibly 5, if you're feeling adventurous :) Option 5 is probably a bit more involved, but would be cool. In particular, I was thinking that it might be cool to be able to use LPEs on "clones", and a linked offset would then just be a certain kind of LPE. Currently this isn't possible as clones are not paths, so it would probably require creating a new kind of "linked path" and making sure that LPEs work with that. Then we would need to create an LPE that does an offset and make sure that the offset can be edited on canvas. With option 5 we could choose to keep the old linked offsets code around or to remove it. The latter has the advantage that existing files will still render correctly, any old-style linked offsets simply aren't editable as linked offsets anymore.

13 19

MediaWiki theme
by Krzysztof Kosiński 30 Aug '11

30 Aug '11

Can the relevant person please update MediaWiki to 1.17 and change the default theme to Vector? Our custom theme is seriously broken and makes the wiki look like a mess. Also, I am rather tired of excuses like "we are going to put all wiki content in a new awesome system Real Soon Now(tm)". This will surely take much more time than this simple update. Regards, Krzysztof

4 6

SVG on web.
by john Culleton 30 Aug '11

30 Aug '11

I came across an example of svg used as a "wireframe" or mockup of the appearance of a web page here: http://www.w3.org/Graphics/SVG/IG/wiki/images/e/ed/Planet.svg The interesting thing to me is that this svg renders the same in Inkscape and in Firefox. And it is editable in Inkscape. So it appears that svg could be added to a web page design. Given that facility, can the svg portion be used for dynamic purposes. For example could an anchor be added to point to another url? Or is svg a graphics-only format? Thoughts, anyone? -- John Culleton Wexford Press "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

4 3

The W3 state of flowPara
by Stefan de Konink 26 Aug '11

26 Aug '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, What is the actual 'state' of the flowPara discussion? Is there in fact an alternative way of representing these proposed? Or is the entire functionality removed. On the wiki it is mentioned that some new syntax is introduced, where is this described? Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk5XgG8ACgkQYH1+F2Rqwn1vAQCfW1cl1h4bdBD4aSyufVRb2Hxz 8y0AnA58jE2mxk87y/M8I4KIQT6+Qynt =plP1 -----END PGP SIGNATURE-----

1 0

Created node should snap to grid
by Johan Engelen 23 Aug '11

23 Aug '11

Hi all, Do more people agree with me that when a node is created (by ctrl+alt or double-click) that it should be snapped to the grid? If so, Diederik, can you look into this? :P Thanks so much! Johan

9 16

Re: [Inkscape-devel] inkscape to synfig studio
by Nikita Kitaev 18 Aug '11

18 Aug '11

2011/8/17 Alexandre Prokoudine <alexandre.prokoudine@...400...>: > Как и просили :) > > > ---------- Forwarded message ---------- > From: Johan Engelen <jbc.engelen@...2592...> > Date: Wed, Aug 17, 2011 at 11:34 PM > Subject: Re: [Inkscape-devel] inkscape to synfig studio > To: inkscape-devel(a)lists.sourceforge.net > > > On 14-8-2011 21:04, Alexandre Prokoudine wrote: >> Hi, >> >> FYI, for a few weeks now Nikita Kitaev has been working on an svg2sif >> extension that allows exporting SVG to Synfig Studio animation editor >> documents. >> >> https://github.com/nikitakit/svg2sif >> >> He hopes that it will eventually replace the existing SVG importer in Synfig. >> >> Discussion forum is here: http://www.synfig.org/forums/viewtopic.php?f=1&t=2953 > > (After a very brief look) > Apparently, the extension requires all shapes to be converted to paths. > Because it is implemented as a python script, an extra Inkscape > subprocess is launched to convert the non-path shapes to paths. I see > the benefit of having a Python script, but is it not easier/faster in > this case to write it in C++ in Inkscape's codebase ? > Or, alternatively, we could add an option for extensions to request > SVG's with path-shapes only...? > > (Alexandre, can you forward this to Nikita? Thanks) > > Ciao, > Johan > Hi everyone, I agree that having direct access to Inkscape's features would save some code repetition and subprocess calls. C++ is probably faster/easier if you're already very familiar with Inkscape's codebase. I'm not. Having extensions request path-only SVGs would help in this case, but hopefully it can be something more flexible. For example, svg2sif also uses Inkscape to get rid of <use> elements -- but at some point in time I plan to use Synfig's linking/clone features instead. If there's a way to request simplified SVGs, it would be nice to be able to pass options. (e.g. "No non-paths", "no clones", etc.) What about dbus extension features? I remember that there were plans and code, but I don't know what the status is. ~Nikita

4 5