Inkscape Wiki - User contributions [en]

Tracking Dependencies

2008-12-17T06:08:57Z

Pjrm: /* Distros */ Minor: Correct wording for other operating systems

(stub contents in need of filling out)

== Overview ==

We need help getting our basic lib dependencies listed out and kept up to date. Also we need to track which versions of which distros have the needed dependencies.

To get glib and GTK+ dependencies figured out, people can go through the API documentation and look for the 'since' entries saying when calls were added. Then look for those calls in our source. Voila! we'll have base minimum dependencies figured out.

== Libs ==

C++ bindings are not included, since their required versions match those of the C counterparts.

{| class="wikitable" border="1"
|-
! Library
! v 0.45
! v 0.46
! v 0.47
|-
| Boehm-GC
| ?
| ?
| ?
|-
| Cairo
| ?
| ?
| ?
|-
| GDK
| ?
| ?
| ?
|-
| Glib
| ?
| ?
| 2.16
|-
| GTK+
| 2.8
| 2.10
| 2.12
|-
| GNU Scientific Library
| X
| X
| ?
|-
| LittleCMS
| ?
| ?
| 1.13
|-
| libxml
| ?
| ?
| 2.6.11
|-
| libxslt
| ?
| ?
| 1.0.15
|-
| Pango
| ?
| ?
| ?
|-
| Poppler
| ?
| ?
| 0.5.9
|-
| libsigc++
| ?
| ?
| 2.0.12
|}

== Functions Used ==

{| class="wikitable" border="1"
|-
! Function
! Lib
! Since
! Required
|-
| g_timeout_add_seconds
| Glib
| 2.14
| ?
|}

== Distros ==

Note: This table is not relevant to Windows and (non-fink) MacOS X, where we ship the desired version with Inkscape.

{| class="wikitable" border="1"
|-
! Distro
! cairo
! glib
! gtk+
! pango
|-
| Fedora 7
| ?
| 2.12
| 2.10.14
| ?
|-
| Fedora 8
| ?
| 2.14
| 2.12.8
| ?
|-
| Fedora 9
| ?
| 2.16
| 2.12.10
| ?
|-
| Open SuSE 10.3
| 1.4.14
| 2.14.1
| 2.12.0
| 1.18.2
|-
| Open SuSE 11.0
| ?
| ?
| 2.12.9
| ?
|-
| Ubuntu 7.10 (Gutsy)
| 1.4.10
| 2.14.1
| 2.12.0
| 1.18.3
|-
| Ubuntu 8.04 LTS (Hardy)
| 1.6.0
| 2.16.6
| 2.12.9
| 1.20.5
|-
| Ubuntu 8.10 (Intrepid)
| 1.8.0
| 2.18.2
| 2.14.4
| 1.22.1
|-
| Xandros
| 1.2.4
| 2.12.4
| 2.8.20
| 1.14.8
|}

Coding Style

2008-07-14T13:48:14Z

Pjrm: /* Whitespace: Space between sigil and following token? */ Expand "looks like code" argument to apply to other cases too, as suggested by Johan['s friend].

== Inkscape Coding Style Discussion ==

The official code style documentation is on the main website.
"http://www.inkscape.org/doc/coding_style.php"

This page is for discussing and working out changes and improvements to that document. When concensus
is reached, the document can be updated in SVN in the inkscape_web module.

=== Editor support ===

Place the following at the end of source files to help emacsen & vim users follow some of our guidelines automatically:
<pre>
/*
Local Variables:
mode:c++
c-file-style:"stroustrup"
c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
indent-tabs-mode:nil
fill-column:99
End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=99 :
</pre>

Once you've added those lines, close the file and re-open it for it to take effect.

Then (for emacsen users), one can re-indent a region with C-M-\.

=== crazyCamelCase v. Underscores ===
* The new coding standards require non-static member functions to be in pseudoCamelCase, and every other type of function to use underscores.
* The current codebase has very few real C++ objects, half of these objects (or more) seem to use underscores for their member functions, the other half seem to use pseudoCamelCase.
** Over-all, 95% of Inkscape's codebase uses underscores in function names (of coures, 90% of the code is still C).
*** It seems underscores are what Inkscape developers are already used to.

* I prefer CamelCase for type names (classes), exceptions, namespaces, and the like. But pseudoCamelCase in member functions clutters the visual space; making types, exceptions, and namescapes stand out much less. And it makes the code much harder (for me) to read.
** Why is there this inconsistency with regard to function names in the new coding standard?
*** (I.e., why a few functions pseudoCamelCase, and everything else underscores?)
** Could all functions just use underscores? (Like the current codebase, like Gtkmm, like Linux, like the C & C++ standard libraries, and like almost every other project out there?)
** Is static vs. non-static member functions really that big of an issue to warrant a change to pseudoCamelCase?

* Hey, we're not programming in Java (or Qt) here! This is C++, where underscore reigns supreme.

=== Underscore as first character of identifiers ===
* Please consider that the C++ standard reserves _* identifiers [17.4.3.1.2]: "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace".

=== Tabs and Alignment ===

Inkscape code uses 4 spaces for indentation and no tabs anywhere.

=== Whitespace: Space between sigil and following token? ===

I.e. do we write ‘<code>int *p</code>’ or ‘<code>int * p</code>’; ‘<code>int *f()</code>’ or ‘<code>int * f()</code>’; ‘<code>int *const p</code>’ or ‘<code>int * const p</code>’ ?

Arguments in favour of no space:

* Promotes better understanding of C/C++'s parsing rules for cases like ‘<code>int *a, b</code>’: the sigil applies only to <code>a</code> in that example, not to <code>b</code>.
** This argument is much less applicable to the case that the following identifier names a function: it is very rare for function prototypes to “syntactically share return types” that way; this rarity reduces the importance of knowing the meaning of ‘<code>int * a(), b()</code>’.
* Less horizontal whitespace usage (reducing the chance of overflowing the available width or requiring a continuation line).
** However, note that overflow is rare for variable declarations; for function headers, continuation doesn't hinder understanding of the header in question, so the argument rather becomes one of taking up more lines, reducing how many statements are visible in one screenful.
* For the case of declarations inside function bodies (and other cases as well, to a lesser extent), ‘<code>Foo * foo</code>’ is more easily mistaken for executable code (as distinct from a declaration) than ‘<code>Foo *foo</code>’ is.
* Less typing. (Minimal importance.)

Arguments in favour of space:

* For the cases where the following token is an identifier, improves the legibility of the identifier. For cases where the following token is a cv-qualifier (‘const’, ‘volatile’), the space improves the legibility of the sigil.

An additional issue is the relative prevalence of the approaches in existing code: this relates to either consistency or the cost of changing code (to the extent that changing is done manually).

Before doing any counting, the impression of one developer [writing this] is that no-space is much more common, but with-space is far from unheard-of. (It's valuable to get an informal impression as a defense against any deficiencies in simplistic automated counting: e.g. we ought to give more weight to code that's often looked at / changed than code that's less often looked at or changed, and should give more weight to code considered Inkscape code than imported code.)

The results of a simplistic automated count confirm that: there are 28037 lines with the no-space style to 7204 lines with the with-space style, a ratio of about 3.9:1; or 1899 vs 746 (2.5:1) in .h files. For the following-token-is-function-identifier case, the gap is narrower, at 1350 vs 792 (1.7:1).

The simplistic automated count in question is:

:find \( -name '*.h' -o -name '*.cpp' \) -type f -print0 |
::xargs -0 cat |tr '\t' ' ' |
::egrep -c '(void|int|unsigned|char|short|float|double|\<[A-Z][a-zA-Z0-9_]*)(( *const)? *[*&])+[a-zA-Z_]'

for no-space, and inserting ‘ +’ before the final ‘[a-zA-Z_]’ for with-space. (‘volatile’ is not used in Inkscape source code at the time of writing.) For the following-token-is-function-identifier case, the final ‘[a-zA-Z_]’ was extended to ‘[a-zA-Z_][a-zA-Z0-9_]* *\(’. Note that this means that both the no-space and with-space counts exclude Gnu-style function definition heads (where the return type is on a separate line).

=== Brace Placement ===

Arguments against "disco"/compact braces:

* Make it hard to match braces visually.

:Partial counter-argument: emacsen & vim each have brace-locating commands. (Emacsen: C-M-u, C-M-n, C-M-p, C-M-d (up/next/prev/down); vim: `[ {', `] }'.)

* The brace closes a block, not an if "statement".

:However, the block is intimately related to the if/for/while in ways that a normal block is not.

=== Functions vs methods, i.e. member vs non-member functions ===

* Information-hiding principle suggests that if a function doesn't need access to private variables then it's better not to make it a member function.

** In more detail: when one wants to change some detain about a private variable, then one must look through everything that has access to that variable. This is easier if there's less code that has access to the variable, e.g. if one uses non-member functions in preference to member-functions.

* Virtual functions must of course be member functions.

* Trivial getter/setter functions seem most natural as member functions. (This is mostly a matter of style or tradition rather than technical reasons.)
** "barType getBar() const { return _bar; }" / "void setBar(barType x) { _bar = x; }" are trivial. It's not clear how much else is to be considered trivial.

* For things needing access to private variables, the requirement of the `friend' declaration for non-member functions is a cost: extra clutter in the class definition, requires updating for changes in the signature; and many of the arguments for non-member functions disappear.

* Member functions must be declared in the class definition, which tends to require more recompilation because one can't use a separate header file.

** Sometimes one can break the class into smaller, simpler classes if there are lots of member functions.

* A related issue is that it's harder (impossible) to write private specializations (same name but subclass arguments): any specialization must be declared in the class definition too, so it isn't private other than through comments.

* The shorter names typical of member functions are harder to search for.

** (Counter-argument: this is a matter of custom, there's no technical reason why one can't use long names for member functions, or even short names for non-member functions.)

** Someone has claimed that some tools do relatively well at finding the right version of a given name. Can someone give examples of such a tool (and some comment as to how widely used that tool is or can be by our developers) ?

* Pointers to member functions aren't as easily used as pointers to non-member functions. ("unwieldy", "heavy-weight".)

* Member functions can't be given static linkage.

=== <tt>static</tt> vs anonymous namespaces for file-local functions/objects ===

The current C++ standard marks this type of `<tt>static</tt>' as deprecated, meaning "Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions".

(Reference: Final Draft of the C++ standard, Annex D "Compatibility features"; and §7.3.1.1 "Unnamed namespaces", ¶2.)

However, g++ up to 3.4 (and possibly later) don't give anonymous-namespace names the same advantages given to static names:

* Warning if the name isn't referenced (and hence unused).
* Optimizations when the function/object can't be used from other object files.
* Static linkage (relevant to analysis using nm).

In addition, having a <tt>static</tt> tag in the declaration itself makes it easier for the programmer to see that the name isn't referenced outside of this translation unit.

Consequently, it is recommended that we use <tt>static</tt> for names not referenced from other translation units.

If and when we encounter a compiler that rejects `static' for objects in namespace scope, we can easily replace `<tt>static</tt>' with `<tt>namespace {</tt> ... <tt>}</tt>'.

=== What to put in what header file ===

Reasons for change:
* Reduce compilation times (most important)
* Fix the mess of NR::Point, NR::Matrix etc. header files. Less confusion as to what needs to be #included, or where to look for the definition of something (especially in the cases where tags-like programs don't help, e.g. if looking for something helpful for a known task rather than having a known name).

What won't change:
* foo.h will still provide the same things it always has (unless you count things "accidentally" provided, which we hope to become less). It's just that some content may be physically moved to a file that foo.h #includes.

The issues are:

* Ease for callers (what file/s to #include). This is largely taken care of by having files that #include other header files, and in particular having the foo.h file as at present.

* "I need to change the blah declaration/definition; what file do I edit?".

* Information we want ppl to be aware of.

Definitions are handled by tags/idutils/global etc (though all of these tools have limitations in their ability to find the _right_ definition).
Declarations that are separate from the definition: [non-member] function declarations are the main case. member functions (obviously kept in same physical file as their class definition); non-member functions

Here are some types of things to be found in header files. Whatever rules you hypothesize, check that the rules cover each of these cases.

* class foo definition
* "class foo;" forward declarations
* struct foo_class (i.e. GObject "class"/vtable type)
* IS_FOO, FOO cast etc. macros
* ancilliary types (e.g. struct StopOnTrue for marshalling)
* enums
* relevant instantiations (traits etc.)
* foo_do_blah (declaration of function defined in .cpp file)
* inline function definitions
* should declaration & definition of inline functions go in different files (there are pros & cons)
* other constants, including #defines
* other macros. Where is the line between "other macro" and "inline function" and IS_FOO macros?

The physical placement of the IS_FOO etc. macros (as distinct from what header files "provide" them) isn't important: we never need to edit them, and they're relatively easy to find by either primitive tags-like programs or by grep.
* This unimportance-of-physical-location is reflected in the inconsistency of current practice, sometimes placing them with foo.h and sometimes in blah-forward.h.
* Exception to unimportance-of-physical-location: IS_FOO etc. should not be physically in the same header file as something that's "expensive" and unneeded by one or more translation units that need IS_FOO etc. ("Expensive" in same sense as `amount' defined below in `Reducing compile times'.)

The main thing for IS_FOO etc. is what header file(s) provide the macro. Thankfully, this is easy in the common case: usually any function that needs the definition of IS_FOO also needs lots of other things relevant to the foo type, so would simply #include foo.h.

Relevant properties of function declarations:

* It is common to add or remove functions, or change the arguments.

* Typically not found by tags-like programs. E.g. neither `tags' nor `TAGS' files store the location of declarations (other than the definition).

* Programmers want to know what functions (including methods, macros, inline things) are available (or rather "is there something that does blah").

** Probably doxygen or the like is the best task for this, though we'd need to make it convenient to use.

* Needed in advance of function definitions (whether in .cpp file or inline function definitions). Not needed in advance by macro definitions per se (but needed in advance of function definitions where the macro is expanded).

Inline function definitions:

* Relatively expensive in compile time for translation units that don't use that inline function definition.
* Must come after (in the translation unit) all referenced declarations. Sometimes this requires that it be outside of the class definition or in a separate file from related declarations. (E.g. if foo.h and bar.h each provide an inline function definition that requires declarations provided by the other file.)

Operator overloading:

* Can be unclear whether to associate with the type of the left operand or the type of the right operand.
* We can simplify things for users of the function by having both left.h and right.h provide it (i.e. have both left.h and right.h #include it). This suggests that it should be physically neither in left.h nor right.h (unless it's OK for left.h to pull in all of right.h or vice versa).

Reducing compile times

* For each translation unit U, reduce the amount of material that gets included by U and isn't needed by U.
** "Amount" is measured by cost: how often that material changes (causing a recompile), and how expensive it is to compile (e.g. inline function definitions).

* In what circumstances does a translation unit include things that it doesn't need?
** Inline function definitions.
** Needs a function declaration but doesn't need the type definition.
*** A special [non-] case of this is needing a member function declaration. Member function declarations can't be separated from their class definition. See also `methods vs functions' above.
** Suppose that struct Foo has a `Bar _bar' member. The translation unit may need to create Foo objects (and thus need the type definition of Bar to know its size), but not need to access _bar (so not needing anything from bar.h other than the type definition of Bar).
*** This is very common. Common examples of Bar: SPShape, NR::Point[[/NR]]::Matrix.
** Needs some function declarations but not others.
** Needs some type forward declarations but not others.
** Comments are never needed for compilation.
** Definition of a marshaller is needed only by emitters. However, it's difficult to separate the marshaller from the signal, and difficult to separate the signal from the definition of the containing type (SPDesktop, SPItem).
** Including the definition of a type when its declaration would suffice.
** Copy&paste of #include lines.

* Ways of reducing the need for type definitions:
** Store just a pointer instead of the whole type.
** Provide a wrapper function (not inlined) for `new Foo'.

==Preprocessor MACROS==

Capitalizing or not?

# define IS_FINITE(_a) (std::isfinite(_a))

===Arguments pro capitalizing===
* Macros don't have a namespace and can therefore easily clash with other names. This happened in the isFinite case. where we had across several files:
#define isFinite(x) ...
...
class Point {
bool isFinite(int x)
}
This obviously nameclashed, where a capitalized IS_FINITE would have never clashes as (I guess) nobody uses capitalized function names. Note that an inline function instead of macro would also have worked.
* Some macros can expand strangely (don't have good example now), so it is good that the user knows it does so.
* Note that it is often also possible to define an inline function instead of a macro!!! (which is a better solution?)

===Arguments against capitalizing===

[[Category:Developer Discussion]]

Coding Style

2008-07-14T12:41:58Z

Pjrm: New section, discussing spacing after sigil

== Inkscape Coding Style Discussion ==

The official code style documentation is on the main website.
"http://www.inkscape.org/doc/coding_style.php"

This page is for discussing and working out changes and improvements to that document. When concensus
is reached, the document can be updated in SVN in the inkscape_web module.

=== Editor support ===

Place the following at the end of source files to help emacsen & vim users follow some of our guidelines automatically:
<pre>
/*
Local Variables:
mode:c++
c-file-style:"stroustrup"
c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
indent-tabs-mode:nil
fill-column:99
End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=99 :
</pre>

Once you've added those lines, close the file and re-open it for it to take effect.

Then (for emacsen users), one can re-indent a region with C-M-\.

=== crazyCamelCase v. Underscores ===
* The new coding standards require non-static member functions to be in pseudoCamelCase, and every other type of function to use underscores.
* The current codebase has very few real C++ objects, half of these objects (or more) seem to use underscores for their member functions, the other half seem to use pseudoCamelCase.
** Over-all, 95% of Inkscape's codebase uses underscores in function names (of coures, 90% of the code is still C).
*** It seems underscores are what Inkscape developers are already used to.

* I prefer CamelCase for type names (classes), exceptions, namespaces, and the like. But pseudoCamelCase in member functions clutters the visual space; making types, exceptions, and namescapes stand out much less. And it makes the code much harder (for me) to read.
** Why is there this inconsistency with regard to function names in the new coding standard?
*** (I.e., why a few functions pseudoCamelCase, and everything else underscores?)
** Could all functions just use underscores? (Like the current codebase, like Gtkmm, like Linux, like the C & C++ standard libraries, and like almost every other project out there?)
** Is static vs. non-static member functions really that big of an issue to warrant a change to pseudoCamelCase?

* Hey, we're not programming in Java (or Qt) here! This is C++, where underscore reigns supreme.

=== Underscore as first character of identifiers ===
* Please consider that the C++ standard reserves _* identifiers [17.4.3.1.2]: "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace".

=== Tabs and Alignment ===

Inkscape code uses 4 spaces for indentation and no tabs anywhere.

=== Whitespace: Space between sigil and following token? ===

I.e. do we write ‘<code>int *p</code>’ or ‘<code>int * p</code>’; ‘<code>int *f()</code>’ or ‘<code>int * f()</code>’; ‘<code>int *const p</code>’ or ‘<code>int * const p</code>’ ?

Arguments in favour of no space:

* Promotes better understanding of C/C++'s parsing rules for cases like ‘<code>int *a, b</code>’: the sigil applies only to <code>a</code> in that example, not to <code>b</code>.
** This argument is much less applicable to the case that the following identifier names a function: it is very rare for function prototypes to “syntactically share return types” that way; this rarity reduces the importance of knowing the meaning of ‘<code>int * a(), b()</code>’.
* Less horizontal whitespace usage (reducing the chance of overflowing the available width or requiring a continuation line).
** However, note that overflow is rare for variable declarations; for function headers, continuation doesn't hinder understanding of the header in question, so the argument rather becomes one of taking up more lines, reducing how many statements are visible in one screenful.
* For the case of declarations inside function bodies: ‘<code>Foo * foo</code>’ is more easily mistaken for executable code (as distinct from a declaration) than ‘<code>Foo *foo</code>’ is.
* Less typing. (Minimal importance.)

Arguments in favour of space:

* For the cases where the following token is an identifier, improves the legibility of the identifier. For cases where the following token is a cv-qualifier (‘const’, ‘volatile’), the space improves the legibility of the sigil.

An additional issue is the relative prevalence of the approaches in existing code: this relates to either consistency or the cost of changing code (to the extent that changing is done manually).

Before doing any counting, the impression of one developer [writing this] is that no-space is much more common, but with-space is far from unheard-of. (It's valuable to get an informal impression as a defense against any deficiencies in simplistic automated counting: e.g. we ought to give more weight to code that's often looked at / changed than code that's less often looked at or changed, and should give more weight to code considered Inkscape code than imported code.)

The results of a simplistic automated count confirm that: there are 28037 lines with the no-space style to 7204 lines with the with-space style, a ratio of about 3.9:1; or 1899 vs 746 (2.5:1) in .h files. For the following-token-is-function-identifier case, the gap is narrower, at 1350 vs 792 (1.7:1).

The simplistic automated count in question is:

:find \( -name '*.h' -o -name '*.cpp' \) -type f -print0 |
::xargs -0 cat |tr '\t' ' ' |
::egrep -c '(void|int|unsigned|char|short|float|double|\<[A-Z][a-zA-Z0-9_]*)(( *const)? *[*&])+[a-zA-Z_]'

for no-space, and inserting ‘ +’ before the final ‘[a-zA-Z_]’ for with-space. (‘volatile’ is not used in Inkscape source code at the time of writing.) For the following-token-is-function-identifier case, the final ‘[a-zA-Z_]’ was extended to ‘[a-zA-Z_][a-zA-Z0-9_]* *\(’. Note that this means that both the no-space and with-space counts exclude Gnu-style function definition heads (where the return type is on a separate line).

=== Brace Placement ===

Arguments against "disco"/compact braces:

* Make it hard to match braces visually.

:Partial counter-argument: emacsen & vim each have brace-locating commands. (Emacsen: C-M-u, C-M-n, C-M-p, C-M-d (up/next/prev/down); vim: `[ {', `] }'.)

* The brace closes a block, not an if "statement".

:However, the block is intimately related to the if/for/while in ways that a normal block is not.

=== Functions vs methods, i.e. member vs non-member functions ===

* Information-hiding principle suggests that if a function doesn't need access to private variables then it's better not to make it a member function.

** In more detail: when one wants to change some detain about a private variable, then one must look through everything that has access to that variable. This is easier if there's less code that has access to the variable, e.g. if one uses non-member functions in preference to member-functions.

* Virtual functions must of course be member functions.

* Trivial getter/setter functions seem most natural as member functions. (This is mostly a matter of style or tradition rather than technical reasons.)
** "barType getBar() const { return _bar; }" / "void setBar(barType x) { _bar = x; }" are trivial. It's not clear how much else is to be considered trivial.

* For things needing access to private variables, the requirement of the `friend' declaration for non-member functions is a cost: extra clutter in the class definition, requires updating for changes in the signature; and many of the arguments for non-member functions disappear.

* Member functions must be declared in the class definition, which tends to require more recompilation because one can't use a separate header file.

** Sometimes one can break the class into smaller, simpler classes if there are lots of member functions.

* A related issue is that it's harder (impossible) to write private specializations (same name but subclass arguments): any specialization must be declared in the class definition too, so it isn't private other than through comments.

* The shorter names typical of member functions are harder to search for.

** (Counter-argument: this is a matter of custom, there's no technical reason why one can't use long names for member functions, or even short names for non-member functions.)

** Someone has claimed that some tools do relatively well at finding the right version of a given name. Can someone give examples of such a tool (and some comment as to how widely used that tool is or can be by our developers) ?

* Pointers to member functions aren't as easily used as pointers to non-member functions. ("unwieldy", "heavy-weight".)

* Member functions can't be given static linkage.

=== <tt>static</tt> vs anonymous namespaces for file-local functions/objects ===

The current C++ standard marks this type of `<tt>static</tt>' as deprecated, meaning "Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions".

(Reference: Final Draft of the C++ standard, Annex D "Compatibility features"; and §7.3.1.1 "Unnamed namespaces", ¶2.)

However, g++ up to 3.4 (and possibly later) don't give anonymous-namespace names the same advantages given to static names:

* Warning if the name isn't referenced (and hence unused).
* Optimizations when the function/object can't be used from other object files.
* Static linkage (relevant to analysis using nm).

In addition, having a <tt>static</tt> tag in the declaration itself makes it easier for the programmer to see that the name isn't referenced outside of this translation unit.

Consequently, it is recommended that we use <tt>static</tt> for names not referenced from other translation units.

If and when we encounter a compiler that rejects `static' for objects in namespace scope, we can easily replace `<tt>static</tt>' with `<tt>namespace {</tt> ... <tt>}</tt>'.

=== What to put in what header file ===

Reasons for change:
* Reduce compilation times (most important)
* Fix the mess of NR::Point, NR::Matrix etc. header files. Less confusion as to what needs to be #included, or where to look for the definition of something (especially in the cases where tags-like programs don't help, e.g. if looking for something helpful for a known task rather than having a known name).

What won't change:
* foo.h will still provide the same things it always has (unless you count things "accidentally" provided, which we hope to become less). It's just that some content may be physically moved to a file that foo.h #includes.

The issues are:

* Ease for callers (what file/s to #include). This is largely taken care of by having files that #include other header files, and in particular having the foo.h file as at present.

* "I need to change the blah declaration/definition; what file do I edit?".

* Information we want ppl to be aware of.

Definitions are handled by tags/idutils/global etc (though all of these tools have limitations in their ability to find the _right_ definition).
Declarations that are separate from the definition: [non-member] function declarations are the main case. member functions (obviously kept in same physical file as their class definition); non-member functions

Here are some types of things to be found in header files. Whatever rules you hypothesize, check that the rules cover each of these cases.

* class foo definition
* "class foo;" forward declarations
* struct foo_class (i.e. GObject "class"/vtable type)
* IS_FOO, FOO cast etc. macros
* ancilliary types (e.g. struct StopOnTrue for marshalling)
* enums
* relevant instantiations (traits etc.)
* foo_do_blah (declaration of function defined in .cpp file)
* inline function definitions
* should declaration & definition of inline functions go in different files (there are pros & cons)
* other constants, including #defines
* other macros. Where is the line between "other macro" and "inline function" and IS_FOO macros?

The physical placement of the IS_FOO etc. macros (as distinct from what header files "provide" them) isn't important: we never need to edit them, and they're relatively easy to find by either primitive tags-like programs or by grep.
* This unimportance-of-physical-location is reflected in the inconsistency of current practice, sometimes placing them with foo.h and sometimes in blah-forward.h.
* Exception to unimportance-of-physical-location: IS_FOO etc. should not be physically in the same header file as something that's "expensive" and unneeded by one or more translation units that need IS_FOO etc. ("Expensive" in same sense as `amount' defined below in `Reducing compile times'.)

The main thing for IS_FOO etc. is what header file(s) provide the macro. Thankfully, this is easy in the common case: usually any function that needs the definition of IS_FOO also needs lots of other things relevant to the foo type, so would simply #include foo.h.

Relevant properties of function declarations:

* It is common to add or remove functions, or change the arguments.

* Typically not found by tags-like programs. E.g. neither `tags' nor `TAGS' files store the location of declarations (other than the definition).

* Programmers want to know what functions (including methods, macros, inline things) are available (or rather "is there something that does blah").

** Probably doxygen or the like is the best task for this, though we'd need to make it convenient to use.

* Needed in advance of function definitions (whether in .cpp file or inline function definitions). Not needed in advance by macro definitions per se (but needed in advance of function definitions where the macro is expanded).

Inline function definitions:

* Relatively expensive in compile time for translation units that don't use that inline function definition.
* Must come after (in the translation unit) all referenced declarations. Sometimes this requires that it be outside of the class definition or in a separate file from related declarations. (E.g. if foo.h and bar.h each provide an inline function definition that requires declarations provided by the other file.)

Operator overloading:

* Can be unclear whether to associate with the type of the left operand or the type of the right operand.
* We can simplify things for users of the function by having both left.h and right.h provide it (i.e. have both left.h and right.h #include it). This suggests that it should be physically neither in left.h nor right.h (unless it's OK for left.h to pull in all of right.h or vice versa).

Reducing compile times

* For each translation unit U, reduce the amount of material that gets included by U and isn't needed by U.
** "Amount" is measured by cost: how often that material changes (causing a recompile), and how expensive it is to compile (e.g. inline function definitions).

* In what circumstances does a translation unit include things that it doesn't need?
** Inline function definitions.
** Needs a function declaration but doesn't need the type definition.
*** A special [non-] case of this is needing a member function declaration. Member function declarations can't be separated from their class definition. See also `methods vs functions' above.
** Suppose that struct Foo has a `Bar _bar' member. The translation unit may need to create Foo objects (and thus need the type definition of Bar to know its size), but not need to access _bar (so not needing anything from bar.h other than the type definition of Bar).
*** This is very common. Common examples of Bar: SPShape, NR::Point[[/NR]]::Matrix.
** Needs some function declarations but not others.
** Needs some type forward declarations but not others.
** Comments are never needed for compilation.
** Definition of a marshaller is needed only by emitters. However, it's difficult to separate the marshaller from the signal, and difficult to separate the signal from the definition of the containing type (SPDesktop, SPItem).
** Including the definition of a type when its declaration would suffice.
** Copy&paste of #include lines.

* Ways of reducing the need for type definitions:
** Store just a pointer instead of the whole type.
** Provide a wrapper function (not inlined) for `new Foo'.

[[Category:Developer Discussion]]

Release notes/0.47

2008-04-12T11:14:47Z

Pjrm: /* Notable bug fixes and effect changes */ query comment about changing old files

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

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

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

=Live path effects=
== Notable bug fixes and effect changes==
We try to refrain from changing the behavior of LPE's, because it will change graphics in old files¹. 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]

* 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]. Recently, Spiro support was added to the FontForge font editor, and now it is available in Inkscape too. It takes some getting used to, but for certain tasks Spiros have a clear advantage over Bezier curves.

: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 - with the kind of smoothness you can achieve with Beziers only after much 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) become curve points of the Spiro path; such points bend the curve but must remain smooth. Note that the length or direction of the Bezier handles of the source path is ignored; the only thing that matters is that the node is smooth.

:* Cusp nodes of the source path become corner points of the Spiro path. Between two corner points, the path is always a straight line.

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

: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 cusp (diamond-shaped) node has collinear handles, it will become a curve point of the Spiro path. For creating half-smooth nodes, use Ctrl+dragging of the node 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.

:Some configurations of points do not converge and produce wild loop 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. 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!

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

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

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

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

= Previous releases =

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

[[Category:Marketing]]

Script extensions

2007-05-15T11:21:12Z

Pjrm: info on how to script Inkscape

[Note: This page concerns using scripting languages to create new Inkscape functionality. To access Inkscape functionality from scripting languages (i.e. to script Inkscape), see the Inkscape man page (especially in the development version or v0.46 or later, which provide --select and --verb options), or see the work in the src/extension/script directory of Inkscape source.]

=== Introduction ===

Inkscape provides the ability for its functionality to be extended using traditional unix scripts. By this, we mean a program that takes in a stream of data through standard in, and then outputs that data on standard out. This is a very easy way to expand Inkscape, and provide custom functionality, without learning the internals of Inkscape. Plus, there are SVG read and writing libraries out there for almost any language, and the rest of them all have XML support (which is really what you probably want to use anyway). This HOWTO discusses the ends and outs of writing one of these scripts and getting it to work with the Inkscape core functionality.

=== Types of scripts ===

There are three functions that added with a script:

* Input, providing translation from a file format to SVG
* Output, providing translation from SVG to a format
* Effect, taking in SVG, changing it, and then outputing SVG

While all of these are very similar in the scripting interface, there are slight differences between them.

=== Interaction ===

It is important for a script author to understand how Inkscape and scripts communicate.

(interpreter)? your_script (--param=value)* /path/to/input[[/SVGfile]] | inkscape

Inkscape runs your script (optionally with an interpreter) passing it any number of parameters in long gnu style. The final argument is the name of the temporary svg file your script should read. After processing, the script should return the modified svg file to inkscape on STDOUT.

=== Important Tips ===

* Receive the inkscape arguments.
* Clear temp files if it creates one.
* Write full changed SVG to the default output.
* Don't break an xml:space="preserve" area.
* Send error text to the error output and help the user.

=== Description ===

In order for Inkscape to make use of an external script or program, you must describe that script to inkscape using an INX file. See the inkscape share directory for examples. The INX file allows the author to:
* label strings for translation
* define parameters
* chain extensions
Please see [[MakingAnINX]] for help creating an INX file for your script.

==== Parameters ====
The INX file describes which parameters the extension needs. Inkscape will prompt the user with a UI to fill out these parameters before the extension is called. Each parameter will be passed through the commandline as "--paramname=paramvalue". Eg. if you have described a string parameter with name 'string1' in the INX file, Inkscape will present a textbox to the user. When the user fills in "text" and presses OK, it will pass '--string1="text"' to the program specified by the <command> tag.

There are several types of parameters that can be requested by the INX description:

* Boolean
* Int
* Float
* String
* Description
* Enum
* Notebook
* Option group (radio buttons)

=== Installing ===

Installing is as simple as copying the script (unless it resides in your path) and its INX file to the inkscape/share/extensions (home/.inkscape/extensions) directory. (If you install a script in your home directory be sure to copy the dependencies.)

If you are looking to use scripts that have already been written, the most difficult part will likely be the installation. Since scripts are seperate programs they may have any number of dependencies that are not included with inkscape. Currently, the best way to find missing dependencies is by reading the error messages produced by running the script from the command line.

=== See Also ===

*[http://www.ekips.org/comp/inkscape/extending.php#ignorance| Aarons website] describing his path to learning how scripting extensions work. '''VERY OUT-OF-DATE'''

*[[MakingAnINX]]

[[Category:Extensions]]

Release notes/0.44

2006-05-28T06:18:02Z

Pjrm: /* Extensions */ Grammar: Move full-sentence parenthesis to separate sentence.

== Inkscape 0.44: overview ==

Inkscape 0.44 is bigger and better than ever. Some highlights:

* Layers dialog

* Outline mode, many performance improvements

* Native PDF export with transparency

* Clipping and masking support

* Configurable keyboard shortcuts, including Xara X emulation

* Docked color palette in the editing window

* Interactive indicator of the style of selection in the statusbar

* Innovative "node sculpting" and other improvements in Node tool

* Extensions are enabled by default and work on both Linux and Windows

* Better SVG support: <switch> element, ICC color profiles for images

* Persistent rotation centers, Paste Size command

* Redesigned preferences dialogs, new icons, rearranged menus, many cosmetic improvements

* Hundreds of bugfixes and smaller features

* Not directly related to Inkscape, but important nevertheless: since our last release, [http://www.mozilla.com/firefox/ Firefox 1.5] was released with SVG support enabled by default. This means that you can now view any Inkscape document right in your Firefox window without any format conversions or installing any plugins!

= Performance =

== Outline mode ==

An Outline ("wireframe") display mode is implemented. Use the View > Display Mode > Outline to activate it. In this mode:

* all paths and shapes are rendered as inverse (black on light background and vice versa) outlines of constant width (1 screen pixel regardless of zoom), without fill;

* text is painted by inverse fill, without stroke;

* bitmaps are shown as is;

* any opacity and gradients are ignored.

The outline mode is usually not drastically faster than regular mode (usually 10% to 50% faster), and in some special cases it may even be slower. However, the value of the outline mode is not only in its speed; it is a good way to get an idea of the structure and objects of your document, and it is convenient for precision node editing and for finding "stray objects".

== Speed ==

In addition to the Outline mode which makes it much easier to work with complex drawings, this version of Inkscape also provides significant speed improvements in many areas.

* Thanks to optimizations in the renderer, Inkscape's screen redraw is faster by at least 10%, and in some cases (such as complex stroked/dashed paths at high zooms) up to three times faster.

* Optimizations in the Node tool resulted in noticeable speed gains for node editing. Thus, switching to and from the Node tool (with a path selected), as well as selecting nodes in that tool, are now at least ten times faster than before. Other operations, including curve and node dragging and move/scale/rotate operations on multiple selected nodes, are much faster as well. This is especially important when working with complex paths; with these optimizations, paths containing several thousand nodes, though still slow, are much more usable.

* An optimization in the attribute setting method made operations such as moving multiple objects with arrow keys at least 30% faster compared to 0.43. This is especially noticeable when you are moving clones selected together with their original (e.g. a clone tiling), in which case Inkscape now works three to four times faster.

* Interface icons are now rendered in the background (from SVG source in <code>share/icons/icons.svg</code>) when Inkscape is idle, rather than waiting for all the icons in a menu to render the first time you pull it up. This eliminates the annoying delay when opening menus for the first time.

* Previously, zooming in to view a small portion of a path (especially big and complex path), there was a very noticeable slowdown and memory use increased dramatically. We optimized the renderer to only process the visible part of a path, and as a result the rendering speed is now almost the same at any zoom up to the maximum, providing up to 10-40 times speedup compared to the previous version (the closer is the zoom, the greater is the gain).

= Interface =

== Layers dialog ==

* Ctrl+Shift+L [joncruz, mental]

== Selected style indicator ==

A new control in the left end of the statusbar lets you quickly view and change the fill and stroke of the selected objects. When you have a text selection in Text tool or a gradient handle selected in the Gradient tool, this indicator displays and changes the style of the text fragment or gradient stop, instead of the entire object (it's the same behavior as the Fill&Stroke dialog.)

* The two indicators, labelled F: (top) and S: (bottom), display fill and stroke of the selected object(s) correspondingly. (For gradient handles, they always display the same style.)

* Each fill/stroke indicator can display either a color+opacity swatch (the opacity shown here is the fill opacity or stroke opacity, not the master opacity) or a text label specifying N/A (nothing selected), None (no fill/stroke), Unset (unset fill/stroke), L Gradient, R Gradient, Pattern (corresponding fill/stroke types), or Different (selected objects have different fill/stroke types).

* Additionally, each indicator may be accompanied by one of two flags, m ("multiple", meaning there are two or more objects all with the same fill/stroke) or a ("averaged", meaning there are two or more objects with different flat colors in fill/stroke, and the indicator shows the average of these colors).

* Left-click on an indicator opens or activates the Fill&Stroke dialog with the corresponding tab (Fill or Stroke) active.

* Right-click on an indicator opens a popup menu with the following items:
** Edit fill/stroke...: Opens or activates the Fill&Stroke dialog with the corresponding tab selected. (Same as left-click.)
** Last set color: Applies to the selected objects the fill/stroke color that was last applied to anythig.
** Last selected color: Applies to the selected objects the fill/stroke color that was last displayed in this indicator. (Allows you to easily copy fill/stroke color between objects: select source, select destination, apply "last selected color".)
** Invert: Sets the fill or stroke to the inverse of the current color (does not affect opacity).
** White, Black: Sets the fill or stroke to the corresponding color (fully opaque).
** Copy color, Paste color: Copies or pastes the fill or stroke color (when it's color) to/from the system clipboard, as text in the <code>#rrggbb</code> hex format.
** Swap fill and stroke: Exchanges fill and stroke (both their types and colors, if any).
** Make fill/stroke opaque: Removes fill or stroke transparency (not master transparency!).
** Unset fill/stroke: Unsets fill or stroke from selected objects.
** Remove fill/stroke: Removes fill or stroke from the selected objects.

* Middle-click on a fill/stroke indicator removes fill/stroke from selected objects; if it is already removed (i.e. if the indicator displays "None"), it does the same as the "Last set color" command from the popup menu.

* Drag and Drop of colors onto a fil/stroke indicator sets the fill and stroke of the selected object(s) correspondingly.

* The Stroke indicator also displays the stroke width of selection (averaged if there are multiple objects selected with different stroke widths), located to the right of the stroke color/transparency swatch. Left-clicking on it opens the Fill&Stroke dialog with the Stroke Style tab selected. Right-clicking on it opens a popup menu which allows you to choose the units for displaying the stroke width, as well as choose one of the presets to assign to selection.

* To the right of the fill/stroke indicators, the Opacity numeric field (labelled "O:") shows and allows you to change the master opacity of the selected object (or the averaged opacity of several selected objects). Right-clicking the numeric field opens a popup menu with preset opacity levels. Middle-clicking on the "O:" label cycles the opacity through the values of 0 (transparent), 0.5, and 1 (opaque).

The zoom field and the cursor coordinates indicator have been rearranged for compactness and moved to the right end of the statusbar. There's also a window resize handle added at the very end of the statusbar.

== Tool style indicators ==

For each object-creating tool (shapes, Pen/Pencil, Calligraphic, Text), the Controls bar (above the canvas) now includes a style indicator on the right. This indicator shows you which style the newly created object will have. The indicator correctly displays whichever style the tool is set to use - the global "last set" style or that tool's fixed style. For example, clicking on a palette swatch (even with nothing selected) changes the "last set" color and, if your tool is set to use the last set color, its indicator is updated, giving you an idea of your "brush" before you start to draw.

== Controls bar for the Text tool ==

[deadchip]

== Docked color palette ==

* Previously, color swatches could only be used from a floating palette (Ctrl+Shift+W). Now the color swatches palette is embedded in the main UI, at the bottom of the window between the canvas and the statusbar. It is enabled by default; use View > Show/Hide > Palette to enable or disable it. The docked palette has the same functionality as the floating one; use a button in the top right corner to access the swatches menu.

* All standard sizes of the swatches (Tiny, Small, Medium, Large, Huge) are made smaller overall.

* The Wrap option (off by default) in the swatches menu converts the palette from a single row into a frame 2 or 3 rows high, for better access to colors in large palettes.

* Drag and Drop of colors has been enabled.
** Dragging colors from a palette shows a live swatch of the color being dragged under cursor.
** Drag and Drop of colors onto the selected style indicator in the statusbar sets the fill or stroke of the selected object(s).
** Colors can be dropped directly on to objects on canvas to set their fill, or shift+dropped to set their stroke. This affects only the object you drop the color on, regardless of whether that object is selected or not.
** Colors can be dragged to and from other applications.

* The new Inkscape default color palette was added. It contains a range of grays, standard HTML named colors, and a full range of colors sorted by their HSL values (475 colors overall). It is generated by a Python script which is available from Inkscape SVN in share/palettes.

* A number of specialized color palettes, useful in color-coordinated projects, was borrowed from GIMP: Reds, Greens, Blues, Gold, Royal, Khaki, Hilite, and Topographic.

== Inkscape Preferences dialog ==

Not only was the Inkscape Preferences dialog completely rewritten and redesigned, it is now also fully GNOME-HIG compliant. Numerous bugs were taken care of with the rewrite. As a new feature, the Simplify threshold can now be set with more precision.

== Document Properties / Metadata dialogs ==

* The Document Preferences dialog is now named Document Properties, and it was split in two: metadata were extracted into the Document Metadata dialog; metadata widgets are now also spread over two pages.

* A button was added to fit the canvas to the current selection or, if there's no selection, to the entire drawing. The button resizes the canvas and, if necessary, moves the drawing into place. It is now very easy to size the canvas to an illustration after it is ready.

* New controls: the new object snapping features required their own property widgets, and you can set the snapping sensitivity with a slider, or let it snap regardless of distance (grid only).

* Rearrangements within Document Properties: everything snapping-related was collected on one page; Grid and Guide widgets are on their own, the same page. For better HIG compliance, all widgets were categorized; especially the widgets on the Page page were completely rearranged in the General/Format/Border categories.

* Bug fixes: grayed out license URI had too low contrast, so it's no longer grayed out; the proprietary license didn't clean the license URI; spinbuttons had no tooltips, and minor grid quirks were removed; data was not updated when a new file replaced another in the same window.

* HIG compliance: much work went into that, and now only a few details are missing from full Gnome-HIG compliance.

* Updated Creative Commons Licenses: Updated CC licenses to the latest 2.5 versions by default in the license tab of the metadata dialog.

== Menus ==

* Zoom commands in the View menu are moved to a submenu; the Zoom In and Zoom Out commands are added to that submenu.

* Clone commands are moved into a submenu in Edit menu and given more descriptive names and tips.

* Pattern commands (Objects to Pattern and Pattern to Objects) are moved into a submenu in Object menu, under the new Clip and Mask submenus.

* The contents of the Effects menu are categorized into submenus, and several effects are renamed to use more intuitive names.

== Statusbar ==

* In Selector, for multiple selected objects, the statusbar now reports their types. For example, if 5 groups are selected, it displays

::5 objects of type Group in layer LayerName.

:instead of just "5 objects selected" as before. If there are up to 3 types in the selection, they will be listed, for example:

::5 objects of types Group, Path, Rectangle in layer LayerName.

:The order of the list will correspond to the order in which the objects were added to selection. If there are 4 or more types in selection, only the number of types is reported, for example:

::5 objects of 4 types in layer LayerName.

* In Selector, objects selected in groups are now identified as such, and the group ID is given, for example:

::Rectangle in group g212 (layer content)

:If selected objects have different parents within one layer (for example, if one is selected in a group and another outside it), the number of parents is reported:

::2 objects of types Rectangle, Path in 2 parents (layer content)

:If objects are in different layers, only the number of layers is reported since this also implies different parents:

::2 objects of types Rectangle, Path in 2 layers

* In Node tool, if your node selection includes nodes from different subpaths, statusbar reports the number of subpaths with selection and the total number of subpaths, for example:

::2 of 195 nodes selected in 2 of 36 subpaths.

* The contents of the statusbar message are now duplicated as a tooltip that is shown when you hover the mouse over the statusbar. [TODO: need to strip markup from the tooltips.]

* The statusbar text is now no longer just cut off if there is insufficient room, but an ellipsis (...) is inserted at the end to show there's more (only with Gtk 2.6 and newer).

== Theme ==

* Inkscape has a new default icon set titled "Crispy" provided by Andre Sousa. The new icons are intended to add a more professional and cohesive look to our application, as well as to make the functions the icons represent more self-evident.

* [new mouse cursors are coloured and antialiased - scislac]

= Clipping and masking =

Inkscape now provides some UI for using clipping paths and masks.

* Any object can be non-destructively intersected with a path (called a clipping path) so that only the intersected portion of the object is visible.
** To apply clipping, select the objects to be clipped and the clipping path object, make sure the clipping path is above the other objects in z-order, and do Object > Clip > Set.
** You can transform, edit, or style the clipped objects as usual. The clipping remains applied and transforms together with each clipped object.
** To remove the clipping, do Object > Clip > Release. The clipping path is returned to the drawing as a regular object; it is inserted on top of the unclipped object in z-order.

* Any object can be non-destructively masked by another object (called mask) so that: the mask's black or transparent areas become fully transparent in the masked object; mask's opaque white areas become fully opaque; and all intermediate colors translate into intermediate levels of opacity in the masked object. This allows you to apply, for example, arbitrary transparency gradients to objects.
** To apply a mask, select the objects to be masked and the mask object, make sure the mask is above the other objects in z-order, and do Object > Mask > Set.
** You can transform, edit, or style the masked objects as usual. The mask remains applied and transforms together with each masked object.
** To remove the masking, do Object > Mask > Release. The mask is returned to the drawing as a regular object; it is inserted on top of the unmasked object in z-order.

* Objects with clippath show their bounding box intersected with the bounding box of the clippath, instead of the original unclipped bbox as before. (However, this does not apply to objects without clippath of their own which are clipped by being inside a clipped group.)

* Clipped or masked objects display "clipped" or "masked", correspondingly, in their statusbar descriptions.

* Although Inkscape had render-only support for clipping paths and masks for quite some time, in this release we fixed a number of bugs which may affect the display of your documents using clippaths or masks.
** Clippaths and masks with objectBoundingBox units are now shown correctly upon loading of the document.
** Clippaths without fill didn't work, this is now fixed.
** Objects with clippaths or masks are correctly copied/pasted between documents.

= SVG conformance =

== Color profile support ==

Inkscape now includes base ICC profile functionality. If compiled with LittleCMS support (if you run <code>configure</code> with <code>--enable-lcms</code> switch), Inkscape passes the [http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-color-prof-01-f.html ICC color profile test] by W3C. The <color-profile> element has been implemented along with the "color-profile" attribute for <image> elements.

== <switch> support ==

Rendering support for SVG 1.1's '''Conditional Processing Module''' has been implemented, including ''switch'' element, ''requiredFeatures'', ''requiredExtensions'', ''systemLanguage'' attributes. Inkscape passes the Conditional processing tests ([http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-struct-cond-01-t.html] and [http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-struct-cond-02-t.html]) by W3C.

== SVG output ==

* In Inkscape's SVG documents, colors are now expressed by name (‘white’) or three-digit form (‘<tt>#f3c</tt>’) when possible.

* The numeric values in <code>transform</code> attributes are written without insignificant trailing zeros, and anything less than that 1e-8 by absolute value (usually caused by rounding errors) is written as 0 to reduce clutter.

= Transformations =

== Transform dialog ==

Fixes and improvements in the Transform dialog (Ctrl+Shift+M):

* The Apply to each object separately checkbox is added, allowing you to scale/rotate/skew each selected object by the same amount, around that object's center. When off (by default), the selection is transformed as a whole. The status of this checkbox is remembered across sessions. (It has no effect on Move and Matrix tabs).

* The Clear button resets the values on the current tab to defaults.

* The Scale tab now allows you to specify horizontal or vertical size increments in percentage or absolute units. Also, there's a Scale proportionally checkbox which ensures that scaling preserves the width/height ratio. (If you are scaling several objects proportionally with "Apply to each object separately", you can only use the % unit to specify the scaling; otherwise each object's scale increments will have the width/height ratio of the entire selection, not of that specific object.)

* The Skew tab can now specify the skew as an absolute displacement (e.g. for horizontal skewing of a rectangle, that means the shift of the top rectangle side relative to the bottom), as percentage displacement (e.g. a 1% horizontal skew of a rectangle means shifting the top side by 1% of the rectangle height), or as an angle (e.g. horizontal skew by 15 degrees results in the sides of a rectangle being rotated to that angle, while the top and bottom remain horizontal).

* The Matrix tab (previously called "Transform") can either edit the current <code>transform=</code> matrix of an object, or post-multiply the <code>transform=</code> with the matrix you specify, depending on the Edit current matrix checkbox. (As it is now redundant, the transformation matrix in the Object Properties dialog is removed.)

* The dialog now correctly watches selection changes in the active document window and updates its values accordingly.

* The layout of the dialog is simplified, tooltips and mnemonics added for better usability.

* Many bugs are fixed, especially in value conversions between units.

== Persistent rotation centers ==

* The position of the center (axis) of rotation and skewing used by Selector is now remembered for all objects and restored when you select those objects again (even after saving and reopening the document). When you move or scale an object, its rotation center is moved or scaled too, so its position relative to the object always remains the same unless you move it explicitly.

* When you have several objects selected, they use the rotation center of the first selected object. If the first object does not have center set (i.e. if it's in a default central position), then several objects will rotate around the geometric center of their common bounding box (as before).

* Shift+click on the rotation center resets it back to the center of the object's box.

* Consequently, dragging the rotation center is now an undoable action; you can press Ctrl+Z to undo the drag.

* Keyboard rotation by [, ] keys with various modifiers, as well as the Rotate tab in the Transform dialog, work around the selected object's rotation center (for multi-object selection, the rotation center of the first selected object).

* Rotation centers are preserved when duplicating, cloning (including clone tiler), grouping/ungrouping, and converting to path.

[TODO:
- make it work smartly for groups: if a group has center not set, return the center of the first object inside group with the center set

- a separate tab in the Transform dialog, with 9 buttons in the square grid (for setting it to object's corners, sides, and center) as well as x/y fields for setting center to any position

- make center snap to grid/guides/objects and to other centers

- make objects snap with their center to grid/guides/objects]

== Pasting size ==

A number of commands are added to easily scale selected objects to match the size of the object(s) previously copied to the clipboard. They are all in the Paste Size submenu in Edit menu:

* Paste Size scales the whole selection to match the overall size of the clipboard object(s).

* Paste Width/Paste Height scale the whole selection horizontally/vertically so that it matches the width/height of the clipboard object(s). These commands honor the scale ratio lock on the Selector controls bar (between W and H fields), so that when that lock is pressed, the other dimension of the selected object is scaled in the same proportion; otherwise the other dimension is unchanged.

* Paste Size Separately, Paste Width Separately and Paste Height Separately work similarly to the above described commands, except that they scale each selected object separately to make it match the size/width/height of the clipboard object(s).

= Tools =

== Node tool ==

=== Node sculpting ===

An entirely new way of manipulating paths in Node tool is added in this version: Node sculpting. Normally, when you have several nodes selected and you drag one of them, all selected nodes move by the same amount. Now, if you Alt-drag one of the selected nodes, only that node is fully displaced; other selected nodes are moved less than the full amount, so that those farthest from the drag point remain stationary. This is similar to "proportional editing" or "soft selection" in 3D editors such as Blender.

So, for example, if you select several nodes on a straight line and Alt+drag the middle selected node, the path will bend into a smooth bell-like curve. Nodes' handles are also adjusted correspondingly to keep the overall shape smooth and natural. (If you don't have enough nodes on a path fragment that you want to reshape in this way, just select the end nodes of that fragment and press Ins a few times to populate it with nodes.)

Moreover, node sculpting is sensitive to pressure of your tablet pen. If you press slightly, your curve will have a narrow sharp tip (i.e. the nearest neighbors of your dragged node will move only a bit); if you press hard, the curve's tip will be wide and blunt (i.e. the nearest neighbors will move almost as much as the dragged node). (Hint: to stop dragging without losing your shape, first release Alt and then lift the tip of the pen.)

There are many possible applications of the sculpting technique. To take a simple example, selecting all nodes of an ellipse-like shape and Alt+dragging one of them will smoothly and naturally stretch and skew the entire shape in any direction. Doing the same to a complex path, such as star or spiral, will twist and punch it without destroying its intricate structure - this is the way to get squashed or self-intersecting stars, eccentric spirals and other shapes not easily doable before. Selecting only part of all nodes allows you to smoothly reshape parts of the figure without disturbing the rest.

When applied to text converted to path, node sculpting is a fun and easy way to twist, bend and distort it, achieving effects similar to "perspective envelope" or "curvilinear envelope" in other programs - but in a more powerful and flexible way. For example, by selecting all or part of the text's nodes and Alt-dragging, you can not only make a wavy banner out of a paragraph of text, but also apply a "magnifying lens"-like effect to any word in the middle.

Especially useful node sculpting is for complex natural paths, such as calligraphic strokes or bitmap traces, where you often want to do large-scale pushes and bends without destroying the small-scale features. Things like making a calligraphic stroke narrower in one place and wider in another, or changing the proportions, extending the ear or flattening the nose of a head - all this is now much faster and more natural to do using sculpting. It is also a new way to create new paths, too - starting from en ellipse with added nodes, it takes just a few Alt+drags to tweak it into a silhouette of a head, or a map of Australia, or an Inkscape logo!

Some examples are shown on the screenshot: [[http://www.inkscape.org/screenshots/gallery/inkscape-0.44-nodesculpting.png]].

=== "Show handles" toggle ===

The Controls bar for the Nodes tool now includes a toggle button which controls whether Bezier handles are shown on selected nodes (on by default). Selecting and dragging nodes on node-dense paths in zoom-out (e.g. for node sculpting) may be extremely difficult without hiding the handles, as it's hard to pick a node and not a handle when handles are shown.

=== New deletion behavior ===

* In Node tool, deleting node(s) by Del/Backspace keys or by Ctrl+Alt+clicking a node now tries to preserve, as much as possible, the current shape of the path. This means that the nodes adjacent to those being deleted have their handles adjusted to approximate the form that the path had before deletion. For example, if you Ctrl+Alt+click a path twice, once to add a new node and then to delete it, the path will not change at all (or change very slightly). The old deletion behavior without adjusting handles is still available via Ctrl+Del or Ctrl+Backspace.

=== Preserving positions of nodes and handles ===

* When you switch the type of the selected node to Smooth or Symmetric by pressing Shift+S/Shift+Y, you can now preserve the position of one of the two handles by hovering your mouse over it, so that only the other handle is rotated/scaled to match.

* Similarly, when you join endnodes by pressing Shift+J, you can preserve the position of one of the two nodes by hovering your mouse over it, so that only the other node is moved.

=== Miscellaneous ===

* The ! key inverts node selection in the current subpath(s) (i.e. subpaths with at least one selected node); Alt+! inverts in the entire path. (This is similar to how these keys work in Selector, with current subpath(s) instead of the current layer.)

* The keyboard shortcut for "Make selected segments curves" in Node tool is changed from Shift+K to Shift+U for better mnemonics.

== Calligraphic pen ==

* Even when using a graphics tablet with pressure sensitivity, the Calligraphy pen's strokes often look too smooth and artificial. To enable a more natural look, the new Tremor parameter is added to the Calligraphy tool in this version. Adjustable in the Controls bar from 0.0 to 1.0, it will affect your strokes producing anything from slight unevenness to wild blotches and splotches. This significantly expands the creative range of the tool.

* In all previous versions, pen width depended on zoom in such a way that the strokes appeared the same visible width at any zoom, but were in fact narrower at zoom-in and wider at zoom-out. This behavior makes sense if you want to keep the same "feel" of the pen regardless of zoom; for example, if you zoomed in to make a small fix to your drawing, it's natural that your pen becomes physically smaller but feels the same to you. So, this behavior is kept as the default, but now we also added an alternative mode where your pen width is constant in absolute units regardless of zoom. To switch to this mode, use the checkbox on the tool's Preferences page (you can open it by double-clicking the tool button).

* The Width field in the tool's controls bar now changes from 1 to 100, which corresponds to the range from 0.01 to 1.0 in the previous version. If the "width in absolute units" mode is turned on, the value in this fields gives the width of the stroke in px units. In the default mode, the value of 100 gives 100px wide strokes only at 100% zoom, and strokes are correspondingly narrower or wider at other zoom levels.

* A new preferences option for the Calligraphic tool, Keep selected, controls whether the newly created object remains selected after you finish drawing it. If you turn it off (by default it's on) and set the tool to using Last Set color, you can easily choose a new color by clicking on the palette without having to worry if this will change the color of the stroke you just created. (Watch the tool style indicator at the right end of the Controls bar for the style of the next stroke you will draw.)

* Esc deselects selected objects in Calligraphic, as in most other tools.

* The stroke you're drawing is now shown, while you're drawing it, with the correct color and opacity that it will eventually have, instead of always black as before.

* On a new Inkscape installation, this tool now uses the last set style by default instead of the fixed black as before (this is changeable in the Inkscape Preferences for the tool).

== Pen tool ==

* While drawing a path, you can now move the last node you created by the same keys as in Node tool - that is, arrows, with Shift (for 10x displacement) or Alt (screen pixel displacement) modifiers.

* Also, you can switch the not-yet-finalized (red) segment of the path being drawn from curve to line (Shift+L) or back to curve (Shift+U), again the same shortcuts as in the Node tool.

* By popular demand, if a new path is being drawn but not yet finished, Ctrl+Z cancels that unfinished path (i.e. does the same as Esc), instead of undoing the previous action.

* In Pen tool, Del works the same as Backspace to delete the last created point on the unfinished path.

= Connectors and automatic layout =

* There have been numerous bugfixes and several improvements to the behaviour of connectors and the connector tool:
** Connectors moved as part of a selection will now stay attached to other objects in the selection, rather than becoming detached from them.
** By default, the Connector tool will not attach connectors to text objects. There is a new checkbox in the connector preferences to control this setting.
** The margins around avoided shapes (used for autorouting connectors) can now be adjusted via the "Spacing" control on the controls bar.

* Automatic Diagram Layout - A new button is available in the alignment and distribution dialogue that performs automatic layout of diagrams involving a network of shapes and connectors. Layout is accomplished using force-directed graph layout based on the Kamada-Kawai algorithm. This algorithm treats edges as if they are springs such that the distance between nodes will be proportional to the path length---number of connectors---between them. Disconnected components (where not every shape is connected) will be arranged around the circumference of a circle.

* There is a new Remove Overlaps button to move the selected objects enough that they don't overlap each other. A minimum spacing between the boundaries of objects can be specifiedTogether with the automatic layout tool, described above, this should be a significant addition to Inkscape's usability for diagramming. [Consider expanding this, comparing with existing Unclump and Distribute edge-to-edge buttons. - pjrm]

= Selective tracing with SIOX =

[ishmal]

= Snapping =

* [object snap - carl]

* [highlight - mtou]

* [only to visible gridlines - mtou]

* Guidelines are made easier to pick: now you don't need to position mouse exactly over a guideline to activate it, instead there's a small position tolerance (1 screen pixel on each side of the guideline).

= Sublayers =

Previously, it was only possible to make a group a temporary sublayer by entering that group. Now Inkscape supports creating and using true persistent sublayers within a layer.

* The Add layer dialog allows you to place the new layer above, below, or inside the current layer.

* Extended "Select All" option - now there is an option for "Select All" and TAB browsing to work in current layer with its sublayers.

= Extensions =

* The Effects menu is now always on, it's no longer an "experimental feature". The preference setting to enable the menu has been removed.

* Python extensions (which includes almost all currently available extensions) work on Windows out of the box, using a copy of Python shipping with Inkscape. The only minor inconvenience is that when an effect is launched, you get an empty console window that stays on while the effect is doing its work. (Don't close that window, it will disappear by itself when the effect is finished.)

* A new Python effect, Render > LaTeX formula, allows you to type in any LaTeX formula and get a vector object with the TeX rendition of this formula inserted into your document. You need to have latex, dvips, and pstoedit installed and in PATH for this to work.

* A new Python effect, Flatten Path, flattens paths in the current selection, approximating each path with a polyline whose segments meet the specified criteria for flatness.

* A new Python effect, Measure Path, attaches a text label to each path in the selection giving the length of that path (in px units).

* The Radius Randomize effect has a new parameter which enables normal distribution of random displacements instead of uniform as before, which gives a more natural feel to the randomized path.

* INX files now have the ability to hold more information. This includes tooltips and descriptions of the extensions. These are all also translatable.

= Formats =

* Inkscape's PDF export is now native (i.e. does not require any external applications) and supports transparency, including gradients with transparency. This replaced the old export extension that required Ghostscript and worked via Postscript, losing any transparency. The new PDF export is still immature; in particular it does not handle text, so you should check "Convert text to path" on the export options dialog. Other things not yet supported include: gradients on stroke; eccentric elliptic gradients; patterns, masks, and clipping paths; embedded images.

* [save zip with images - mipmip] collects the svg file and all linked images into a zip archive for distribution.

* An output format for desktop cutting plotters, such as the Wishblade and Craftrobo, was added. This format is a very minimalist DXF file with appropriate scaling and translation applied. This output format should not be expected to operate as a generalized DXF output.

* [xfig]

* [odg - ishmal]

* The new XCF output extension exports all top-level elements (i.e. layers and objects directly under root) as PNGs and assembles them into an XCF for procesing in the Gimp. Requires Python, PyXML and Gimp. Gimp 2.2.x or above must be in the path and be named <code>gimp</code>. A version of Inkscape 0.44 or above must be accessible from the path. Does not function in Windows.

= Configurable keyboard =

Inkscape's keyboard shortcuts are now configurable!

At this time, not all Inkscape actions can have their shortcuts customized. However, the majority of actions, including everything you see in the menus, are already configurable, and we're working on making more actions configurable.

On startup, Inkscape reads its keyboard shortcuts from <code>share/keys/default.xml</code>. That file is a copy of <code>inkscape.xml</code> in the same directory, which also contains keyboard emulation profiles for other vector editors:

*<code>xara.xml</code>: Xara X/Xara Xtreme/Xara LX keys

You can copy any of these over default.xml to use that profile. In all profiles, those keys which are not used by the corresponding program still have their Inkscape bindings. If you can contribute a profile for some vector editor that we don't yet have, we will appreciate that. The files have a simple XML-based format described in <code>inkscape.xml</code>.

You can also customize some of your keybindings without overwriting the main <code>default.xml</code>. If your profile directory (<code>~/.inkscape</code> on Linux) contains a <code>keys</code> subdirectory with a <code>default.xml</code> file, the keybindings from that file will overlay (i.e. add to, and override in case of a conflict) the default bindings. The format of your own <code>default.xml</code> is the same as that of the main <code>default.xml</code>.

= Miscellaneous shortcuts =

* Now you can use Shift+middle button drag, in any tool, to zoom into an area. This works the same as simple drag in Zoom tool, but is faster because it does not require switching away from your current tool. Together with middle button drag (panning), middle button click (zoom in) and Shift+middle button click (zoom out), this completes the set of canvas navigation shortcuts available in any tool or context.

* In Gradient tool, Shift+R reverses the gradient definition (i.e. mirrors the stop positions) without moving the gradient handles. For example, an elliptic gradient with blue center and red periphery becomes red in the center and blue in the periphery. This works on the gradient(s) of the currently selected gradient handle or, if no handle is selected, on all selected objects' gradients. (Compare with the Node tool where Shift+R reverses the direction of the selected path.) This is especially convenient for elliptic gradients which, unlike linear, you cannot simply rotate by 180 degrees for the same result.

* In Selector, Ctrl+Enter enters the selected group (making it a temporary layer). Ctrl+Backspace leaves the current layer and goes one layer up in the hierarchy (but not to root).

= Miscellaneous improvements =

* Document templates (listed in File > New) are now first searched in the <code>templates</code> subdirectory of the user's profile directory (on Linux it's <code>~/.inkscape/templates</code>), then in the system-wide Inkscape templates directory. This allows you to add your own templates on top of the list of standard templates, as well as override the default template with your own one (the <code>default.svg</code> in the profile directory has priority over the system-wide one).

* Converting stroke to path now correctly processes dashed strokes. For paths with markers, this command now creates a group containing the stroke converted to path and all its markers as independent objects (i.e. they are not markers anymore, but instead you can easily transform them or paint them any color, as a workaround for the "markers don't take the color of the stroke" bug).

* When toggling one of the "transform with object" buttons (for stroke width, rounded rectangle corners, gradients, or patterns), a message is displayed in the statusbar explaining what has changed in the program's behavior. Hopefully this will reduce the number of complaints from users who had accidentally toggled one of these and were surprised by the result.

* Whole thousands above 2000 in the rulers are now displayed as 2k, 3k, 4k etc.

* In the Document Preferences dialog, the new object style for each tool is now shown as a style swatch (displaying fill/stroke colors and opacity, stroke width, and master opacity), similar in design to the selected style indicator in the statusbar.

* In the Grid Arrange dialog, row/column spacing can now be negative.

* The installation default is now to scale the rounded rectangle corners with the rectangles themselves (the previous default mode, still available as an option, was to keep rounding radii unchanged when scaling rectangles).

* Added a new <code>--export-area-canvas</code> command line parameter that causes the exported PNG to contain the full canvas. This option as well as <code>--export-area-drawing</code> and <code>--export-area</code> can now be used along with <code>--export-id</code> and <code>--export-id-only</code> for greater flexibility.

* The <code>--query-*</code> command line parameters now return the true SVG bounding box of the object instead of the Inkscape coordinate system bbox (with inverted Y axis). The new behavior makes more sense for scripting use of Inkscape.

* The dpi value in the Export dialog has had its range extended; now possible values are from 0.01 to 100000.

* Individual <tspan>s within text objects (including line tspans) can now be selected via the XML editor to view their bounding boxes (though per SVG, you cannot transform them). Also, you can use the <code>--query-*</code> command line parameters to find out the bounding boxes of tspans from a script. (Individual strings within or between tspans are still not selectable, and they cannot have an ID for querying anyway.)

* The placeholder image which is shown when a bitmap file was no longer accessible reads now "Linked image not found" instead of the confusing "Broken image".

* Cloning multiple selected objects now works as expected (i.e. each selected object is cloned separately, similar to the Duplicate command). Previously you could only clone a single selected object.

* The separate "license" and "contributors" dialogs have been merged into tabs on the About dialog. The about dialog now correctly sizes itself to fit the size of the splash SVG (while remaining resizable), and the rendering area is now cropped to the correct aspect ratio when the dialog is resized. The dialog also now displays the build information in the upper right corner.

* [new cursors - scislac]

* In the Transform dialog / Rotate tab, the icon was flipped horizontally to be in line with the direction of positive rotation; the change was applied to the default (now crispy) and legacy icon sets.

* The scale ratio lock button on the Selector controls bar shows a closed lock when pressed and open lock otherwise (same as the layer lock in the statusbar).

* The Browse button on Export dialog now opens the new file chooser, same as those used by Open and Save.

* A new RazorWire path marker was added. By applying it as a mid-marker you can get a good approximation of a razor wire.

= Miscellaneous bugfixes =

* Reading a document with an incorrect namespace URI not only did not cause Inkscape to complain, but could also "pollute" Inkscape's internal namespace table, resulting in an "infection" of subsequently saved documents by the incorrect namespace. This is now fixed, but as a result, documents with incorrect namespace URIs will no longer load. You will have to edit them in a text editor to fix the namespaces.

* With newer versions of GTK, dragging with graphics tablet pen did not work in some tools and contexts (in particular, in Node and Rectangle tools). This is fixed.

* Scaling of objects with stroke in Selector used to cause undesired shifts of the scaled object, as well as scaling it in the dimension which was intended to remain untouched (e.g. slight change in width when you scale only height). All these problems are now fixed, both for interactive scaling by mouse and for numeric scaling via the Controls bar, and for both values of the "Scale stroke with objects" option. Among other things, this means that stroked objects no longer lose snapping on scale, and that the "Default scale origin" option in the Selector tool preferences finally works as designed. Caveat: There may still be problems if you scale a selection that contains objects with different stroke widths.

* Scaling of stroke now works for objects that didn't specify stroke-width; before, they always ended up with the default 1px stroke.

* The bounding box for text and flowed text objects did not include stroke width. This has been fixed.

* Stroke miterlimit on text objects was misinterpreted in absolute units instead of multiplies of stroke width (resulting in miter joins rendered as bevel).

* The unfinished path in Pen tool is now cancelled, not finalized, when you switch away from the Pen tool. Apart from being more intuitively correct, this also fixes a crash when you quit Inkscape with the unfinished path in Pen tool.

* Fonts on Win32 now use the native font mapper, meaning that Inkscape's font list is the same as other Windows programs, and the (potentially) very long delay experienced when using fonts for the first time in each session is gone.

* Setting dash pattern was broken for transformed objects, and copy/paste of style with dash pattern did not apply correctly to objects with transforms.

* An error caused a complete extra screen redraw after each zoom operation. That is, after you press "+" in a complex drawing, Inkscape redraws, but for some time after that it remains still unresponsive because it does that second redraw (invisibly for you, i.e. nothing changes on the screen). This is fixed.

* Gradient rendering was off by one pixel, which often resulted in visibly wrong gradient rendering for small objects or in zoom-out.

* The SVG path parser could not handle fractional numbers with the initial dot.

* Several pattern rendering bugs are fixed, discovered by working with SVG files exported from Adobe Illustrator.

* Inkscape on Mac OS X will now notice fonts in your ~/Library/Fonts directory, in addition to the other standard places.

* Inkscape couldn't be compiled with libxml versions <= 2.6.9, and we now bumped the requirements from 2.6.0 up to libxml >= 2.6.11, which is the earliest you can get officially, anyway.

* Inkscape no longer crashes when presented with a defective inx file for extensions.

* More document memory is now freed when documents are closed.

* EPS output now correctly includes an %%EOF footer.

* There was a regression in 0.43 that caused several minor, though annoying bugs; knots and handles remained highlighted after the mouse was released, and the rubberband selection rectangle stayed visible if the selection was ended over a node while in the node tool. This regression has been fixed.

* The connector routing code would previously sometimes confuse objects between multiple documents resulting in strange routing behaviour. This has been fixed.

* There existed a bug in 0.43's Inkboard code that allowed a malicious outsider to very easily disrupt an Inkboard session. This has been fixed.

* There existed a bug in 0.43's Inkboard code that would cause deadlocks in the case that two users attempted to invite each other at the same time (see bug #[https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1352522&group_id=93438 1352522] for further details). This should be fixed, although the fix has not been widely tested.

* There existed a bug in 0.43's Inkboard code that would cause session invitations to not appear on the invitee's screen. This was the result of a mistake in handling GDK modifier flags, and has been fixed.

= Translations =

* INX files (containing the UI of the external effects) now allow the user visible strings to be translated. This means that effect dialogs, file type selections, and extension names can all be translated by translators.

= Internal =

* The Document Properties Dialog code was completely gtkmmified, which lead to dramatic reduction of code size due to usage of widget objects. The used widget objects should be reusable by other dialogs, too, and the code is much more readable.

* Work on optimizing includes in all cpp files started, using the purgeincludes tool specifically written for that purpose, and ended with 40% of include lines removed!

= Known problems =

=== Namespaces may need fixing ===

* Previous versions of inkscape sometimes silently saved documents with wrong namespace URIs. This has been fixed, but such corrupted documents will no longer load successfully. Such documents may require their namespace declarations to be fixed by hand.

=== Beware of defective themes on Linux ===

* Inkscape and other Gtk programs can crash on any Linux, when the gtk2-engines-smooth / libsmooth package is installed. We have filed a bug against libsmooth which is now in gtk-engine and part of gnome. Removing the package resolves the problem, however, but it would be nice if you as affected user would inform the gtk-engines maintainers of the problem. See especially http://bugzilla.gnome.org/show_bug.cgi?id=312115 (thanks to Thomas Wood)
* A similar crash happens if the KDE Baghira theme or the package gtk_qt_engine are installed. If you experience Inkscape crashes on KDE, please try to install a different theme from Baghira, or uninstall the gtk_qt_engine package from your system. Both problems also affect older versions of Inkscape.

= Previous releases =

* ReleaseNotes043 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes043)
* ReleaseNotes042 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes042)
* ReleaseNotes041 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes041)
* ReleaseNotes040 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes040)
* ReleaseNotes039 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes039)
* ReleaseNotes038 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes038)
* ReleaseNotes037 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes037)
* ReleaseNotes036 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes036)
* ReleaseNotes035 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes035)

Release notes/0.44

2006-05-28T06:13:48Z

Pjrm: /* Sublayers */ Grammar: no apostrophe in possessive "its"

== Inkscape 0.44: overview ==

Inkscape 0.44 is bigger and better than ever. Some highlights:

* Layers dialog

* Outline mode, many performance improvements

* Native PDF export with transparency

* Clipping and masking support

* Configurable keyboard shortcuts, including Xara X emulation

* Docked color palette in the editing window

* Interactive indicator of the style of selection in the statusbar

* Innovative "node sculpting" and other improvements in Node tool

* Extensions are enabled by default and work on both Linux and Windows

* Better SVG support: <switch> element, ICC color profiles for images

* Persistent rotation centers, Paste Size command

* Redesigned preferences dialogs, new icons, rearranged menus, many cosmetic improvements

* Hundreds of bugfixes and smaller features

* Not directly related to Inkscape, but important nevertheless: since our last release, [http://www.mozilla.com/firefox/ Firefox 1.5] was released with SVG support enabled by default. This means that you can now view any Inkscape document right in your Firefox window without any format conversions or installing any plugins!

= Performance =

== Outline mode ==

An Outline ("wireframe") display mode is implemented. Use the View > Display Mode > Outline to activate it. In this mode:

* all paths and shapes are rendered as inverse (black on light background and vice versa) outlines of constant width (1 screen pixel regardless of zoom), without fill;

* text is painted by inverse fill, without stroke;

* bitmaps are shown as is;

* any opacity and gradients are ignored.

The outline mode is usually not drastically faster than regular mode (usually 10% to 50% faster), and in some special cases it may even be slower. However, the value of the outline mode is not only in its speed; it is a good way to get an idea of the structure and objects of your document, and it is convenient for precision node editing and for finding "stray objects".

== Speed ==

In addition to the Outline mode which makes it much easier to work with complex drawings, this version of Inkscape also provides significant speed improvements in many areas.

* Thanks to optimizations in the renderer, Inkscape's screen redraw is faster by at least 10%, and in some cases (such as complex stroked/dashed paths at high zooms) up to three times faster.

* Optimizations in the Node tool resulted in noticeable speed gains for node editing. Thus, switching to and from the Node tool (with a path selected), as well as selecting nodes in that tool, are now at least ten times faster than before. Other operations, including curve and node dragging and move/scale/rotate operations on multiple selected nodes, are much faster as well. This is especially important when working with complex paths; with these optimizations, paths containing several thousand nodes, though still slow, are much more usable.

* An optimization in the attribute setting method made operations such as moving multiple objects with arrow keys at least 30% faster compared to 0.43. This is especially noticeable when you are moving clones selected together with their original (e.g. a clone tiling), in which case Inkscape now works three to four times faster.

* Interface icons are now rendered in the background (from SVG source in <code>share/icons/icons.svg</code>) when Inkscape is idle, rather than waiting for all the icons in a menu to render the first time you pull it up. This eliminates the annoying delay when opening menus for the first time.

* Previously, zooming in to view a small portion of a path (especially big and complex path), there was a very noticeable slowdown and memory use increased dramatically. We optimized the renderer to only process the visible part of a path, and as a result the rendering speed is now almost the same at any zoom up to the maximum, providing up to 10-40 times speedup compared to the previous version (the closer is the zoom, the greater is the gain).

= Interface =

== Layers dialog ==

* Ctrl+Shift+L [joncruz, mental]

== Selected style indicator ==

A new control in the left end of the statusbar lets you quickly view and change the fill and stroke of the selected objects. When you have a text selection in Text tool or a gradient handle selected in the Gradient tool, this indicator displays and changes the style of the text fragment or gradient stop, instead of the entire object (it's the same behavior as the Fill&Stroke dialog.)

* The two indicators, labelled F: (top) and S: (bottom), display fill and stroke of the selected object(s) correspondingly. (For gradient handles, they always display the same style.)

* Each fill/stroke indicator can display either a color+opacity swatch (the opacity shown here is the fill opacity or stroke opacity, not the master opacity) or a text label specifying N/A (nothing selected), None (no fill/stroke), Unset (unset fill/stroke), L Gradient, R Gradient, Pattern (corresponding fill/stroke types), or Different (selected objects have different fill/stroke types).

* Additionally, each indicator may be accompanied by one of two flags, m ("multiple", meaning there are two or more objects all with the same fill/stroke) or a ("averaged", meaning there are two or more objects with different flat colors in fill/stroke, and the indicator shows the average of these colors).

* Left-click on an indicator opens or activates the Fill&Stroke dialog with the corresponding tab (Fill or Stroke) active.

* Right-click on an indicator opens a popup menu with the following items:
** Edit fill/stroke...: Opens or activates the Fill&Stroke dialog with the corresponding tab selected. (Same as left-click.)
** Last set color: Applies to the selected objects the fill/stroke color that was last applied to anythig.
** Last selected color: Applies to the selected objects the fill/stroke color that was last displayed in this indicator. (Allows you to easily copy fill/stroke color between objects: select source, select destination, apply "last selected color".)
** Invert: Sets the fill or stroke to the inverse of the current color (does not affect opacity).
** White, Black: Sets the fill or stroke to the corresponding color (fully opaque).
** Copy color, Paste color: Copies or pastes the fill or stroke color (when it's color) to/from the system clipboard, as text in the <code>#rrggbb</code> hex format.
** Swap fill and stroke: Exchanges fill and stroke (both their types and colors, if any).
** Make fill/stroke opaque: Removes fill or stroke transparency (not master transparency!).
** Unset fill/stroke: Unsets fill or stroke from selected objects.
** Remove fill/stroke: Removes fill or stroke from the selected objects.

* Middle-click on a fill/stroke indicator removes fill/stroke from selected objects; if it is already removed (i.e. if the indicator displays "None"), it does the same as the "Last set color" command from the popup menu.

* Drag and Drop of colors onto a fil/stroke indicator sets the fill and stroke of the selected object(s) correspondingly.

* The Stroke indicator also displays the stroke width of selection (averaged if there are multiple objects selected with different stroke widths), located to the right of the stroke color/transparency swatch. Left-clicking on it opens the Fill&Stroke dialog with the Stroke Style tab selected. Right-clicking on it opens a popup menu which allows you to choose the units for displaying the stroke width, as well as choose one of the presets to assign to selection.

* To the right of the fill/stroke indicators, the Opacity numeric field (labelled "O:") shows and allows you to change the master opacity of the selected object (or the averaged opacity of several selected objects). Right-clicking the numeric field opens a popup menu with preset opacity levels. Middle-clicking on the "O:" label cycles the opacity through the values of 0 (transparent), 0.5, and 1 (opaque).

The zoom field and the cursor coordinates indicator have been rearranged for compactness and moved to the right end of the statusbar. There's also a window resize handle added at the very end of the statusbar.

== Tool style indicators ==

For each object-creating tool (shapes, Pen/Pencil, Calligraphic, Text), the Controls bar (above the canvas) now includes a style indicator on the right. This indicator shows you which style the newly created object will have. The indicator correctly displays whichever style the tool is set to use - the global "last set" style or that tool's fixed style. For example, clicking on a palette swatch (even with nothing selected) changes the "last set" color and, if your tool is set to use the last set color, its indicator is updated, giving you an idea of your "brush" before you start to draw.

== Controls bar for the Text tool ==

[deadchip]

== Docked color palette ==

* Previously, color swatches could only be used from a floating palette (Ctrl+Shift+W). Now the color swatches palette is embedded in the main UI, at the bottom of the window between the canvas and the statusbar. It is enabled by default; use View > Show/Hide > Palette to enable or disable it. The docked palette has the same functionality as the floating one; use a button in the top right corner to access the swatches menu.

* All standard sizes of the swatches (Tiny, Small, Medium, Large, Huge) are made smaller overall.

* The Wrap option (off by default) in the swatches menu converts the palette from a single row into a frame 2 or 3 rows high, for better access to colors in large palettes.

* Drag and Drop of colors has been enabled.
** Dragging colors from a palette shows a live swatch of the color being dragged under cursor.
** Drag and Drop of colors onto the selected style indicator in the statusbar sets the fill or stroke of the selected object(s).
** Colors can be dropped directly on to objects on canvas to set their fill, or shift+dropped to set their stroke. This affects only the object you drop the color on, regardless of whether that object is selected or not.
** Colors can be dragged to and from other applications.

* The new Inkscape default color palette was added. It contains a range of grays, standard HTML named colors, and a full range of colors sorted by their HSL values (475 colors overall). It is generated by a Python script which is available from Inkscape SVN in share/palettes.

* A number of specialized color palettes, useful in color-coordinated projects, was borrowed from GIMP: Reds, Greens, Blues, Gold, Royal, Khaki, Hilite, and Topographic.

== Inkscape Preferences dialog ==

Not only was the Inkscape Preferences dialog completely rewritten and redesigned, it is now also fully GNOME-HIG compliant. Numerous bugs were taken care of with the rewrite. As a new feature, the Simplify threshold can now be set with more precision.

== Document Properties / Metadata dialogs ==

* The Document Preferences dialog is now named Document Properties, and it was split in two: metadata were extracted into the Document Metadata dialog; metadata widgets are now also spread over two pages.

* A button was added to fit the canvas to the current selection or, if there's no selection, to the entire drawing. The button resizes the canvas and, if necessary, moves the drawing into place. It is now very easy to size the canvas to an illustration after it is ready.

* New controls: the new object snapping features required their own property widgets, and you can set the snapping sensitivity with a slider, or let it snap regardless of distance (grid only).

* Rearrangements within Document Properties: everything snapping-related was collected on one page; Grid and Guide widgets are on their own, the same page. For better HIG compliance, all widgets were categorized; especially the widgets on the Page page were completely rearranged in the General/Format/Border categories.

* Bug fixes: grayed out license URI had too low contrast, so it's no longer grayed out; the proprietary license didn't clean the license URI; spinbuttons had no tooltips, and minor grid quirks were removed; data was not updated when a new file replaced another in the same window.

* HIG compliance: much work went into that, and now only a few details are missing from full Gnome-HIG compliance.

* Updated Creative Commons Licenses: Updated CC licenses to the latest 2.5 versions by default in the license tab of the metadata dialog.

== Menus ==

* Zoom commands in the View menu are moved to a submenu; the Zoom In and Zoom Out commands are added to that submenu.

* Clone commands are moved into a submenu in Edit menu and given more descriptive names and tips.

* Pattern commands (Objects to Pattern and Pattern to Objects) are moved into a submenu in Object menu, under the new Clip and Mask submenus.

* The contents of the Effects menu are categorized into submenus, and several effects are renamed to use more intuitive names.

== Statusbar ==

* In Selector, for multiple selected objects, the statusbar now reports their types. For example, if 5 groups are selected, it displays

::5 objects of type Group in layer LayerName.

:instead of just "5 objects selected" as before. If there are up to 3 types in the selection, they will be listed, for example:

::5 objects of types Group, Path, Rectangle in layer LayerName.

:The order of the list will correspond to the order in which the objects were added to selection. If there are 4 or more types in selection, only the number of types is reported, for example:

::5 objects of 4 types in layer LayerName.

* In Selector, objects selected in groups are now identified as such, and the group ID is given, for example:

::Rectangle in group g212 (layer content)

:If selected objects have different parents within one layer (for example, if one is selected in a group and another outside it), the number of parents is reported:

::2 objects of types Rectangle, Path in 2 parents (layer content)

:If objects are in different layers, only the number of layers is reported since this also implies different parents:

::2 objects of types Rectangle, Path in 2 layers

* In Node tool, if your node selection includes nodes from different subpaths, statusbar reports the number of subpaths with selection and the total number of subpaths, for example:

::2 of 195 nodes selected in 2 of 36 subpaths.

* The contents of the statusbar message are now duplicated as a tooltip that is shown when you hover the mouse over the statusbar. [TODO: need to strip markup from the tooltips.]

* The statusbar text is now no longer just cut off if there is insufficient room, but an ellipsis (...) is inserted at the end to show there's more (only with Gtk 2.6 and newer).

== Theme ==

* Inkscape has a new default icon set titled "Crispy" provided by Andre Sousa. The new icons are intended to add a more professional and cohesive look to our application, as well as to make the functions the icons represent more self-evident.

* [new mouse cursors are coloured and antialiased - scislac]

= Clipping and masking =

Inkscape now provides some UI for using clipping paths and masks.

* Any object can be non-destructively intersected with a path (called a clipping path) so that only the intersected portion of the object is visible.
** To apply clipping, select the objects to be clipped and the clipping path object, make sure the clipping path is above the other objects in z-order, and do Object > Clip > Set.
** You can transform, edit, or style the clipped objects as usual. The clipping remains applied and transforms together with each clipped object.
** To remove the clipping, do Object > Clip > Release. The clipping path is returned to the drawing as a regular object; it is inserted on top of the unclipped object in z-order.

* Any object can be non-destructively masked by another object (called mask) so that: the mask's black or transparent areas become fully transparent in the masked object; mask's opaque white areas become fully opaque; and all intermediate colors translate into intermediate levels of opacity in the masked object. This allows you to apply, for example, arbitrary transparency gradients to objects.
** To apply a mask, select the objects to be masked and the mask object, make sure the mask is above the other objects in z-order, and do Object > Mask > Set.
** You can transform, edit, or style the masked objects as usual. The mask remains applied and transforms together with each masked object.
** To remove the masking, do Object > Mask > Release. The mask is returned to the drawing as a regular object; it is inserted on top of the unmasked object in z-order.

* Objects with clippath show their bounding box intersected with the bounding box of the clippath, instead of the original unclipped bbox as before. (However, this does not apply to objects without clippath of their own which are clipped by being inside a clipped group.)

* Clipped or masked objects display "clipped" or "masked", correspondingly, in their statusbar descriptions.

* Although Inkscape had render-only support for clipping paths and masks for quite some time, in this release we fixed a number of bugs which may affect the display of your documents using clippaths or masks.
** Clippaths and masks with objectBoundingBox units are now shown correctly upon loading of the document.
** Clippaths without fill didn't work, this is now fixed.
** Objects with clippaths or masks are correctly copied/pasted between documents.

= SVG conformance =

== Color profile support ==

Inkscape now includes base ICC profile functionality. If compiled with LittleCMS support (if you run <code>configure</code> with <code>--enable-lcms</code> switch), Inkscape passes the [http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-color-prof-01-f.html ICC color profile test] by W3C. The <color-profile> element has been implemented along with the "color-profile" attribute for <image> elements.

== <switch> support ==

Rendering support for SVG 1.1's '''Conditional Processing Module''' has been implemented, including ''switch'' element, ''requiredFeatures'', ''requiredExtensions'', ''systemLanguage'' attributes. Inkscape passes the Conditional processing tests ([http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-struct-cond-01-t.html] and [http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-struct-cond-02-t.html]) by W3C.

== SVG output ==

* In Inkscape's SVG documents, colors are now expressed by name (‘white’) or three-digit form (‘<tt>#f3c</tt>’) when possible.

* The numeric values in <code>transform</code> attributes are written without insignificant trailing zeros, and anything less than that 1e-8 by absolute value (usually caused by rounding errors) is written as 0 to reduce clutter.

= Transformations =

== Transform dialog ==

Fixes and improvements in the Transform dialog (Ctrl+Shift+M):

* The Apply to each object separately checkbox is added, allowing you to scale/rotate/skew each selected object by the same amount, around that object's center. When off (by default), the selection is transformed as a whole. The status of this checkbox is remembered across sessions. (It has no effect on Move and Matrix tabs).

* The Clear button resets the values on the current tab to defaults.

* The Scale tab now allows you to specify horizontal or vertical size increments in percentage or absolute units. Also, there's a Scale proportionally checkbox which ensures that scaling preserves the width/height ratio. (If you are scaling several objects proportionally with "Apply to each object separately", you can only use the % unit to specify the scaling; otherwise each object's scale increments will have the width/height ratio of the entire selection, not of that specific object.)

* The Skew tab can now specify the skew as an absolute displacement (e.g. for horizontal skewing of a rectangle, that means the shift of the top rectangle side relative to the bottom), as percentage displacement (e.g. a 1% horizontal skew of a rectangle means shifting the top side by 1% of the rectangle height), or as an angle (e.g. horizontal skew by 15 degrees results in the sides of a rectangle being rotated to that angle, while the top and bottom remain horizontal).

* The Matrix tab (previously called "Transform") can either edit the current <code>transform=</code> matrix of an object, or post-multiply the <code>transform=</code> with the matrix you specify, depending on the Edit current matrix checkbox. (As it is now redundant, the transformation matrix in the Object Properties dialog is removed.)

* The dialog now correctly watches selection changes in the active document window and updates its values accordingly.

* The layout of the dialog is simplified, tooltips and mnemonics added for better usability.

* Many bugs are fixed, especially in value conversions between units.

== Persistent rotation centers ==

* The position of the center (axis) of rotation and skewing used by Selector is now remembered for all objects and restored when you select those objects again (even after saving and reopening the document). When you move or scale an object, its rotation center is moved or scaled too, so its position relative to the object always remains the same unless you move it explicitly.

* When you have several objects selected, they use the rotation center of the first selected object. If the first object does not have center set (i.e. if it's in a default central position), then several objects will rotate around the geometric center of their common bounding box (as before).

* Shift+click on the rotation center resets it back to the center of the object's box.

* Consequently, dragging the rotation center is now an undoable action; you can press Ctrl+Z to undo the drag.

* Keyboard rotation by [, ] keys with various modifiers, as well as the Rotate tab in the Transform dialog, work around the selected object's rotation center (for multi-object selection, the rotation center of the first selected object).

* Rotation centers are preserved when duplicating, cloning (including clone tiler), grouping/ungrouping, and converting to path.

[TODO:
- make it work smartly for groups: if a group has center not set, return the center of the first object inside group with the center set

- a separate tab in the Transform dialog, with 9 buttons in the square grid (for setting it to object's corners, sides, and center) as well as x/y fields for setting center to any position

- make center snap to grid/guides/objects and to other centers

- make objects snap with their center to grid/guides/objects]

== Pasting size ==

A number of commands are added to easily scale selected objects to match the size of the object(s) previously copied to the clipboard. They are all in the Paste Size submenu in Edit menu:

* Paste Size scales the whole selection to match the overall size of the clipboard object(s).

* Paste Width/Paste Height scale the whole selection horizontally/vertically so that it matches the width/height of the clipboard object(s). These commands honor the scale ratio lock on the Selector controls bar (between W and H fields), so that when that lock is pressed, the other dimension of the selected object is scaled in the same proportion; otherwise the other dimension is unchanged.

* Paste Size Separately, Paste Width Separately and Paste Height Separately work similarly to the above described commands, except that they scale each selected object separately to make it match the size/width/height of the clipboard object(s).

= Tools =

== Node tool ==

=== Node sculpting ===

An entirely new way of manipulating paths in Node tool is added in this version: Node sculpting. Normally, when you have several nodes selected and you drag one of them, all selected nodes move by the same amount. Now, if you Alt-drag one of the selected nodes, only that node is fully displaced; other selected nodes are moved less than the full amount, so that those farthest from the drag point remain stationary. This is similar to "proportional editing" or "soft selection" in 3D editors such as Blender.

So, for example, if you select several nodes on a straight line and Alt+drag the middle selected node, the path will bend into a smooth bell-like curve. Nodes' handles are also adjusted correspondingly to keep the overall shape smooth and natural. (If you don't have enough nodes on a path fragment that you want to reshape in this way, just select the end nodes of that fragment and press Ins a few times to populate it with nodes.)

Moreover, node sculpting is sensitive to pressure of your tablet pen. If you press slightly, your curve will have a narrow sharp tip (i.e. the nearest neighbors of your dragged node will move only a bit); if you press hard, the curve's tip will be wide and blunt (i.e. the nearest neighbors will move almost as much as the dragged node). (Hint: to stop dragging without losing your shape, first release Alt and then lift the tip of the pen.)

There are many possible applications of the sculpting technique. To take a simple example, selecting all nodes of an ellipse-like shape and Alt+dragging one of them will smoothly and naturally stretch and skew the entire shape in any direction. Doing the same to a complex path, such as star or spiral, will twist and punch it without destroying its intricate structure - this is the way to get squashed or self-intersecting stars, eccentric spirals and other shapes not easily doable before. Selecting only part of all nodes allows you to smoothly reshape parts of the figure without disturbing the rest.

When applied to text converted to path, node sculpting is a fun and easy way to twist, bend and distort it, achieving effects similar to "perspective envelope" or "curvilinear envelope" in other programs - but in a more powerful and flexible way. For example, by selecting all or part of the text's nodes and Alt-dragging, you can not only make a wavy banner out of a paragraph of text, but also apply a "magnifying lens"-like effect to any word in the middle.

Especially useful node sculpting is for complex natural paths, such as calligraphic strokes or bitmap traces, where you often want to do large-scale pushes and bends without destroying the small-scale features. Things like making a calligraphic stroke narrower in one place and wider in another, or changing the proportions, extending the ear or flattening the nose of a head - all this is now much faster and more natural to do using sculpting. It is also a new way to create new paths, too - starting from en ellipse with added nodes, it takes just a few Alt+drags to tweak it into a silhouette of a head, or a map of Australia, or an Inkscape logo!

Some examples are shown on the screenshot: [[http://www.inkscape.org/screenshots/gallery/inkscape-0.44-nodesculpting.png]].

=== "Show handles" toggle ===

The Controls bar for the Nodes tool now includes a toggle button which controls whether Bezier handles are shown on selected nodes (on by default). Selecting and dragging nodes on node-dense paths in zoom-out (e.g. for node sculpting) may be extremely difficult without hiding the handles, as it's hard to pick a node and not a handle when handles are shown.

=== New deletion behavior ===

* In Node tool, deleting node(s) by Del/Backspace keys or by Ctrl+Alt+clicking a node now tries to preserve, as much as possible, the current shape of the path. This means that the nodes adjacent to those being deleted have their handles adjusted to approximate the form that the path had before deletion. For example, if you Ctrl+Alt+click a path twice, once to add a new node and then to delete it, the path will not change at all (or change very slightly). The old deletion behavior without adjusting handles is still available via Ctrl+Del or Ctrl+Backspace.

=== Preserving positions of nodes and handles ===

* When you switch the type of the selected node to Smooth or Symmetric by pressing Shift+S/Shift+Y, you can now preserve the position of one of the two handles by hovering your mouse over it, so that only the other handle is rotated/scaled to match.

* Similarly, when you join endnodes by pressing Shift+J, you can preserve the position of one of the two nodes by hovering your mouse over it, so that only the other node is moved.

=== Miscellaneous ===

* The ! key inverts node selection in the current subpath(s) (i.e. subpaths with at least one selected node); Alt+! inverts in the entire path. (This is similar to how these keys work in Selector, with current subpath(s) instead of the current layer.)

* The keyboard shortcut for "Make selected segments curves" in Node tool is changed from Shift+K to Shift+U for better mnemonics.

== Calligraphic pen ==

* Even when using a graphics tablet with pressure sensitivity, the Calligraphy pen's strokes often look too smooth and artificial. To enable a more natural look, the new Tremor parameter is added to the Calligraphy tool in this version. Adjustable in the Controls bar from 0.0 to 1.0, it will affect your strokes producing anything from slight unevenness to wild blotches and splotches. This significantly expands the creative range of the tool.

* In all previous versions, pen width depended on zoom in such a way that the strokes appeared the same visible width at any zoom, but were in fact narrower at zoom-in and wider at zoom-out. This behavior makes sense if you want to keep the same "feel" of the pen regardless of zoom; for example, if you zoomed in to make a small fix to your drawing, it's natural that your pen becomes physically smaller but feels the same to you. So, this behavior is kept as the default, but now we also added an alternative mode where your pen width is constant in absolute units regardless of zoom. To switch to this mode, use the checkbox on the tool's Preferences page (you can open it by double-clicking the tool button).

* The Width field in the tool's controls bar now changes from 1 to 100, which corresponds to the range from 0.01 to 1.0 in the previous version. If the "width in absolute units" mode is turned on, the value in this fields gives the width of the stroke in px units. In the default mode, the value of 100 gives 100px wide strokes only at 100% zoom, and strokes are correspondingly narrower or wider at other zoom levels.

* A new preferences option for the Calligraphic tool, Keep selected, controls whether the newly created object remains selected after you finish drawing it. If you turn it off (by default it's on) and set the tool to using Last Set color, you can easily choose a new color by clicking on the palette without having to worry if this will change the color of the stroke you just created. (Watch the tool style indicator at the right end of the Controls bar for the style of the next stroke you will draw.)

* Esc deselects selected objects in Calligraphic, as in most other tools.

* The stroke you're drawing is now shown, while you're drawing it, with the correct color and opacity that it will eventually have, instead of always black as before.

* On a new Inkscape installation, this tool now uses the last set style by default instead of the fixed black as before (this is changeable in the Inkscape Preferences for the tool).

== Pen tool ==

* While drawing a path, you can now move the last node you created by the same keys as in Node tool - that is, arrows, with Shift (for 10x displacement) or Alt (screen pixel displacement) modifiers.

* Also, you can switch the not-yet-finalized (red) segment of the path being drawn from curve to line (Shift+L) or back to curve (Shift+U), again the same shortcuts as in the Node tool.

* By popular demand, if a new path is being drawn but not yet finished, Ctrl+Z cancels that unfinished path (i.e. does the same as Esc), instead of undoing the previous action.

* In Pen tool, Del works the same as Backspace to delete the last created point on the unfinished path.

= Connectors and automatic layout =

* There have been numerous bugfixes and several improvements to the behaviour of connectors and the connector tool:
** Connectors moved as part of a selection will now stay attached to other objects in the selection, rather than becoming detached from them.
** By default, the Connector tool will not attach connectors to text objects. There is a new checkbox in the connector preferences to control this setting.
** The margins around avoided shapes (used for autorouting connectors) can now be adjusted via the "Spacing" control on the controls bar.

* Automatic Diagram Layout - A new button is available in the alignment and distribution dialogue that performs automatic layout of diagrams involving a network of shapes and connectors. Layout is accomplished using force-directed graph layout based on the Kamada-Kawai algorithm. This algorithm treats edges as if they are springs such that the distance between nodes will be proportional to the path length---number of connectors---between them. Disconnected components (where not every shape is connected) will be arranged around the circumference of a circle.

* There is a new Remove Overlaps button to move the selected objects enough that they don't overlap each other. A minimum spacing between the boundaries of objects can be specifiedTogether with the automatic layout tool, described above, this should be a significant addition to Inkscape's usability for diagramming. [Consider expanding this, comparing with existing Unclump and Distribute edge-to-edge buttons. - pjrm]

= Selective tracing with SIOX =

[ishmal]

= Snapping =

* [object snap - carl]

* [highlight - mtou]

* [only to visible gridlines - mtou]

* Guidelines are made easier to pick: now you don't need to position mouse exactly over a guideline to activate it, instead there's a small position tolerance (1 screen pixel on each side of the guideline).

= Sublayers =

Previously, it was only possible to make a group a temporary sublayer by entering that group. Now Inkscape supports creating and using true persistent sublayers within a layer.

* The Add layer dialog allows you to place the new layer above, below, or inside the current layer.

* Extended "Select All" option - now there is an option for "Select All" and TAB browsing to work in current layer with its sublayers.

= Extensions =

* The Effects menu is now always on, it's no longer an "experimental feature". The preference setting to enable the menu has been removed.

* Python extensions (which includes almost all currently available extensions) work on Windows out of the box, using a copy of Python shipping with Inkscape. The only minor inconvenience is that when an effect is launched, you get an empty console window that stays on while the effect is doing its work (don't close that window, it will disappear by itself when the effect is finished).

* A new Python effect, Render > LaTeX formula, allows you to type in any LaTeX formula and get a vector object with the TeX rendition of this formula inserted into your document. You need to have latex, dvips, and pstoedit installed and in PATH for this to work.

* A new Python effect, Flatten Path, flattens paths in the current selection, approximating each path with a polyline whose segments meet the specified criteria for flatness.

* A new Python effect, Measure Path, attaches a text label to each path in the selection giving the length of that path (in px units).

* The Radius Randomize effect has a new parameter which enables normal distribution of random displacements instead of uniform as before, which gives a more natural feel to the randomized path.

* INX files now have the ability to hold more information. This includes tooltips and descriptions of the extensions. These are all also translatable.

= Formats =

* Inkscape's PDF export is now native (i.e. does not require any external applications) and supports transparency, including gradients with transparency. This replaced the old export extension that required Ghostscript and worked via Postscript, losing any transparency. The new PDF export is still immature; in particular it does not handle text, so you should check "Convert text to path" on the export options dialog. Other things not yet supported include: gradients on stroke; eccentric elliptic gradients; patterns, masks, and clipping paths; embedded images.

* [save zip with images - mipmip] collects the svg file and all linked images into a zip archive for distribution.

* An output format for desktop cutting plotters, such as the Wishblade and Craftrobo, was added. This format is a very minimalist DXF file with appropriate scaling and translation applied. This output format should not be expected to operate as a generalized DXF output.

* [xfig]

* [odg - ishmal]

* The new XCF output extension exports all top-level elements (i.e. layers and objects directly under root) as PNGs and assembles them into an XCF for procesing in the Gimp. Requires Python, PyXML and Gimp. Gimp 2.2.x or above must be in the path and be named <code>gimp</code>. A version of Inkscape 0.44 or above must be accessible from the path. Does not function in Windows.

= Configurable keyboard =

Inkscape's keyboard shortcuts are now configurable!

At this time, not all Inkscape actions can have their shortcuts customized. However, the majority of actions, including everything you see in the menus, are already configurable, and we're working on making more actions configurable.

On startup, Inkscape reads its keyboard shortcuts from <code>share/keys/default.xml</code>. That file is a copy of <code>inkscape.xml</code> in the same directory, which also contains keyboard emulation profiles for other vector editors:

*<code>xara.xml</code>: Xara X/Xara Xtreme/Xara LX keys

You can copy any of these over default.xml to use that profile. In all profiles, those keys which are not used by the corresponding program still have their Inkscape bindings. If you can contribute a profile for some vector editor that we don't yet have, we will appreciate that. The files have a simple XML-based format described in <code>inkscape.xml</code>.

You can also customize some of your keybindings without overwriting the main <code>default.xml</code>. If your profile directory (<code>~/.inkscape</code> on Linux) contains a <code>keys</code> subdirectory with a <code>default.xml</code> file, the keybindings from that file will overlay (i.e. add to, and override in case of a conflict) the default bindings. The format of your own <code>default.xml</code> is the same as that of the main <code>default.xml</code>.

= Miscellaneous shortcuts =

* Now you can use Shift+middle button drag, in any tool, to zoom into an area. This works the same as simple drag in Zoom tool, but is faster because it does not require switching away from your current tool. Together with middle button drag (panning), middle button click (zoom in) and Shift+middle button click (zoom out), this completes the set of canvas navigation shortcuts available in any tool or context.

* In Gradient tool, Shift+R reverses the gradient definition (i.e. mirrors the stop positions) without moving the gradient handles. For example, an elliptic gradient with blue center and red periphery becomes red in the center and blue in the periphery. This works on the gradient(s) of the currently selected gradient handle or, if no handle is selected, on all selected objects' gradients. (Compare with the Node tool where Shift+R reverses the direction of the selected path.) This is especially convenient for elliptic gradients which, unlike linear, you cannot simply rotate by 180 degrees for the same result.

* In Selector, Ctrl+Enter enters the selected group (making it a temporary layer). Ctrl+Backspace leaves the current layer and goes one layer up in the hierarchy (but not to root).

= Miscellaneous improvements =

* Document templates (listed in File > New) are now first searched in the <code>templates</code> subdirectory of the user's profile directory (on Linux it's <code>~/.inkscape/templates</code>), then in the system-wide Inkscape templates directory. This allows you to add your own templates on top of the list of standard templates, as well as override the default template with your own one (the <code>default.svg</code> in the profile directory has priority over the system-wide one).

* Converting stroke to path now correctly processes dashed strokes. For paths with markers, this command now creates a group containing the stroke converted to path and all its markers as independent objects (i.e. they are not markers anymore, but instead you can easily transform them or paint them any color, as a workaround for the "markers don't take the color of the stroke" bug).

* When toggling one of the "transform with object" buttons (for stroke width, rounded rectangle corners, gradients, or patterns), a message is displayed in the statusbar explaining what has changed in the program's behavior. Hopefully this will reduce the number of complaints from users who had accidentally toggled one of these and were surprised by the result.

* Whole thousands above 2000 in the rulers are now displayed as 2k, 3k, 4k etc.

* In the Document Preferences dialog, the new object style for each tool is now shown as a style swatch (displaying fill/stroke colors and opacity, stroke width, and master opacity), similar in design to the selected style indicator in the statusbar.

* In the Grid Arrange dialog, row/column spacing can now be negative.

* The installation default is now to scale the rounded rectangle corners with the rectangles themselves (the previous default mode, still available as an option, was to keep rounding radii unchanged when scaling rectangles).

* Added a new <code>--export-area-canvas</code> command line parameter that causes the exported PNG to contain the full canvas. This option as well as <code>--export-area-drawing</code> and <code>--export-area</code> can now be used along with <code>--export-id</code> and <code>--export-id-only</code> for greater flexibility.

* The <code>--query-*</code> command line parameters now return the true SVG bounding box of the object instead of the Inkscape coordinate system bbox (with inverted Y axis). The new behavior makes more sense for scripting use of Inkscape.

* The dpi value in the Export dialog has had its range extended; now possible values are from 0.01 to 100000.

* Individual <tspan>s within text objects (including line tspans) can now be selected via the XML editor to view their bounding boxes (though per SVG, you cannot transform them). Also, you can use the <code>--query-*</code> command line parameters to find out the bounding boxes of tspans from a script. (Individual strings within or between tspans are still not selectable, and they cannot have an ID for querying anyway.)

* The placeholder image which is shown when a bitmap file was no longer accessible reads now "Linked image not found" instead of the confusing "Broken image".

* Cloning multiple selected objects now works as expected (i.e. each selected object is cloned separately, similar to the Duplicate command). Previously you could only clone a single selected object.

* The separate "license" and "contributors" dialogs have been merged into tabs on the About dialog. The about dialog now correctly sizes itself to fit the size of the splash SVG (while remaining resizable), and the rendering area is now cropped to the correct aspect ratio when the dialog is resized. The dialog also now displays the build information in the upper right corner.

* [new cursors - scislac]

* In the Transform dialog / Rotate tab, the icon was flipped horizontally to be in line with the direction of positive rotation; the change was applied to the default (now crispy) and legacy icon sets.

* The scale ratio lock button on the Selector controls bar shows a closed lock when pressed and open lock otherwise (same as the layer lock in the statusbar).

* The Browse button on Export dialog now opens the new file chooser, same as those used by Open and Save.

* A new RazorWire path marker was added. By applying it as a mid-marker you can get a good approximation of a razor wire.

= Miscellaneous bugfixes =

* Reading a document with an incorrect namespace URI not only did not cause Inkscape to complain, but could also "pollute" Inkscape's internal namespace table, resulting in an "infection" of subsequently saved documents by the incorrect namespace. This is now fixed, but as a result, documents with incorrect namespace URIs will no longer load. You will have to edit them in a text editor to fix the namespaces.

* With newer versions of GTK, dragging with graphics tablet pen did not work in some tools and contexts (in particular, in Node and Rectangle tools). This is fixed.

* Scaling of objects with stroke in Selector used to cause undesired shifts of the scaled object, as well as scaling it in the dimension which was intended to remain untouched (e.g. slight change in width when you scale only height). All these problems are now fixed, both for interactive scaling by mouse and for numeric scaling via the Controls bar, and for both values of the "Scale stroke with objects" option. Among other things, this means that stroked objects no longer lose snapping on scale, and that the "Default scale origin" option in the Selector tool preferences finally works as designed. Caveat: There may still be problems if you scale a selection that contains objects with different stroke widths.

* Scaling of stroke now works for objects that didn't specify stroke-width; before, they always ended up with the default 1px stroke.

* The bounding box for text and flowed text objects did not include stroke width. This has been fixed.

* Stroke miterlimit on text objects was misinterpreted in absolute units instead of multiplies of stroke width (resulting in miter joins rendered as bevel).

* The unfinished path in Pen tool is now cancelled, not finalized, when you switch away from the Pen tool. Apart from being more intuitively correct, this also fixes a crash when you quit Inkscape with the unfinished path in Pen tool.

* Fonts on Win32 now use the native font mapper, meaning that Inkscape's font list is the same as other Windows programs, and the (potentially) very long delay experienced when using fonts for the first time in each session is gone.

* Setting dash pattern was broken for transformed objects, and copy/paste of style with dash pattern did not apply correctly to objects with transforms.

* An error caused a complete extra screen redraw after each zoom operation. That is, after you press "+" in a complex drawing, Inkscape redraws, but for some time after that it remains still unresponsive because it does that second redraw (invisibly for you, i.e. nothing changes on the screen). This is fixed.

* Gradient rendering was off by one pixel, which often resulted in visibly wrong gradient rendering for small objects or in zoom-out.

* The SVG path parser could not handle fractional numbers with the initial dot.

* Several pattern rendering bugs are fixed, discovered by working with SVG files exported from Adobe Illustrator.

* Inkscape on Mac OS X will now notice fonts in your ~/Library/Fonts directory, in addition to the other standard places.

* Inkscape couldn't be compiled with libxml versions <= 2.6.9, and we now bumped the requirements from 2.6.0 up to libxml >= 2.6.11, which is the earliest you can get officially, anyway.

* Inkscape no longer crashes when presented with a defective inx file for extensions.

* More document memory is now freed when documents are closed.

* EPS output now correctly includes an %%EOF footer.

* There was a regression in 0.43 that caused several minor, though annoying bugs; knots and handles remained highlighted after the mouse was released, and the rubberband selection rectangle stayed visible if the selection was ended over a node while in the node tool. This regression has been fixed.

* The connector routing code would previously sometimes confuse objects between multiple documents resulting in strange routing behaviour. This has been fixed.

* There existed a bug in 0.43's Inkboard code that allowed a malicious outsider to very easily disrupt an Inkboard session. This has been fixed.

* There existed a bug in 0.43's Inkboard code that would cause deadlocks in the case that two users attempted to invite each other at the same time (see bug #[https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1352522&group_id=93438 1352522] for further details). This should be fixed, although the fix has not been widely tested.

* There existed a bug in 0.43's Inkboard code that would cause session invitations to not appear on the invitee's screen. This was the result of a mistake in handling GDK modifier flags, and has been fixed.

= Translations =

* INX files (containing the UI of the external effects) now allow the user visible strings to be translated. This means that effect dialogs, file type selections, and extension names can all be translated by translators.

= Internal =

* The Document Properties Dialog code was completely gtkmmified, which lead to dramatic reduction of code size due to usage of widget objects. The used widget objects should be reusable by other dialogs, too, and the code is much more readable.

* Work on optimizing includes in all cpp files started, using the purgeincludes tool specifically written for that purpose, and ended with 40% of include lines removed!

= Known problems =

=== Namespaces may need fixing ===

* Previous versions of inkscape sometimes silently saved documents with wrong namespace URIs. This has been fixed, but such corrupted documents will no longer load successfully. Such documents may require their namespace declarations to be fixed by hand.

=== Beware of defective themes on Linux ===

* Inkscape and other Gtk programs can crash on any Linux, when the gtk2-engines-smooth / libsmooth package is installed. We have filed a bug against libsmooth which is now in gtk-engine and part of gnome. Removing the package resolves the problem, however, but it would be nice if you as affected user would inform the gtk-engines maintainers of the problem. See especially http://bugzilla.gnome.org/show_bug.cgi?id=312115 (thanks to Thomas Wood)
* A similar crash happens if the KDE Baghira theme or the package gtk_qt_engine are installed. If you experience Inkscape crashes on KDE, please try to install a different theme from Baghira, or uninstall the gtk_qt_engine package from your system. Both problems also affect older versions of Inkscape.

= Previous releases =

* ReleaseNotes043 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes043)
* ReleaseNotes042 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes042)
* ReleaseNotes041 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes041)
* ReleaseNotes040 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes040)
* ReleaseNotes039 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes039)
* ReleaseNotes038 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes038)
* ReleaseNotes037 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes037)
* ReleaseNotes036 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes036)
* ReleaseNotes035 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes035)

Google Summer of Code 2006

2006-05-19T11:48:17Z

Pjrm: Correct statement of existing CSS support. Nominate mentor.

=== SOC 2006 ===

[http://code.google.com/soc/ Google] has been kind enough to invite Inkscape to participate as a mentoring organization in the Summer of Code 2006. The students and developers had a lot of fun last year, and resulted in some _great_ additions to the software, so we are very enthused about this year.

Below is a list of ideas that Inkscape developers think might make good projects. Please do not let this list constrain you; if you have a good idea beyond what is listed we'd love to see it!

Also, we would strongly encourage students to contact us on the Inkscape developer's list prior to submitting your proposal. This gives us a chance to get to know you and to give you feedback that will strengthen your proposal.

To submit a proposal, [https://www.google.com/accounts/NewAccount sign up] for a Google Account, and then log in to the [http://code.google.com/soc/ Summer of Code] site.

== Project Ideas ==

=== A. PDF Export Extension ===

PDF is the most important graphic document interchange format, but Inkscape's current capability is woefully inadequate (we export to postscript and use ps2pdf). This project would focus on establishing a solid solution to this need.

An implementation approach for this would be to create a new Inkscape extension, "crs2pdf", which links to the [http://cairographics.org/ Cairo] library for [http://www.cairographics.org/manual/cairo-PDF-Surfaces.html PDF rendering] capability, and to [http://scratchcomputing.com/projects/vectorsection Vector Section] for parsing the SVG into CRS.

This work may also require making some alterations to Cairo and/or VectorSection to improve the quality of the throughput.

The tool must successfully convert at least half of the about screens used in Inkscape versions 0.35-0.44. Major kudos if you can convert all of them.

Mentor: [[EricWilhelm]]

=== B. EPS Import ===

While SVG is becoming a common format for exchanging data between graphics programs, EPS is currently much more common. Inkscape's current EPS support is flakey and poorly maintained. The plan is to switch to use of Scribus' EPS Import Library.

This project would involve creating a new Inkscape extension, "eps2crs", which links to Scribus' EPS import library and exports into the [http://scratchcomputing.com/projects/vectorsection Vector Section] CRS format.

This work may also require making some alterations to the Scribus PDF library and/or VectorSection to improve the quality of the throughput.

Mentor: [[EricWilhelm]]

=== C. Memory Optimization ===

Inkscape is a bit heavy in its memory use, and is tough to use on computers with limited RAM. This project would seek to analyze and understand Inkscape's memory usage, identify and correct major memory leaks, and decrease memory usage for typical cases by a nontrivial amount. Ultimately, the project should result in Inkscape running smoothly on lower RAM systems than currently.

Mentor: MentalGuy

=== D. Inkboard Portability ===

Last year we had a successful project to integrate the SVG online whiteboard capability, called Inkboard, into Inkscape. Unfortunately, it does not work on Windows, so many users are missing out on this capability.

This work may involve [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/protocol/ formalizing and extending the Inkboard communication protocol] and [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/ working on the INKBOARD_PEDRO branch])

Mentor: Ted

=== E. New Grids ===

Inkscape currently has square grids that can be snapped to. Extend this to allow other kinds of grids: Perspective, hex, iso, etc.

This will involve modifying the grid code to support the ability to have multiple kinds of grids, implementing at least 3 new grids, and adding the UI elements to allow users to make use of them.

Mentor: TBD

=== F. SVG Filters ===

Filters are a very important SVG capability, that allows giving special features to drawing objects, including shadows, blurs, etc. Inkscape currently does not support this capability, but it's high on the list of desires.

This project would consist of two parts: (1) adding a SPObject for filters and CSS support for referencing them; (2) adding renderer support for doing the actual filter effects when rendering. Completing this project requires implementing at least one filter, 'Gaussian blur' as a proof of concept.

Mentor: Bulia

=== G. Adding bitmap capabilities to Inkscape ===

While the purpose of Inkscape is to be a vector editor, design in the real world requires dealing with bitmaps too. Inkscape can import the bitmaps, and have them as full canvas objects, but there is no significant bitmap operations in Inkscape. While there is no reason for Inkscape to replicate the functionality of The GIMP, it would be desirable to have a few simple operations available from Inkscape.

This project will use the Inkscape extensions system to add a series of bitmap effects. The majority of the effects will be achieved through the integration of the ImageMagick bitmap handling libraries. GIMP may be another source. These effects can then be run on bitmap graphics within Inkscape.

The work should be encapsulated in such a way that in theory, other vector graphics applications (such as Xara), could also use the work. However, for the scope of this project we only require demonstration of the capabilities in Inkscape.

Project Timeline:

* Implement first effect. This involves building Inkscape, linking in ImageMagick and getting one effect written (6 weeks)
* Implement remaining effects within ImageMagick (3 weeks)
* Build a test suite for operations and complete all Doxygen documentation of code (3 weeks)

Mentor: Ted

=== H. Inkscape / GIMP Bitmap Editing Integration ===

Currently, you can embed raster/bitmap images into Inkscape drawings, but editing them is a bit of a hassle because Inkscape isn't really "aware" of external bitmap editing tools.

This project would seek to correct this by modifying inkscape's image embedding code to interoperate more directly with external bitmap programs. For instance, there would be an "open external editor" command that could be used when one or more bitmap images are selected. Another idea would be to include some common bitmap modification commands from the external program, that can be run entirely within Inkscape. A third idea is drag and drop of selections from the bitmap editor to Inkscape, and SVG selections from Inkscape to the bitmap tool.

As a proof of concept, the result should demonstrate this interoperability with GIMP. Note that the code should be developed such that in theory it should work with any bitmap editor, but we would only require demonstration of working with GIMP.

Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=862655&group_id=93438&atid=604309

Mentor: TBD

=== I. Text Tool Improvements ===

Inkscape's text tool is handy, but still lacks many of the niceties that users would like. This project would seek to address this by implementing various improvements that users have requested.

Some ideas for improvements:
* Make flowed text respect the default style of the text tool
* when flowing a text which already contains line breaks, provide a way for the line breaks to be conserved.
* when the style selected in the the Text and Font dialog is applied it erases any other style applied to some part of the text (like italics on some words, bold on others...), it would also be better to keep them where appropriate.
* Search through the Inkscape RFE list for other text and font improvement ideas

See: http://valessio.ul-jb.org/projetos/inkscape/inkscribus.htm

Mentor: TBD

=== J. Color Adjustment Dialog ===

Currently, it is possible to select, say, 12 objects in the drawing and set them to the same color/gradient/pattern. This project would go a step further, allowing multiple objects of differing color to have aspects of their color (such as brightness/contrast, HSL, etc.) altered, and to operate on vector objects with different fill styles (flat, gradient, or pattern fills), and to bitmaps.

Mentor: Bulia

=== K. External CSS Support ===

Inkscape currently has good support for inline CSS, and limited read-only support for an internal stylesheet in a <style> element, and no support for external stylesheets. Support for editing non-inline CSS would allow better expressiveness and adaptation, and smaller SVG files, and better support for SVG generated by other programs that use non-inline CSS.

Mentor: Peter Moulder

=== L. Bucket fill tool ===

This feature provides a new tool that generates a vector object with the desired color. This would allow, for example, the artist to draw a set of intersecting lines, and paint the blank spaces in between.

Two approaches have been proposed: The first would render the current image to a in-memory bitmap, perform a flood-fill (borrow the algorithm e.g. from Gimp), then trace the result and insert the resulting vector object into the drawing. The second would strive to detect the surrounding vector objects and perform a boolean path operation to construct a matching shape with the desired fill. Both approaches have their pros and cons; please select either and explain why you wish to do it that way, and how you would do it.

More discussion is available here: http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&group_id=93438&atid=604309

Mentor: Bulia

=== M. Justified Text ===

The lack of this feature is perhaps one of the reasons why Inkscape is currently unusable for many applications. Justified text is very useful, and is currently missing. Justification options to offer might be some subset of those proposed at http://www.w3.org/TR/css3-text/.

One reasonable starting point if you want to support text-in-shape and TeX-like line-breaking and hyphenation is the work of the Monash University group, who have a command-line tool that can justify some small subset of XHTML, and fit into a shape that can grow/shrink in a user-defined way to fit the text, and produces SVG output: http://bowman.csse.monash.edu.au/~pmoulder/text-in-shape.tar.gz. A disadvantage of this starting point is that the tool was not designed with editing in mind.

'''Mentor:''' Peter Moulder

== Additional Ideas ==

* SVG support in OpenOffice (not exactly Inkscape development, but would allow Inkscape users to paste in art rather than having to export to png and really promote usuage of Inkscape). Not to mention eliminating all those duplicate svg/png image files!

* More potrace/SIOX/etc. style features/development

* Extending the online InkscapeSVG stuff - might be very cool for sharing sketches, etc

* Building a public whiteboard server for Inkscape users, with a web site of its own, user galleries, interest groups, scheduled drawathons, connections to OCAL, etc.

* Skeletal Strokes and Effect Lines - A few links: Our wiki page on Expression [[http://wiki.inkscape.org/wiki/index.php/Expression]], Technical papers on Skeletal Strokes [[http://portal.acm.org/citation.cfm?id=192186]], Examples - [[http://northlite.50megs.com/expr/effectlines.htm]], [[http://www.wa.commufa.jp/~ksg/p_pfwp5_cgf.htm]], [[http://personal-computer-tutor.com/abc4/v36/sara36.htm]].

* Improve the functionality and ease of use of the python effects API (see my proposal in the [[ImprovingPythonExtensionAPI]] page )

* Standalone palette editor

* Converter from Visio to VectorSection's CRS format

* Converter from CorelDraw (CDR) to VectorSection's CRS format

* Converter enhancements for VectorSection (dxf2rzp, rzp2dxf, rzp2crs, crs2rzp, etc.)

* Converter from Flash (SWF) to VectorSection's CRS format

* Implementation of scissors and razor tools. Yes, these blunt tools are so necessary to quickly cut paths.

* Add user profiles (some nice graphical interface) to store different sets of default metadata that can be used quickly

* upgrade the metadata and licensing dialogs with more options and general licenses checking (upgrade cc license selection to using web services

* Advanced grade tool. Each node of a shape could have a different color. Inkscape fills in with a complex grade.

* Begin work on adding animation features to inkscape. If animated SVG is to ever truely compete with Macromedia Flash, then we'll need a good editor to create them with ;)

=== SOC 2005 ===
* [[SOC Accepted Proposals]]
* [[SOC Writing Project Proposals]]
* [[SOC Selection Criteria]]
* [[SOC Original Project Prompts]]

Google Summer of Code 2006

2006-05-19T11:38:25Z

Pjrm: Link to existing work

=== SOC 2006 ===

[http://code.google.com/soc/ Google] has been kind enough to invite Inkscape to participate as a mentoring organization in the Summer of Code 2006. The students and developers had a lot of fun last year, and resulted in some _great_ additions to the software, so we are very enthused about this year.

Below is a list of ideas that Inkscape developers think might make good projects. Please do not let this list constrain you; if you have a good idea beyond what is listed we'd love to see it!

Also, we would strongly encourage students to contact us on the Inkscape developer's list prior to submitting your proposal. This gives us a chance to get to know you and to give you feedback that will strengthen your proposal.

To submit a proposal, [https://www.google.com/accounts/NewAccount sign up] for a Google Account, and then log in to the [http://code.google.com/soc/ Summer of Code] site.

== Project Ideas ==

=== A. PDF Export Extension ===

PDF is the most important graphic document interchange format, but Inkscape's current capability is woefully inadequate (we export to postscript and use ps2pdf). This project would focus on establishing a solid solution to this need.

An implementation approach for this would be to create a new Inkscape extension, "crs2pdf", which links to the [http://cairographics.org/ Cairo] library for [http://www.cairographics.org/manual/cairo-PDF-Surfaces.html PDF rendering] capability, and to [http://scratchcomputing.com/projects/vectorsection Vector Section] for parsing the SVG into CRS.

This work may also require making some alterations to Cairo and/or VectorSection to improve the quality of the throughput.

The tool must successfully convert at least half of the about screens used in Inkscape versions 0.35-0.44. Major kudos if you can convert all of them.

Mentor: [[EricWilhelm]]

=== B. EPS Import ===

While SVG is becoming a common format for exchanging data between graphics programs, EPS is currently much more common. Inkscape's current EPS support is flakey and poorly maintained. The plan is to switch to use of Scribus' EPS Import Library.

This project would involve creating a new Inkscape extension, "eps2crs", which links to Scribus' EPS import library and exports into the [http://scratchcomputing.com/projects/vectorsection Vector Section] CRS format.

This work may also require making some alterations to the Scribus PDF library and/or VectorSection to improve the quality of the throughput.

Mentor: [[EricWilhelm]]

=== C. Memory Optimization ===

Inkscape is a bit heavy in its memory use, and is tough to use on computers with limited RAM. This project would seek to analyze and understand Inkscape's memory usage, identify and correct major memory leaks, and decrease memory usage for typical cases by a nontrivial amount. Ultimately, the project should result in Inkscape running smoothly on lower RAM systems than currently.

Mentor: MentalGuy

=== D. Inkboard Portability ===

Last year we had a successful project to integrate the SVG online whiteboard capability, called Inkboard, into Inkscape. Unfortunately, it does not work on Windows, so many users are missing out on this capability.

This work may involve [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/protocol/ formalizing and extending the Inkboard communication protocol] and [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/ working on the INKBOARD_PEDRO branch])

Mentor: Ted

=== E. New Grids ===

Inkscape currently has square grids that can be snapped to. Extend this to allow other kinds of grids: Perspective, hex, iso, etc.

This will involve modifying the grid code to support the ability to have multiple kinds of grids, implementing at least 3 new grids, and adding the UI elements to allow users to make use of them.

Mentor: TBD

=== F. SVG Filters ===

Filters are a very important SVG capability, that allows giving special features to drawing objects, including shadows, blurs, etc. Inkscape currently does not support this capability, but it's high on the list of desires.

This project would consist of two parts: (1) adding a SPObject for filters and CSS support for referencing them; (2) adding renderer support for doing the actual filter effects when rendering. Completing this project requires implementing at least one filter, 'Gaussian blur' as a proof of concept.

Mentor: Bulia

=== G. Adding bitmap capabilities to Inkscape ===

While the purpose of Inkscape is to be a vector editor, design in the real world requires dealing with bitmaps too. Inkscape can import the bitmaps, and have them as full canvas objects, but there is no significant bitmap operations in Inkscape. While there is no reason for Inkscape to replicate the functionality of The GIMP, it would be desirable to have a few simple operations available from Inkscape.

This project will use the Inkscape extensions system to add a series of bitmap effects. The majority of the effects will be achieved through the integration of the ImageMagick bitmap handling libraries. GIMP may be another source. These effects can then be run on bitmap graphics within Inkscape.

The work should be encapsulated in such a way that in theory, other vector graphics applications (such as Xara), could also use the work. However, for the scope of this project we only require demonstration of the capabilities in Inkscape.

Project Timeline:

* Implement first effect. This involves building Inkscape, linking in ImageMagick and getting one effect written (6 weeks)
* Implement remaining effects within ImageMagick (3 weeks)
* Build a test suite for operations and complete all Doxygen documentation of code (3 weeks)

Mentor: Ted

=== H. Inkscape / GIMP Bitmap Editing Integration ===

Currently, you can embed raster/bitmap images into Inkscape drawings, but editing them is a bit of a hassle because Inkscape isn't really "aware" of external bitmap editing tools.

This project would seek to correct this by modifying inkscape's image embedding code to interoperate more directly with external bitmap programs. For instance, there would be an "open external editor" command that could be used when one or more bitmap images are selected. Another idea would be to include some common bitmap modification commands from the external program, that can be run entirely within Inkscape. A third idea is drag and drop of selections from the bitmap editor to Inkscape, and SVG selections from Inkscape to the bitmap tool.

As a proof of concept, the result should demonstrate this interoperability with GIMP. Note that the code should be developed such that in theory it should work with any bitmap editor, but we would only require demonstration of working with GIMP.

Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=862655&group_id=93438&atid=604309

Mentor: TBD

=== I. Text Tool Improvements ===

Inkscape's text tool is handy, but still lacks many of the niceties that users would like. This project would seek to address this by implementing various improvements that users have requested.

Some ideas for improvements:
* Make flowed text respect the default style of the text tool
* when flowing a text which already contains line breaks, provide a way for the line breaks to be conserved.
* when the style selected in the the Text and Font dialog is applied it erases any other style applied to some part of the text (like italics on some words, bold on others...), it would also be better to keep them where appropriate.
* Search through the Inkscape RFE list for other text and font improvement ideas

See: http://valessio.ul-jb.org/projetos/inkscape/inkscribus.htm

Mentor: TBD

=== J. Color Adjustment Dialog ===

Currently, it is possible to select, say, 12 objects in the drawing and set them to the same color/gradient/pattern. This project would go a step further, allowing multiple objects of differing color to have aspects of their color (such as brightness/contrast, HSL, etc.) altered, and to operate on vector objects with different fill styles (flat, gradient, or pattern fills), and to bitmaps.

Mentor: Bulia

=== K. External CSS Support ===

Inkscape currently supports inline CSS, but real support for editing non-inline CSS would allow for great functionality when storing style elements in the document head or an external file. Implemengting this would help prevent a lot of duplication of css and will greatly improve our ability to use SVG generated by other programs that use non-inline CSS.

Mentor: TBD

=== L. Bucket fill tool ===

This feature provides a new tool that generates a vector object with the desired color. This would allow, for example, the artist to draw a set of intersecting lines, and paint the blank spaces in between.

Two approaches have been proposed: The first would render the current image to a in-memory bitmap, perform a flood-fill (borrow the algorithm e.g. from Gimp), then trace the result and insert the resulting vector object into the drawing. The second would strive to detect the surrounding vector objects and perform a boolean path operation to construct a matching shape with the desired fill. Both approaches have their pros and cons; please select either and explain why you wish to do it that way, and how you would do it.

More discussion is available here: http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&group_id=93438&atid=604309

Mentor: Bulia

=== M. Justified Text ===

The lack of this feature is perhaps one of the reasons why Inkscape is currently unusable for many applications. Justified text is very useful, and is currently missing. Justification options to offer might be some subset of those proposed at http://www.w3.org/TR/css3-text/.

One reasonable starting point if you want to support text-in-shape and TeX-like line-breaking and hyphenation is the work of the Monash University group, who have a command-line tool that can justify some small subset of XHTML, and fit into a shape that can grow/shrink in a user-defined way to fit the text, and produces SVG output: http://bowman.csse.monash.edu.au/~pmoulder/text-in-shape.tar.gz. A disadvantage of this starting point is that the tool was not designed with editing in mind.

'''Mentor:''' Peter Moulder

== Additional Ideas ==

* SVG support in OpenOffice (not exactly Inkscape development, but would allow Inkscape users to paste in art rather than having to export to png and really promote usuage of Inkscape). Not to mention eliminating all those duplicate svg/png image files!

* More potrace/SIOX/etc. style features/development

* Extending the online InkscapeSVG stuff - might be very cool for sharing sketches, etc

* Building a public whiteboard server for Inkscape users, with a web site of its own, user galleries, interest groups, scheduled drawathons, connections to OCAL, etc.

* Skeletal Strokes and Effect Lines - A few links: Our wiki page on Expression [[http://wiki.inkscape.org/wiki/index.php/Expression]], Technical papers on Skeletal Strokes [[http://portal.acm.org/citation.cfm?id=192186]], Examples - [[http://northlite.50megs.com/expr/effectlines.htm]], [[http://www.wa.commufa.jp/~ksg/p_pfwp5_cgf.htm]], [[http://personal-computer-tutor.com/abc4/v36/sara36.htm]].

* Improve the functionality and ease of use of the python effects API (see my proposal in the [[ImprovingPythonExtensionAPI]] page )

* Standalone palette editor

* Converter from Visio to VectorSection's CRS format

* Converter from CorelDraw (CDR) to VectorSection's CRS format

* Converter enhancements for VectorSection (dxf2rzp, rzp2dxf, rzp2crs, crs2rzp, etc.)

* Converter from Flash (SWF) to VectorSection's CRS format

* Implementation of scissors and razor tools. Yes, these blunt tools are so necessary to quickly cut paths.

* Add user profiles (some nice graphical interface) to store different sets of default metadata that can be used quickly

* upgrade the metadata and licensing dialogs with more options and general licenses checking (upgrade cc license selection to using web services

* Advanced grade tool. Each node of a shape could have a different color. Inkscape fills in with a complex grade.

* Begin work on adding animation features to inkscape. If animated SVG is to ever truely compete with Macromedia Flash, then we'll need a good editor to create them with ;)

=== SOC 2005 ===
* [[SOC Accepted Proposals]]
* [[SOC Writing Project Proposals]]
* [[SOC Selection Criteria]]
* [[SOC Original Project Prompts]]

Color management

2006-03-22T07:49:48Z

Pjrm: Implementation: new subsection Profile Database

=== Inkscape's Color User Interface ===
* [[CurrentColorWidget]]
* [[ColourPicker]]
* [[ColorPalette]]

=== What is "Color"? ===

That is a very good question. In Inkscape, color is basically RGB value triplets. But in order to get precise, and to enable the same color to be seen on different computers, the general idea of [http://en2.wikipedia.org/wiki/Color_space colorspaces] comes into play.

A common colorspace for the internet is [http://www.w3.org/Graphics/Color/sRGB.html sRGB]. SVG defaults to sRGB.

Then there is CMYK. Of course, this is not a single colorspace, but needs to be specified per output device, inks, media, viewing conditions, etc.

And then there are [http://www.ps.missouri.edu/PS2/support/TutorialFolder/ColorTutorial/ColorTutorial2.html spot colors]. Many designers (and thus users of vector art packages) often specify spot colors that are precise matches from a book, such as [http://en.wikipedia.org/wiki/Pantone Pantone] named colors. The main thing about these is that they are supposed to be fixed single colors of a known appearance.

So, off hand it seems that it would be good if Inkscape would support:
*sRGB color
*spot color

*colorspace definition

There are two different problems: firstly, displaying a composite image composed of several spot colours. This is easy - just represent the spot colours with their rgb approximations. The only work is at the interface and colour lookup phase - implementing schemes or palettes solves this straight off. The second problem is generating postscript or png with the colours separated correctly. This is hard.

=== Color Management ====
For Inkscape to be accepted in the print world, there must be good reliable support for both RGBA and CMYK color spaces. At the moment, the easiest way to get Inkscape SVG into CMYK color spaces is via import into Scribus or using Acrobat Distiller on Win32. Export to eps and conversion using perl script pscol from http://dionysos.mpch-mainz.mpg.de/~joeckel/pscol/ is also possible.

Scribus and [[The_Gimp]] both use littlecms for a color mangement module for doing "soft previews" of RGBA color into a CMYK (print) space. At some point, adding color management support should be discussed.

There is a list just starting on freedesktop.org on this topic. Details to be announced soon.

Adding support for littlecms means we match color output across devices (like Apple's inkscape) like scanner > digital camera > app > monitor > print, and also, both [[The_Gimp]] and Scribus use littlecms.

[[LittleCMS]] also has its own VERY ACCURATE COLOR CONVERSION ROUTINES!!! I know we were discussing this awhile back when the new color palette was being built.

=== Implementation ===

We can store the CYMK and RGB approximations side-by-side in the CSS, using SVG's ICC color support and a selected CYMK ICC profile.

For example:

fill: #ff0000 icc-color(blah, 0.0, 1.0, 1.0, 0.0);

Where "blah" would be bound to some CYMK color profile. (SVG specifies "sRGB" to be bound to standard sRGB profile, but there is seemingly no "standard" CYMK profile. So we may need to be able to use a device-specific one.)

Of course our CSS infrastructure alone would need some radical changes before it would deal well with this well.
:What changes do you have in mind? Below are the changes I'm aware of, but these aren't particularly radical. --pjrm

==== SPIPaint ====
See http://www.w3.org/TR/SVG11/painting.html#SpecifyingPaint for what SPIPaint will eventually need to support; and see http://www.w3.org/TR/SVG11/painting.html#InterfaceSVGPaint for the DOM interface (and http://www.w3.org/TR/SVG11/idl.html for its base interface SVGColor): the DOM interface might be good to copy from.

A minimal change would be adding to SPIPaint a pointer to an ICC color struct, which might have the same field names as interface SVGICCColor (in http://www.w3.org/TR/SVG11/idl.html).

==== Profile Database ====
Fill/stroke paints that mention an icc color reference a color-profile by name.
We thus need a mapping from name to color profile.
This mapping is to be populated by handlers for the <color-profile> element and the <tt>@color-profile</tt> CSS at-rule. However, note that these handlers also need to cope with the user changing or deleting that element/stylesheet; and that there can be multiple purported definitions for a given name (in which case the last one wins). I think we want a doubly-linked list of definitions, and then we re-create the mapping (hashtable or whatever) in full when the list changes. (We don't expect the list to contain many entries, so it's cheap to rescan the whole list.) The <color-profile> element object should then include a pointer into that list, and I suppose that stylesheet objects should include multiple pointers into the list (given that stylesheets can contain arbitrarily many <tt>@color-profile</tt> at-rules). (The reason for storing a pointer rather than just storing the name is to allow for duplicate names in the list.)

=== Links ===

*[http://www.w3.org/TR/SVGPrint/#devcolor SVG Print mentions color issues], including expected color support in SVG 1.2

Color management

2006-03-22T07:28:26Z

Pjrm: Describe SPIPaint changes needed

=== Inkscape's Color User Interface ===
* [[CurrentColorWidget]]
* [[ColourPicker]]
* [[ColorPalette]]

=== What is "Color"? ===

That is a very good question. In Inkscape, color is basically RGB value triplets. But in order to get precise, and to enable the same color to be seen on different computers, the general idea of [http://en2.wikipedia.org/wiki/Color_space colorspaces] comes into play.

A common colorspace for the internet is [http://www.w3.org/Graphics/Color/sRGB.html sRGB]. SVG defaults to sRGB.

Then there is CMYK. Of course, this is not a single colorspace, but needs to be specified per output device, inks, media, viewing conditions, etc.

And then there are [http://www.ps.missouri.edu/PS2/support/TutorialFolder/ColorTutorial/ColorTutorial2.html spot colors]. Many designers (and thus users of vector art packages) often specify spot colors that are precise matches from a book, such as [http://en.wikipedia.org/wiki/Pantone Pantone] named colors. The main thing about these is that they are supposed to be fixed single colors of a known appearance.

So, off hand it seems that it would be good if Inkscape would support:
*sRGB color
*spot color

*colorspace definition

There are two different problems: firstly, displaying a composite image composed of several spot colours. This is easy - just represent the spot colours with their rgb approximations. The only work is at the interface and colour lookup phase - implementing schemes or palettes solves this straight off. The second problem is generating postscript or png with the colours separated correctly. This is hard.

=== Color Management ====
For Inkscape to be accepted in the print world, there must be good reliable support for both RGBA and CMYK color spaces. At the moment, the easiest way to get Inkscape SVG into CMYK color spaces is via import into Scribus or using Acrobat Distiller on Win32. Export to eps and conversion using perl script pscol from http://dionysos.mpch-mainz.mpg.de/~joeckel/pscol/ is also possible.

Scribus and [[The_Gimp]] both use littlecms for a color mangement module for doing "soft previews" of RGBA color into a CMYK (print) space. At some point, adding color management support should be discussed.

There is a list just starting on freedesktop.org on this topic. Details to be announced soon.

Adding support for littlecms means we match color output across devices (like Apple's inkscape) like scanner > digital camera > app > monitor > print, and also, both [[The_Gimp]] and Scribus use littlecms.

[[LittleCMS]] also has its own VERY ACCURATE COLOR CONVERSION ROUTINES!!! I know we were discussing this awhile back when the new color palette was being built.

=== Implementation ===

We can store the CYMK and RGB approximations side-by-side in the CSS, using SVG's ICC color support and a selected CYMK ICC profile.

For example:

fill: #ff0000 icc-color(blah, 0.0, 1.0, 1.0, 0.0);

Where "blah" would be bound to some CYMK color profile. (SVG specifies "sRGB" to be bound to standard sRGB profile, but there is seemingly no "standard" CYMK profile. So we may need to be able to use a device-specific one.)

Of course our CSS infrastructure alone would need some radical changes before it would deal well with this well.
:What changes do you have in mind? Below are the changes I'm aware of, but these aren't particularly radical. --pjrm

==== SPIPaint ====
See http://www.w3.org/TR/SVG11/painting.html#SpecifyingPaint for what SPIPaint will eventually need to support; and see http://www.w3.org/TR/SVG11/painting.html#InterfaceSVGPaint for the DOM interface (and http://www.w3.org/TR/SVG11/idl.html for its base interface SVGColor): the DOM interface might be good to copy from.

A minimal change would be adding to SPIPaint a pointer to an ICC color struct, which might have the same field names as interface SVGICCColor (in http://www.w3.org/TR/SVG11/idl.html).

=== Links ===

*[http://www.w3.org/TR/SVGPrint/#devcolor SVG Print mentions color issues], including expected color support in SVG 1.2

OpenDraw

2006-03-13T12:22:47Z

Pjrm: Mention graph layout functionality in inkscape

Please post links to screenshots and/or insights of this vector graphics application.
We must learn from others.

[[OpenDraw]] currently has more features than [[Inkscape]]:

* Better support for 3D.
* Better import/export capability.
* "Convert to", convert objects to and from Paths and other object can be very useful (please rephrase this)
* Export to Portable Document Format (PDF)
* Integration with the rest of a Suite has the advantage of getting [[OpenDraw]] in the door as well as providing other side benefits.
* Very intuitive editing of grouped objects (without ungrouping them). Double-clicking the group blurs the other objects, allowing in-group editing.
* (Please add to this list, I gather there are many others.)

Nevertheless, there are some areas where it's better to use Inkscape:

* [http://graphics.openoffice.org/svg/svg.htm SVG support] (Openoffice has some support for exporting SVG).
* Spirals, stars & calligraphy pen are fairly unique to [[Inkscape]] and [[SodiPodi]] ([[JascWebDraw]] also has includes spirals).
* Apparently [[OpenDraw]] can't fill curves with a gradient or pattern.
* [[OpenDraw]] doesn't have mid-markers, only end markers (arrow heads).
* "Simplify curve" missing from [[OpenDraw]] (unique to Inkscape?)
* [[OpenDraw]] has only 3 boolean operations.
* Inkscape does better at text-on-path. It seems that [[OpenDraw]] requires converting text to curve first, so one can't edit the text after putting it on a curve.
* Inset/outset (unique to inkscape? Not unique [[MacromediaFreehand]] does it better)
* Graph layout: automatic connector routing, node overlap removal, and graph layout functions (0.43+devel) are probably better in Inkscape than OpenDraw. (Indeed, does OpenDraw have any of these, other than a simple Distribute command?)
* Patterns in Inkscape (SVG) aren't restricted to bitmaps.

=== Links ===

Presentation on [[OpenDraw]]: http://www.openoffice.org/product/draw.html

[[OpenDraw]] tutorials (among many others):
* http://www.linuxgraphic.org/section2d/articles/startoff/index.html
* http://www2.ac-rennes.fr/crdp/29/ie/aides/imgnum/vectoriel-draw/vectoriel-draw.htm

=== License ===

[[OpenDraw]] is available under [http://www.openoffice.org/license.html various licenses]

* Public Document License (PDL)
* GNU General Public License (GPL)
* GNU Lesser General Public License (LGPL)
* Sun Industry Standards Source License (SISSL). Deprecated, LGPL is used instead.

Release notes/0.44

2006-03-13T11:12:18Z

Pjrm: Mention change in writing colours.

= Inkscape 0.44 =

== In brief ==

Bigger and better.

== Outline mode ==

An Outline ("wireframe") display mode is implemented. Use the View > Display Mode > Outline to activate it. In this mode:

* all paths and shapes are rendered as inverse (black on light background and vice versa) outlines of constant width (1 screen pixel regardless of zoom), without fill;

* text is painted by inverse fill, without stroke;

* bitmaps are shown as is;

* any opacity and gradients are ignored.

The outline mode is usually not drastically faster than regular mode (usually 10% to 50% faster), and in some special cases it may even be slower. However, the value of the outline mode is not only in its speed; it is a good way to get an idea of the structure and objects of your document, and it is convenient for precision node editing and for finding "stray objects".

== Selected style indicator ==

A new control in the left end of the statusbar lets you quickly view and change the fill and stroke of the selected objects. When you have a text selection in Text tool or a gradient handle selected in the Gradient tool, this indicator displays and changes the style of the text fragment or gradient stop, instead of the entire object (it's the same behavior as the Fill&Stroke dialog.)

* The two indicators, labelled F: (top) and S: (bottom), display fill and stroke of the selected object(s) correspondingly. (For gradient handles, they always display the same style.)

* Each fill/stroke indicator can display either a color+opacity swatch (the opacity shown here is the fill opacity or stroke opacity, not the master opacity) or a text label specifying N/A (nothing selected), None (no fill/stroke), Unset (unset fill/stroke), L Gradient, R Gradient, Pattern (corresponding fill/stroke types), or Different (selected objects have different fill/stroke types).

* Additionally, each indicator may be accompanied by one of two flags, m ("multiple", meaning there are two or more objects all with the same fill/stroke) or a ("averaged", meaning there are two or more objects with different flat colors in fill/stroke, and the indicator shows the average of these colors).

* Left-click on an indicator opens or activates the Fill&Stroke dialog with the corresponding tab (Fill or Stroke) active.

* Right-click on an indicator opens a popup menu with the following items:
** Edit fill/stroke...: Opens or activates the Fill&Stroke dialog with the corresponding tab selected. (Same as left-click.)
** Last set color: Applies to the selected objects the fill/stroke color that was last applied to anythig.
** Last selected color: Applies to the selected objects the fill/stroke color that was last displayed in this indicator. (Allows you to easily copy fill/stroke color between objects: select source, select destination, apply "last selected color".)
** Invert: Sets the fill or stroke to the inverse of the current color (does not affect opacity).
** White, Black: Sets the fill or stroke to the corresponding color (fully opaque).
** Copy color, Paste color: Copies or pastes the fill or stroke color (when it's color) to/from the system clipboard, as text in the <code>#rrggbb</code> hex format.
** Swap fill and stroke: Exchanges fill and stroke (both their types and colors, if any).
** Make fill/stroke opaque: Removes fill or stroke transparency (not master transparency!).
** Unset fill/stroke: Unsets fill or stroke from selected objects.
** Remove fill/stroke: Removes fill or stroke from the selected objects.

* Middle-click on a fill/stroke indicator removes fill/stroke from selected objects; if it is already removed (i.e. if the indicator displays "None"), it does the same as the "Last set color" command from the popup menu.

* The Stroke indicator also displays the stroke width of selection (averaged if there are multiple objects selected with different stroke widths), located to the right of the stroke color/transparency swatch. Left-clicking on it opens the Fill&Stroke dialog with the Stroke Style tab selected. Right-clicking on it opens a popup menu which allows you to choose the units for displaying the stroke width, as well as choose one of the presets to assign to selection.

* To the right of the fill/stroke indicators, the Opacity numeric field (labelled "O:") shows and allows you to change the master opacity of the selected object (or the averaged opacity of several selected objects). Right-clicking the numeric field opens a popup menu with preset opacity levels. Middle-clicking on the "O:" label cycles the opacity through the values of 0 (transparent), 0.5, and 1 (opaque).

The zoom field and the cursor coordinates indicator have been rearranged for compactness and moved to the right end of the statusbar. There's also a window resize handle added at the very end of the statusbar.

== Color palette ==

[joncruz]

== Transform dialog ==

Fixes and improvements in the Transform dialog (Ctrl+Shift+M):

* The Apply to each object separately checkbox is added, allowing you to scale/rotate/skew each selected object by the same amount, around that object's center. When off (by default), the selection is transformed as a whole. The status of this checkbox is remembered across sessions. (It has no effect on Move and Matrix tabs).

* The Clear button resets the values on the current tab to defaults.

* The Scale tab now allows you to specify horizontal or vertical size increments in percentage or absolute units. Also, there's a Scale proportionally checkbox which ensures that scaling preserves the width/height ratio. (If you are scaling several objects proportionally with "Apply to each object separately", you can only use the % unit to specify the scaling; otherwise each object's scale increments will have the width/height ratio of the entire selection, not of that specific object.)

* The Skew tab can now specify the skew as an absolute displacement (e.g. for horizontal skewing of a rectangle, that means the shift of the top rectangle side relative to the bottom), as percentage displacement (e.g. a 1% horizontal skew of a rectangle means shifting the top side by 1% of the rectangle height), or as an angle (e.g. horizontal skew by 15 degrees results in the sides of a rectangle being rotated to that angle, while the top and bottom remain horizontal).

* The Matrix tab (previously called "Transform") can either edit the current <code>transform=</code> matrix of an object, or post-multiply the <code>transform=</code> with the matrix you specify, depending on the Edit current matrix checkbox. (As it is now redundant, the transformation matrix in the Object Properties dialog is removed.)

* The dialog now correctly watches selection changes in the active document window and updates its values accordingly.

* The layout of the dialog is simplified, tooltips and mnemonics added for better usability.

* Many bugs are fixed, especially in value conversions between units.

== Remembering the rotation center ==

* The position of the center (axis) of rotation and skewing used by Selector is now remembered for all objects and is restored when you select those objects again (even after save and reload). When you move or scale an object, its rotation center is moved or scaled too, so its position relative to the object always remains the same.

* When you have several objects selected, they use the rotation focus of the first selected object. If the first object does not have center set (i.e. if it's in a default central position), then several objects will rotate around the center of their common bounding box.

* Shift+click on the rotation center resets it back to the center of the object's box.

* Consequently, dragging the transformation center is now an undoable action; you can press Ctrl+Z to undo the drag.

[TODO:

- make use of this in keyboard transforms and Transform dialog;

- make it work smartly for groups: if a group has center not set, return the center of the first object inside group with the center set

- a separate tab in the Transform dialog, with 9 buttons in the square grid (for setting it to object's corners, sides, and center) as well as x/y fields for setting center to any position

- make center snap to grid/guides/objects and to other centers

- make objects snap with their center to grid/guides/objects]

== Align & Distribute dialog: remove overlaps ==

* There is a new button to move the selected objects enough that they don't overlap each other.
This should be a significant addition to Inkscape's usability for diagramming.

[Consider expanding this, comparing with existing Unclump and Distribute edge-to-edge buttons.]

== Document Properties / Metadata dialogs ==

* The Document Preferences dialog is now named Document Properties, and it was split in two: metadata were extracted into the Document Metadata dialog; metadata widgets are now also spread over two pages.

* New controls: the new object snapping features required their own property widgets, and you can set the snapping sensitivity with a slider, or let it snap regardless of distance.

* Rearrangements within Document Properties: everything snapping related was collected on one page; Grid and Guide widgets are on their own, the same page. Due to HIG compliance, all widgets were categorized; especially the widgets on the Page page were completely rearranged in the General/Format/Border categories.

* Bug fixes: grayed out license URI had too low contrast, so it's no longer grayed out; the proprietary license didn't clean the license uri; spinbuttons had no tooltips, and minor grid quirks were removed; data was not updated when a new file replaced another in the same window.

* HIG compliance: much work went into, and now only a few details are missing from full Gnome-HIG compliance.

== Keyboard profiles ==

[mental]

== Path effects ==

[acspike]

== Snapping ==

* [object snap - carl]

* [highlight - mtou]

* [only to visible gridlines - mtou]

* Guidelines are made easier to pick: now you don't need to position mouse exactly over a guideline to activate it, instead there's a small position tolerance (1 screen pixel on each side of the guideline).

== Connectors ==

* The buffer around avoided shapes (used for autorouting connectors) can now be adjusted via the "Spacing" control on the Connector toolbar.

== Important bugfixes ==
* inkscape couldn't be compiled with libxml versions <= 2.6.9, and we now bumped the requirements from 2.6.0 up to libxml >= 2.6.11, which is the earliest you can get officially, anyway.

* Scaling of objects with stroke in Selector used to cause undesired shifts of the scaled object, as well as scaling it in the dimension which was intended to remain untouched (e.g. slight change in width when you scale only height). All these problems are now fixed, both for interactive scaling by mouse and for numeric scaling via the Controls bar, and for both values of the "Scale stroke with objects" option. Among other things, this means that stroked objects no longer lose snapping on scale, and that the "Default scale origin" option in the Selector tool preferences finally works as designed. Caveat: There may still be problems if you scale a selection that contains objects with different stroke widths.

* Bounding box for text objects did not include stroke width.

* Stroke miterlimit on text objects was misinterpreted in absolute units instead of multiplies of stroke width (resulting in miter joins rendered as bevel).

* [win32 font backend - cyreve]

* Setting dash pattern was broken for transformed objects, and copy/paste of style with dash pattern did not apply correctly to objects with transforms.

* An error caused a complete extra screen redraw after each zoom operation. That is, after you press "+" in a complex drawing, Inkscape redraws, but for some time after that it remains still unresponsive because it does that second redraw (invisibly for you, i.e. nothing changes on the screen). This is fixed.

* Gradient rendering was off by one pixel, which often resulted in visibly wrong gradient rendering for small objects or in zoom-out.

* The SVG path parser could not handle fractional numbers with the initial dot.

* Several pattern rendering bugs are fixed, discovered by working with SVG files exported from Adobe Illustrator.

* Inkscape on Mac OS X will now notice fonts in your ~/Library/Fonts directory, in addition to the other standard places.

* Scaling of stroke didn't work for objects that didn't specify stroke-width and thus had the default 1px stroke.

* Inkscape no longer crashes when presented with a defect inx file for extensions.

* There was a regression in 0.43 that caused several minor, though annoying bugs; knots and handles remained highlighted after the mouse was released, and the rubberband selection rectangle stayed visible if the selection was ended over a node while in the node tool. This regression has been fixed.

* The connector routing code would previously sometimes confuse objects between multiple documents resulting in strange routing behaviour. This has been fixed.

== Misc improvements ==

* Now you can use Shift+middle button drag in any tool to zoom into an area. This works the same as simple drag in Zoom tool, but is faster because it does not require switching away from your current tool. Together with middle button drag (panning), middle button click (zoom in) and Shift+middle button click (zoom out), this completes the set of canvas navigation shortcuts available in any tool or context.

* Document templates (listed in File > New) are now first searched in the <code>templates</code> subdirectory of the user's profile directory (on Linux it's <code>~/.inkscape/templates</code>), then in the system-wide Inkscape templates directory. This allows you to add your own templates on top of the list of standard templates, as well as override the default template with your own one (the <code>default.svg</code> in the profile directory has priority over the system-wide one).

* In Gradient tool, Shift+R reverses the gradient definition (i.e. mirrors the stop positions) without moving the gradient handles. For example, an elliptic gradient with blue center and red periphery becomes red in the center and blue in the periphery. This works on the gradient(s) of the currently selected gradient handle or, if no handle is selected, on all selected objects' gradients. (Compare with the Node tool where Shift+R reverses the direction of the selected path.) This is especially convenient for elliptic gradients which, unlike linear, you cannot simply rotate by 180 degrees for the same result.

* When toggling one of the "transform with object" buttons (for stroke width, rounded rectangle corners, gradients, or patterns), a message is displayed in the statusbar explaining what has changed in the program's behavior.

* Zoom commands in the View menu are moved to a submenu; the Zoom In and Zoom Out commands are added to that submenu.

* The contents of the statusbar message are now duplicated as a tooltip that is shown when you hover the mouse over the statusbar. [TODO: need to strip from the tooltips.] Also, the status bar text is now no longer just cut off if there is no room but, at the end position, ellipses (...) are inserted to show there's more (only with Gtk 2.6 and newer).

* Whole thousands above 2000 in the rulers are now displayed as 2k, 3k, 4k etc.

* By popular demand, in Pen tool, if a new path is being drawn but not yet finished, Ctrl+Z cancels that unfinished path (i.e. does the same as Esc), instead of undoing the previous action.

* In Pen tool, Del works the same as Backspace to delete the last created point on the unfinished path.

* In Node tool, the ! key inverts node selection in the current subpath(s) (i.e. subpaths with at least one selected node); Alt+! inverts in the entire path. (This is similar to how these keys work in Selector, with current subpath(s) instead of the current layer.)

* The keyboard shortcut for "Make selected segments curves" in Node tool is changed from Shift+K to Shift+U for better mnemonics.

* In Calligraphic tool, Esc deselects as in most other tools.

* In Selector, Ctrl+Enter enters the selected group (making it a temporary layer). Ctrl+Backspace leaves the current layer and goes one layer up in the hierarchy (but not to root).

* In the Document Preferences dialog, the new object style for each tool is now shown as a style swatch (displaying fill/stroke colors and opacity, stroke width, and master opacity), similar in design to the selected style indicator in the statusbar.

* Simplify threshold in Inkscape Preferences can now be set with more precision.

* [pen tool keys - bb]

* In the Grid Arrange dialog, row/column spacing can now be negative.

* The installation default is now scaling rounded rectangle corners with the rectangles.

* The <code>--query-*</code> command line parameters now return the true SVG bounding box of the object instead of the Inkscape coordinate system bbox (with inverted Y axis). The new behavior makes more sense for scripting use of Inkscape.

* Individual <tspan>s within text objects (including line tspans) can now be selected via the XML editor to view their bounding boxes (though per SVG, you cannot transform them). Also, you can use the <code>--query-*</code> command line parameters to find out the bounding boxes of tspans from a script. (Individual strings within or between tspans are still not selectable, and they cannot have an ID for querying anyway.)

* Objects with clippath show the correct clipped bounding box, instead of the original unclipped bbox as before. (However, this does not apply to objects without clippath of their own which are clipped by being inside a clipped group.)

* The contents of the Effects menu are categorized into submenus, and several effects are renamed to more intuitive names.

* The placeholder image which is shown when a bitmap file was no longer accessible reads now "Linked image not found" instead of the confusing "Broken image".

* [save zip with images - acspike?]

* [about dialog redesign - mental]

* [icons prerendering - joncruz, mental]

* [extensions on windows - ishmal]

* [new icons?]

* [python extensions to work out of the box on windows? - ishmal]

* [new cursors - scislac]

* Added and output format for Destop Cutting Plotters, like the Wishblade and Craftrobo. This format is a very minimalist DXF file with appropriate scaling and translation applied. This output format should not be expected to operate as a generalized DXF output.

* In the Transform dialog / Rotate tab, the icon was flipped horizontally to be in line with the direction of positive rotation; the change was applied to the default and crispy icon sets.

== SVG Output ==

* Colors are now expressed by name (‘white’) or three-digit form (‘<tt>#f3c</tt>’) when possible.

== Speed ==

* Thanks to optimizations in the renderer, Inkscape's screen redraw is faster by at least 10%, and in some cases (such as complex stroked/dashed paths at high zooms) up to three times faster.
* An optimization in the attribute setting method made operations such as moving objects on the canvas at least 30% faster compared to 0.43. This is especially noticeable when you are moving clones selected together with their original (e.g. a clone tiling), in which case Inkscape now works three to four times faster.

== Translations ==

* INX files (containing the UI of the external effects) now allow the user visible strings to be translated. This means that effect dialogs, file type selections, and extension names can all be translated by translators.

== Internal ==

* The Document Properties Dialog code was completely gtkmmified, which lead to dramatic reduction of code size due to usage of widget objects. The used widget objects should be reusable by other dialogs, too, and the code is much more readable.

* Work on optimizing includes in all cpp files started, using the purgeincludes tool specifically written for that purpose, and ended with 40% of include lines removed!

== Known problems ==

=== Beware: defect themes on Linux ===

* Inkscape and other Gtk programs can crash on any Linux, when the gtk2-engines-smooth / libsmooth package is installed. We have filed a bug against libsmooth which is now in gtk-engine and part of gnome. Removing the package resolves the problem, however, but it would be nice if you as affected user would inform the gtk-engines maintainers of the problem. See especially http://bugzilla.gnome.org/show_bug.cgi?id=312115 (thanks to Thomas Wood)
* A similar crash happens if the KDE Baghira theme or the package gtk_qt_engine are installed. If you experience Inkscape crashes on KDE, please try to install a different theme from Baghira, or uninstall the gtk_qt_engine package from your system. Both problems also affect older versions of Inkscape.

== Previous releases ==

* ReleaseNotes043 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes043)
* ReleaseNotes042 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes042)
* ReleaseNotes041 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes041)
* ReleaseNotes040 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes040)
* ReleaseNotes039 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes039)
* ReleaseNotes038 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes038)
* ReleaseNotes037 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes037)
* ReleaseNotes036 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes036)
* ReleaseNotes035 (http://wiki.inkscape.org/wiki/index.php/ReleaseNotes035)

SVG Tiny Compliance

2006-03-11T06:31:32Z

Pjrm: Revert last two spam-adding revisions

It'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs. SVG Tiny is a good thing to aim for. A number of developers have voiced support for trying to achieve this.

As a first glance without looking much at either the spec or inkscape
source, I believe we need the following: don't rely on style attributes
working (use fill=... attributes); switch; SVG fonts; animation.

In more detail:

Styling:
* We must write `fill="..." etc. attributes instead of using style="fill:...". (I.e. when writing SVG Tiny documents, we must not use style attributes -- or at least use only "redundant" style attributes if that's easier to implement.)

<switch>:
* Minimum requirement is that we render it correctly (e.g. as a viewer would, showing just one child). Interface for viewing other branches would be nice (perhaps a non-modal dialog box listing the children named by their requiredFeatures, requiredExtensions and systemLanguage attributes. The layers dialog box may be a good base.

SVG fonts: font, font-face, font-face-src, font-face-name, missing-glyph, glyph:
* massifr has started work on this. He's still new to inkscape source code, so could use guidance.

Anchors (<a>):
* Especially relevant to Inkview. Inkscape can create <a> elements with right-click on an existing item, and has a textual dialog box for filling in attribute values (object-attributes.cpp). We have a "follow link" item in the contextual menu, but it does nothing (object-ui.cpp:sp_anchor_link_follow).

Animation: animate, animateColor, animateMotion, animateTransform, mpath, set:
* My reading is that we can't claim to support all of SVG Tiny without supporting animation.
* See [[Animation-(Timeline)]] for implementation notes.

(<foreignObject>: I believe we don't need to do anything to support the foreignObject element. We already have the property of not discarding unrecognized elements like foreignObject and its children.)

Looking back at the full SVG (1.1) spec, is Inkscape already able to claim to be a "[http://www.w3.org/TR/SVG11/conform.html#ConformingSVGGenerators Conforming SVG Generator]", for which I think lack of animation/filtering features would not be a problem (it seems to me that it doesn't matter what features you support, as long the generated file is valid SVG) but compliance with the Priority 1 accessibility guidelines from the "[http://www.w3.org/TR/ATAG10/ Authoring Tool Accessibility Guidelines 1.0]" would be necessary. http://www.w3.org/TR/SVG11/access.html outlines how accessibility applies to SVG. Some low-hanging fruit would be better support for [http://www.w3.org/TR/SVG11/struct.html#TitleElement <tt>title</tt>] and [http://www.w3.org/TR/SVG11/struct.html#DescElement <tt>desc</tt>] elements (e.g. from the Object Properties dialog box) and the [http://www.w3.org/TR/REC-xml/#sec-lang-tag <tt>xml:lang</tt>] attribute for text spans (whose initial implementation could be as simple as a textbox in the Text&Font dialog box).

We would not, however, be able to claim to be a "[http://www.w3.org/TR/SVG11/conform.html#ConformingSVGInterpreters Conforming Static SVG Interpreter]" or "[http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers Conforming Static SVG Viewer]" until [http://www.w3.org/TR/SVG11/feature.html#SVG-static more features] were supported, e.g. filters and SVG fonts.

=== Research ===

* Check out all these [http://svg.org/special/svg_phones phones] that use svg now!!!
* Check out [[Beatware Mobile Designer]]