Inkscape Wiki - User contributions [en]

CompilingMacOsX

2025-02-12T08:49:54Z

Mfloryan: /* Using Homebrew */ + libspelling

__TOC__

Section about MacPorts IS OUTDATED AND UNMAINTAINED!
Section about HomeBrew IS UP TO DATE as of Oct 30, 2024

= Using MacPorts =

If you can build successfully with MacPorts, please update this file and remove above comment.

<ol>
<li>Download and install [http://www.macports.org/ MacPorts]
<li>Edit the MacPorts variants config (optional).
 Add this line to <code>/opt/local/etc/macports/variants.conf</code>
<pre>-x11 +quartz</pre>
<li>In Terminal (Applications>Utilities>Terminal) type
<syntaxhighlight lang="bash">sudo port install \
adwaita-icon-theme \
boehmgc \
boost \
cairo \
ccache \
cmake \
double-conversion \
gdl3 \
gettext \
gsl \
gtkmm3 \
gtk-osx-application-gtk3 \
lcms2 \
libsoup \
libxslt \
ninja \
poppler \
potrace \
py-lxml \
py-numpy \
-x11 +quartz
</syntaxhighlight>
<li>In Terminal, get Inkscape
<syntaxhighlight lang="bash">git clone --recurse-submodules https://gitlab.com/inkscape/inkscape.git</syntaxhighlight>
<li>And build inkscape
<syntaxhighlight lang="bash">
# use a clean MacPorts environment (optional)
LIBPREFIX="/opt/local"
export PATH="$LIBPREFIX/bin:/usr/bin:/bin:/usr/sbin:/sbin"

# where to install
PREFIX="$PWD/install-prefix"

# where to build
mkdir build
cd build

cmake \
-G Ninja \
-DCMAKE_PREFIX_PATH="$LIBPREFIX" \
-DCMAKE_INSTALL_PREFIX="$PREFIX" \
-DCMAKE_C_COMPILER_LAUNCHER=ccache \
-DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
-DWITH_OPENMP=OFF \
../inkscape

ninja
ninja install
</syntaxhighlight>
''Note: Using [https://en.wikipedia.org/wiki/Ccache ccache] and [https://ninja-build.org/ ninja] is not required, but very common because it speeds up compilation.''
<li>Run Inkscape
<syntaxhighlight lang="bash">
$PREFIX/bin/inkscape
</syntaxhighlight>
</ol>

= Using Homebrew =

Prerequisites:
* Xcode (AppStore)
* Xcode command line tools (<code>xcode-select --install</code>)
* HomeBrew

If you are using [https://brew.sh/ Homebrew] instead, you can still use the above guidelines with small modifications.
(Make sure you don't have any MacPorts stuff in your PATH.)

List of '''packages''' to install with brew
(for Inkscape on master branch using GTK4):

<syntaxhighlight lang="bash">
brew install \
adwaita-icon-theme \
bdw-gc \
boost \
cairomm \
ccache \
cmake \
double-conversion \
gettext \
gsl \
gspell \
gtkmm4 \
gtksourceview5 \
imagemagick \
intltool \
lcms2 \
libomp \
libsoup@2 \
libxslt \
ninja \
pkg-config \
poppler \
potrace
</syntaxhighlight>

You may substitute <code>imagemagick</code> with <code>graphicsmagick</code>.

If you want to include spell cheker also install <code>libspelling</code> using brew.

To build version <code>1.4-x</code> you need <code>gtkmm3</code>, the <code>gtkmm4</code> is used from version <code>1.5</code>

Some keg-only libraries need to be added to <code>$PKG_CONFIG_PATH</code>

Some libraries can cause trouble if they are picked up from the SDK instead of Homebrew (observed with <code>libxslt</code> and <code>libxml2</code>). Adding them to <code>$PKG_CONFIG_PATH</code> should fix this.

Check out the source if you haven't already:

<syntaxhighlight lang="bash">git clone --recurse-submodules https://gitlab.com/inkscape/inkscape.git</syntaxhighlight>

Then <code>cd inkscape</code> and follow the steps below.

Tested with:
* M4 MacBook Air with macOS 15.1.1 and Inkscape 1.5-dev (takes about 7 minutes)
* M1 MacBook Air with macOS 11.6 and Inkscape 1.2-dev
* M2 MacBook Air with macOS 13.0.1 and Inkscape 1.2.1, 1.2.x from git.
* M2 Mac Mini with macOS 14.2 and Inkscape 1.4-dev. (After adding pkg-config.)
* VM with macOS 15.1 and Inkscape 1.5-dev (master branch)

<syntaxhighlight lang="bash">
# use a clean Homebrew environment (optional)
LIBPREFIX="/opt/homebrew"
export PATH="$LIBPREFIX/bin:/usr/bin:/bin:/usr/sbin:/sbin"

# keg-only libraries
export PKG_CONFIG_PATH="$LIBPREFIX/opt/icu4c/lib/pkgconfig"
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$LIBPREFIX/opt/libsoup@2/lib/pkgconfig"

# prevent picking up libxslt and libxml2 from the (wrong) SDK
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$LIBPREFIX/opt/libxslt/lib/pkgconfig"
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$LIBPREFIX/opt/libxml2/lib/pkgconfig"

# where to install
PREFIX="$PWD/install-prefix"

mkdir -p build
cd build

cmake \
-G Ninja \
-DCMAKE_SHARED_LINKER_FLAGS="-L$LIBPREFIX/lib" \
-DCMAKE_EXE_LINKER_FLAGS="-L$LIBPREFIX/lib" \
-DCMAKE_INSTALL_PREFIX=$PREFIX \
-DCMAKE_C_COMPILER_LAUNCHER=ccache \
-DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
-DWITH_DBUS=OFF \
..

ninja
ninja install
</syntaxhighlight>

=Running=

If you encounter the following error (when, eg. going to open file dialog):
<code>
(org.inkscape.Inkscape:91305): GLib-GIO-ERROR **: 11:18:06.449: No GSettings schemas are installed on the system
</code>

Then you have to modify the following:
<code>
export XDG_DATA_DIRS=$XDG_DATA_DIRS:/opt/homebrew/share
</code>

=Packaging=

If <code>$PREFIX/bin/inkscape</code> works when executed and you want to turn it into an app or a DMG, have a look at the files inside the <code>inkscape/packaging/macos</code> directory. More info can be found on upstream mibap:

* https://github.com/dehesselle/mibap

Follow the steps to install the toolset, package the app, and create a DMG. In case you use upstream mibap, you will get the app under <code>/Users/Shared/work/mibap-*/</code> and you will get a DMG file in the same place you ran <code>./build_inkscape.sh</code>.

=See also=
* [[Tracking Dependencies]]
* [[Extension requirements]]
*[[Compiling Inkscape]]
*[[Notes on Packaging for OS X]]
* https://github.com/valerioa/Inkscape-MacOS-Curated-Build
* [https://github.com/ipatch/homebrew-us-05/blob/master/inkscape/inkscape-building-for-macOS.md ipatch's collection of notes] about building Inkscape using Homebrew

[[Category:Developer Documentation]]

CompilingSuse

2011-10-06T10:28:41Z

Mfloryan:

== OpenSuSE 12.1 ==

zypper install autoconf automake intltool
zypper install gcc-c++ gtkmm24-devel gsl-devel boost-devel popt-devel
zypper install libtool liblcms-devel libxml2-devel libxslt-devel libMagick++-devel libpng14-devel

You may also want:

zypper install libwpg-devel dbus-1-glib-devel

To import some additional formats install UniConvertor, available in [http://download.opensuse.org/repositories/graphics/ graphics] repository (though not working at the moment 2011/10/05)

== OpenSUSE 11.2 ==

It's easiest to use zypper from the command line to install the required packages. So log in as root and execute this:

zypper install autoconf automake intltool
zypper install gcc-c++ glibmm2 gtkmm24-devel gsl-devel boost-devel popt-devel
zypper install libtool liblcms liblcms-devel libxml2-devel libxslt-devel libMagick++-devel libpng-devel

Now you're ready to download the source code, for example by using bazaar. This has been explained elsewhere on this wiki. Please be patient, because bazaar will download around 250 MB. After downloading the source code, change to that directory and run

./autogen.sh
./configure
make -j4 # Assuming you have a quadcore. -j4 tells make to use 4 cores
make install # inkscape need to be installed at least once, to put all icons
# in the correct shared directories. After that you can simply
# run inkscape from the start menu or execute it directly
# in the source directory (src/inkscape)
Have fun!

== 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]]

TranslationStatus

2010-06-07T20:31:44Z

Mfloryan: /* Interface translation (po files) */

Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

= Interface translation (po files) =

* There are some graphical statistics for the current UI translation progress at
http://mfloryan.statnet.pl/inkscape/

* Preliminary note : the names and e-mail addresses of contributors and last translator can be found in the header of the po file (simply open it with your favorite text editor or in Linux you can use the command '''head de.po''' to view the first 10 lines of the file de.po)

* General information

Status updated on 19 July 2006

Total number of localizable strings: '''2213'''

Total number of PO files: '''44'''

Average translated: 1345 ('''60 %'''), fuzzy: 408 ( 18 %), untranslated: 459 ( 20 %)

* '''Amharic''': am.po

translated: 78 ('''3 %'''), fuzzy: 660 ( 29 %), untranslated: 1475 ( 66 %)

* '''Azerbaijani/Turkic''': az.po

translated: 65 ('''2 %'''), fuzzy: 932 ( 42 %), untranslated: 1216 ( 54 %)

* '''Belarusian''': be.po

translated: 159 ('''7 %'''), fuzzy: 1026 ( 46 %), untranslated: 1028 ( 46 %)

* '''Catalan''': ca.po

translated: 2075 ('''93 %'''), fuzzy: 97 ( 4 %), untranslated: 41 ( 1 %)

* '''Czech''': cs.po

translated: 2085 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 30 ( 1 %)

* '''Danish''': da.po

translated: 2210 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 3 ( 0 %)

* '''German''': de.po

translated: 2107 ('''95 %'''), fuzzy: 84 ( 3 %), untranslated: 22 ( 0 %)

* '''Greek''': el.po

translated: 328 ('''14 %'''), fuzzy: 965 ( 43 %), untranslated: 920 ( 41 %)

* '''English/Great Britain''': en_GB.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Spanish''': es.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Spanish/Mexico''': es_MX.po

translated: 337 ('''15 %'''), fuzzy: 1014 ( 45 %), untranslated: 862 ( 38 %)

* '''Estonian''': et.po

translated: 9 ('''0 %'''), fuzzy: 861 ( 38 %), untranslated: 1343 ( 60 %)

* '''Basque''': eu.po

translated: 2075 ('''93 %'''), fuzzy: 99 ( 4 %), untranslated: 39 ( 1 %)

* '''Finnish''': fi.po

translated: 2213 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''French''': fr.po

translated: 2192 ('''99 %'''), fuzzy: 11 ( 0 %), untranslated: 10 ( 0 %)

* '''Irish''': ga.po

translated: 14 ('''0 %'''), fuzzy: 794 ( 35 %), untranslated: 1405 ( 63 %)

* '''Galician''': gl.po

translated: 84 ('''3 %'''), fuzzy: 1046 ( 47 %), untranslated: 1083 ( 48 %)

* '''Hungarian''': hu.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Italian''': it.po

translated: 2078 ('''93 %'''), fuzzy: 97 ( 4 %), untranslated: 38 ( 1 %)

* '''Japanese''': ja.po

translated: 1290 ('''58 %'''), fuzzy: 511 ( 23 %), untranslated: 412 ( 18 %)

* '''Korean''': ko.po

translated: 836 ('''37 %'''), fuzzy: 81 ( 3 %), untranslated: 1296 ( 58 %)

* '''Lithuanian''': lt.po

translated: 1892 ('''85 %'''), fuzzy: 98 ( 4 %), untranslated: 223 ( 10 %)

* '''Macedonian''': mk.po

translated: 0 ('''0 %'''), fuzzy: 679 ( 30 %), untranslated: 1534 ( 69 %)

* '''Nepali''': ne.po

translated: 2088 ('''97 %'''), fuzzy: 1 ( 0 %), untranslated: 55 ( 3 %)

* '''Norwegian/Bokmål dialect''': nb.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 2 %)

* '''Norwegian/Nynorsk''': nn.po

translated: 1592 ('''71 %'''), fuzzy: 372 ( 16 %), untranslated: 249 ( 11 %)

* '''Dutch: nl.po'''

translated: 1439 ('''65 %'''), fuzzy: 478 ( 21 %), untranslated: 296 ( 13 %)

* '''Piglatin''': pig.po

translated: ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Punjabi''': pa.po

translated: 907 ('''40 %'''), fuzzy: 432 ( 19 %), untranslated: 874 ( 39 %)

* '''Polish''': pl.po

translated: 2073 ('''93 %'''), fuzzy: 98 ( 4 %), untranslated: 42 ( 1 %)

* '''Portuguese''': pt.po

translated: 185 ( '''8 %'''), fuzzy: 1089 ( 49 %), untranslated: 939 ( 42 %)

* '''Portuguese/Brazil''': pt_BR.po

translated: 1495 ('''67 %'''), fuzzy: 444 ( 20 %), untranslated: 274 ( 12 %)

* '''Romanian''': ro.po

translated: 0 ('''0 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Russian''': ru.po

translated: 2081 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 34 ( 1 %)

* '''Slovak''': sk.po

translated: 844 ('''38 %'''), fuzzy: 748 ( 33 %), untranslated: 621 ( 28 %)

* '''Slovenian''': sl.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Serbian''': sr.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Serbian@Latine''': sr@Latn.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Swedish''': sv.po

translated: 564 ('''25 %'''), fuzzy: 824 ( 37 %), untranslated: 825 ( 37 %)

* '''Turkish''': tr.po

translated: 893 ('''40 %'''), fuzzy: 656 ( 29 %), untranslated: 664 ( 30 %)

* '''Ukrainian''': uk.po

translated: 1466 ('''66 %'''),fuzzy: 466 ( 21 %), untranslated: 281 ( 12 %)

* '''Vietnamese''': vi.po

translated: 2213 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Chinese/Simplified''': zh_CN.po

translated: 2083 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 32 ( 1 %)

* '''Chinese/Traditional''': zh_TW.po

translated: 2085 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 30 ( 1 %)

= Tutorials =

Already available in svn (as of Oct 2009):
* Basic: bg, ca, cs, da, de, eo, es, eu, fr, hu, it, ja, nl, nn, pl, pt_BR, ru, sk, sl, tr, vi, zh_CN, zh_TW
* Shapes: ca, cs, de, es, eu, fr, hu, it, ja, pl, pt_BR, ru, sk, sl, vi, zh_CN, zh_TW
* Advanced: ca, cs, de, es, eu, fr, hu, it, ja, pl, pt_BR, ru, sk, sl, vi, zh_CN, zh_TW
* Tracing: ca, de, es, eu, fr, hu, ja, pl, pt_BR, ru, sk, sl, vi, zh_TW
* Calligraphy: ca, cs, de, es, eu, fr, hu, ja, pl, pt_BR, ru, sk, sl, vi, zh_TW
* Elements of design: ca, de, es, eu, fr, hu, ja, pl, pt_BR, ru, sk, sl, zh_TW
* Tips and tricks: ca, de, es, eu, fr, hu, it, ja, pl, pt_BR, ru, sk, sl, vi, zh_TW
* Interpolate: de, hu, pl, sl, vi

= Keys (shortcuts) =

Already available in svn :
* de
* en
* fr
* sl

= Windows installer =

Already available in svn :
* catalan.nsh
* czech.nsh
* english.nsh
* french.nsh
* german.nsh
* italian.nsh
* polish.nsh
* slovak.nsh
* spanish.nsh

= Wiki translation =

= Website =

2006-08 001.inc de en it

2006-07 001.inc de en it

2006-06 010.inc de en it

2006-06 009.inc de en it

2006-06 008.inc de en it

2006-06 007.inc de en it

2006-06 006.inc de en

2006-06 005.inc de en

2006-06 004.inc de en

2006-06 003.inc de en

2006-06 002.inc de en

2006-06 001.inc de en

2006-05 007.inc de en

2006-05 006.inc de en

2006-05 005.inc de en

2006-05 004.inc de en

2006-05 003.inc de en

2006-05 002.inc de en

2006-05 001.inc de en es it

2006-04 005.inc de en es

2006-04 004.inc de en es

2006-04 003.inc de en

2006-04 002.inc de en

2006-04 001.inc de en fr

2006-02 001.inc en fr

2006-01 003.inc en fr

2006-01 002.inc en fr

2006-01 001.inc en fr it

2005-11 007.inc de en fr it

= News =

GNOME has the following at >50%.

bg, ca, cs, de, en_CA, en_GB, es, fi, fr, nb, ne, nl, pl, pt, pt_BR, ru, sk, sr, sv, uk, vi, zh_CN, and zh_TW

Of these, we have some at >80% already. The ones not at 80% are:

bg, en_CA, en_GB, fi, nb, ne, nl, pl, pt, pr_BR, ru, sk, sr, sv, uk, vi

pl, pt_BR, ru, sr, and uk are between 60-80%, so these seem like they should not be hard to boost to at least 80%! en_CA and en_GB ought to also be easy, aye?

= Translation information =
Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

TranslationStatus

2010-06-07T20:31:08Z

Mfloryan: /* Interface translation (po files) */

Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

= Interface translation (po files) =

* There are some graphical statistics for the current UI translation progress at [http://mfloryan.statnet.pl/inkscape/] - (started in May 2009)

* Preliminary note : the names and e-mail addresses of contributors and last translator can be found in the header of the po file (simply open it with your favorite text editor or in Linux you can use the command '''head de.po''' to view the first 10 lines of the file de.po)

* General information

Status updated on 19 July 2006

Total number of localizable strings: '''2213'''

Total number of PO files: '''44'''

Average translated: 1345 ('''60 %'''), fuzzy: 408 ( 18 %), untranslated: 459 ( 20 %)

* '''Amharic''': am.po

translated: 78 ('''3 %'''), fuzzy: 660 ( 29 %), untranslated: 1475 ( 66 %)

* '''Azerbaijani/Turkic''': az.po

translated: 65 ('''2 %'''), fuzzy: 932 ( 42 %), untranslated: 1216 ( 54 %)

* '''Belarusian''': be.po

translated: 159 ('''7 %'''), fuzzy: 1026 ( 46 %), untranslated: 1028 ( 46 %)

* '''Catalan''': ca.po

translated: 2075 ('''93 %'''), fuzzy: 97 ( 4 %), untranslated: 41 ( 1 %)

* '''Czech''': cs.po

translated: 2085 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 30 ( 1 %)

* '''Danish''': da.po

translated: 2210 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 3 ( 0 %)

* '''German''': de.po

translated: 2107 ('''95 %'''), fuzzy: 84 ( 3 %), untranslated: 22 ( 0 %)

* '''Greek''': el.po

translated: 328 ('''14 %'''), fuzzy: 965 ( 43 %), untranslated: 920 ( 41 %)

* '''English/Great Britain''': en_GB.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Spanish''': es.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Spanish/Mexico''': es_MX.po

translated: 337 ('''15 %'''), fuzzy: 1014 ( 45 %), untranslated: 862 ( 38 %)

* '''Estonian''': et.po

translated: 9 ('''0 %'''), fuzzy: 861 ( 38 %), untranslated: 1343 ( 60 %)

* '''Basque''': eu.po

translated: 2075 ('''93 %'''), fuzzy: 99 ( 4 %), untranslated: 39 ( 1 %)

* '''Finnish''': fi.po

translated: 2213 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''French''': fr.po

translated: 2192 ('''99 %'''), fuzzy: 11 ( 0 %), untranslated: 10 ( 0 %)

* '''Irish''': ga.po

translated: 14 ('''0 %'''), fuzzy: 794 ( 35 %), untranslated: 1405 ( 63 %)

* '''Galician''': gl.po

translated: 84 ('''3 %'''), fuzzy: 1046 ( 47 %), untranslated: 1083 ( 48 %)

* '''Hungarian''': hu.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Italian''': it.po

translated: 2078 ('''93 %'''), fuzzy: 97 ( 4 %), untranslated: 38 ( 1 %)

* '''Japanese''': ja.po

translated: 1290 ('''58 %'''), fuzzy: 511 ( 23 %), untranslated: 412 ( 18 %)

* '''Korean''': ko.po

translated: 836 ('''37 %'''), fuzzy: 81 ( 3 %), untranslated: 1296 ( 58 %)

* '''Lithuanian''': lt.po

translated: 1892 ('''85 %'''), fuzzy: 98 ( 4 %), untranslated: 223 ( 10 %)

* '''Macedonian''': mk.po

translated: 0 ('''0 %'''), fuzzy: 679 ( 30 %), untranslated: 1534 ( 69 %)

* '''Nepali''': ne.po

translated: 2088 ('''97 %'''), fuzzy: 1 ( 0 %), untranslated: 55 ( 3 %)

* '''Norwegian/Bokmål dialect''': nb.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 2 %)

* '''Norwegian/Nynorsk''': nn.po

translated: 1592 ('''71 %'''), fuzzy: 372 ( 16 %), untranslated: 249 ( 11 %)

* '''Dutch: nl.po'''

translated: 1439 ('''65 %'''), fuzzy: 478 ( 21 %), untranslated: 296 ( 13 %)

* '''Piglatin''': pig.po

translated: ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Punjabi''': pa.po

translated: 907 ('''40 %'''), fuzzy: 432 ( 19 %), untranslated: 874 ( 39 %)

* '''Polish''': pl.po

translated: 2073 ('''93 %'''), fuzzy: 98 ( 4 %), untranslated: 42 ( 1 %)

* '''Portuguese''': pt.po

translated: 185 ( '''8 %'''), fuzzy: 1089 ( 49 %), untranslated: 939 ( 42 %)

* '''Portuguese/Brazil''': pt_BR.po

translated: 1495 ('''67 %'''), fuzzy: 444 ( 20 %), untranslated: 274 ( 12 %)

* '''Romanian''': ro.po

translated: 0 ('''0 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Russian''': ru.po

translated: 2081 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 34 ( 1 %)

* '''Slovak''': sk.po

translated: 844 ('''38 %'''), fuzzy: 748 ( 33 %), untranslated: 621 ( 28 %)

* '''Slovenian''': sl.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Serbian''': sr.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Serbian@Latine''': sr@Latn.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Swedish''': sv.po

translated: 564 ('''25 %'''), fuzzy: 824 ( 37 %), untranslated: 825 ( 37 %)

* '''Turkish''': tr.po

translated: 893 ('''40 %'''), fuzzy: 656 ( 29 %), untranslated: 664 ( 30 %)

* '''Ukrainian''': uk.po

translated: 1466 ('''66 %'''),fuzzy: 466 ( 21 %), untranslated: 281 ( 12 %)

* '''Vietnamese''': vi.po

translated: 2213 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Chinese/Simplified''': zh_CN.po

translated: 2083 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 32 ( 1 %)

* '''Chinese/Traditional''': zh_TW.po

translated: 2085 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 30 ( 1 %)

= Tutorials =

Already available in svn (as of Oct 2009):
* Basic: bg, ca, cs, da, de, eo, es, eu, fr, hu, it, ja, nl, nn, pl, pt_BR, ru, sk, sl, tr, vi, zh_CN, zh_TW
* Shapes: ca, cs, de, es, eu, fr, hu, it, ja, pl, pt_BR, ru, sk, sl, vi, zh_CN, zh_TW
* Advanced: ca, cs, de, es, eu, fr, hu, it, ja, pl, pt_BR, ru, sk, sl, vi, zh_CN, zh_TW
* Tracing: ca, de, es, eu, fr, hu, ja, pl, pt_BR, ru, sk, sl, vi, zh_TW
* Calligraphy: ca, cs, de, es, eu, fr, hu, ja, pl, pt_BR, ru, sk, sl, vi, zh_TW
* Elements of design: ca, de, es, eu, fr, hu, ja, pl, pt_BR, ru, sk, sl, zh_TW
* Tips and tricks: ca, de, es, eu, fr, hu, it, ja, pl, pt_BR, ru, sk, sl, vi, zh_TW
* Interpolate: de, hu, pl, sl, vi

= Keys (shortcuts) =

Already available in svn :
* de
* en
* fr
* sl

= Windows installer =

Already available in svn :
* catalan.nsh
* czech.nsh
* english.nsh
* french.nsh
* german.nsh
* italian.nsh
* polish.nsh
* slovak.nsh
* spanish.nsh

= Wiki translation =

= Website =

2006-08 001.inc de en it

2006-07 001.inc de en it

2006-06 010.inc de en it

2006-06 009.inc de en it

2006-06 008.inc de en it

2006-06 007.inc de en it

2006-06 006.inc de en

2006-06 005.inc de en

2006-06 004.inc de en

2006-06 003.inc de en

2006-06 002.inc de en

2006-06 001.inc de en

2006-05 007.inc de en

2006-05 006.inc de en

2006-05 005.inc de en

2006-05 004.inc de en

2006-05 003.inc de en

2006-05 002.inc de en

2006-05 001.inc de en es it

2006-04 005.inc de en es

2006-04 004.inc de en es

2006-04 003.inc de en

2006-04 002.inc de en

2006-04 001.inc de en fr

2006-02 001.inc en fr

2006-01 003.inc en fr

2006-01 002.inc en fr

2006-01 001.inc en fr it

2005-11 007.inc de en fr it

= News =

GNOME has the following at >50%.

bg, ca, cs, de, en_CA, en_GB, es, fi, fr, nb, ne, nl, pl, pt, pt_BR, ru, sk, sr, sv, uk, vi, zh_CN, and zh_TW

Of these, we have some at >80% already. The ones not at 80% are:

bg, en_CA, en_GB, fi, nb, ne, nl, pl, pt, pr_BR, ru, sk, sr, sv, uk, vi

pl, pt_BR, ru, sr, and uk are between 60-80%, so these seem like they should not be hard to boost to at least 80%! en_CA and en_GB ought to also be easy, aye?

= Translation information =
Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

Interface translation

2010-06-07T20:29:56Z

Mfloryan: /* Get the PO file for your language */

Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

== Introduction to PO file format ==

If you've never translated a PO file before, you will find its syntax very simple. The PO format is a really simple format, which probably at least partly explains its success and widespread use. The format is basically a hash list consisting of msgid and msgstr pairs, with the msgid being the original English string and key, and the msgstr being the translated value of it. Below is an example of a message.

#: gedit/dialogs/gedit-plugin-program-location-dialog.c:78
#: gedit/dialogs/program-location-dialog.glade2.h:2
msgid "Set program location..."
msgstr "Ställ in programplats..."

In addition to the msgid and msgstr parts, a message usually also has lines starting with #: that tells what source files and what lines the string used as msgid was extracted from. These lines have no syntactic value. They are only there as a help for translators and developers to know where a message came from.

A message in a PO file can be in one of essentially three different states. The message can be translated, fuzzy, or untranslated. A message counts as translated as soon as the msgstr part of it is non-empty. In a similar manner, an untranslated message is one where the msgstr is empty. The fuzzy state is special and essentially means that there is a translation in the msgstr part, but that this translation is most likely not entirely correct, and that it thus needs manual attention by a translator. A message can become fuzzy in one of two ways:

* The original string that the msgid represents was changed in the source code. A typo in the string may have been fixed or the string altered in some other way. The translator needs to check that the msgstr is still valid and make changes if necessary.
* A new string has been added to the source, and the string is very similar, but not identical, to the msgid of an already existing, translated message. Then the msgstr of that message will be automatically reused for the new message, but the new message will also at the same time be marked fuzzy so that the translator knows there is some difference that he or she needs to adapt the translation to match.

There is always one special message in each valid PO file: the PO file header. It is encoded with the msgid for the empty string ("") as the key, and the actual header values are in the msgstr part. This unfortunately means that if you mark an empty string for translation, you will get the entire PO file header back as the "translation". In almost all cases this is probably not what you want. Hence, do not mark empty strings for translation.

== Get the PO file for your language ==

Download the .po file for your language from here:

http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/po/

If a .po file for your language does not yet exist, then you will have to get an empty template file to start a new translation.
You may also need to use the updated template file (mentioned blow) to bring the .po file up to date with new strings introduced in the UI.

The most straightforward way to obtain the inkscape.pot template is to download it from here:

http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/annotate/head:/po/inkscape.pot

Alternatively, you can checkout the full BZR project repository and generate the project template. Information on how to get the source tree can be found [http://inkscape.org/bzr.php?lang=en here]. Then, you have to follow some steps in order to generate the template:

1. "./autogen.sh"
2. "./configure"
3. enter the "po" directory: "cd po"
4. generate the current PO template: "intltool-update --pot"

To make an absolutely up-to-date translation (in case the PO file in BZR is not up-to-date enough),

1. update your local copy of Inkscape in the usual way: "bzr pull"
2. merge your existing translations into the new POT file (inkscape.pot):

"msgmerge your_latest_PO_file inkscape.pot > new_PO_file"

If you want to update ALL .po files in po/, cd there and run:

make update-po

Now that you have an empty PO template, you can start translating the messages.

You can track progress of all Inkscape translations here (unofficial, maintained by [http://twitter.com/mfloryan mfloryan]):
http://mfloryan.statnet.pl/inkscape/

== Tools for translators ==

You can edit PO files from any plain text editor, since they are simple text files. However, many useful tools have been developed to provide a simple experience translating PO files.

* emacs' po-mode (contained in the gettext distribution; the version in po-utils is old)
* kbabel (http://i18n.kde.org/tools/kbabel/)
* gtranslator (http://gtranslator.sourceforge.net/)
* poEdit (http://www.poedit.net/)
* GEdit (installed on GNOME desktops) has a syntax highlight mode for PO file syntax.
* [http://translate.sourceforge.net/wiki/virtaal/index Virtaal] - cross-platform PO editor that is clean, simple to use yet powerful.

And last but not least, [http://www.gnu.org/software/gettext/manual/ gettext] utils, which are installed on every linux distribution. You can see a complete reference too from installed info pages by running the command:

info gettext

== A few important things to remember ==

* Some strings that can be ambiguous or having several meanings according to different contexts may have a context prefix : "Context|Amibiguous string". In this case, simply translate "Ambiguous string", the "Context|" string is just a not to translate indication. (Some info on how to disambiguate a string can be found [http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html#Q-:CAPS here].)
* After translating a fuzzy string (one that is marked with a ", fuzzy" comment), please remove its "fuzzy" tag -- otherwise this translation will be discarded by the build process, meaning that this string will show up untranslated. KBabel can do this automatically (see KBabel settings).
* Before publishing your work (after you have finished updating the PO file), please update the "PO-Revision-Date" and "Last-Translator" fields in the PO file header. KBabel can do this automatically.

== Review ==

This is the start of a list of places to get translation reviews done. So far:
http://www.linux.it/tp/

== Verification ==

Before submitting your file in the patch tracker, please make sure it is valid:
* Make sure the file is encoded in UTF-8
* Make sure it is a valid po file and obtain some statistics about it: simply run "msgfmt --statistics -cv translationFile.po" from a command window
* Make sure it is correctly formatted: run "check-markup translationFile.po" from a command window and verify it doesn't output any error message. "check-markup" perl script can be found in the /po directory of Inkscape svn trunk

== Locale Testing ==

Before reporting that a locale doesn't work in Inkscape, you need to make sure that your system has that locale correctly set up. To do this, you need to generally find a way to run "locale-gen". (Under Debian/Ubuntu this is via "dpkg-reconfigure locales".) If you set both the LANG and LANGUAGE variables and check a regular tool, you should see the correct language for both the libc error (first line) and the tool error (second line):

LANG=es_MX LANGUAGE=es_MX ls -z
ls: opción inválida -- z
Pruebe `ls --help' para más información.

If it reports the regular C messages, your locale has not been correctly configured, and you'll need to find the right way to run "locale-gen" for your distribution:

LANG=es_ES LANGUAGE=es_MX ls -z
ls: invalid option -- z
Try `ls --help' for more information.

== Submit finished work ==

Upload your work via the [[Launchpad]] bug tracker:

https://bugs.launchpad.net/inkscape/

Report a new bug and attach your translated file to it. Don't forget to compress your file before uploading it.

Additionally, you may send a message to Inkscape's translators mailing list.

== Programmers ==
Please make sure you use [http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC150 dgettext] for any pluralized strings.

= Windows installer translation =

Strings for Windows installer are saved in *.nsh files. Each translation has its own file located in ''packaging\win32\'' directory of subversion checkout. Get this file in similar way of getting *.po file.
=== Translating ===
# Get the file according to your language. If there is not such a file, copy ''english.nsh'' file and rename it to ''yourlanguage.nsh''.
# Translate strings in the file
# Change '''!insertmacro MUI_LANGUAGE "English"''' and each occurence of '''${LANG_ENGLISH}''' to values corresponding with your language. For example '''!insertmacro MUI_LANGUAGE "Czech"''' and '''${LANG_CZECH}'''.
# Change header information in '''yourlanguage.nsh''' file, like "windows code page" and "Authors" to proper values.
=== Testing the translation ===
# This part is optional but recommended. For this part you need [http://nsis.sourceforge.net/Main_Page NSIS installer] and run <pre>make -f Makefile.mingw dist</pre> command after succesfull compilation of Inkscape. This command prepares binary of Inkscape for installator creation.
# Add filename of your file to '''inkscape.nsi''' file, "STRING LOCALIZATION" section, "Language files" subsection.
# Right click on the inkscape.nsi file and choose "Compile NSIS Script". The installer compilation will start.
# When the installer is finished, run it to test translations of strings in Installer and Uninstaller parts.
# If the translation is tested succesfully, submit it to the patch tracker at sourceforge.net and mark as "Translation". If you haven't tested your translation yet, submit it too but enter this information to the patch information. You will be contacted about its correctness.

= Default template translation =

* To translate default template, modify the default.svg file and save it as default.xx.svg where "xx" is ISO code of your language. The file can be found in ''/usr/share/inkscape/templates/'' directory on Linux, or ''C:\Program Files\Inkscape\share\templates\'' directory on MS Windows(tm). Also you can get it from [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/trunk/share/templates/ SVN repository].
* You need to modify your PO translation as well to use your localized default template. Look up for a msgid "default.svg" on the PO file and translate it accordingly to the file name of the localized template.
* To test it, save it to the proper location and restart Inkscape. Default document should be now based on your localized template. (This is valid if your system is properly set to your locales).
* Upload default.xx.svg to the patch tracker.

To translate default template can be used Inkscape as well as any UTF-8 encoding capable text editor.

= Translation information =
Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

TranslationStatus

2009-06-05T20:58:37Z

Mfloryan: /* Interface translation (po files) */

Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

= Interface translation (po files) =

* There are some graphical statistics for the current UI translation progress at [http://mfloryan.statnet.pl/~mfloryan/inkscape/] - (started in May 2009)

* Preliminary note : the names and e-mail addresses of contributors and last translator can be found in the header of the po file (simply open it with your favorite text editor or in Linux you can use the command '''head de.po''' to view the first 10 lines of the file de.po)

* General information

Status updated on 19 July 2006

Total number of localizable strings: '''2213'''

Total number of PO files: '''44'''

Average translated: 1345 ('''60 %'''), fuzzy: 408 ( 18 %), untranslated: 459 ( 20 %)

* '''Amharic''': am.po

translated: 78 ('''3 %'''), fuzzy: 660 ( 29 %), untranslated: 1475 ( 66 %)

* '''Azerbaijani/Turkic''': az.po

translated: 65 ('''2 %'''), fuzzy: 932 ( 42 %), untranslated: 1216 ( 54 %)

* '''Belarusian''': be.po

translated: 159 ('''7 %'''), fuzzy: 1026 ( 46 %), untranslated: 1028 ( 46 %)

* '''Catalan''': ca.po

translated: 2075 ('''93 %'''), fuzzy: 97 ( 4 %), untranslated: 41 ( 1 %)

* '''Czech''': cs.po

translated: 2085 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 30 ( 1 %)

* '''Danish''': da.po

translated: 2210 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 3 ( 0 %)

* '''German''': de.po

translated: 2107 ('''95 %'''), fuzzy: 84 ( 3 %), untranslated: 22 ( 0 %)

* '''Greek''': el.po

translated: 328 ('''14 %'''), fuzzy: 965 ( 43 %), untranslated: 920 ( 41 %)

* '''English/Great Britain''': en_GB.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Spanish''': es.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Spanish/Mexico''': es_MX.po

translated: 337 ('''15 %'''), fuzzy: 1014 ( 45 %), untranslated: 862 ( 38 %)

* '''Estonian''': et.po

translated: 9 ('''0 %'''), fuzzy: 861 ( 38 %), untranslated: 1343 ( 60 %)

* '''Basque''': eu.po

translated: 2075 ('''93 %'''), fuzzy: 99 ( 4 %), untranslated: 39 ( 1 %)

* '''Finnish''': fi.po

translated: 2213 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''French''': fr.po

translated: 2192 ('''99 %'''), fuzzy: 11 ( 0 %), untranslated: 10 ( 0 %)

* '''Irish''': ga.po

translated: 14 ('''0 %'''), fuzzy: 794 ( 35 %), untranslated: 1405 ( 63 %)

* '''Galician''': gl.po

translated: 84 ('''3 %'''), fuzzy: 1046 ( 47 %), untranslated: 1083 ( 48 %)

* '''Hungarian''': hu.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Italian''': it.po

translated: 2078 ('''93 %'''), fuzzy: 97 ( 4 %), untranslated: 38 ( 1 %)

* '''Japanese''': ja.po

translated: 1290 ('''58 %'''), fuzzy: 511 ( 23 %), untranslated: 412 ( 18 %)

* '''Korean''': ko.po

translated: 836 ('''37 %'''), fuzzy: 81 ( 3 %), untranslated: 1296 ( 58 %)

* '''Lithuanian''': lt.po

translated: 1892 ('''85 %'''), fuzzy: 98 ( 4 %), untranslated: 223 ( 10 %)

* '''Macedonian''': mk.po

translated: 0 ('''0 %'''), fuzzy: 679 ( 30 %), untranslated: 1534 ( 69 %)

* '''Nepali''': ne.po

translated: 2088 ('''97 %'''), fuzzy: 1 ( 0 %), untranslated: 55 ( 3 %)

* '''Norwegian/Bokmål dialect''': nb.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 2 %)

* '''Norwegian/Nynorsk''': nn.po

translated: 1592 ('''71 %'''), fuzzy: 372 ( 16 %), untranslated: 249 ( 11 %)

* '''Dutch: nl.po'''

translated: 1439 ('''65 %'''), fuzzy: 478 ( 21 %), untranslated: 296 ( 13 %)

* '''Piglatin''': pig.po

translated: ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Punjabi''': pa.po

translated: 907 ('''40 %'''), fuzzy: 432 ( 19 %), untranslated: 874 ( 39 %)

* '''Polish''': pl.po

translated: 2073 ('''93 %'''), fuzzy: 98 ( 4 %), untranslated: 42 ( 1 %)

* '''Portuguese''': pt.po

translated: 185 ( '''8 %'''), fuzzy: 1089 ( 49 %), untranslated: 939 ( 42 %)

* '''Portuguese/Brazil''': pt_BR.po

translated: 1495 ('''67 %'''), fuzzy: 444 ( 20 %), untranslated: 274 ( 12 %)

* '''Romanian''': ro.po

translated: 0 ('''0 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Russian''': ru.po

translated: 2081 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 34 ( 1 %)

* '''Slovak''': sk.po

translated: 844 ('''38 %'''), fuzzy: 748 ( 33 %), untranslated: 621 ( 28 %)

* '''Slovenian''': sl.po

translated: 2085 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 31 ( 1 %)

* '''Serbian''': sr.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Serbian@Latine''': sr@Latn.po

translated: 2087 ('''94 %'''), fuzzy: 97 ( 4 %), untranslated: 29 ( 1 %)

* '''Swedish''': sv.po

translated: 564 ('''25 %'''), fuzzy: 824 ( 37 %), untranslated: 825 ( 37 %)

* '''Turkish''': tr.po

translated: 893 ('''40 %'''), fuzzy: 656 ( 29 %), untranslated: 664 ( 30 %)

* '''Ukrainian''': uk.po

translated: 1466 ('''66 %'''),fuzzy: 466 ( 21 %), untranslated: 281 ( 12 %)

* '''Vietnamese''': vi.po

translated: 2213 ('''100 %'''), fuzzy: 0 ( 0 %), untranslated: 0 ( 0 %)

* '''Chinese/Simplified''': zh_CN.po

translated: 2083 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 32 ( 1 %)

* '''Chinese/Traditional''': zh_TW.po

translated: 2085 ('''94 %'''), fuzzy: 98 ( 4 %), untranslated: 30 ( 1 %)

= Tutorials =

Already available in svn:
* Basic: ca, cs, de, en, es, fr, ja, nn, pt_BR, ru, sl
* Shapes: ca, cs, de, en, es, fr, ja, pt_BR, sl
* Advanced: ca, cs, de, en, es, fr, ja, pt_BR, sl
* Tracing: ca, de, en, es, fr, sl
* Calligraphy: ca, cs, de, en, es, fr, pt_BR, sl
* Elements of design: de, en, es, fr, pt_BR, sl
* Tips and tricks: de, en, es, fr, pt_BR, sl

= Keys (shortcuts) =

Already available in svn :
* de
* en
* fr
* sl

= Windows installer =

Already available in svn :
* catalan.nsh
* czech.nsh
* english.nsh
* french.nsh
* german.nsh
* italian.nsh
* polish.nsh
* slovak.nsh
* spanish.nsh

= Wiki translation =

= Website =

2006-08 001.inc de en it

2006-07 001.inc de en it

2006-06 010.inc de en it

2006-06 009.inc de en it

2006-06 008.inc de en it

2006-06 007.inc de en it

2006-06 006.inc de en

2006-06 005.inc de en

2006-06 004.inc de en

2006-06 003.inc de en

2006-06 002.inc de en

2006-06 001.inc de en

2006-05 007.inc de en

2006-05 006.inc de en

2006-05 005.inc de en

2006-05 004.inc de en

2006-05 003.inc de en

2006-05 002.inc de en

2006-05 001.inc de en es it

2006-04 005.inc de en es

2006-04 004.inc de en es

2006-04 003.inc de en

2006-04 002.inc de en

2006-04 001.inc de en fr

2006-02 001.inc en fr

2006-01 003.inc en fr

2006-01 002.inc en fr

2006-01 001.inc en fr it

2005-11 007.inc de en fr it

= News =

GNOME has the following at >50%.

bg, ca, cs, de, en_CA, en_GB, es, fi, fr, nb, ne, nl, pl, pt, pt_BR, ru, sk, sr, sv, uk, vi, zh_CN, and zh_TW

Of these, we have some at >80% already. The ones not at 80% are:

bg, en_CA, en_GB, fi, nb, ne, nl, pl, pt, pr_BR, ru, sk, sr, sv, uk, vi

pl, pt_BR, ru, sr, and uk are between 60-80%, so these seem like they should not be hard to boost to at least 80%! en_CA and en_GB ought to also be easy, aye?

= Translation information =
Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

User:Mfloryan

2008-06-19T14:12:17Z

Mfloryan:

=Marcin Floryan=

aka <tt>mfx</tt>
* [http://marcin.floryan.pl/ Marcin Floryan PL]

User:Mfloryan

2008-06-19T14:11:33Z

Mfloryan: /* Marcin Floryan */

=Marcin Floryan=

* [http://marcin.floryan.pl/ Marcin Floryan PL]

Release notes/0.47

2008-04-30T08:19:37Z

Mfloryan: /* API changes */

=Inkscape 0.47=
'''(not released yet)'''

=Refactoring effort=
[mention the 'main' goal of 0.47 and list which things have been refactored and the benefits/new features/different workflow? --johan]

=Tools=

==Node tool==

* [helper path display, flashing - johan]
* The Node tool can now edit '''clipping paths''' and '''masks''' of objects on canvas, without releasing them. If the selected object has a clipping path and mask, the corresponding buttons on the controls bar of the tool will be enabled; pressing these buttons will display the editable paths or handles of the clippath or mask. A clipping path is stroked green, a mask is stroked blue (the same colors as those used for them in Outline mode).
* Snapping has been improved (more details in Snapping below)
* When dragging a node '''handle with Ctrl''', it now snaps not only to the 15 degree increments starting from 0 and to the original handle direction, but also to the direction of the '''opposite handle''' (if it exists) or of the '''opposite line segment''' (if it is a straight line).
* The behavior of the buttons/shortucts that make a node smooth or cusp has been improved:
:* If a node is already cusp (diamond shaped), pressing Shift+C again on it will retract both its handles. As this works for any number of selected nodes, you can always retract all handles in all nodes by selecting all nodes and pressing Shift+C twice.
:* If a non-smooth node is next to a straight line segment, pressing Shift+S once makes it ''half-smooth'': it now has one handle aligned with that line segment. Another press of Shift+S will expand the second handle as well turning it into a full smooth node. If a node is between two curve segments, Shift+S will expand both handles as before.

==Calligraphy tool ==
Added 4 preset buttons for dip, pen, brush and reed in the toolbox. Clicking one button sets the calligraphic tool with the matching presets.

==Paint Bucket tool==
* Paint Bucket is now more tightly integrated with potrace. As a result, memory and CPU usage on each fill operation have been reduced significantly.

==Eraser Tool==
A new eraser tool has been added. It has two main modes:
* Delete-mode where any shape touched by the tool is deleted completely. This operation is in line with "vector" editing.
* Cut mode where erasing acts similar to erasing in a standard bitmap editor.
Erasing is also limited to the currently selected objects if there are any selected.

=Live path effects=
== Notable bug fixes and effect changes==
We try to refrain from changing the behavior of LPE's, because it will change appearance in old files when opened in Inkscape¹. But when an effect is really broken, we have to fix it.

[¹ fixme: Shouldn't the above say "it will change editing behaviour in old files" ? If it changes the appearance, then that's a bug: inkscape should always save SVG that represents the appearance, and should display according to the SVG rather than any inkscape:blah annotations. --pjrm 
What is meant is the following. Files with LPEs opened in a random viewer will always look the same, regardless of Inkscape version. However, when viewed in Inkscape, the LPE is recalculated. When LPE behavior changes, the appearance will change. --johan]

* The Pattern Along Path effect used to stretch the pattern across discontinuities. This has been fixed; now it treats a discontinuous path as a group of continuous paths and applied the effect separately to each.

==New effects==
[new: sketch, von koch, knot]

* Perspective paths: Draw an arbitrary path as if viewed in perspective. This is work in progress. Known limitations (among others): It can only use the first perspective that exists in the document defs, and the perspective cannot be adapted interactively yet (the effect must be removed and reapplied after modifying the perspective).

* '''Spiro splines''' are a novel way of defining curvilinear paths [http://www.levien.com/spiro/ developed by Raph Levien]. It takes some getting used to, but for certain tasks (such as lettershape design) Spiros have a clear advantage over Bezier curves. Recently, Spiro support was added to the FontForge font editor; now it is available in Inkscape too, which means you can use all the convenient Inkscape path tools (moving and transforming groups of nodes, node sculpting, etc.) on Spiro paths.

:A Spiro path is defined by a sequence of points, but unlike a regular path with Bezier curves, all Spiro points lie on the path and there are no off-path handles. The curvature of the path is defined entirely by the positions of the points and their types. The path behaves very similar to a springy rod which is forced to pass through the given points and which uses the minimum possible curvature to satisfy the requirement. As such, it feels quite natural and the resulting path is very smooth - not just superficially smooth (i.e. having no cusps), but smooth at a deeper level, which you can achieve with Beziers only after a lot of laborious tweaking.

:To create a Spiro path, select any path and assign the "Spiro spline" path effect to it. There are no parameters. Each node of your path becomes a point of a Spiro path, depending on the type of node:

:* Smooth nodes (those with two collinear Bezier handles; use Shift+S to make a node smooth) become smooth curve points of the Spiro path. Note that the length or direction of the Bezier handles of the source path is ignored; the only thing that matters is their collinearity.

:* Cusp nodes of the source path become corner points of the Spiro path, like free hinges on the springy rod. Between two corner points, the path is always a straight line. To make a node cusp, retract its Bezier handles by Ctrl+click, or press Shift+C and move one of the handles so they are no longer collinear.

:* Half-smooth nodes - those with one Bezier handle collinear with a straight line segment on the other hand - become "left" or "right" points on the Spiro path which behave exactly the same: they sit between a straight line and a curve and enforce that these two segments join smoothly without a cusp. To create such a node, make sure one of the segments is a line (select its ends and press Shift+L), then Ctrl+drag the remaining handle to make it snap to the direction of the straight line segment on the other side, or press Shift+S to lock it to that direction.

:Note that what matters is the actual collinearity of a node's handles, regardless of the node type that the node has in the Node tool; for example, if a node designated as cusp (diamond-shaped) has collinear handles, it will become a smooth curve point of the Spiro path.

:Some configurations of points do not converge and produce wild loops and spirals instead of a smooth curve. According to Raph, "The spline solver in this release is _not_ numerically robust. When you start drawing random points, you'll quickly run into divergence. However, "sensible" plates based on real fonts usually converge." Avoid too sharp changes in direction between points to prevent divergence. Hopefully, the robustness of the algorithm will be improved in future releases.

:For now, to edit Spiro paths viewing the result in real time, you have to use the Node tool; it is recommended to turn off the red highlight of the source path as it is a distraction. The Pen tool does not yet allow you to preview a Spiro as you draw, although you can paste the Spiro effect on the path and see the result as soon as the path is finalized.

:You can always use the Node tool to continue a Spiro path by duplicating and dragging away its end nodes. Also, when you have a Spiro path selected, you can add a new subpath to it with Pen or Pencil if you start drawing with Shift.

==New features==
* The '''Paste Path Effect''' command is enabled to assign the path effect of the clipboard to any number of paths, going recursively into groups if necessary.

* A new command, '''Remove path effect''' removes any path effects from all selected objects, going recursively into groups if necessary.

* Along with the commands to open the path effects dialog and to paste path effects, the three commands were collected in a submenu under Path menu.

* Live path effects can now be assigned to the sides of a 3D box (use Ctrl+click to select individual sides).

* The Pen and Pencil tools now correctly work with paths with LPEs: you can continue such a path or add a new subpath to it by drawing with Shift, all preserving the effect applied to it.

* Path type parameters can now link to existing shapes and text, like clones do. Now it is possible to use text as input for the Pattern Along Path effect for example!

* Lib2geom now has an implementation for SVGEllipticalArc. For Inkscape, this means that it is now possible to directly copy-paste ellipse shapes on path parameters (e.g. 'pattern' in Pattern along Path), without the need to convert the ellipse object to path first. [needs coding and checking]

==Live Path Effect for groups==

LPE can now be assigned to a group. For most LPE, the effect is applied recursively but for Bend Path the result is more powerful : the distortion applies on the whole group.

*Original path of the group can as usual be edited by double-clicking.
*It applies recursively, this means that a LPE can be assigned to groups of groups
*The Effect can be applied definitively with "Convert Object to path"

=Import/Export=
==Corel DRAW files import==

Now Inkscape can import more Corel DRAW files of following types:

* Corel DRAW Compressed Exchange files (CCX)
* Corel DRAW 7-X4 Template files (CDT)
* Corel DRAW Presentation Exchange files (CMX)

Text objects are not supported as of UniConvertor 1.1.1.

==sK1 files import==

Inkscape uses UniConvertor to import sK1 files. Text objects are not supported as of UniConvertor 1.1.1.

==CGM import==

Inkscape uses UniConvertor to import Computer Graphics Metafile (CGM) files. Text objects are not supported as of UniConvertor 1.1.1.

==PDF export==

With PDF export, it is now possible to make the PDF page the size of the entire drawing, instead of the same as SVG page as before by the "Export drawing, not page" checkbox in PDF export options. Also, you can export a single object from a complex document to PDF if you specify the ID of that object in the "Limit export to the object with ID" field; the page of such PDF will be the same size as the bounding box of that object and will show only that object (all others will be hidden).

The same capabilities are available from the command line by using <code>--export-area-drawing</code> and <code>--export-id=ID</code> parameters with <code>--export-pdf</code> (previously, they only worked for PNG export).

=Extension effects=
==New and improved effects==

* The new '''Text > Convert to Braille''' extension recodes English (or just Latin letters) text to [http://en.wikipedia.org/wiki/Braille Braille] code created for visually impaired people.
* The new '''Render > Alphabet Soup''' extension is a vector rework of Matt Chrisholm's GPLed script [http://www.theory.org/artprojects/alphabetsoup/main.html]. Alphabet Soup randomly mashes glyph-elements together to make exotic looking text.
* The new '''Arrange > Restack''' extension restacks selected objects Z-order, from left to right, top to bottom (or vice versa), with radial outward or inward or by an arbitrary angle, specifying the base point for comparison (top, left, middle, etc.).

==API changes==

While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute <code>needs-live-preview="false"</code> in the <code>effect</code> element in the .inx file of the effect to suppress this checkbox for your effect.

Parameters passed to extensions (via the <param> element) now have a new boolean attribute - <code>gui-hidden</code> to indicate that the parameter should not be represented in the GUI. If all parameters are marked as hidden no GUI is presented for such extension.

All '''.inx''' files are now properly formatted XML files with its own namespace of: <code><nowiki>http://www.inkscape.org/namespace/inkscape/extension</nowiki></code> and a Relax NG schema to define it. More information can be found in the [[Extensions]] Article.

=SVG output=

==Optimized CSS properties==

As a file size optimization, Inkscape does not write into SVG some of the stroke properties if the object has stroke:none and some of the fill properties when it has fill:none. The only situation where this might affect you is if you remove stroke from an object and then turn it back on - the object will get the default stroke instead of the same it had before.

Also, in manually-edited SVG where a parent group has no stroke but sets some stroke properties to be inherited by its descendants, you will need to set stroke property to other than none on the group, and suppress inheritance with stroke:none on those children that don't need it.

Specifically, if stroke:none, the following properties do not get written to SVG:

stroke-width
stroke-linecap
stroke-linejoin
stroke-miterlimit
stroke-opacity
stroke-dasharray
stroke-dashoffset

Note that this does not include marker properties, which means you can still have markers on a path without visible stroke.

If fill:none, the following properties do not get written to SVG:

fill-opacity
fill-rule

==Optimized path data==

In this version, the size of the path data written in the <code>d=</code> attribute of <code>path</code> elements is reduced by about 10%. Inkscape generates the shortest possible path strings by avoiding repeated operators and using relative coordinates (when it helps).

This is controlled by the following attributes in <code>group id="svgoutput"</code> in your preferences.xml file:

* allowrelativecoordinates (default 1) to switch relative coordinates on (1) or off (0)
* forcerepeatcommands (default 0) to force repeating operators (1) or allow use of the more compact representation without repeated operators (0)

=User interface=
==Filters can be disabled==
In order to facilitate editing documents that use lots of SVG filter effects, filter effects can now be disabled for a particular document window by selecting '''View|Display mode|No Filters''' from its menu. This provides an intermediate step between "normal" and "outline" view modes.

The Toggle view command in the Display mode submenu (Ctrl+keypad 5) toggles between the outline view and either regular or no-filters view, depending on which was used most recent.

==Native file dialogs for Windows==
The windows builds of inkscape now have Windows-native file dialogs to keep consistency with other windows applications.

==Clipboard enhancements==

The clipboard used by Inkscape is now system-wide instead of being confined to a single instance of the application. Copied elements are exported to the clipboard using all the available output formats. SVG data can be pasted into other applications supporting one of Inkscape's output formats, and SVG data provided by other applications can be pasted into Inkscape.

If you copy a string that can be interpreted as a hexadecimal color specification, i.e. 2f7ab4 or #014522b0, and then paste it into Inkscape, the fill of the selected objects will change to the given color. This is especially useful when working with HTML pages.

==Masks and clipping paths==

[editable in node tool - johan]

==Stroke width changeable by dragging==

[bbyak]

==Enhanced Tablet Support==

===Input device tool switching===

Tablets and other input devices that report separate hardware are now recognized and current tool and/or settings can be set to switch in response to the physical tool being used.

===Extended input device configuration===

The stock Input Devices dialog has been replaced with a completely redone version that provides a more useful representation of settings. It also contains a simple area for testing different inputs of different devices.

Additionally hardware setup itself has been separated from general settings to allow for easier dynamic switching of settings appropriate to the task at hand.

==Dropper tool==

The confusing icons on buttons in the controls bar of the Dropper tool (pick/assign opacity) are replaced by text labels.

==Swatches==

Hovering over a swatch now shows the name of the swatch in the status bar. This makes it easier for tablet users to identify a swatch by name, as holding a stylus still enough to show a tool tip is difficult.

==Toolbars==

The toolbar icon sizes for the three main toolbars are now separately configurable and to a few different sizes. This allows users to get a smaller UI on certain systems, including Ubuntu.

=Grids, guides, snapping=

==Guides==

There is now an option to treat groups as single objects during conversion to guides (as opposed to converting each object inside the group separately).

==Snapping==
Snapping has been implemented or improved in these areas:
* The '''node tool''' now snaps to any unselected node (cusp or smooth) within the path that's being edited, and to cusp nodes of other paths. It also snaps to the path itself, but only to the stationary segments in between two unselected nodes.
* The object snapper now also allows to snap to the '''page border'''

==Snap indicator==
[mention that it exist, and the different snaps that are indicated]

=Notable bug fixes=

* The '''visual bounding box''' (which is the default bounding box type used by Inkscape) of an object with a filter applied, now includes the expanded area of the filter. For '''single blur filter''' (such as the blur you apply with a slider in the Fill and Stroke dialog), this expands the bounding box by 2.4*radius; although theoretically, blur is infinite, this is the distance at which the opacity of the object drops below the perceptibility threshold of our renderer. For all other filters, the area is expanded by the relative amounts you specify on the "Filter general settings" tab of the Filter Effects dialog.

:Only visual bounding box is affected; if you use geometric bounding box, you will notice no change in most cases. However, the Export bitmap dialog always uses the visual bbox for selection of the export area; this means that you can now export a blurred object to bitmap without any clipping of the blur.

* Several fixes allows Inkscape to correctly render and edit SVG files that use <code>currentColor</code> in objects' style (this includes files created by gnuplot).

= Previous releases =

* [[ReleaseNotes046]]
* [[ReleaseNotes045]]
* [[ReleaseNotes044]]
* [[ReleaseNotes043]]
* [[ReleaseNotes042]]
* [[ReleaseNotes041]]
* [[ReleaseNotes040]]
* [[ReleaseNotes039]]
* [[ReleaseNotes038]]
* [[ReleaseNotes037]]
* [[ReleaseNotes036]]
* [[ReleaseNotes035]]

[[Category:Marketing]]

Release notes/0.47

2008-04-23T15:17:16Z

Mfloryan: /* API changes */ + Extensions schema

=Inkscape 0.47=
'''(not released yet)'''

=Refactoring effort=
[mention the 'main' goal of 0.47 and list which things have been refactored and the benefits/new features/different workflow? --johan]

=Tools=

==Node tool==

* [helper path display, flashing - johan]
* The Node tool can now edit '''clipping paths''' and '''masks''' of objects on canvas, without releasing them. If the selected object has a clipping path and mask, the corresponding buttons on the controls bar of the tool will be enabled; pressing these buttons will display the editable paths or handles of the clippath or mask. A clipping path is stroked green, a mask is stroked blue (the same colors as those used for them in Outline mode).
* Snapping has been improved (more details in Snapping below)
* When dragging a node '''handle with Ctrl''', it now snaps not only to the 15 degree increments starting from 0 and to the original handle direction, but also to the direction of the '''opposite handle''' (if it exists) or of the '''opposite line segment''' (if it is a straight line).
* The behavior of the buttons/shortucts that make a node smooth or cusp has been improved:
:* If a node is already cusp (diamond shaped), pressing Shift+C again on it will retract both its handles. As this works for any number of selected nodes, you can always retract all handles in all nodes by selecting all nodes and pressing Shift+C twice.
:* If a non-smooth node is next to a straight line segment, pressing Shift+S once makes it ''half-smooth'': it now has one handle aligned with that line segment. Another press of Shift+S will expand the second handle as well turning it into a full smooth node. If a node is between two curve segments, Shift+S will expand both handles as before.

==Calligraphy tool ==
Added 4 preset buttons for dip, pen, brush and reed in the toolbox. Clicking one button sets the calligraphic tool with the matching presets.

==Paint Bucket tool==
* Paint Bucket is now more tightly integrated with potrace. As a result, memory and CPU usage on each fill operation have been reduced significantly.

=Live path effects=
== Notable bug fixes and effect changes==
We try to refrain from changing the behavior of LPE's, because it will change appearance in old files when opened in Inkscape¹. But when an effect is really broken, we have to fix it.

[¹ fixme: Shouldn't the above say "it will change editing behaviour in old files" ? If it changes the appearance, then that's a bug: inkscape should always save SVG that represents the appearance, and should display according to the SVG rather than any inkscape:blah annotations. --pjrm 
What is meant is the following. Files with LPEs opened in a random viewer will always look the same, regardless of Inkscape version. However, when viewed in Inkscape, the LPE is recalculated. When LPE behavior changes, the appearance will change. --johan]

* The Pattern Along Path effect used to stretch the pattern across discontinuities. This has been fixed; now it treats a discontinuous path as a group of continuous paths and applied the effect separately to each.

==New effects==
[new: sketch, von koch, knot]

* Perspective paths: Draw an arbitrary path as if viewed in perspective. This is work in progress. Known limitations (among others): It can only use the first perspective that exists in the document defs, and the perspective cannot be adapted interactively yet (the effect must be removed and reapplied after modifying the perspective).

* '''Spiro splines''' are a novel way of defining curvilinear paths [http://www.levien.com/spiro/ developed by Raph Levien]. It takes some getting used to, but for certain tasks (such as lettershape design) Spiros have a clear advantage over Bezier curves. Recently, Spiro support was added to the FontForge font editor; now it is available in Inkscape too, which means you can use all the convenient Inkscape path tools (moving and transforming groups of nodes, node sculpting, etc.) on Spiro paths.

:A Spiro path is defined by a sequence of points, but unlike a regular path with Bezier curves, all Spiro points lie on the path and there are no off-path handles. The curvature of the path is defined entirely by the positions of the points and their types. The path behaves very similar to a springy rod which is forced to pass through the given points and which uses the minimum possible curvature to satisfy the requirement. As such, it feels quite natural and the resulting path is very smooth - not just superficially smooth (i.e. having no cusps), but smooth at a deeper level, which you can achieve with Beziers only after a lot of laborious tweaking.

:To create a Spiro path, select any path and assign the "Spiro spline" path effect to it. There are no parameters. Each node of your path becomes a point of a Spiro path, depending on the type of node:

:* Smooth nodes (those with two collinear Bezier handles; use Shift+S to make a node smooth) become smooth curve points of the Spiro path. Note that the length or direction of the Bezier handles of the source path is ignored; the only thing that matters is their collinearity.

:* Cusp nodes of the source path become corner points of the Spiro path, like free hinges on the springy rod. Between two corner points, the path is always a straight line. To make a node cusp, retract its Bezier handles by Ctrl+click, or press Shift+C and move one of the handles so they are no longer collinear.

:* Half-smooth nodes - those with one Bezier handle collinear with a straight line segment on the other hand - become "left" or "right" points on the Spiro path which behave exactly the same: they sit between a straight line and a curve and enforce that these two segments join smoothly without a cusp. To create such a node, make sure one of the segments is a line (select its ends and press Shift+L), then Ctrl+drag the remaining handle to make it snap to the direction of the straight line segment on the other side, or press Shift+S to lock it to that direction.

:Note that what matters is the actual collinearity of a node's handles, regardless of the node type that the node has in the Node tool; for example, if a node designated as cusp (diamond-shaped) has collinear handles, it will become a smooth curve point of the Spiro path.

:Some configurations of points do not converge and produce wild loops and spirals instead of a smooth curve. According to Raph, "The spline solver in this release is _not_ numerically robust. When you start drawing random points, you'll quickly run into divergence. However, "sensible" plates based on real fonts usually converge." Avoid too sharp changes in direction between points to prevent divergence. Hopefully, the robustness of the algorithm will be improved in future releases.

:For now, to edit Spiro paths viewing the result in real time, you have to use the Node tool; it is recommended to turn off the red highlight of the source path as it is a distraction. The Pen tool does not yet allow you to preview a Spiro as you draw, although you can paste the Spiro effect on the path and see the result as soon as the path is finalized.

:You can always use the Node tool to continue a Spiro path by duplicating and dragging away its end nodes. Also, when you have a Spiro path selected, you can add a new subpath to it with Pen or Pencil if you start drawing with Shift.

==New features==
* The '''Paste Path Effect''' command is enabled to assign the path effect of the clipboard to any number of paths, going recursively into groups if necessary.

* A new command, '''Remove path effect''' removes any path effects from all selected objects, going recursively into groups if necessary.

* Along with the commands to open the path effects dialog and to paste path effects, the three commands were collected in a submenu under Path menu.

* Live path effects can now be assigned to the sides of a 3D box (use Ctrl+click to select individual sides).

* The Pen and Pencil tools now correctly work with paths with LPEs: you can continue such a path or add a new subpath to it by drawing with Shift, all preserving the effect applied to it.

* Path type parameters can now link to existing shapes and text, like clones do. Now it is possible to use text as input for the Pattern Along Path effect for example!

* Lib2geom now has an implementation for SVGEllipticalArc. For Inkscape, this means that it is now possible to directly copy-paste ellipse shapes on path parameters (e.g. 'pattern' in Pattern along Path), without the need to convert the ellipse object to path first. [needs coding and checking]

==Live Path Effect for groups==

LPE can now be assigned to a group. For most LPE, the effect is applied recursively but for Bend Path the result is more powerful : the distortion applies on the whole group.

*Original path of the group can as usual be edited by double-clicking.
*It applies recursively, this means that a LPE can be assigned to groups of groups
*The Effect can be applied definitively with "Convert Object to path"

=Import/Export=
==Corel DRAW files import==

Now Inkscape can import more Corel DRAW files of following types:

* Corel DRAW Compressed Exchange files (CCX)
* Corel DRAW 7-X4 Template files (CDT)
* Corel DRAW Presentation Exchange files (CMX)

Text objects are not supported as of UniConvertor 1.1.1.

==sK1 files import==

Inkscape uses UniConvertor to import sK1 files. Text objects are not supported as of UniConvertor 1.1.1.

==CGM import==

Inkscape uses UniConvertor to import Computer Graphics Metafile (CGM) files. Text objects are not supported as of UniConvertor 1.1.1.

==PDF export==

With PDF export, it is now possible to make the PDF page the size of the entire drawing, instead of the same as SVG page as before by the "Export drawing, not page" checkbox in PDF export options. Also, you can export a single object from a complex document to PDF if you specify the ID of that object in the "Limit export to the object with ID" field; the page of such PDF will be the same size as the bounding box of that object and will show only that object (all others will be hidden).

The same capabilities are available from the command line by using <code>--export-area-drawing</code> and <code>--export-id=ID</code> parameters with <code>--export-pdf</code> (previously, they only worked for PNG export).

=Extension effects=
==New and improved effects==

* The new '''Text > Convert to Braille''' extension recodes English (or just Latin letters) text to [http://en.wikipedia.org/wiki/Braille Braille] code created for visually impaired people.
* The new '''Render > Alphabet Soup''' extension is a vector rework of Matt Chrisholm's GPLed script [http://www.theory.org/artprojects/alphabetsoup/main.html]. Alphabet Soup randomly mashes glyph-elements together to make exotic looking text.
* The new '''Arrange > Restack''' extension restacks selected objects Z-order, from left to right, top to bottom (or vice versa), with radial outward or inward or by an arbitrary angle, specifying the base point for comparison (top, left, middle, etc.).

==API changes==

While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute <code>needs-live-preview="false"</code> in the <code>effect</code> element in the .inx file of the effect to suppress this checkbox for your effect.

All '''.inx''' files are now properly formatted XML files with its own namespace of: <code><nowiki>http://www.inkscape.org/namespace/inkscape/extension</nowiki></code> and a Relax NG schema to define it. More information can be found in the [[Extensions]] Article.

=SVG output=

==Optimized CSS properties==

As a file size optimization, Inkscape does not write into SVG some of the stroke properties if the object has stroke:none and some of the fill properties when it has fill:none. The only situation where this might affect you is if you remove stroke from an object and then turn it back on - the object will get the default stroke instead of the same it had before.

Also, in manually-edited SVG where a parent group has no stroke but sets some stroke properties to be inherited by its descendants, you will need to set stroke property to other than none on the group, and suppress inheritance with stroke:none on those children that don't need it.

Specifically, if stroke:none, the following properties do not get written to SVG:

stroke-width
stroke-linecap
stroke-linejoin
stroke-miterlimit
stroke-opacity
stroke-dasharray
stroke-dashoffset

Note that this does not include marker properties, which means you can still have markers on a path without visible stroke.

If fill:none, the following properties do not get written to SVG:

fill-opacity
fill-rule

==Optimized path data==

In this version, the size of the path data written in the <code>d=</code> attribute of <code>path</code> elements is reduced by about 10%. Inkscape generates the shortest possible path strings by avoiding repeated operators and using relative coordinates (when it helps).

This is controlled by the following attributes in <code>group id="svgoutput"</code> in your preferences.xml file:

* allowrelativecoordinates (default 1) to switch relative coordinates on (1) or off (0)
* forcerepeatcommands (default 0) to force repeating operators (1) or allow use of the more compact representation without repeated operators (0)

=User interface=
==Filters can be disabled==
In order to facilitate editing documents that use lots of SVG filter effects, filter effects can now be disabled for a particular document window by selecting '''View|Display mode|No Filters''' from its menu. This provides an intermediate step between "normal" and "outline" view modes.

The Toggle view command in the Display mode submenu (Ctrl+keypad 5) toggles between the outline view and either regular or no-filters view, depending on which was used most recent.

==Native file dialogs for Windows==
The windows builds of inkscape now have Windows-native file dialogs to keep consistency with other windows applications.

==Clipboard enhancements==

The clipboard used by Inkscape is now system-wide instead of being confined to a single instance of the application. Copied elements are exported to the clipboard using all the available output formats. SVG data can be pasted into other applications supporting one of Inkscape's output formats, and SVG data provided by other applications can be pasted into Inkscape.

If you copy a string that can be interpreted as a hexadecimal color specification, i.e. 2f7ab4 or #014522b0, and then paste it into Inkscape, the fill of the selected objects will change to the given color. This is especially useful when working with HTML pages.

==Masks and clipping paths==

[editable in node tool - johan]

==Stroke width changeable by dragging==

[bbyak]

==Enhanced Tablet Support==

===Input device tool switching===

Tablets and other input devices that report separate hardware are now recognized and current tool and/or settings can be set to switch in response to the physical tool being used.

===Extended input device configuration===

The stock Input Devices dialog has been replaced with a completely redone version that provides a more useful representation of settings. It also contains a simple area for testing different inputs of different devices.

Additionally hardware setup itself has been separated from general settings to allow for easier dynamic switching of settings appropriate to the task at hand.

==Dropper tool==

The confusing icons on buttons in the controls bar of the Dropper tool (pick/assign opacity) are replaced by text labels.

==Swatches==

Hovering over a swatch now shows the name of the swatch in the status bar. This makes it easier for tablet users to identify a swatch by name, as holding a stylus still enough to show a tool tip is difficult.

=Grids, guides, snapping=

==Guides==

There is now an option to treat groups as single objects during conversion to guides (as opposed to converting each object inside the group separately).

==Snapping==
Snapping has been implemented or improved in these areas:
* The '''node tool''' now snaps to any unselected node (cusp or smooth) within the path that's being edited, and to cusp nodes of other paths. It also snaps to the path itself, but only to the stationary segments in between two unselected nodes.
* The object snapper now also allows to snap to the '''page border'''

==Snap indicator==
[mention that it exist, and the different snaps that are indicated]

=Notable bug fixes=

* The '''visual bounding box''' (which is the default bounding box type used by Inkscape) of an object with a filter applied now includes the expanded area of the filter. For '''single blur filter''' (such as the blur you apply with a slider in the Fill and Stroke dialog), this expands the bounding box by 2.4*radius; although theoretically, blur is infinite, this is the distance at which the opacity of the object drops below the perceptibility threshold of our renderer. For all other filters, the area is expanded by the relative amounts you specify on the "Filter general settings" tab of the Filter Effects dialog.

:Only visual bounding box is affected; if you use geometric bounding box, you will notice no change in most cases. However, the Export bitmap dialog always uses the visual bbox for selection export area; this means that you can now export a blurred object to bitmap without any clipping of the blur.

* Several fixes allowed Inkscape to correctly render and edit SVG files that use <code>currentColor</code> in objects' style (this includes files created by gnulpot).

= Previous releases =

* [[ReleaseNotes046]]
* [[ReleaseNotes045]]
* [[ReleaseNotes044]]
* [[ReleaseNotes043]]
* [[ReleaseNotes042]]
* [[ReleaseNotes041]]
* [[ReleaseNotes040]]
* [[ReleaseNotes039]]
* [[ReleaseNotes038]]
* [[ReleaseNotes037]]
* [[ReleaseNotes036]]
* [[ReleaseNotes035]]

[[Category:Marketing]]

Extensions

2008-04-18T15:10:18Z

Mfloryan: /* RadioButton example */

This page is intended as a guide for providing new extensions for Inkscape. Currently the majority of extensions are provided as python scripts.

==Extension types==
The following extension types exist for Inkscape:
* '''input'''
* '''output'''
* '''effect'''
* '''print'''
* '''''path-effect''''' - path effects are '''not''' currently implemented as extension but there is intention to migrate those over as entensions

==Extension implementation==
* Internal
** C++ implementation (directly in code)
* External
** '''scripts''' - written in '''python''', '''perl''' or as system (console) scripts
** '''xslt transformations'''
** '''plugins''' - ''not fully implemented yet''

==Parameters==
Extensions can be supplied with values obtained through easily definable parameters. Inkscape provides the basic GUI for user input. The following parameters are supported:
* '''integer'''
* '''string'''
* '''float'''
* '''boolean'''
* '''enum'''
* '''optiongroup'''
* '''colour'''

For the sake of the UI there are also the following two parameters that do not provide data to the extension but alter the user input GUI.
* '''description'''
* '''notebook'''

==Extension Definition File (INX)==
All extensions are defined through Inkscape Extension Definition Files (.inx) which are XML files in the <pre>http://www.inkscape.org/namespace/inkscape/extension</pre> namespace and described by the [http://relaxng.org/ Relax NG] available [here]
===Structure===
===Examples===
====RadioButton example====
The following mark-up:
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<inkscape-extension xmlns="http://www.inkscape.org/namespace/inkscape/extension">
<_name>RadioButton example</_name>
<id>org.inkscape.effect.radiobuttontest</id>
<param name="radio1" type="optiongroup" _gui-text="Select option: ">
<option value="string1">translatable string 1</option>
<option value="string2">string 2</option>
<option value="string3">test 3!</option>
</param>
<param name="radio2" type="optiongroup" _gui-text="Select second option: ">
<option value="string11">string1</option>
<option value="string22">string2</option>
<option>test3!</option>
</param>
<effect>
<object-type>all</object-type>
<effects-menu>
<submenu _name="Developer Examples"/>
</effects-menu>
</effect>
...
</inkscape-extension>
</pre>
Will result in the following GUI being created:

[[Image:Extensions-radiobutton_gui_example.png]]

===i18n===
To allow the .inx files to fit snugly into Inkscape's i18n infrastructure some XML elements and attributes are prefixed with an underscore (_) character to indicate that the containing text should be marked for translation.

File:Extensions-radiobutton gui example.png

2008-04-18T15:09:57Z

Mfloryan:

Extensions

2008-04-18T15:09:36Z

Mfloryan: /* RadioButton example */

This page is intended as a guide for providing new extensions for Inkscape. Currently the majority of extensions are provided as python scripts.

==Extension types==
The following extension types exist for Inkscape:
* '''input'''
* '''output'''
* '''effect'''
* '''print'''
* '''''path-effect''''' - path effects are '''not''' currently implemented as extension but there is intention to migrate those over as entensions

==Extension implementation==
* Internal
** C++ implementation (directly in code)
* External
** '''scripts''' - written in '''python''', '''perl''' or as system (console) scripts
** '''xslt transformations'''
** '''plugins''' - ''not fully implemented yet''

==Parameters==
Extensions can be supplied with values obtained through easily definable parameters. Inkscape provides the basic GUI for user input. The following parameters are supported:
* '''integer'''
* '''string'''
* '''float'''
* '''boolean'''
* '''enum'''
* '''optiongroup'''
* '''colour'''

For the sake of the UI there are also the following two parameters that do not provide data to the extension but alter the user input GUI.
* '''description'''
* '''notebook'''

==Extension Definition File (INX)==
All extensions are defined through Inkscape Extension Definition Files (.inx) which are XML files in the <pre>http://www.inkscape.org/namespace/inkscape/extension</pre> namespace and described by the [http://relaxng.org/ Relax NG] available [here]
===Structure===
===Examples===
====RadioButton example====
The following mark-up:
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<inkscape-extension xmlns="http://www.inkscape.org/namespace/inkscape/extension">
<_name>RadioButton example</_name>
<id>org.inkscape.effect.radiobuttontest</id>
<param name="radio1" type="optiongroup" _gui-text="Select option: ">
<option value="string1">translatable string 1</option>
<option value="string2">string 2</option>
<option value="string3">test 3!</option>
</param>
<param name="radio2" type="optiongroup" _gui-text="Select second option: ">
<option value="string11">string1</option>
<option value="string22">string2</option>
<option>test3!</option>
</param>
<effect>
<object-type>all</object-type>
<effects-menu>
<submenu _name="Developer Examples"/>
</effects-menu>
</effect>
...
</inkscape-extension>
</pre>
Will result in the following GUI being created:
[[Image:Extensions-radiobutton_gui_example.png]]

===i18n===
To allow the .inx files to fit snugly into Inkscape's i18n infrastructure some XML elements and attributes are prefixed with an underscore (_) character to indicate that the containing text should be marked for translation.

Extensions

2008-04-18T15:04:43Z

Mfloryan: initiated new page. Hopefuly more will come here

This page is intended as a guide for providing new extensions for Inkscape. Currently the majority of extensions are provided as python scripts.

==Extension types==
The following extension types exist for Inkscape:
* '''input'''
* '''output'''
* '''effect'''
* '''print'''
* '''''path-effect''''' - path effects are '''not''' currently implemented as extension but there is intention to migrate those over as entensions

==Extension implementation==
* Internal
** C++ implementation (directly in code)
* External
** '''scripts''' - written in '''python''', '''perl''' or as system (console) scripts
** '''xslt transformations'''
** '''plugins''' - ''not fully implemented yet''

==Parameters==
Extensions can be supplied with values obtained through easily definable parameters. Inkscape provides the basic GUI for user input. The following parameters are supported:
* '''integer'''
* '''string'''
* '''float'''
* '''boolean'''
* '''enum'''
* '''optiongroup'''
* '''colour'''

For the sake of the UI there are also the following two parameters that do not provide data to the extension but alter the user input GUI.
* '''description'''
* '''notebook'''

==Extension Definition File (INX)==
All extensions are defined through Inkscape Extension Definition Files (.inx) which are XML files in the <pre>http://www.inkscape.org/namespace/inkscape/extension</pre> namespace and described by the [http://relaxng.org/ Relax NG] available [here]
===Structure===
===Examples===
====RadioButton example====
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<inkscape-extension xmlns="http://www.inkscape.org/namespace/inkscape/extension">
<_name>RadioButton example</_name>
<id>org.inkscape.effect.radiobuttontest</id>
<param name="radio1" type="optiongroup" _gui-text="Select option: ">
<option value="string1">translatable string 1</option>
<option value="string2">string 2</option>
<option value="string3">test 3!</option>
</param>
<param name="radio2" type="optiongroup" _gui-text="Select second option: ">
<option value="string11">string1</option>
<option value="string22">string2</option>
<option>test3!</option>
</param>
<effect>
<object-type>all</object-type>
<effects-menu>
<submenu _name="Developer Examples"/>
</effects-menu>
</effect>
...
</inkscape-extension>
</pre>
===i18n===
To allow the .inx files to fit snugly into Inkscape's i18n infrastructure some XML elements and attributes are prefixed with an underscore (_) character to indicate that the containing text should be marked for translation.

ExtensionsSystem

2008-04-18T14:44:18Z

Mfloryan: /* Key Requirements */

This is a copy of the original spec for the extensions system. Part of this was accepted into the Sodipodi codebase.
This might be replaced by a more full-fledged plugin system in Inkscape at some point. The original patch is at
http://developer.osdl.org/bryce/patches/sodipodi/extension_02/

== Sodipodi Simple Extension System ==

This specification describes a design for implementing extension
capabilities in Sodipodi, a 2D vector-based drawing application that
uses the Scalable Vector Graphics (SVG) file format and the GNOME
graphical user interface system.

The concept for this extension system is simple: The user selects
some drawing elements within Sodipodi, and then chooses an extension
program to run on them. Sodipodi renders the textual SVG code for the
elements and then pipes this data to the stdin of the extension
program. The extension performs its operations and prints the
resulting SVG text to its stdout, which Sodipodi captures, parses, and
displays. This can either be added to a new document or the same
document, and if the latter, it can either replace the original
selections or be added atop it.

The idea of "pipes" should resonate well with experienced UNIX users,
because of the value they provide in general day-to-day use at the
commandline. This approach allows small general purpose tools to be
quickly combined to perform some specific purpose.

This is not a sophisticated, ultra-powerful, or high-performance
system, but it is not intended to be so. The primary objectives this
design seeks to achieve are simplicity of interface, language
independence, and maximum flexibility. We aim to permit even neophyte
programmers to be able to quickly throw together a little script to
conduct some necessary transformation, without needing to first learn
some new programming technologies. We also aim to enable more
experienced software engineers to augment Sodipodi's functionality
in a modular fashion that is independent of core development. And
further, we hope that by allowing extension-writing to be done in a
multiplicity of languages that we can take advantage of powerful
functionalities already available via other languages (such as Perl's
wealth of CPAN modules, or Java's XML manipulation technologies, or
C++-based graphic manipulation libraries). This system may not be
able to intrinsically meet 100% of the desires one would wish for in a
powerful C-based plug-in system, but it hopefully will meet a sizable
chunk of the needs, and should be able to do so with minimal impact on
Sodipodi's internal development.

=== Key Requirements ===
* Extensions can be added to sodipodi without compiling it
* Extensions can be invoked from the GUI Sodipodi
* Extensions can be invoked from the commandline Sodipodi
* Extensions can be organized into one or more menus and toolboxes
* Quantity of extensions shall not delay program initialization
* Extensions (incl init) shall not run in background
* Authoring of an extension should be straightforward & easy to grok
* Extensions shall operate on entire SVG documents
* Extensions shall operate on fragments of SVG documents
* Extensions shall operate on individual SVG entities
* It shall be possible to write extensions in most any programming language

=== Architecture of a Compliant Extension ===

The extension is implemented as a commandline filter that takes some
arbitrary SVG through stdin, conducts some operations, and returns
processed SVG through stdout.

The benefit of the stdin/stdout approach is that it allows them to be
pipe chained. For example, if one wished to modify a stock diagram
of a data center lab by indicating status of particular machines with
color, one might approach it via a complex commandline such as:

$ cat lab_diagram.svg \
| svg_highlight --stroke-color=yellow --id=rack_24 --id=rack_42 \
| svg_highlight --stroke-color=red --stroke-width=2px --id=rack_13 \
| svg_delete --id=main_border --id="legend_*" \
| svg_change_text --id=title_text --sed="s[[/Lab]] Diagram[[/Rack]] Status/" \
| sodipodi -z --export-png lab_diagram__rack_status.png

Extensions can also be run at the commandline as stand-alone filter
programs. They are able to take a saved Sodipodi SVG file as input
and emit a changed files with exactly the same effects as if it were
invoked on the entire document within the Sodipodi GUI.

By being runnable from the commandline, these filters have a much larger
applicability because they can be useful tools in their own right. For
instance, the above example could be tied to output from a status
sampler program such as Nagios to provide a dynamic graphic of the data
center's machine status.

Each extension has a set of extension-specificit 'parameters'
associated with it. These parameters are used to control the
extension's behavior. Each parameter is indicated via gnu-style,
double-dash option syntax (i.e., --blah --foo=bar).

If Sodipodi is running in GUI mode and some parameters for an invoked
extension require or permit user specification at runtime, then a GUI
dialog box will be displayed with the appropriate widgets shown to
allow data specification by the user.

The extension also accepts one or more filenames on the commandline.
If any filenames are provided, the extension will open and process those
files the same as if they'd been cat'ed to STDIN. (This is the standard
behavior for Perl scripts when using the common `while (<>) {` syntax.)

The extension is required to provide an exit status value when it
completes. These are as follows:

<0 - Extension-specific error
0 - Success
1 - General failure
2 - Memory error
3 - File I[[/O]] error
4 - Math error
5 - Input not understood (not valid SVG?)
6 - Could not operate on any objects in this data stream
7-127 - Reserved

If an extension returns any error value other than 0, it can also
print a textual error description (or stream) to STDERR. This could
be used by Sodipodi to display error information to the user through a
GUI or stderr, and/or recorded into an error log.

In any case where the return value is non-zero, anything emitted to
STDOUT is discarded and ignored.

=== Parseable Error Language ===

If the first three characters of the STDERR stream match the characters
'#%%', then the stream is considered to be 'parseable error language'
text. The remainder of the line following the '#%%' signifier is used
to specify the format and/or parsing options for the stream. For
instance, if the first line matches '#%% INI', then the stream will be
interpreted as a line-oriented list of key=value pairs separated by
[sections]. The range of options supported by Sodipodi will be limited
(assuming any are available at all), so extension developers should take
care to select syntaxes that are well supported.

This 'parseable error language' system is completely optional for
extensions, and is not recommended for typical extensions. It is
provided as a mechanism for allowing better interaction between an
extension and its caller than is available simply through error codes.
For instance, this could allow returning a list of per-entity error
messages, that Sodipodi could pop-up

For example, it could allow returning a long list of
error messages, with one message declared the "main error" and the
others provided for reference; or it could allow returning per-entity
error messages, that the calling application could display in
association with those objects; or it could permit returning error
information for input dialogs (e.g., if the user has provided invalid
input data), allowing them to re-edit and re-run the extension.

=== Extension Registration ===

Extension registration is controlled and cached by Sodipodi and occurs
automatically when Sodipodi is started up.

Each extension is housed in its own subdirectory and is composed of
the following files:

* Toolbutton image
* Config file (XML)
* Main executable
* Additional code files (optional)
* README, COPYING, AUTHORS, Changes, etc.

The process of installation of these files is left to the
responsibility of the extension in question. For instance, they could
be installed via RPM, make, or even generated by the script itself
(e.g., like 'shar'). If the extension does not provide a toolbar
image or config file, generic defaults will be used.

Sodipodi maintains a global XML config file with information about
each extension, taken from the extension's config file. During
program initialization, it will look in the various places where
Sodipodi extensions can be installed, for any config files with
timestamps newer than the last time it loaded them. If it finds such
a file, it will re-parse that file and load it in place of the old
data. The reason for using this procedure is because it is believed
that loading and parsing a single config file, coupled with simple
directory checking operations will be significantly faster than
parsing individual extension config files during each activation.

In the master config file, each extension is registered with the
following information:

* Extension title
* State (active / inactive / etc.)
* Description
* Path (e.g., /usr/share/sodipodi/extensions/foobar/)
* Toolbutton image filename
* Executable filename
* Help document filename
* List of parameters with type and default value
* Class(es) of data it acts on (text, nodes, etc.)
* Whether data is replaced, added, or added to new doc
* Toolbox menu location
* Toolbox menu state (closed, etc.)
* Timestamp of last loading

Sodipodi includes some information about extensions that are not
necessarily present in the extension config file. In addition, the
extension may incorporate other information into its config file that
Sodipodi may ignore and not load into the master config.

Overriding of some of this information is optionally permitted via the
user's preferences file. These overrides are always preserved (on a
per-user basis) even if the global config file is regenerated. This
capability is included to permit, for instance, per-user
reorganization of the toolbox menu structure. The management of this
preference information is outside the scope of this document.

The benefit of loading from a global config file is that generally one
need only perform a single file-parse step during program
initialization, which should help avoid excessive paging, etc. It is
particularly advantageous if one is loading a large number (hundreds)
of plugins, or are running in a very tight-memory situation.

Extensions are not allowed to modify this global config file directly.
They instead can update their personal config file (during
installation or upgrades), and Sodipodi will re-parse these as
appropriate. Sodipodi will not make any changes to the individual
extension's config file directly. In any case where config
information needs to be stored in the extension's config file,
Sodipodi will supply this information through the normal
commandline-option-based interface, and the extension will be
responsible for making the appropriate alterations to its config file.

A command will also be provided within Sodipodi's menubar to permit
regeneration of the master config file from all of the extension
configs. This command will also be available as a commandline option
for the sodipodi executable.

# Remaining Questions
#
# What format/schema is the master config file?
#
# What API (i.e., std cmdline option) should be used to specify
# config values to add to the extension's config file?

=== Extension Operation ===

When an extension is invoked from Sodipodi, the currently selected SVG
elements are serialized into textual SVG document fragments and piped
to the extension executable's stdin. Sodipodi receives the resulting
stdout from the pipe in textual SVG form. This is reparsed into
internal data elements by a method in repr-io.c in Sodipodi. If this
parsing is successful and results in valid objects, the original
elements are deleted and replaced with the ones generated by the
script.

The operations performed by the extension are treated as a single
conceptual "change" for purposes of bookkeeping undo/redo, cache, etc.

Each extension specifies the classes and quantities of SVG elements it
can operate on in its config file. Sodipodi could use this
information, for example, to determine when to "grey out" and
invalidate buttons of extensions that cannot be used on the current
selection. Note that the extension mustn't assume that the data it is
passed is validated to meet these criteria before being called, and
should always perform data filtering and validation itself, on the
data it is given; consider for instance a case where the extension is
used on the commandline on a SVG file directly.

Any valid SVG element (line, circle, rectangle, text, etc.) recognized
by Sodipodi may be used for the class specification. In addition,
individual nodes and the document itself (with no contents) are valid
types for extensions to operate on. A method in sp-obect-repr.c will
be used to get a dynamic list of element classes.

Extensions may specify classes higher in the inheritance chain, so
that for example one can specify that it operates on 'shapes' in
general, including rects, lines, spirals and whatever new types there
may be added in future.
Quantities can be specified as ranges and/or comma separated lists,
for instance, "1+", "2", "2,4,6,8,10", or "2,4-42".

SVG DOM syntax is used to specify the naming/inheritance. Sodipodi
will implement some DOM name queries to support this.

Note that as of this writing, Sodipodi does not implement
button-invalidation, but something like Qt 'actions' may be
implemented to support this in the future.

# Remaining Questions
#
# Is it possible to pass a nodal entity and specify a subset of its
# nodes to operate upon? How?

=== Extension Interface Specification ====

Some extensions can act directly on the elements selected, but many
will require further information to quantify & specify the parameters
that control their operation. For example, an extension that
stretches elements would need to know what percentage to stretch the
object. Another might need to know a color to use, or replacement
text for search and replace, etc.

Rather than require each extension to implement GUI behaviors
independently (using Gtk bindings, Tk, etc.) this design includes
provision for extensions to provide interface "descriptions", which
Sodipodi can parse and use to dynamically generate dialogs for the
extension. In addition to simplifying the work facing extension
authors, this will provide more consistency of interface to end users,
and avoid a class of portability issues, should one wish, for example,
to use the scripts on a non-UNIX O[[/S]].

This interface description language must provide easy specification of
the widgets and text for the dialog, such as buttons, input boxes,
color/alpha selectors, dropdown boxes, radio buttons, checkboxes,
selection lists, gradient boxes, preview thumbnails, tree displays
(e.g., for XML editing, etc.). It must allow precise positioning and
sizing of the widgets, but also allow auto-layout (so that one can
simply provide a list of text+widget_type pairs and the widgets placed
onto the dialog in a running list. This way, extension authors can
specify the dialogs with a minimum of fuss, but can also have more
exact control over the layout of the form if they wish.

Parameter settings are not expected to be kept from one invocation of
the extension to the next. If it is found to be necessary, it should
be provided via Sodipodi, rather than by the extension.

# Remaining Questions:
#
# Should the interface definition be taken from config file
# or queried from the script?
#
# What already-existing interface abstraction languages exist?
#
# How would multi-dialog interfaces be implemented?

=== Extension Examples ===

The following cases are provided as "use cases" to help conceive the
way the extension system should/could work. It should be clear that
some of these functions, while of obvious utility to certain
userbases, are too application specific to be worth incorporating into
Sodipodi's core.

Spellcheck: Checks spelling of text in document and changes color of
misspelled words to red. This would be invaluable if one is producing

Translate: Converts selected text into alternative language using
separate translation application.

Align_to_grid: Adjusts all selected elements to line up to the
document grid. Resizes objects so that all corners touch on grid
corner points.

Data_center_status: Queries database of computer hardware and
generates a map of the machine room using color to indicate state of
computer racks.

Fractalize: Changes a nodal line or shape's border to be
roughened using fractals. This could be useful for creation of
realistic-looking coastlines in a map.

Weave: Takes two overlapping curved lines and "weaves" them to
resemble a scroll-work rope such as is common in Celtic art.

-- Bryce W. Harrington

[[Category:Wiki Attic]]

Free Desktop Graphic Suite

2008-04-07T14:22:15Z

Mfloryan:

Common interface for graphic programs on the free desktop.

Many artists use several applications in their workflow.
This includes using one program for photo editing, one for illustration and one for page layout.
To ease the user experience for someone using these apps, consistency in wording, looks and similar working tools needs to be adressed.

The three programs that will be adressed are:
* GNU Image Manipulator Program aka GIMP (bitmap image editing)
* Inkscape (scalable graphics illustration)
* Scribus (page layout)

[[Common dialogs]]

[[Tool consistency]]

'''Resources that can be shared:'''
* Patterns (PNGs)
* Gradients (SVGs)
* Palettes (We need a standard here.) (suggestion: .xml format, based on .ai format (each text line with each colour name and its rgb, cmyk or whatever))
* Clipart (SVG[[/PNG]])
* Icons
* Cursors
* Color Management
* Fonts
* Symbols
* Filters

To help manage these resources it would probably be wise to try and incorporate some kind of Thumbnail Browser into any such suite. Unfortunately there is no obvious choice of cross platform and open source Thumbnail browser.

[[Feature Requests]]

There are many features in the GIMP that Inkscape will want to copy such as the Dock Widgets for managing Palettes.

There are also some enhancements to the GIMP like this [http://bugzilla.gnome.org/show_bug.cgi?id=133030 request for a standard toolbar] that would be helpful for Inkscape users.

'''Links'''
* [http://www.nabble.com/Desktop-f822.html Open Source Desktop Forum] - a large forum hosted by [http://www.nabble.com Nabble] on big open source desktop projects such as [http://www.nabble.com/Gnome-f1226.html Gnome], [http://www.nabble.com/Xfce-f830.html Xfce], [http://www.nabble.com/Rox-f827.html Rox], [http://www.nabble.com/Etoile-f823.html Etoile].

* [http://software.newsforge.com/software/05/02/02/215259.shtml?tid=75&tid=131&tid=132 Article on free graphics software integration]

* [http://www.osnews.com/story.php?news_id=9658 '''Achieving higher consistency between OSS graphics applications''' - Bryce Harringtons article on the issue]

* [http://developer.gnome.org/projects/gup/hig/2.0/ Gnome Human Interface Guidelines]

* [http://usability.kde.org/ KDE Usability project]

* http://www.openusability.org/

* http://www.freedesktop.org/

* http://developer.gimp.org/standards.html

* [http://www.freedesktop.org/wiki/Standards_2ficon_2dtheme_2dspec Unified icon spec on freedesktop.org]

* http://openclipart.org/

[[Category:Developer Discussion]]
[[Category:Needs Work]]

Compiling Inkscape on Windows 32-bit

2008-04-03T19:53:47Z

Mfloryan: /* Getting The Compiler & Libraries */ updated libs version

See the [http://sourceforge.net/tracker/index.php?func=detail&aid=847856&group_id=93438&atid=604308 Win32 Build ticket] for some info.

=== Inkscape under Windows ===

Inkscape was originally written for Linux, but has been ported to other platforms, including Windows, through the work of a number of dedicated developers.

You can get pre-built binaries of the Windows releases (both stable and development) from the [http://www.inkscape.org/download/?lang=en Inkscape download page]

=== Building Your Own Binary ===
As well as getting a pre-built binary, you can also build your own. You may do this for fun, to learn about programming, or to help test or improve Inkscape.

Several steps are required to build your own binary, as follows;
* You will need to download and install the MinGW compiler
* You will also need the supporting libraries used by Inkscape
* A recommended step is to download and install the TortoiseSVN program to help manage source files and patching
* You need to download the source code and possibly apply patches if bug testing

==== Getting The Compiler & Libraries ====

Ishmal provides a complete set of compiler and library files on his website. You can get all packages from http://inkscape.modevia.com/win32libs/.

Before you download, check for the last versions. As of '''April 3 2008''' those are:
* the mingw compiler version 4.2 http://inkscape.modevia.com/win32libs/mingw-4.2.1-071022-dw2.7z
* other libraries http://inkscape.modevia.com/win32libs/devlibs-2.12-080403.7z

The configuration files expect the packages in specific directories:
* the compiler C:\MINGW (referenced by mingwenv.bat)
* other libraries C:\DEVLIBS (referenced in build.xml used by buildtool)

==== Getting The Inkscape Source ====
The best way to get the source is straight from the SVN repository using the TortoiseSVN program. Follow these steps;

'''''Setting up a local source repository:'''''
* Get TortoiseSVN from http://tortoisesvn.net/downloads
* Install Tortoise SVN.
* Once Tortoise is installed, make a working folder wherever you want.
* Inside the working folder, right click and select ''TortoiseSVN'' -> ''Create repository here''. This will make a bunch of folders inside your working folder.
* Now make another folder in the working folder called 0.46branch or whatever else you'd like to call it. This will hold the source files.

'''''Getting the source:'''''
* Enter the folder you created for the source files. Right click and select ''SVN Checkout''.
* Enter the URL for the source code you want;
** For the 0.46 release branch, use https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/RELEASE_0_46_BRANCH/ (This branch of the source is frozen for the 0.46 release. New features are not allowed in order to focus on bug fixing. This is what you need to test for bugs in the 0.46 release.)
** For the 0.47 development branch (trunk), use https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/ (This branch of the source is for ongoing development and includes new and experimental features not in the 0.46 release branch. It is slowly diverging from the 0.46 release branch, thus becoming progressively less useful for testing bugs in the 0.46 release.)
* TortoiseSVN will now download the source files, which are just over 30Mb.

'''''Notes:'''''
* You can also get a zipped up version of the trunk (0.47 dev) from Ishmal's site - http://inkscape.modevia.com/svn-snap/

==== Patching The Source Code ====

'''''Using TortoiseSVN:'''''

Tortoise makes patching quite easy. Follow these steps;

1. Find your patch. Windows Patches to the main SVN are now being kept in a folder under your main working directory called ''packaging\win32\patches''. If you download or make a subsequent patch, put it in this directory to keep things orderly. It should be called {patchname}.patch or {patchname}.diff

2. Right click on the patch, and select ''TortoiseSVN'' -> ''Apply Patch...''. Because the Windows patches are kept a little tucked away, Tortoise will probably give a message; '''The path {working directory}\packaging\win32\patches seems not to match the paths in the patchfile. But Tortoise found the path {working directory} matches it better. Do you want to use the suggested path instead?''' Click ''Yes'' to proceed.

3. Now comes the actual patching process. See the Tortoise website for an explanation of how to use the merge tool - http://tortoisesvn.net/docs/release/TortoiseMerge_en/tmerge-dug.html#tmerge-dug-open-view (see also the following pages)

4. Once patched, you will now notice that the patched file has a red exclamation rather than a green tick, as do its parent folders. This signifies that it has been altered from the SVN version, and helps you find altered files really quickly.

5. If you want to go back to the SVN version you originally ''checked out'', simply right click on an individual file or a whole folder and select ''TortoiseSVN'' -> ''Revert''. This will bring up a list of files that can be reverted. If you only selected one file, only that will be available to revert. If you selected a folder, all the modified files in that folder will be available to revert. Tick only those you wish to revert to the SVN version last checked out.

'''''Notes:'''''
* When applying several patches at once, you will possibly find that some patches update the same code modules. This is normal, and Tortoise can help you compare files and resolve conflicts. See the [http://tortoisesvn.net/docs/release/TortoiseMerge_en/tmerge-dug.html#tmerge-dug-open-view link mentioned above] to learn more.
* Sometimes conflicts are not able to be resolved using Tortoise, and you will need to edit the files by hand. Don't worry, you can always ''revert'' the files if you make a mistake. A good text editor to help is Notepad 2 - http://www.flos-freeware.ch/
* If you edit the source files yourself, Tortoise will register that the files are changed with an exclamation mark. To create your own patch from a changed file, right click on the ''src'' directory folder that contains your changed file, then select ''Tortoise SVN -> Create Patch''. Now tick only the file/s you edited and save the patch file. This can be posted to a bug report as a test, and possibly committed to SVN if your patch works.

'''''Using the GNU patch program:'''''

For those who love the command line, you can patch the hard way using the GNU patch program.

* Download the program from here - http://gnuwin32.sourceforge.net/packages/patch.htm
* Put the patch program wherever you like, as it works independently from the compiler.
* If the patch file refers to the location in its header, put it in the /src directory and then patch, otherwise put it in the same directory as the file to be patched
* In a command window, type something like the following;
...>patch --binary {''modulename''}.cpp {''modulename''}.cpp.patch
* You should now have a patched code module to copy back to the same spot in the source tree.
* The ''--binary'' switch is only necessary if the files contain the wrong sort of line endings. The [http://gnuwin32.sourceforge.net/packages/patch.htm GnuWin32 Patch page] notes the following; ''"On MS-Windows, the patch file must be a text file, i.e. CR-LF must be used as line endings. A file with LF may give the error: "Assertion failed, hunk, file patch.c, line 343," unless the option '--binary' is given."''

==== Building The Binary ====

Before you begin, it might be an idea to temporarily lower the level of any over zealous security software, screen savers or other background programs that chew a lot of processor power when the computer is not attended. These programs can interfere with the build process, and cause you to have to start again.

'''''Doing A New Build'''''

You will need to open a command window (DOS prompt) to build the binary. Go to the Start Menu, select Run, and then type command (or cmd). Now you need to step into the Inkscape source directory:
...\> cd ...\inkscape

Firstly run the batch file that sets up the MinGW environment variables
...\> mingwenv.bat
You can usually just type mingwenv (enter) and Windows will execute the batch file.

Now, build the build tool:
...\> g++ buildtool.cpp -o btool
or, if you get errors about gettimeofday:
...\> g++ -DNEED_GETTIMEOFDAY buildtool.cpp -o btool

Now you can start the build process by simply running btool.
...\> btool

Grab a coffee and find something else to do. On an AMD-64 3000+ 1Gb it takes about 70 minutes, but your mileage may vary. The build process can normally continue in the background while you're doing other stuff on your PC.

If everything went well, you should now have you fresh Inkscape in the ...\Inkscape directory.

'''''Re-building after modifying source modules'''''

If you've already built the source once and done a few changes to source code files, you can do a quick rebuild using many of the files already compiled in the ''build'' directory. Only those that need to be rebuilt will be, and the ''btool'' program automatically figures that out. It will then 'link' the relevant files together and copy them into the ''inkscape'' directory.

To do a quick rebuild, simply go to the directory that contains the source and do the following;

* Delete or rename the ''inkscape'' directory, which contains the previous fully built and linked version of Inkscape
* Now open a command window and run the following;
...> mingwenv
...> btool
* Ishmal's build tool should now rebuild the individual files that have changed, along with any extra 'dependencies' these might require. If you've only applied one new patch, it can be done in less than 5 minutes!

'''''Note:''''' It is best not to do a quick rebuild if you have changed the version of libraries in C:\DEVLIBS. This can cause problems, as the files in the ''build'' directory incorporate functions from these libraries, which can change significantly between library versions. You will need to rebuild from scratch (see below).

'''''Rebuilding From Scratch'''''

To rebuild from scratch, you need to clean out any build files. First of all, if you want to keep the previously built version, rename the ''inkscape'' directory. Now open a command window and run the following;
...> mingwenv
...> btool clean
...> btool

==== Dealing With Build Errors ====
Feel free to add any questions or answers you have in here;

'''Q''' - My firewall software (Comodo's Defense+ component or similar) stopped the process continuing to the next step in the build, because I wasn't there to permit an action and it timed out. What can I do?

'''A1''' - The best thing is to disable stuff like Defense+ (put it in learning mode works) because it will stop any process that is not approved, and building makes new files which can't be approved before they're built. Disabling Comodo's Defense+ does not disable your firewall, either inbound or outbound, but just the part that scans every application for suspicious operations. Other firewalls etc may vary.

'''A2''' - If that doesn't suit, often you can simply run btool again and wait for Defense+ (or similar) to ask for approval for the process, and it will then continue as normal with the build. But remember that approving all the processes involved in the build process once doesn't mean they will all slip through next time.

'''A3''' - This is the more complex way to continue, but may help if you have problems with A2. If you know the stage the process was meant to be up to (look at the output in the command windows and compare to the stages in the ''build.xml'' file), you can start again from there.

You may see something like this in the command window;
=============================
## Target : link : link objects and library to create executable
---- task : rc
============ cmd ============
windres -o build/inkres.o --include-dir=src src/inkscape.rc
=============================
---- task : link
This will likely be followed by an error message. This means you were at the ''link'' stage

Now simply type;
...>btool ''stage''
Or in this case
...>btool link
And the build will continue from there.

After this, you will probably have to step through the remaining stages manually, one by one. The stages can include (see build.xml, where each stage is labelled 'target name="''target''"') ''init'', ''touchabout'', ''compile'', ''java'', ''lib'', ''i18n'', ''link'', ''linkinkview'', ''dist'', ''dist-all'', ''clean''.

'''Q''' - How do I rebuild just one ''file.o'' file? For instance if one particular file has gone wrong, or I want to try patching just one part of the code.

'''A''' - To find the right command for building any particular file in Inkscape, just look in the compile.lst after you have used btool once. Search for the name of the particular file (eg: print.cpp) and you will find the command used to compile it. You'll need to paste this into a text file, remove any carriage reurns and then paste that onto the command line.

'''Q''' - After I patched a file, I left a backup of the old file in the same directory called Copy of{filename}.cpp. The compiler complains about this file when building and stops.

'''A''' - Do not leave anything with a suffix .cpp in the source directories, apart from the original (or patched) source files. The build tool will try to compile everything ending in .cpp and will complain. If you backup an old file in the same directory before patching, call it {filename}.cpp.old or similar.

==== For more information ====
There is some old information on building Inkscape with either Mingw on Windows, or a cross-compiler on Linux, at http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html

=== Create the Setup package for Win32 ===

To create the setup package you need the NSIS installer on your PC. Get that from http://nsis.sf.net .
You have successfully built Inkscape and everything is in the ...\Inkscape\Inkscape\ directory.
Open the ...\Inkscape\packaging\win32\inkscape.nsi using the NSIS program and compile the package. Sooo easy :-)

==== A Note from Jon about UNICODE on Win32 ====

Actually, Microsoft themselves never use _UNICODE, nor it's 'evil' friends TCHAR and _T.
If it is used, it results in a binary that can not be run on Windows 95/98[[/ME]]. It is more of a "Windows NT only" define.

Microsoft applications like MS Office have been pure 16-bit Unicode internally for years now. Also remember that BSTRs in Win32 are required to have 16-bit Unicode data. So for any COM access on a Win32 box running Win9x[[/ME]] 'multibyte' or '8-bit' COM calls convert all ANSI data to Unicode once you pass things in. To avoid this, Microsoft just keeps data 16-bit Unicode and then translates to local ANSI codepage only when data needs to be passed directly to a Win32 call.

To help developers, Microsoft finally made public their API they had been using. It's [http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx "The Microsoft Layer for Unicode"].

Although that simplifies things, it's not required. I've done Win32 programs that are 16-bit Unicode and run on Windows 95/98[[/ME]] with no problems years before they released that.

Soo.... _UNICODE can't be used as it makes your binary unusable on Win9x[[/ME]]. Then it turns out that TCHAR and _T can't be used either. (Oh, and MS can't really use them, since Office does run on Win9x[[/ME]]). So just explicitly use some 16-bit datatype for chars. Microsoft is misleading in their documentation when they state that wchar_t is 16-bit. Most other platforms (including Mac OS, Linux, Solaris, BSD, etc) follow the language standard's recommendation and make it 32-bit. So it is best to avoid wchar_t for any real cross-platform code.

So, some general guidelines are:
* Never define _UNICODE
* Don't use _T
* Don't use TCHAR
* Don't use wchar_t
* Use some explicit 16-bit type for characters/strings
** [http://icu.sourceforge.net/ IBM's ICU] does this

So then it's a simple matter of converting data from the standard UTF-8 GTK+ data to UTF-16 data before passing to Win32-land.

The result? A single binary that executes properly on both [[Win9X/ME]] and [[WinNT/2K/XP]], including full and proper font and filename support.

And, as I've mentioned before, I've actually achieved this for a few different shipping products and projects.

-- [[JonCruz|Jon C]]

=== SVN and Windows ===

If you want to access Inkscapes' subversion repository on SourceForge from Windows, I'd heartily recommend [[TortoiseSVN]].
It has the SSH stuff built into it so you don't have to mess about with putty, and
it integrates right into Explorer, so SVN becomes just an extension of the right-click file commands.
get it from http://tortoisesvn.net/

John

Change VCS

2008-04-02T13:16:50Z

Mfloryan: /* Links */

With [[0.47_Refactoring_Plan]] coming along, the idea was brought up to change for a new version control system which would ease refactoring in particular. This page summarizes [http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/25255/focus=25274 various email threads]. The project is to use a Distributed Version Control System instead of subversion.

As a general source of information, see http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

== Why change? ==

Several things make a DVCS preferable to subversion for Inkscape:
* speed
* local commits allow to commit often
* easier branching and merging, which is likely to be useful for feature work or Summer of Code work while the core is refactored
* ... add your favorite feature from the wikipedia page above

This does not come without cost either:
* someone must move the code to the new system
* each dev must potentially learn a new system

== Comparison of DVCS ==

Since past discussions seemed to lead to the concensus that the benefits outweigh the cost, the question remaining is which DCVS to use. The three main contenders are [http://git.or.cz/ git], [http://www.selenic.com/mercurial/ mercurial] and [http://bazaar-vcs.org/ bazaar]. Here is a list of the their cost and benefits in the context of Inkscape development

=== Git ===
Good
* faster: local commits: <1s vs 4s, push a new branch: instantaneous vs 35 min
* ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view
* probably the fastest growing user base => many tools
* TextMate bundle

Bad
* git is designed with the Linux kernel's hierarchical workflow in mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit)
* we would need to set up and administer this ourselves
* revisions are indicated with SHA's rather than numbers
* commands dissimilar to what we're used to with svn (e.g., no 'git update')
* no decent GUI (for windows?)

Not sure
* have to git add all modified files before committing them or resort to `git commit -a`. This is shift from the SVN way of doing things. However with single files, `git commit filename` is equivalent to `svn commit filename`. Plus, with multiple files git basic workflow is probably more powerful: it allows to add a set of files to a commit and only then to actually do the commit. The same thing with svn (or other similarly behaving systems) requires to write a long list of files in a single command line.

=== Mercurial (Hg) ===
Good
* tortoiseHG (remains to be evaluated)
* TextMate bundle

Bad

===Bazaar===
Good
* already integrated in [[http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html launchpad]]
** Associating branches to bugs
** Associating branches to blueprints
** Changes state of bugs in LP when committing in Bazaar
** Web interface for creating branches quickly and easily
* supports bundling changesets
* tortoiseBZR
* Fewer commands - makes it easier to learn
* Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
* Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help.

Bad
* no support for line-endings conversion/convention enforcing (but such systems may create the risk of wrongly recognizing binary files)

Not sure
* A good point is that bazaar supports renames but it could actually be considered a "Bad" by git users

== (D)VCS Clients ==

== Links ==
* [http://bazaar-vcs.org/BzrWhy Bazaar Why]
* [http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html Bazaar in Lanunchpad]
* [http://bazaar-vcs.org/Workflows Bazaar workflows]
* Google talk videos on '''GIT''' [http://video.google.com/videoplay?docid=-2199332044603874737] [http://www.youtube.com/watch?v=8dhZ9BXQgc4]
* [http://git.or.cz/course/svn.html SVN Course]

Change VCS

2008-04-02T13:16:32Z

Mfloryan: small changes

With [[0.47_Refactoring_Plan]] coming along, the idea was brought up to change for a new version control system which would ease refactoring in particular. This page summarizes [http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/25255/focus=25274 various email threads]. The project is to use a Distributed Version Control System instead of subversion.

As a general source of information, see http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

== Why change? ==

Several things make a DVCS preferable to subversion for Inkscape:
* speed
* local commits allow to commit often
* easier branching and merging, which is likely to be useful for feature work or Summer of Code work while the core is refactored
* ... add your favorite feature from the wikipedia page above

This does not come without cost either:
* someone must move the code to the new system
* each dev must potentially learn a new system

== Comparison of DVCS ==

Since past discussions seemed to lead to the concensus that the benefits outweigh the cost, the question remaining is which DCVS to use. The three main contenders are [http://git.or.cz/ git], [http://www.selenic.com/mercurial/ mercurial] and [http://bazaar-vcs.org/ bazaar]. Here is a list of the their cost and benefits in the context of Inkscape development

=== Git ===
Good
* faster: local commits: <1s vs 4s, push a new branch: instantaneous vs 35 min
* ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view
* probably the fastest growing user base => many tools
* TextMate bundle

Bad
* git is designed with the Linux kernel's hierarchical workflow in mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit)
* we would need to set up and administer this ourselves
* revisions are indicated with SHA's rather than numbers
* commands dissimilar to what we're used to with svn (e.g., no 'git update')
* no decent GUI (for windows?)

Not sure
* have to git add all modified files before committing them or resort to `git commit -a`. This is shift from the SVN way of doing things. However with single files, `git commit filename` is equivalent to `svn commit filename`. Plus, with multiple files git basic workflow is probably more powerful: it allows to add a set of files to a commit and only then to actually do the commit. The same thing with svn (or other similarly behaving systems) requires to write a long list of files in a single command line.

=== Mercurial (Hg) ===
Good
* tortoiseHG (remains to be evaluated)
* TextMate bundle

Bad

===Bazaar===
Good
* already integrated in [[http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html launchpad]]
** Associating branches to bugs
** Associating branches to blueprints
** Changes state of bugs in LP when committing in Bazaar
** Web interface for creating branches quickly and easily
* supports bundling changesets
* tortoiseBZR
* Fewer commands - makes it easier to learn
* Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
* Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help.

Bad
* no support for line-endings conversion/convention enforcing (but such systems may create the risk of wrongly recognizing binary files)

Not sure
* A good point is that bazaar supports renames but it could actually be considered a "Bad" by git users

== (D)VCS Clients ==

== Links ==
* [http://bazaar-vcs.org/BzrWhy Bazaar Why]
* [http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html Bazaar in Lanunchpad]
* [http://bazaar-vcs.org/Workflows Bazaar workflows]

* Google talk videos on '''GIT''' [http://video.google.com/videoplay?docid=-2199332044603874737] [http://www.youtube.com/watch?v=8dhZ9BXQgc4]
* [http://git.or.cz/course/svn.html SVN Course]

Roadmap

2008-02-29T10:08:24Z

Mfloryan: /* Milestone 12 - Inkscape 0.46 */ added Quarks info if still relevant

== Inkscape Development Roadmap ==

NOTE: This is a working document showing specific near-term tasks needed for achieving the numbered milestones.

''Milestones 0-11 have been completed since the start of the Inkscape Project. See [[OldRoadmap]]''

=== Milestone 12 - Inkscape 0.46 ===

New/Changed Dependencies:
* (DONE) Gtk 2.8 (required)
* 2geom (optional)
**2geom is a hard dependency now due to LPE. 2geom source has been copied to the inkscape tree, so that inkscape can make full profit from the latest and greatest 2geom (instead of depending on an earlier official 2geom release) [johan])

Architectural Refactoring Effort:
* Eliminate all use of sp_repr_new in favor of XML::Document::* classes (see [http://article.gmane.org/gmane.comp.graphics.inkscape.devel/19068])
* Migrate SPObject to native C++ classes
* Implement [http://grin-optics.org gradient] UI "release" handler to deal with gradient garbage collection (see bug 984854)
* Create an SPObject API for tracking references and avoiding id clashes on import and interdocument copy/paste. What we need are a void SPDocument::importCopies([set of SPObjects]), and an [set of SPObjects] SPObject::dependencies() method.
* Prepatory work to integrate lib2geom next release
** what exactly is meant by this? is this already done with LPE?

Codebase Cleanup Effort:
* Change to use of GQuarks instead of #defines where feasible
** Where can information be found on this? (I have no clue what GQuarks are for example)
::Try here: [http://library.gnome.org/devel/glib/stable/glib-Quarks.html Quarks]
* Learn and use autoscan and autoreconf to find out which configure tests are still needed.
* Clean up configure.in
* (PARTIALLY DONE) [[DirectoryReorgProposal]]
* Convert all tabs into spaces (convert tabs to 4 spaces)
** Also see http://sourceforge.net/mailarchive/message.php?msg_id=7164324
* Remove trailing whitespace
** See http://wiki.inkscape.org/wiki/index.php/InkscapeJanitors#Cleanup:_Whitespace
* Rename all '[[SPFooBar]]' routines to '[[FooBar]]' and put into namespaces
** (DONE) dialogs folder
* (DONE) Convert use of gboolean to bool where feasible
**(Bulia: "This was attempted and (partially?) rolled back, because it broke GTK calls which require gbooleans.")
* (DONE) Switch from use of TRUE/FALSE to true/false
**(Bulia: "This was attempted and (partially?) rolled back, because it broke GTK calls which require gbooleans.")

File Format Support Effort:
* PDF Import/Export
** (HELP NEEDED) Identify remaining problems with the cairo-based PDF tool check [[FileTypes]]
** Ensure clippaths, transparency, bitmaps, etc. all work

Inkboard Effort
* Stabilize the code by closing crash bugs in the bug tracker

SVG Feature Compliance Effort:
* Animation
** Sketch out UI mockup ideas for animation rendering/animation
** Make an ultra-preliminary proof of concept of at least one animation feature

Extension Effort:
* Unification of the way to display help on extensions
* Localizable help of bundled extensions
* Effect extensions browser

User Documentation Effort:
* Re-arrange tutorial categories [ScislaC]
* (PARTIALLY DONE) Switch to use of xml2po for tutorial files ([[User:Colin Marquardt|Colin Marquardt]])
* Document filters

=== Milestone 13 - Inkscape 0.47 ===

New/Changed Dependencies:
* Gtk 2.10 (required)
* 2geom (required)

File Format Support Effort:
* PDF Import/Export
** Choice of PDF spec. (PDF/X-1a, PDF/X-3)
** Add file info/comments
** Add color bars
* [[MicrosoftVisio|Visio]] support
** Add extension for use of [[VDX2SVG]] (http://vdxtosvg.sourceforge.net/)
** (OBSOLETE) Add extension for use of [[PDF2SVG]] (http://www.solidcode.net/pdf2svg/ - this doesn't actually link to a useful page)

Tools:
* [https://bugs.launchpad.net/inkscape/+bug/sf904962 correct handling of multiple font faces] by Text tool
* [http://article.gmane.org/gmane.comp.graphics.inkscape.devel/16938/ Filters tool]

Architectural Refactoring Effort:
* 2geom Integration
** Eliminate code in favor of 2geom where feasible
* Convert remaining GTK dialog code to Gtkmm

Inkscape SVG Effort
* Revisit coordination system (move away from Cartesian)

DOM Binding Effort:
* Evaluate Adobe Activescript to use instead of Spidermonkey for our JS engine
* Create sample prototype app to explore ActiveScript
* Decide whether to go with Spidermonkey or Adobe ActiveScript

User Interface Effort:
* improvement of svg patterns UI - make it similar to gradient-drag, instead of piggybacking knotholder
* Palettes
** Custom palettes like from Gnome
** Ability to load 3rd-party palettes (e.g. Pantone, Trumatch, Focoltone, Toyo, etc.)
* Reenable fuzzy font matching [bb]
* Improve freehand curve smoothness [pjrm, paraprax]

Desktop Integration Effort:
* (DONE) Replace existing printer dialog with one from gtk 2.10
* Inter-application cut-and-paste
* Inter-application drag-and-drop

Testing Effort:
* Include some rendering tests in `make check'.
* Get 'make check' to pass on Win32 and OSX (with the current btool, does this mean a 'btool check' should pass?)
* Investigate performance measurement testing for Inkscape

Animation Effort
* Create a written conceptualization of how it should work
** Currently, part of the concept discussion is at [[Animation-(Timeline)|here]]

Inkboard Effort
* Ensure multi-user conferences work across most JEP-compliant Jabber servers
* Conduct an informal security analysis of Inkboard for security flaws

User Documentation Effort:
* Solicit more tutorial contributions from userbase
** Node editing
** Advanced text effects
** Grid snapping
** Connectors
** Creating photo-realistic art

=== Milestone 14 - Inkscape 0.48 - Animation ===

* Get basic rendering and authoring of simple animations working adequately

Architectural Refactoring Effort:
* Complete lib2geom integration
* Streamline style.*
** Eliminate use of the style.h types in as much of codebase as possible, particularly display/*.
** Externally, it should present a simple sset of accessor methods for getting/setting properties by name, and propagating to/from repr.
** Inside, it should have:
*** a concise list of property names with the expected domain of values in CSS and the associated Inkscape data type
*** a concise list of property aliases which represent one or more properties combined, each with the rule used to combine
*** definitions of the aforementioned rules and value domains
*** some generic code (not tied to any one property) implementing the needed behavior

DOM Binding Effort:
* Create tool that reads the w3c idl files and generates binding code
* Bind xpath parsing/execution
* Finish the CSS-DOM classes
* Add a 'run' mode in a separate window that runs and displays the scripted SVG

Desktop Integration Effort:
* [[WebDAV/FTP]] support via GNOME-VFS, Neon, or the like
* Finish making printing work more efficiently and reliably
* Clipart manager GUI

File Format Support Effort:
* PDF Import/Export
** Generate multipage PDF documents
** Define bleed and slug areas for offset printing
** Add crop, bleed and registration marks

=== Milestone 15 - Inkscape 0.49 - Prototype all SVG Mobile features ===

SVG Feature Compliance Effort:
* Ability to select which SVG spec version to save as
* Multi-page
* Animation
* Implement perspective transformations via [[PerspectiveObject]]
* Path editing
* Shaped strokes
* Masking/clippaths
** on-canvas editing (patch for 0.47 is ready)
** Should work like gradient tool to apply transparency
* [https://bugs.launchpad.net/inkscape/+bug/sf893812 hyperlinking]
* Ensure Inkscape does not throw away the internal DTD subsets of documents it reads

=== Milestone 16 - Inkscape 0.50 - SVG Mobile Support ===

SVG Feature Compliance Effort:
* Multi-page
* Scripting
* Markers
** Inherit stroke properties like color
** On-canvas editing
** Fix snapping issue
* Real CMYK / LAB / HSB support

=== Milestone 17 - Inkscape 0.51 ===

Architectural Refactoring Effort:
* cairo Adoption Effort:
** Prereq: Is renderer immune to the same kinds of numerical problems we see with our new renderer, libnr, or libart?
** Will the new renderer improve performance for most users?
** Integrate a cairo-based SVG Canvas library
* follow the [http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html Freedesktop Icon Naming Spec] for easier themeing

File Format Support Effort:
* Native [[Adobe Illustrator]] file Import (DONE)/Export
** Requires good PDF Import/Export
* Native [[CorelDraw]] file Import/Export (DONE as extension)
* DXF import/export
* gdkpixbuf(?) - would give JPEG support

=== Milestone 18 - Inkscape 0.52 - Tech drawing abilities ===

User Interface Effort:
* (DONE) Object-to-object snapping
* (DONE) Implement [[LittleCMS]] as color management system
* Implement iso (DONE) & hex grid
* Editable toolbars (libegg)
* Geometrical constraints
** "Perpendicular-to", "Parallel-to", etc.
* Path trimming/extending/offset
* Filleting tool

Extensions Effort:
* Implement extension registry for users to upload/download extensions via Inkscape
* Dia-like smart shapes support

=== Milestone 19 - Inkscape 0.53 - Inkcore ===

* Separate sections of code into various libraries for use by other programs
** inkcanvas
** inkview
** inkscape

=== Milestone 20 - Inkscape 0.54 ===
=== Milestone 21 - Inkscape 0.55 ===

=== ??? - Inkscape 1.00 - Full SVG 1.1 support ===

=== Milestone [Future] ===

[[Category:Developer Documentation]]

Compiling Inkscape on Windows 32-bit

2008-02-28T12:22:14Z

Mfloryan: /* A Note from Jon about UNICODE on Win32 */ fixed signature

See the [http://sourceforge.net/tracker/index.php?func=detail&aid=847856&group_id=93438&atid=604308 Win32 Build ticket] for some info.

=== Inkscape under Windows ===

Ishmal provides a complete set of compiler and libraries on his website. You can get all packages from http://inkscape.modevia.com/win32libs/. You better check there the last version, but as of February 28th 2008 those are:
* the mingw compiler version 4.2 http://inkscape.modevia.com/win32libs/mingw-4.2.1-071022-dw2.7z
* the gtk libraries version 2.10 http://inkscape.modevia.com/win32libs/gtk210-071023-dw2.7z
* other libraries http://inkscape.modevia.com/win32libs/devlibs-2.12-080226.7z

The configuration files expect the packages in specific directories:
* the compiler C:\MinGW
* the libraries C:\gtk210
* other libraries C:\devlibs

Now you step into the Inkscape source directory:
...\> cd ...\inkscape
set up the environment variables
...\> mingwenv.bat
build the magic make replacement:
...\> g++ buildtool.cpp -o btool
or, if you get errors about gettimeofday:
...\> g++ -DNEED_GETTIMEOFDAY buildtool.cpp -o btool
start the build proccess:
...\> btool
Now you should have you fresh Inkscape in the ...\Inkscape\Inkscape directory.

We will update this page soon with information on how to build Inkscape on the Win32 platform. In the meantime,
there are some fairly complete notes on how to build the current package with either Mingw on Windows, or a
cross-compiler on Linux, at

http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html

(note: http://inkscape.modevia.com/win32libs/ may have more complete and up-to-date library packages).

There is also a [[Win32 installer]]

=== Create the Setup package for Win32 ===

To create the setup package you need the NSIS installer on your PC. Get that from http://nsis.sf.net .
You have successfully built Inkscape and everything is in the ...\Inkscape\Inkscape\ directory.
Open the ...\Inkscape\packaging\win32\inkscape.nsi using the NSIS program and compile the package. Sooo easy :-)

==== A Note from Jon about UNICODE on Win32 ====

Actually, Microsoft themselves never use _UNICODE, nor it's 'evil' friends TCHAR and _T.
If it is used, it results in a binary that can not be run on Windows 95/98[[/ME]]. It is more of a "Windows NT only" define.

Microsoft applications like MS Office have been pure 16-bit Unicode internally for years now. Also remember that BSTRs in Win32 are required to have 16-bit Unicode data. So for any COM access on a Win32 box running Win9x[[/ME]] 'multibyte' or '8-bit' COM calls convert all ANSI data to Unicode once you pass things in. To avoid this, Microsoft just keeps data 16-bit Unicode and then translates to local ANSI codepage only when data needs to be passed directly to a Win32 call.

To help developers, Microsoft finally made public their API they had been using. It's [http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx "The Microsoft Layer for Unicode"].

Although that simplifies things, it's not required. I've done Win32 programs that are 16-bit Unicode and run on Windows 95/98[[/ME]] with no problems years before they released that.

Soo.... _UNICODE can't be used as it makes your binary unusable on Win9x[[/ME]]. Then it turns out that TCHAR and _T can't be used either. (Oh, and MS can't really use them, since Office does run on Win9x[[/ME]]). So just explicitly use some 16-bit datatype for chars. Microsoft is misleading in their documentation when they state that wchar_t is 16-bit. Most other platforms (including Mac OS, Linux, Solaris, BSD, etc) follow the language standard's recommendation and make it 32-bit. So it is best to avoid wchar_t for any real cross-platform code.

So, some general guidelines are:
* Never define _UNICODE
* Don't use _T
* Don't use TCHAR
* Don't use wchar_t
* Use some explicit 16-bit type for characters/strings
** [http://icu.sourceforge.net/ IBM's ICU] does this

So then it's a simple matter of converting data from the standard UTF-8 GTK+ data to UTF-16 data before passing to Win32-land.

The result? A single binary that executes properly on both [[Win9X/ME]] and [[WinNT/2K/XP]], including full and proper font and filename support.

And, as I've mentioned before, I've actually achieved this for a few different shipping products and projects.

-- [[JonCruz|Jon C]]

=== SVN and Windows ===

If you want to access Inkscapes' subversion repository on SourceForge from Windows, I'd heartily recommend [[TortoiseSVN]].
It has the SSH stuff built into it so you don't have to mess about with putty, and
it integrates right into Explorer, so SVN becomes just an extension of the right-click file commands.
get it from http://tortoisesvn.net/

John

Compiling Inkscape on Windows 32-bit

2008-02-28T12:21:25Z

Mfloryan: /* Inkscape under Windows */ the year!!

See the [http://sourceforge.net/tracker/index.php?func=detail&aid=847856&group_id=93438&atid=604308 Win32 Build ticket] for some info.

=== Inkscape under Windows ===

Ishmal provides a complete set of compiler and libraries on his website. You can get all packages from http://inkscape.modevia.com/win32libs/. You better check there the last version, but as of February 28th 2008 those are:
* the mingw compiler version 4.2 http://inkscape.modevia.com/win32libs/mingw-4.2.1-071022-dw2.7z
* the gtk libraries version 2.10 http://inkscape.modevia.com/win32libs/gtk210-071023-dw2.7z
* other libraries http://inkscape.modevia.com/win32libs/devlibs-2.12-080226.7z

The configuration files expect the packages in specific directories:
* the compiler C:\MinGW
* the libraries C:\gtk210
* other libraries C:\devlibs

Now you step into the Inkscape source directory:
...\> cd ...\inkscape
set up the environment variables
...\> mingwenv.bat
build the magic make replacement:
...\> g++ buildtool.cpp -o btool
or, if you get errors about gettimeofday:
...\> g++ -DNEED_GETTIMEOFDAY buildtool.cpp -o btool
start the build proccess:
...\> btool
Now you should have you fresh Inkscape in the ...\Inkscape\Inkscape directory.

We will update this page soon with information on how to build Inkscape on the Win32 platform. In the meantime,
there are some fairly complete notes on how to build the current package with either Mingw on Windows, or a
cross-compiler on Linux, at

http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html

(note: http://inkscape.modevia.com/win32libs/ may have more complete and up-to-date library packages).

There is also a [[Win32 installer]]

=== Create the Setup package for Win32 ===

To create the setup package you need the NSIS installer on your PC. Get that from http://nsis.sf.net .
You have successfully built Inkscape and everything is in the ...\Inkscape\Inkscape\ directory.
Open the ...\Inkscape\packaging\win32\inkscape.nsi using the NSIS program and compile the package. Sooo easy :-)

==== A Note from Jon about UNICODE on Win32 ====

Actually, Microsoft themselves never use _UNICODE, nor it's 'evil' friends TCHAR and _T.
If it is used, it results in a binary that can not be run on Windows 95/98[[/ME]]. It is more of a "Windows NT only" define.

Microsoft applications like MS Office have been pure 16-bit Unicode internally for years now. Also remember that BSTRs in Win32 are required to have 16-bit Unicode data. So for any COM access on a Win32 box running Win9x[[/ME]] 'multibyte' or '8-bit' COM calls convert all ANSI data to Unicode once you pass things in. To avoid this, Microsoft just keeps data 16-bit Unicode and then translates to local ANSI codepage only when data needs to be passed directly to a Win32 call.

To help developers, Microsoft finally made public their API they had been using. It's [http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx "The Microsoft Layer for Unicode"].

Although that simplifies things, it's not required. I've done Win32 programs that are 16-bit Unicode and run on Windows 95/98[[/ME]] with no problems years before they released that.

Soo.... _UNICODE can't be used as it makes your binary unusable on Win9x[[/ME]]. Then it turns out that TCHAR and _T can't be used either. (Oh, and MS can't really use them, since Office does run on Win9x[[/ME]]). So just explicitly use some 16-bit datatype for chars. Microsoft is misleading in their documentation when they state that wchar_t is 16-bit. Most other platforms (including Mac OS, Linux, Solaris, BSD, etc) follow the language standard's recommendation and make it 32-bit. So it is best to avoid wchar_t for any real cross-platform code.

So, some general guidelines are:
* Never define _UNICODE
* Don't use _T
* Don't use TCHAR
* Don't use wchar_t
* Use some explicit 16-bit type for characters/strings
** [http://icu.sourceforge.net/ IBM's ICU] does this

So then it's a simple matter of converting data from the standard UTF-8 GTK+ data to UTF-16 data before passing to Win32-land.

The result? A single binary that executes properly on both [[Win9X/ME]] and [[WinNT/2K/XP]], including full and proper font and filename support.

And, as I've mentioned before, I've actually achieved this for a few different shipping products and projects.

-- [[[JonCruz]] Jon C]

=== SVN and Windows ===

If you want to access Inkscapes' subversion repository on SourceForge from Windows, I'd heartily recommend [[TortoiseSVN]].
It has the SSH stuff built into it so you don't have to mess about with putty, and
it integrates right into Explorer, so SVN becomes just an extension of the right-click file commands.
get it from http://tortoisesvn.net/

John

Compiling Inkscape on Windows 32-bit

2008-02-28T12:20:35Z

Mfloryan: /* Inkscape under Windows */ updated links

See the [http://sourceforge.net/tracker/index.php?func=detail&aid=847856&group_id=93438&atid=604308 Win32 Build ticket] for some info.

=== Inkscape under Windows ===

Ishmal provides a complete set of compiler and libraries on his website. You can get all packages from http://inkscape.modevia.com/win32libs/. You better check there the last version, but as of February 28th 2007 those are:
* the mingw compiler version 4.2 http://inkscape.modevia.com/win32libs/mingw-4.2.1-071022-dw2.7z
* the gtk libraries version 2.10 http://inkscape.modevia.com/win32libs/gtk210-071023-dw2.7z
* other libraries http://inkscape.modevia.com/win32libs/devlibs-2.12-080226.7z

The configuration files expect the packages in specific directories:
* the compiler C:\MinGW
* the libraries C:\gtk210
* other libraries C:\devlibs

Now you step into the Inkscape source directory:
...\> cd ...\inkscape
set up the environment variables
...\> mingwenv.bat
build the magic make replacement:
...\> g++ buildtool.cpp -o btool
or, if you get errors about gettimeofday:
...\> g++ -DNEED_GETTIMEOFDAY buildtool.cpp -o btool
start the build proccess:
...\> btool
Now you should have you fresh Inkscape in the ...\Inkscape\Inkscape directory.

We will update this page soon with information on how to build Inkscape on the Win32 platform. In the meantime,
there are some fairly complete notes on how to build the current package with either Mingw on Windows, or a
cross-compiler on Linux, at

http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html

(note: http://inkscape.modevia.com/win32libs/ may have more complete and up-to-date library packages).

There is also a [[Win32 installer]]

=== Create the Setup package for Win32 ===

To create the setup package you need the NSIS installer on your PC. Get that from http://nsis.sf.net .
You have successfully built Inkscape and everything is in the ...\Inkscape\Inkscape\ directory.
Open the ...\Inkscape\packaging\win32\inkscape.nsi using the NSIS program and compile the package. Sooo easy :-)

==== A Note from Jon about UNICODE on Win32 ====

Actually, Microsoft themselves never use _UNICODE, nor it's 'evil' friends TCHAR and _T.
If it is used, it results in a binary that can not be run on Windows 95/98[[/ME]]. It is more of a "Windows NT only" define.

Microsoft applications like MS Office have been pure 16-bit Unicode internally for years now. Also remember that BSTRs in Win32 are required to have 16-bit Unicode data. So for any COM access on a Win32 box running Win9x[[/ME]] 'multibyte' or '8-bit' COM calls convert all ANSI data to Unicode once you pass things in. To avoid this, Microsoft just keeps data 16-bit Unicode and then translates to local ANSI codepage only when data needs to be passed directly to a Win32 call.

To help developers, Microsoft finally made public their API they had been using. It's [http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx "The Microsoft Layer for Unicode"].

Although that simplifies things, it's not required. I've done Win32 programs that are 16-bit Unicode and run on Windows 95/98[[/ME]] with no problems years before they released that.

Soo.... _UNICODE can't be used as it makes your binary unusable on Win9x[[/ME]]. Then it turns out that TCHAR and _T can't be used either. (Oh, and MS can't really use them, since Office does run on Win9x[[/ME]]). So just explicitly use some 16-bit datatype for chars. Microsoft is misleading in their documentation when they state that wchar_t is 16-bit. Most other platforms (including Mac OS, Linux, Solaris, BSD, etc) follow the language standard's recommendation and make it 32-bit. So it is best to avoid wchar_t for any real cross-platform code.

So, some general guidelines are:
* Never define _UNICODE
* Don't use _T
* Don't use TCHAR
* Don't use wchar_t
* Use some explicit 16-bit type for characters/strings
** [http://icu.sourceforge.net/ IBM's ICU] does this

So then it's a simple matter of converting data from the standard UTF-8 GTK+ data to UTF-16 data before passing to Win32-land.

The result? A single binary that executes properly on both [[Win9X/ME]] and [[WinNT/2K/XP]], including full and proper font and filename support.

And, as I've mentioned before, I've actually achieved this for a few different shipping products and projects.

-- [[[JonCruz]] Jon C]

=== SVN and Windows ===

If you want to access Inkscapes' subversion repository on SourceForge from Windows, I'd heartily recommend [[TortoiseSVN]].
It has the SSH stuff built into it so you don't have to mess about with putty, and
it integrates right into Explorer, so SVN becomes just an extension of the right-click file commands.
get it from http://tortoisesvn.net/

John

Release notes/0.47

2008-02-28T11:48:45Z

Mfloryan: /* Corel DRAW files import */ UC1.1.1 supports Corel X4 files as well

=Inkscape 0.47=
'''(not released yet)'''
=User Interface=
==Native File Dialogs for Windows==
The windows builds of inkscape now have Windows-native file dialogs to keep consistency with other windows applications.

=Import/Export=
==Corel DRAW files import==

Now Inkscape can import more Corel DRAW files of following types:

* Corel DRAW Compressed Exchange files (CCX)
* Corel DRAW 7-X4 Template files (CDT)
* Corel DRAW Presentation Exchange files (CMX)

Text objects are not supported as of UniConvertor 1.1.1.

==sK1 files import==

Inkscape uses UniConvertor to import sK1 files. Text objects are not supported as of UniConvertor 1.1.1.

==CGM import==

Inkscape uses UniConvertor to import Computer Graphics Metafile (CGM) files. Text objects are not supported as of UniConvertor 1.1.1.

=User interface=
==Masks and clipping paths==

[johan]

= Previous releases =

* [[ReleaseNotes046]]
* [[ReleaseNotes045]]
* [[ReleaseNotes044]]
* [[ReleaseNotes043]]
* [[ReleaseNotes042]]
* [[ReleaseNotes041]]
* [[ReleaseNotes040]]
* [[ReleaseNotes039]]
* [[ReleaseNotes038]]
* [[ReleaseNotes037]]
* [[ReleaseNotes036]]
* [[ReleaseNotes035]]

[[Category:Marketing]]

User:Mfloryan

2008-02-13T12:49:02Z

Mfloryan: New page: =Marcin Floryan=

=Marcin Floryan=

Compiling Inkscape on Windows 32-bit

2008-02-11T15:54:24Z

Mfloryan: /* Inkscape under Windows */ updated devlibs link

See the [http://sourceforge.net/tracker/index.php?func=detail&aid=847856&group_id=93438&atid=604308 Win32 Build ticket] for some info.

=== Inkscape under Windows ===

Ishmal provides a complete set of compiler and libraries on his website. You can get all packages from http://inkscape.modevia.com/win32libs/. You better check there the last version, but as of November 30th 2007 those are:
* the mingw compiler version 4.2 http://inkscape.modevia.com/win32libs/mingw-4.2.1-071022-dw2.7z
* the gtk libraries version 2.10 http://inkscape.modevia.com/win32libs/gtk210-071023-dw2.7z
* other libraries http://inkscape.modevia.com/win32libs/devlibs-2.12-080204.7z

The configuration files expect the packages in specific directories:
* the compiler C:\MinGW
* the libraries C:\gtk210
* other libraries C:\devlibs

Now you step into the Inkscape source directory:
...\> cd ...\inkscape
set up the environment variables
...\> mingwenv.bat
build the magic make replacement:
...\> g++ buildtool.cpp -o btool
or, if you get errors about gettimeofday:
...\> g++ -DNEED_GETTIMEOFDAY buildtool.cpp -o btool
start the build proccess:
...\> btool
Now you should have you fresh Inkscape in the ...\Inkscape\Inkscape directory.

We will update this page soon with information on how to build Inkscape on the Win32 platform. In the meantime,
there are some fairly complete notes on how to build the current package with either Mingw on Windows, or a
cross-compiler on Linux, at

http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html

(note: http://inkscape.modevia.com/win32libs/ may have more complete and up-to-date library packages).

There is also a [[Win32 installer]]

=== Create the Setup package for Win32 ===

To create the setup package you need the NSIS installer on your PC. Get that from http://nsis.sf.net .
You have successfully built Inkscape and everything is in the ...\Inkscape\Inkscape\ directory.
Open the ...\Inkscape\packaging\win32\inkscape.nsi using the NSIS program and compile the package. Sooo easy :-)

==== A Note from Jon about UNICODE on Win32 ====

Actually, Microsoft themselves never use _UNICODE, nor it's 'evil' friends TCHAR and _T.
If it is used, it results in a binary that can not be run on Windows 95/98[[/ME]]. It is more of a "Windows NT only" define.

Microsoft applications like MS Office have been pure 16-bit Unicode internally for years now. Also remember that BSTRs in Win32 are required to have 16-bit Unicode data. So for any COM access on a Win32 box running Win9x[[/ME]] 'multibyte' or '8-bit' COM calls convert all ANSI data to Unicode once you pass things in. To avoid this, Microsoft just keeps data 16-bit Unicode and then translates to local ANSI codepage only when data needs to be passed directly to a Win32 call.

To help developers, Microsoft finally made public their API they had been using. It's [http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx "The Microsoft Layer for Unicode"].

Although that simplifies things, it's not required. I've done Win32 programs that are 16-bit Unicode and run on Windows 95/98[[/ME]] with no problems years before they released that.

Soo.... _UNICODE can't be used as it makes your binary unusable on Win9x[[/ME]]. Then it turns out that TCHAR and _T can't be used either. (Oh, and MS can't really use them, since Office does run on Win9x[[/ME]]). So just explicitly use some 16-bit datatype for chars. Microsoft is misleading in their documentation when they state that wchar_t is 16-bit. Most other platforms (including Mac OS, Linux, Solaris, BSD, etc) follow the language standard's recommendation and make it 32-bit. So it is best to avoid wchar_t for any real cross-platform code.

So, some general guidelines are:
* Never define _UNICODE
* Don't use _T
* Don't use TCHAR
* Don't use wchar_t
* Use some explicit 16-bit type for characters/strings
** [http://icu.sourceforge.net/ IBM's ICU] does this

So then it's a simple matter of converting data from the standard UTF-8 GTK+ data to UTF-16 data before passing to Win32-land.

The result? A single binary that executes properly on both [[Win9X/ME]] and [[WinNT/2K/XP]], including full and proper font and filename support.

And, as I've mentioned before, I've actually achieved this for a few different shipping products and projects.

-- [[[JonCruz]] Jon C]

=== SVN and Windows ===

If you want to access Inkscapes' subversion repository on SourceForge from Windows, I'd heartily recommend [[TortoiseSVN]].
It has the SSH stuff built into it so you don't have to mess about with putty, and
it integrates right into Explorer, so SVN becomes just an extension of the right-click file commands.
get it from http://tortoisesvn.net/

John

Interface translation

2008-02-08T09:33:59Z

Mfloryan: /* Get the PO file for your language */ change following https://bugs.launchpad.net/inkscape/+bug/179209

Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.

== Introduction to PO file format ==

If you've never translated a PO file before, you will find its syntax very simple. The PO format is a really simple format, which probably at least partly explains its success and widespread use. The format is basically a hash list consisting of msgid and msgstr pairs, with the msgid being the original English string and key, and the msgstr being the translated value of it. Below is an example of a message.

#: gedit/dialogs/gedit-plugin-program-location-dialog.c:78
#: gedit/dialogs/program-location-dialog.glade2.h:2
msgid "Set program location..."
msgstr "Ställ in programplats..."

In addition to the msgid and msgstr parts, a message usually also has lines starting with #: that tells what source files and what lines the string used as msgid was extracted from. These lines have no syntactic value. They are only there as a help for translators and developers to know where a message came from.

A message in a PO file can be in one of essentially three different states. The message can be translated, fuzzy, or untranslated. A message counts as translated as soon as the msgstr part of it is non-empty. In a similar manner, an untranslated message is one where the msgstr is empty. The fuzzy state is special and essentially means that there is a translation in the msgstr part, but that this translation is most likely not entirely correct, and that it thus needs manual attention by a translator. A message can become fuzzy in one of two ways:

* The original string that the msgid represents was changed in the source code. A typo in the string may have been fixed or the string altered in some other way. The translator needs to check that the msgstr is still valid and make changes if necessary.
* A new string has been added to the source, and the string is very similar, but not identical, to the msgid of an already existing, translated message. Then the msgstr of that message will be automatically reused for the new message, but the new message will also at the same time be marked fuzzy so that the translator knows there is some difference that he or she needs to adapt the translation to match.

There is always one special message in each valid PO file: the PO file header. It is encoded with the msgid for the empty string ("") as the key, and the actual header values are in the msgstr part. This unfortunately means that if you mark an empty string for translation, you will get the entire PO file header back as the "translation". In almost all cases this is probably not what you want. Hence, do not mark empty strings for translation.

== Get the PO file for your language ==

Download the .po file for your language from here:

http://inkscape.svn.sourceforge.net/viewcvs.py/inkscape/inkscape/trunk/po/

If a .po file for your language does not yet exist, then you will have to get an empty template file to start a new translation.
You may also need to use the updated template file (mentioned blow) to bring the .po file up to date with new strings introduced in the UI.

The most straightforward way to obtain the inkscape.pot template is to download it from here:

http://inkscape.modevia.com/potfile/inkscape.pot

More recent version of this file may also be available here (please check which is more up to date):

http://www.unstable.it/luca/inkscape.pot

Alternatively, you can checkout the full SVN project repository and generate the project template. Information on how to get the source tree can be found [http://inkscape.org/svn.php here]. Then, you have to follow some steps in order to generate the template:

1. "./autogen.sh"
2. "./configure"
3. enter the "po" directory: "cd po"
4. generate the current PO template: "intltool-update --pot"

To make an absolutely up-to-date translation (in case the PO file in SVN is not up-to-date enough),

1. update your local copy of Inkscape in the usual way: "svn update"
2. merge your existing translations into the new POT file (inkscape.pot):

"msgmerge your_latest_PO_file inkscape.pot > new_PO_file"

If you want to update ALL .po files in po/, cd there and run:

make update-po

Now that you have an empty PO template, you can start translating the messages.

== Tools for translators ==

You can edit PO files from any plain text editor, since they are simple text files. However, many useful tools have been developed to provide a simple experience translating PO files.

* emacs' po-mode (contained in the gettext distribution; the version in po-utils is old)
* kbabel (http://i18n.kde.org/tools/kbabel/)
* gtranslator (http://gtranslator.sourceforge.net/)
* poEdit (http://www.poedit.net/)
* GEdit (installed on GNOME desktops) has a syntax highlight mode for PO file syntax.

And last but not least, [http://www.gnu.org/software/gettext/manual/ gettext] utils, which are installed on every linux distribution. You can see a complete reference too from installed info pages by running the command:

info gettext

== A few important things to remember ==

* Some strings that can be ambiguous or having several meanings according to different contexts may have a context prefix : "Context|Amibiguous string". In this case, simply translate "Ambiguous string", the "Context|" string is just a not to translate indication. (Some info on how to disambiguate a string can be found [http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html#Q-:CAPS here].)
* After translating a fuzzy string (one that is marked with a ", fuzzy" comment), please remove its "fuzzy" tag -- otherwise this translation will be discarded by the build process, meaning that this string will show up untranslated. KBabel can do this automatically (see KBabel settings).
* Before publishing your work (after you have finished updating the PO file), please update the "PO-Revision-Date" and "Last-Translator" fields in the PO file header. KBabel can do this automatically.

== Review ==

This is the start of a list of places to get translation reviews done. So far:
http://www.linux.it/tp/

== Verification ==

Before submitting your file in the patch tracker, please make sure it is valid:
* Make sure the file is encoded in UTF-8
* Make sure it is a valid po file and obtain some statistics about it: simply run "msgfmt --statistics -cv translationFile.po" from a command window
* Make sure it is correctly formatted: run "check-markup translationFile.po" from a command window and verify it doesn't output any error message. "check-markup" perl script can be found in the /po directory of Inkscape svn trunk

== Locale Testing ==

Before reporting that a locale doesn't work in Inkscape, you need to make sure that your system has that locale correctly set up. To do this, you need to generally find a way to run "locale-gen". (Under Debian/Ubuntu this is via "dpkg-reconfigure locales".) If you set both the LANG and LANGUAGE variables and check a regular tool, you should see the correct language for both the libc error (first line) and the tool error (second line):

LANG=es_MX LANGUAGE=es_MX ls -z
ls: opción inválida -- z
Pruebe `ls --help' para más información.

If it reports the regular C messages, your locale has not been correctly configured, and you'll need to find the right way to run "locale-gen" for your distribution:

LANG=es_ES LANGUAGE=es_MX ls -z
ls: invalid option -- z
Try `ls --help' for more information.

== Submit finished work ==

Upload your work via the [[Launchpad]] bug tracker:

https://bugs.launchpad.net/inkscape/

Report a new bug and attach your translated file to it. Don't forget to compress your file before uploading it.

Additionally, you may send a message to Inkscape's translators mailing list.

== Programmers ==
Please make sure you use [http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC150 dgettext] for any pluralized strings.

= Windows installer translation =

Strings for Windows installer are saved in *.nsh files. Each translation has its own file located in ''packaging\win32\'' directory of subversion checkout. Get this file in similar way of getting *.po file.
=== Translating ===
# Get the file according to your language. If there is not such a file, copy ''english.nsh'' file and rename it to ''yourlanguage.nsh''.
# Translate strings in the file
# Change '''!insertmacro MUI_LANGUAGE "English"''' and each occurence of '''${LANG_ENGLISH}''' to values corresponding with your language. For example '''!insertmacro MUI_LANGUAGE "Czech"''' and '''${LANG_CZECH}'''.
# Change header information in '''yourlanguage.nsh''' file, like "windows code page" and "Authors" to proper values.
=== Testing the translation ===
# This part is optional but recommended. For this part you need [http://nsis.sourceforge.net/Main_Page NSIS installer] and run <pre>make -f Makefile.mingw dist</pre> command after succesfull compilation of Inkscape. This command prepares binary of Inkscape for installator creation.
# Add filename of your file to '''inkscape.nsi''' file, "STRING LOCALIZATION" section, "Language files" subsection.
# Right click on the inkscape.nsi file and choose "Compile NSIS Script". The installer compilation will start.
# When the installer is finished, run it to test translations of strings in Installer and Uninstaller parts.
# If the translation is tested succesfully, submit it to the patch tracker at sourceforge.net and mark as "Translation". If you haven't tested your translation yet, submit it too but enter this information to the patch information. You will be contacted about its correctness.

= Default template translation =

* To translate default template, modify the default.svg file and save it as default.xx.svg where "xx" is ISO code of your language. The file can be found in ''/usr/share/inkscape/templates/'' directory on Linux, or ''C:\Program Files\Inkscape\share\templates\'' directory on MS Windows(tm). Also you can get it from [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/trunk/share/templates/ SVN repository].
* You need to modify your PO translation as well to use your localized default template. Look up for a msgid "default.svg" on the PO file and translate it accordingly to the file name of the localized template.
* To test it, save it to the proper location and restart Inkscape. Default document should be now based on your localized template. (This is valid if your system is properly set to your locales).
* Upload default.xx.svg to the patch tracker.

To translate default template can be used Inkscape as well as any UTF-8 encoding capable text editor.

= Translation information =
Go Back to the main [http://wiki.inkscape.org/wiki/index.php/Translation_information Translation information] page.