I’ve made a patch for building it, but I can’t distribute it (see below):
Some issues I can find with it:
No copyright or license information.
Depends on glib, which synfig doesn’t yet use
Doesn’t build yet due to using the wrong paths to canvas.h/etc.
Code duplication; I’m not all that happy with adding a complete SVG parser to synfig; instead I think we should compile against a well-known library used by multiple projects. The only one I know is a beta one from cairographics. I guess we can deal with this later down the track though.
I’ll fix the stuff where I can but I won’t be able to distribute the changes until akagogo puts a license on it.
Hi Pabs, I don’t know if this help it.
I add 2 methods to load_canvas, so I delete glib dependencies and writing on disk
also I delete other scraps methods
I’m going to be away for a week or so, so I can’t really check out your stuff yet.
I’m not the copyright holder/author (you are) so I cannot add copyright/license information. Generally stuff in synfig is licensed under the GNU GPL v2+ - check the other source code files for how to do it.
I’ve attached a patch to enable building a mod_svg. You just need to put the files in place, rerun autoreconf and ./configure then build.
I think we could commit this soon and later when an SVG parsing library becomes available convert it to use that and directly creating canvas/bline/etc objects in memory. mod_svg.diff.txt (2.5 KB)
Here is my problem.
The output of svg importer is a xml which can be a canvas by load_canvas
Now I have a svg importer that give us a canvas but i don’t know where put it
If I put it side load_canvas, all will be easy but I should (or shall I don’t know :S) be breaking design, I suppose (In the case that there will be several inputs parsers/decoders like svg, illustrator, swf ,etc).
The natural location is a module. But the importer module is so limited, this is a layer that render a filepath.
Layer module is cool but it appears in Layer>New Layer> Group > svg_layer , I don’t know what I do.
I’m reading the synfig code every days but still I don’t resolve this thing.
Please a kindly developer who can help me
Hi.
In this patch I’m using a layer module, well it’s like a trick, but run .
I don’t like because is a trick layer, but is the only idea that I got.
There is a Import layer for import stuff, so I did other Import layer like this, a PasteCanvas or Inline Canvas with sub canvas by a parser (svg, etc)
here a preview vimeo.com/2896755 synfig-studio.patch.tar.gz (69.5 KB) synfig-core.patch.tar.gz (68.6 KB)
: D , this is so funny for me, I don’t know how to use svn, less how to make patch or diffs files. Today, I tested last patchs, so I know that they aren’t ok.
lol xD, sorry guys. svg.patch.tar.gz (357 KB)
Hi akagogo.
The zip file you provided is not useful. You have to provide the diff file from the current version that is in svn. If not how do you pretend we can apply your changes?. Maybe you’re using an old svn version and just copy your files would produce a back step on the revisions.
To produce a clean patch file:
Be sure that you have the latest svn revision downloaded.
Following the build instructions build the svn revision (it would allow be sure that you don’t obtain any compile or dependence error for the own svn and not for your code.
Modify the code you need to include the svg importer. DON’T copy files. Modify the code. Copying the files can delete a later svn revision.
Compile it following the build instructions again (this allow to be sure that anyone can compile it)
In the folder of where the source code was downloaded change to the folder of etl, synfig-core or synfig-studio (remember that they are three different svn trees) and type:
svn diff | less
to checkout that the patch looks fine. Press ‘q’ to exit ‘less’.
Type this to really produce the patch.
svn diff > patch.txt
To apply a patch you have to type:
patch -p0 < patch.txt
in the same folder where the patch was created.
NOTE: if your patch modifies any code files that has text marked as translatable, probably the corresponding .po files will be modified too (due to it keep track on where the translatable code lines are). In that case just edit the patch and delete the sections that mention the .po files.
I hope that helps you.
-G
PD: Still missing your copyright and a header of the license of the svg_parser.cpp and .h files.
libtool: compile: g++ -DHAVE_CONFIG_H -I…/…/… -I…/…/…/src -I/usr/include/libxml+±2.6 -I/usr/lib/libxml+±2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc+±2.0 -I/usr/lib/sigc+±2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/local/include -I/usr/include/sigc+±2.0 -I/usr/lib/sigc+±2.0/include -DSYNFIG_NO_DEPRECATED -DLOCALEDIR="/usr/local/share/locale" -DNDEBUG -O2 -W -Wall -MT libmod_svg_la-main.lo -MD -MP -MF .deps/libmod_svg_la-main.Tpo -c main.cpp -fPIC -DPIC -o .libs/libmod_svg_la-main.o
In file included from svg_parser.cpp:28:
svg_parser.h:151: error: multiple parameters named ‘value’
svg_parser.h:153: error: multiple parameters named ‘value’
svg_parser.cpp: In member function ‘void synfig::Svg_parser::set_id(synfig::String)’:
svg_parser.cpp:95: warning: comparison is always true due to limited range of data type
svg_parser.cpp: In member function ‘void synfig::Svg_parser::parser_layer(const xmlpp::Node*, xmlpp::Element*, synfig::String, synfig::Matrix*)’:
svg_parser.cpp:276: warning: suggest explicit braces to avoid ambiguous ‘else’
svg_parser.cpp: In member function ‘void synfig::Svg_parser::parser_polygon(const xmlpp::Node*, xmlpp::Element*, synfig::String, synfig::Matrix*)’:
svg_parser.cpp:336: warning: suggest explicit braces to avoid ambiguous ‘else’
svg_parser.cpp: In member function ‘void synfig::Svg_parser::parser_path(const xmlpp::Node*, xmlpp::Element*, synfig::String, synfig::Matrix*)’:
svg_parser.cpp:416: warning: suggest explicit braces to avoid ambiguous ‘else’
In file included from layer_svg.h:36,
from main.cpp:38:
svg_parser.h:151: error: multiple parameters named ‘value’
svg_parser.h:153: error: multiple parameters named ‘value’
In file included from layer_svg.h:36,
from layer_svg.cpp:38:
svg_parser.h:151: error: multiple parameters named ‘value’
svg_parser.h:153: error: multiple parameters named ‘value’
svg_parser.cpp: In member function ‘synfig::Color synfig::Svg_parser::adjustGamma(float, float, float, float)’:
svg_parser.cpp:1224: warning: suggest explicit braces to avoid ambiguous ‘else’
svg_parser.cpp:1230: warning: suggest explicit braces to avoid ambiguous ‘else’
svg_parser.cpp:1236: warning: suggest explicit braces to avoid ambiguous ‘else’
svg_parser.cpp: In member function ‘synfig::String synfig::Svg_parser::loadAttribute(synfig::String, synfig::String, synfig::String, synfig::String, synfig::String)’:
svg_parser.cpp:1669: warning: suggest explicit braces to avoid ambiguous ‘else’[/code]
Any idea?
Which gcc version did you used? I’m using gcc 4.3.2
-G
I see. Well I compiled it again and there aren’t problems. I have gcc 4.2 and gcc 3.3 installed, but i don’t know which is used by make. ubuntu 8.04.
you have many warnings and only 2 errors. on linux it’s sweet but on windows is worse, i think.
… I think this new patch isn’t usefull for you , because I just read the irc xD
your problem must be warning of set_id method, I supose
svg_parser.cpp: In member function ‘void synfig::Svg_parser::set_id(synfig::String)’:
svg_parser.cpp:95: warning: comparison is always true due to limited range of data type
if this is true, obviously you get segmentation fault.
but now we don’t need set_id method because, svg already isn’t a child_canvas, only is a layer :S
so you can delete this method.(I did it and my synfig hold ok )
If this doesn’t help , please try to opening your svg with inkscape then save it and test
From GCC 4.2 (or 4.3, don’t really remember right now), things get very “picky”. Lot’s of deprecated functions and lots of new warnings and errors.
In your code, you have functions with the same value parameters. For example, in the build_integer() method you have two parameters called “value” in your header file (in the source code file you have them named “name” and “value”). That’s now an error. I suggest you to compile with -Wall after compiling Synfig, just to see all your code warnings.
I haven’t had the chance to compile it yet, only have looked a bit through the source code, so maybe there are more little bugs. However, hope this helps!
thanks uiomae, you have reason
hey genete!!! I get your configuration with ubuntu 8.10 in other pc, so you also have reason
but I just fix it, please wait me a while and I’ll submit this patch
here is. the 2 files are the same, but one is different by this:
this line is required for libtool 1.5.26 but must not be present for libtool 2.2.4…
hehe I was testing this patch so I tested some svg of openclipart. all are ok
but then of a while I find to DJ Cactus http://openclipart.org/media/files/DooFi/10240
this svg is of 5.2 MB xD, i’d wanna test it so i tried and got this http://none.carlos.googlepages.com/svg5mb.png
but i can’t save this because my computer fail. (PIV 2.4GHZ + 512ram =/).
this would be like save a sifz of 60-80 MB, I guess.
i think that we must say to users that this kind of operation are dangerous.
Currently, it was 82MB uncompressed (you were very near ), 1.5MB compressed. but it ate half my memory (512Mb) and half my swap space (1.5Gb), Synfig Studio became irresponsive, etc.
If you add Inkscape support to the importer, I’m sure this will be kept in 3-6Mb AND we’ll be able to edit shapes as the original ones (stars, circles, etc), and if you add filters support (blur, etc), I think this will be complete.
Inkscape have their own set of tags, like ‘inkscape:type=“star”’ or “sodipodi:xxxx” (from the old Sodipodi code, the father of Inkscape), so if you support those tags, you could read “star” and “width:50, height 25, radius 21.5” instead of all the data in the “d” tag.
The idea is:
If the document is an Inkscape one, place higher priority on the Inkscape tags, so draw a Star layer instead of all the points in a star, ignoring “d” for that shape.
If the shape doesn’t have Inkscape type, draw “d” tag as you normally would.
In the end, if the document is a Inkscape one, you’ll have a much smaller file, and with some great capabilities, like the one I’ve already listed (editing the star shape like a star, not a bunch of points )
Take a look an Inkscape file or the reference (I think there ought to be one, maybe in their website)
I hope I’ve made myself clear . If I doesn’t, please reply and I’ll try better next time
I imagine that would require inkscape to create a library for parsing their stuff, but I don’t think they currently have an externally exposed one do they? Definitely would be good to do this, perhaps one day we can get dooglus/someone to LGM to talk about this stuff with inkscape folks.
), 1.5MB compressed. but it ate half my memory (512Mb) and half my swap space (1.5Gb), Synfig Studio became irresponsive, etc.
)
. If I doesn’t, please reply and I’ll try better next time 