Inkscape Wiki - User contributions [en]

Save Cleaned SVG

2009-07-21T03:54:38Z

Jeff schiller: /* Reference Work */

= Create Cleaned SVG =

Please fix this wiki page if it doesn't fit the standard blueprint template.

== Rationale ==

We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.

== Technologies ==

* Python
* python-xml
* inkscape plugin svg/python module

== Presented Options ==

The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.

== Cleaning Operations ==

* Specify a limit to the precision of all positional elements.
* Clean up XML Elements
* Collapse multiple redundent groups
* Remove empty tags, such as defs or metadata.
* Remove id tags for elements not referenced
* Clean up Definitions
* Remove unused definitions
* Remove duplicate gradient stops
* Collapse duplicate gradient definitions
* Remove gradients that are only referenced by one other gradient
* Clean up CSS
* Remove Default values, i.e. opacity: 1;
* Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;
* Convert RGB colours from RGB(r,g,b) to #RRGGBB format
* Convert RGB colours from #RRGGBB to #RGB if possible
* Clean up paths
* Detect vertical/horizontal lines and replace.
* Eliminate empty path segments
* Eliminate last segment in a polygon
* Collapse straight curves.
* Convert absolute path segments to relative ones.
* Process Transformations
* Process quadratic Bezier curves
* Collapse all group based transformations
* Convert known properties to element attributes
* css to element attributes
* Output Standard SVG
* Remove inkscape namespace
* Remove sodipodi namespace
* Remove adobe namespace
* Use viewPort instead of document width/height

== Tests ==

Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.

== Reference Work ==

This script has been created in Ruby where some of the ideas have been pulled:

http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy

NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.

http://codedread.com/scour/

Working with SVN

2007-03-24T21:59:51Z

Jeff schiller: Added docbook URL

(This began a copy of [[WorkingWithCVS]]; bear with us as it is updated for SVN)

== Subversion (SVN) Basics ==

This node discusses the basics of using SVN.

For information on more advanced usage, see:

* [[WorkingWithSVNBranches]] - making branches and merging between them

=== Concepts ===

==== The Repository ====

SVN stores source code in a shared '''repository''' (in our case on Sourceforge's server). The repository contains all past and present versions of the code, and is shared by everyone.

==== Your Working Copy ====

To work with the source code, SVN requires you to '''check out''' a ''working copy''. This copy is private, so you can make and test any changes you like without disturbing anyone else.

If you have '''write access''' to the repository, when you are finished making your changes, you may '''commit''' your changes to the shared repository, making them available to everyone.

Alternately, you may generate a file containing the changes you made (a ''diff''), and send it to a developer with write access to be incorporated.

You can check out as many working copies as you want; they take up only your own disk space, and they are completely independent of each other.

If you no longer need a working copy, you may simply delete it.

=== Getting Started ===

==== Setting Up ====

==== How Do I Check Out a Working Copy? ====

To check out a copy of Inkscape from the SVN repository, you may use the following command:

svn checkout https://svn.sourceforge.net/svnroot/inkscape/inkscape/trunk inkscape

Here are what the options mean:

"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).

"https://svn.sourceforge.net/svnroot/inkscape/inkscape/trunk" is a repository URL; in this case, it refers to the "main" development branch for Inkscape. Other repository URLs are:

* http://inkscape.svn.sourceforge.net/svnroot/inkscape/doc-docbook/trunk - contains the docbook source of the Inkscape tutorials

"inkscape" is the name of the directory to check out into

==== Now What? ====

You should have a complete working copy in the '''inkscape''' directory. You can cd to it and try compiling.

:Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile

When you're inside the working copy, you won't normally need to specify the repository URL, because SVN remembers where the working copy came from.

Note that a Subversion command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.

=== Bringing Your Working Copy Up-To-Date ===

Your working copy will not automatically include changes others have made to the repository since you checked it out.

To ''update'' your working copy, use this command:

svn update

=== Dealing with Conflicts ===

If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?

Normally, SVN can work this out on its own. Sometimes you have to help it along, though. If SVN says there were conflicts, look for which files have a ''C'' next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.

<<<<<<< ''filename''
The changes in your version will be here
=======
The changes by the other person will be here
>>>>>>> ''some version here''

Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that SVN is no substitute for communication.

Also, always make sure to build and test after an update to make sure that the combined changes work as intended!

=== Generating a Diff ===

('''Always''' update before generating a diff!)

From the top-level directory, run the command:

svn diff -x -u3 > filename

-x -u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.

This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.

=== Automatic Commit Diff ===

[ fixme: how to do this in SVN?
SVN_EDITOR instead of CVSEDITOR
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.confarea.opts.config ]

To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:

#!/bin/bash
# get rid of redhat 9 locale ugliness
unset LC_CTYPE
# Turn on ro access (to stop multiple locks) for local roots
grep @ CVS/Root >/dev/null 2>&1 || export CVSREADONLYFS=1
# Tell the user what's going on
echo Building diff...
cvs diff -up 2>/dev/null | perl -ne 'print "CVS: $_" unless /^\?/' >> "$1"
exec ${EDITOR:-vi} "$1"

If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:

export CVSEDITOR=~/bin/cvsdiffvi

Now, every time you commit, the entire diff will be visible to you as you write your commit comments.

=== Applying a Diff ===

A diff file can be applied to the codebase using the 'patch' command.

If the diff was made as <code>inkscape/src/thingy.cpp</code> and you're in the "inkscape" directory, you'll want to use the command:

patch -p1 < thingy.diff

Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.

=== Committing your Changes ===

('''Always''' update before committing!)

If you have write access to the repository, you can commit your changes like this:

Before you commit, please make sure that you describe the changes you have made in the [[ChangeLog]] file at the top-level directory.

svn commit -m "Your description of your changes goes here"

Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the [[ChangeLog]], since it will remind you of all the changes you've made.

=== Adding Files to the Repository ===

To add new files as part of your commit, you will need to run:

svn add ''files and directories to add go here''

Before you commit. This also goes for new directories.

The actual addition or removal will not take effect until you commit.

=== Removing Files from the Repository ===

svn remove ''files to remove go here''

[[Category:Developer Documentation]]

CompilingSuse

2007-03-20T01:45:35Z

Jeff schiller: /* OpenSUSE 10.2 */ popt-devel

== OpenSUSE 10.2 ==

You need to install these packages to pass the compilation of SVN trunk:
* gtkmm-devel
* glibmm-devel
* cairomm-devel
* libsigc-2.0-devel
* popt-devel
* gc-6.6 (Boehm's collector)
* intltool
* + their dependencies
* AND automake-1.8.5 or any other then 1.9.6 that is installed by default.
* and any other optionally required packages

If you compile automake-1.8.5 by yourself then be sure that you install it to /usr prefix and not to /usr/local. If you still install to /usr/local, then instead of running "autogen.sh" on svn version, run:

ACLOCAL_FLAGS="$ACLOCAL_FLAGS -I /usr/share/aclocal" ./autogen.sh

Then run ./configure; make; sudo make install as usually.

Thanks go to Dobey who helped a lot to figure out what was the problem.

== Suse 9.0 ==

One of the challenges with Suse 9.0 is the lack of a distro provided gtkmm2 and libsigc++ packages.

Best place to find them: ftp://ftp.gwdg.de/pub/linux/misc/apt4rpm/suse/usr-local-bin/9.0/
[ This URL does not exist anymore :-( ]

Suse 9.1 includes both now in the GNOME supplemental downloads.

Note that for SuSE the gtk+2 packages are called gtk2. The gtk+2 2.4 package is not provided via Yast but can be found via rpmseek as gtk2 and gtk2-devel

To find the .pc files, I had to set:

setenv PKG_CONFIG_PATH/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:/opt/gnome/lib/pkgconfig/

In SuSE 9.1 I ran into this error:

configure.in:25: required file `./ltmain.sh' not found

Copying /usr/share/libtool/ltmain.sh into the top directory fixed it.

For 0.40cvs the libgc dependency is added. In [[SuSE]] 9.1 this is package 'boehm-gc', but it doesn't work - you need to compile from source. Download from:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc6.3.tar.gz

Then configure it with the command:

$ ./configure --enable-cplus-plus

SuSE 9.1 also does not have libsigc++ 2.0; I couldn't find an rpm for it so ended up having to compile it from source, from http://prdownloads.sourceforge.net/libsigc/libsigc++-2.0.3.tar.gz

I also had to compile gtkmm 2.4 and glib 2.4 from source; download them from ftp://ftp.gnome.org/pub/GNOME/sources/gtkmm/2.4/ and http://ftp.gnome.org/pub/GNOME/sources/glibmm/2.4/

Looks like these packages are also available from here:ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.1-i386/RPMS.gnome/

Also, stuff got installed to /opt/gnome/bin/, so I had to also
`export PATH=$PATH:/opt/gnome/bin/`

[[Category:Developer Documentation]]
[[Category:Needs Work]]