Inkscape Wiki - User contributions [en]

Scratchpad clippingtutorial

2010-01-03T16:06:32Z

Richardink: fix typo

{{Tutorial_scratchpad_header}}

=Title=
Clipping, Masking and Patterns

=Author(s)=
ryan lerch, ryanlerch at gmail dot com, josh andler, emailwillbe@in.docbook
=Abstract=
This tutorial covers the usage of the clip and mask functions in inkscape, as well as how to create, apply and edit patterns to fills and strokes. It is advised that you go through the Basic & Advanced tutorials first so that you will be familiar with
the terms used in this tutorial.
=Body=
==Basics==
Clip paths, masks, and patterns are greatly useful additions to an artist or designers' tool set. A common property that all three share is the concept of boundaries. Clip paths and masks bound the contents of the items they contain, whereas patterns are only visible inside the bounds of the object they are applied to (in all three cases cropping visibility).

These methods do not delete parts of your objects, they merely tell the SVG renderer not to display them. This non-destructive editing makes it so that we can also release objects from from their bounded areas as well.

There are benefits to working with clip paths or masks combined with either individual or grouped objects.

==Clipping==
The clip function in inkscape allows an object or a group of objects to be clipped (cropped) so that only parts of the elements are visible. Clipping can be applied to any object (including groups, layers, bitmaps, etc.)

The easiest way to understand clipping is to see it in action. Take the following assortment of objects:

http://wiki.inkscape.org/wiki/images/Clipmaskpat-f01.svg

Now, place another object on top of all the others. This is what we are using for our clipping object. Note that the z-order of the clipping object is important, as the default behavior in Inkscape takes the top-most object as the clipping object. Also note that the style (fill, stroke, opacity etc) of the object is irrelevant, all that is used when clipping is the shape of the object.

http://wiki.inkscape.org/wiki/images/Clipmaskpat-f02.svg

The next step is to select all the objects that you want clipped and the clipping object. Then in the menus, go to object > clip > set. The result is:

http://wiki.inkscape.org/wiki/images/Clipmaskpat-f03.svg

Since this is all non-destructive editing, it means that we can also release objects from a clip. Do this by selecting the object that you wish to release, and in the menus go to object > clip release. In the following example, the blue star object was selected, and the clip was released:

http://wiki.inkscape.org/wiki/images/Clipmaskpat-f04.svg

So the purple clipping object has now returned, and the blue star object is no longer clipped. Note that the other two objects are still clipped, as the clip was applied to 3 separate objects. These clips still apply and can be released if needed. Because clipping paths can be applied to any object, if you wanted to treat the 3 objects as a whole, you would group them, then apply the clip to the group.

Clipping can be done on any object, even objects that have had filters applied to them. Below is an example of using clipping to create a bubble effect on a circle:

http://wiki.inkscape.org/wiki/images/Clipmaskpat-f05.svg

A clip can also be done on bitmaps that are embedded into or linked from an SVG:

http://wiki.inkscape.org/wiki/images/Clipmaskpat-f06.svg

==Masking==
Like clip paths, masks allows an object or a group of objects to be visually cropped with the additional benefit of giving alpha transparency to the items it is applied to.

In the following example you will see both the masks and the items they're applied to. As you'll notice, masks offer the ability for you to texture objects, give them depth, and other things that clip paths can't provide:

- example goes here -

==Patterns==
Patterns allow the fill or stroke of an object to be set to a repeated tessellation of 1 or more objects that have been defined previously. Below is and example of a pattern being applied to a the fill of a star shaped object:

http://wiki.inkscape.org/wiki/images/Clipmaskpat-f07.svg

Win32 Installer

2010-01-03T16:05:55Z

Richardink: fix typo

There has been some complaints about the Windows installer and also many ideas has been raised. So I want to bundle all those ideas here on one page.

=== new feature request will cause complete rework ===
There is a request from a professor on the university to have a .msi installer in order to integrate inkscape into the university software distribution system.
This would require a complete rework and an entirely separate package as NSIS is not compatible with MSI packages. The standard recommendation from NSIS is to use the silent install options they provide to help automate large installations.

=== reported problems ===
* no uninstall option, this is a privilege issue as the user has no rigths to write the necessary registry strings
*- in order to install Inkscape on systems with limited rights the installer ignores such errors and just do not write registry keys
* Windows: problems installing as non-priviledged user, same as above. We should help the user selecting the correct settings -- remove the check for all users or shortcuts in general (done)
* the uninstaller simply deletes the install directory. If the user installs accidently to C:\Program Files\ ... oh that S****

=== comming up - where you can help ===
* check if Inkscape installer is not translated into your language and help translating it
* msi package using the wix installer, volunteers welcome

=== status ===
* screenshots [http://www.geocities.com/theAdib current version]
* multi user installation
*translated into catalan, english, czech, french, finnish, german, italian, polish, slovak, slovenian and spanish
* optional sets file assoziations for .svg and .svgz
* optional keeps the personal preferences
* selectable components (core, gtk, shortcuts, examples, tutorials, translations)
* show GPL, not need to accept just click next
* added non program files (README, AUTHORS, ...)
* crc validation
* does not show details any more during installation/deinstallation
* silent install, all settings can be done via command line
* test if the user has pivileges to write registry,
* test if inkscape is installed and the previous installation is done by the same user
* ask to uninstall inkscape before overwriting
* test if the same user uninstalls inkscape
* optionally removes all reacheable inkscape personal settings

=== feedback or what users say ===
* the file associacion should go to the toplevel three
* also accociations for other file formats

=== component page ===
* inkscape core files (required)
* gtk files (required)
* shortcuts
*- install for all user
*- desktop icon
*- quick launch icon
*- default SVG editor
*- shell menue integration
* additional Files
*- examples
*- tutorials
* languages
*- English (required)
*- German
*- Frensh
*- ...

=== ideas ===
# (DONE) installer installs everything, I don't need chinese translations
# (DONE) installer translations is bad, I don't understand the sense
* there are descriptions if you select/mouse-over that menue item
# (DONE) crc validation
# custom installations (examples, tutorial, translations)
# (DONE) silent installation
* is by default enables but no other option as [[/D]] directory can be set. Use [[/S]] to switch silent mode.
* now all the Options can be deselected with command line parameters
# use the common/extra gtk-lib as gaim or gimp are doing and only supply extra libs
* (Ishmal) We have talked about this before, and it is something that we need to examine. But
what we need is more of a reason to do this than only download size or disk space. This
would be much more work than just repackaging.
# The individual packages of their existing ports were built individually. This means that
for development, the dev must have the makefile point to all of their individual trees.
The pkg-config information thus also refers to individual trees. This would make development
-much- more difficult than is is now. Remember, the Win32 build is just another build
environment of the Inkscape tree. We can edit/compile/debug on it just as easily as
on Linux. It is -not- a port, where the development is done entirely on Linux.
# We would need for the startup code to look for the location of the Gtk directory in the
registry. We would then either need to add it to the path, or do explicit [[LoadLibrary]]()
calls.
# If the user does not already have the common Gtk directory, then it must be part of our
install process. We cannot ask the user to go to some website, download and install it.
We provide -everything- now. We would need an extremely good reason to stop doing this.
Actually, if you have ever used [[InstallShield]], you would know that it provides all of its
dependencies, too (the huge ODBC or OLE packages within your installer are examples).
I am not against this. We just need to do it a different way. What we have discussed is the
possibility of being able to build the entire set of libraries from source, all of the way from
iconv to Gtkmm and libxslt and beyond. If we could do this, then the build would be clean, and have
valid interdependencies (no missing DLLs or DLLs with the wrong names). A single pkg-config
directory would point to all of the correct places. This would benefit everyone; Gimp, Gaim,
Inkscape, and anyone else who wanted to build a Gtk app on Win32 would find it much easier
this way. We need to talk with the guys doing the porting, about doing something just like this.

There is a promising subproject of [[MinGW]], 'portmaker,' which can maybe allow this to happen.
It is [http://sourceforge.net/forum/forum.php?forum_id=476731 here].

# (DONE) there is no need to show the GPL just for the usage of the program. Make it not mandatory to accept.
* (Ishmal) I think the GPL is cool. It basically says "Welcome to Open Source," and reminds
the users that it is not a commercial application, but a community effort.
# (DONE) not to show Details by default
# test dependencies before installing extensions
# assoziate more than just .svg
* uh, again how do we test which dependencies are supported uberconverter, ghostscript, etc

=== problems and questions ===
* (DONE) we need to detect, what are the inkscape translations and let the user choose
: how we present the languages?
: In the native one "English, Deutsch, Italiano" or in the language of the installer?
* currently it is presented like that, ordered by ISO code "am Amharic, de German)
: once we detected inkscape translation we can left over the other languages from the gtk package
* how can we put the translations out of the installer so that more people can help translating
* what about let a script write the translation part ?
this script then should access the po files for the translations
Q: does python or perl allow to access the inkscape po files ?
* (DONE) what should a silent installation do, what are the options ?
* all options are supported a /? gives a screen with all possible options
* (DONE) we also need to add some none program-files: license (done), authors, hacking, news (release-notes), readme,

=== more todo ===
* please provide samples or screenshots of a application that you satisfied and think is good
* other ideas

=== screenshots ===
* [[http://www.geocities.com/theAdib screenshots Abiword Blender Gaim Gimp NSIS WinCVS WinMerge installer]]

Adib

SodiPodi

2010-01-03T16:05:16Z

Richardink: Fix typo

=== Inkscape Sodipodi Comparison ===

Inkscape started as a fork of Sodipodi and Inkscape would not be where it is today without having had the base of Sodipodi to build on. As the two programs evolve it becomes increasingly useful to compare the two so that the developers of each can consider what features to copy from each other, and so that users can which program is useful for which drawing task or suits them best.

* Overall, Inkscape progresses faster and has more developers working on it. Inkscape's developer and user lists are currently more active.

* Sodipodi's <b>renderer</b> is noticeably faster, but less correct (often has artifacts with complex self-intersecting paths).

* Sodipodi's <b>freehand tool</b> is different from Inkscape's. Inkscape and Sodipodi have improved different aspects of the freehand tool since the fork. Sodipodi uses for the freehand tool an algorithm similar to that of the calligraphic tool, with parameters like drag and mass (not adjustable, however, as of 0.34); this makes the tool seem to adapt how closely the curve should match the mouse's path, whereas in Inkscape one must choose a fixed tolerance in advance.

:Situation as of Inkscape 0.40: Some people prefer the behavior of Sodipodi's freehand, while others prefer Inkscape. See [[FreehandComparison]] page for example screenshots from both categories of users. After 0.40, Inkscape CVS will experiment with incorporating sodipodi's improvements.

* For <b>documentation</b>, Inkscape has a detailed manpage, several big SVG tutorials and a complete shortcuts reference in SVG and HTML. The Sodipodi documentation is limited to a brief text-only shortcuts list and various web pages. (Some of Inkscape's documentation could be helpful for Sodipodi use too.)

* Inkscape fixed scores of <b>bugs</b> that Sodipodi has not yet fixed. Most applicable fixes from Sodipodi since the fork have been ported to Inkscape. On the other hand, the tons of new features in Inkscape undoubtedly introduced their own bugs. Inkscape employs a very intensive bug tracking process, that seems to help stabilize new features, though. Overall, people seem to agree that Inkscape is more robust and crashes less.

* Inkscape's package for <b>Microsoft Windows</b> is self-contained and easy to install. A single package makes things simpler and more convenient for testers and ordinary users.
: Sodipodi requires a separate installation of GTK libraries which although more complicated can be helpful if you wish to use less diskspace/bandwidth by sharing the same version of GTK (and settings) with other applictions GTK applications such as the GIMP, GAIM and more.
Inkscape may in future try to also provide this kind of split package but given how rapidly Inkscape changes the most up to date version of GTK is almost always required anyway. To save bandwith the file inkscape.exe has been offered to testers allowing them to avoid a full upgrade every time but it would not be recommended for ordinary users.

* Opinion is mixed as to which <b>interface</b> is better. Overall, most people seem to prefer Inkscape's use of a Single Document Interface (SDI) to the use of a Controlled Single Document Interface (CSDI) in Sodipodi where to the Toolbox is the main window and the panels are all in other separate windows.

** Inkscape has tools and tool controls attached to each editing window as toolbars. This seeks to minimize the need for floating windows and makes the most important controls more predictably positioned and faster to reach. Sodipodi has one big floating toolbox shared by all document windows.

::Sodipodi's interface has been described as more [http://www.gimp.org/ GIMP]-like. Inkscape's interface, on the other hand, resembles some of the commercial vector applications, most notably [[Xara X]].

:: Users with dual-screen setups and complex Window manager software tend to be those most likely to prefer the Sodipodi style interface as it allows/requires them to organise everything themselves.

:: One disadvantage to Inkscape's approach is that toolbars may either be partially cut off when the editing window is too small, or prevent the window from getting as small as possible. Inkscape toolbars are, in theory, detachable, so they can be removed from the editing window and float freely as separate windows. In practice, however, this is hardly usable because GTK does not make such detached toolbars stay on top, so they sink to the bottom very soon and are rather cumbersome to dig up again, especially if you have many windows. Let's hope GTK will fix this one day. (Windows need to set the correct hint to let the window manager know they are utility windows, the proceeding point may already be out of date and the following comments seem to confirm it).

::Also, any Inkscape toolbar can be permanently hidden; you can easily make a "bare" window without any buttons, if you are willing to use keyboard shortcuts instead of toolbar buttons.

** Inkscape's dialogs by default stay on top of the currently active document window. Sodipodi's dialogs (including the toolbox) sink.
:: <i>Not anymore, recent version of Sodipodi has the same "problem" as Inkscape - dialogs stay on top. --[[HandgranatSandra]]</i>
:: <i>Do they stay on top of all editing windows (as in Inkscape), or only over the original one from which they were called? --bb</i>

** Inkscape remembers the size and position of dialogs across sessions, Sodipodi does not.

* Inkscape has a lead in <b>usability</b>:

** Inkscape has many more keyboard and mouse shortcuts (but arguably this is greater flexibility not necessarily better usability, and accidentally hitting the wrong keybinding can waste time). Compare [http://inkscape.org/doc/keys.html Inkscape list] and [http://www.sodipodi.com/index.php3?section=documentation/usage/keybindings Sodipodi list]. Inkscape has a unique focus on keyboard accessibility of basic editing operations (move, transform, z-order, etc.)

** Inkscape remembers the zoom and view and window geometry of saved files.

** Selecting objects in Inkscape is much easier (select in groups, select under, forced rubberband, settable drag and grab tolerances, canvas autoscrolls when you drag objects or do a rubberband selection).

** Consistent treatment of stroke width, patterns, and gradients, which are either transformed in sync with their objects or stay unchanged in transformation, depending on a user setting.

** Inkscape has many more statusbar tips, tooltips, and other runtime verbiage. The size of an average .po file (containing all the interface strings) of Inkscape is more than twice that of Sodipodi.

** In Inkscape Exporting to bitmap (PNG) repeatedly is much more convenient since the filename and resolution are remembered, selected objects only export, more command line export options.

** Inkscape has made many usability enhancements, too many to list here. See [[Release Notes|release notes]] for the past versions for a complete list.

* <b>Features</b> of Sodipodi not currently in Inkscape (possibly incomplete; please add if you know of others):

** The "Apply to duplicate" checkbox in the Transformations dialog. However, in Inkscape 0.41 most if not all effects achievable by this checkbox can be replicated using the Tile Clones dialog that creates clones (which can then be unlinked to become regular duplicates).

** The "Repeat" command to repeat the last command.

* <b>Features</b> in Inkscape but not currently in Sodipodi:

** Layers.

** Manual and automatic kerning and letterspacing in text.

** Text on path, flowed text.

** Editing of SVG markers (e.g. arrowheads). Sodipodi has only a limited display support for markers.

** Much more convenient on-canvas gradient editing.

** Creation and editing of clones (SVG <use> element). Sodipodi only has limited display support for <use>.

** Clone tiling (arranging multiple clones with various symmetries, shifts, rotations, randomization, etc).

** Creation and editing of pattern fills. Sodipodi has only display support.

** Editing multi-stop gradients. Sodipodi has only display support.

** Intergration with Potrace, for tracing bitmap images to vectors. Sodipodi users can only use Potrace from the command line.

** Inkscape uses Pango for text and therefore better supports right-to-left and other non-Western scripts.

** Inkscape has more import and export formats, although many of them rely on external applications and are not available on all platforms.

** Inkscape has a usable (but still unfinished) plugins and extensions support. Python extensions that are shipped with Inkscape do a lot of fun things.

** Inkscape shapes and shape tools have more options and controls.

** More path operations (Simplify, Cut path, Division).

** Offset (inset or outset) paths, including dynamic and linked offsets.

=== History ===

Inkscape forked from SodiPodi in late 2003. See [[InkscapeHistory]] for more information.

=== Screenshots ===

[http://www.sodipodi.com/index.php3?section=screenshots Sodipodi screenshots]

=== Links ===

[http://www.sodipodi.com/ Sodipodi Official site]

=== License ===

GNU General Public License (GPL)

Script extensions

2010-01-03T16:04:29Z

Richardink: Typo

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

Traditional unix scripts can be used to extend Inkscape's functionality.
Such programs read a stream of data on standard input, transform the data in some way, and then write the modified data to standard output. This is an easy way to expand Inkscape and provide custom functionality without learning the internals of Inkscape. Libraries for reading and writing SVG data exist for many programming languages, and most provide support for XML. This HOWTO describes the "ins and outs" of writing one of these scripts and making it work with Inkscape's core functionality.

=== Types of scripts ===

There are three kinds of functions that can be 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 separate 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 ===

*[[Generating_objects_from_extensions]]. How to use a script to generate actual objects inside SVG documents.

*[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]]

*[[PythonEffectTutorial]]

*[[Tips For Python Script Extensions]]

[[Category:Extensions]]

Inkscape SVG vs. plain SVG

2010-01-03T16:03:29Z

Richardink: Fix typo

== Inkscape SVG vs. Plain SVG ==

Some notes about "Inkscape SVG" [http://sourceforge.net/mailarchive/forum.php?thread_id=7412326&forum_id=37513 ref]:
* the default mode of saving
* standards-conforming (the SVG standard permits these kinds of extensions)
* should render identically with or without the inkscape extensions
* gives Inkscape hints how to treat things in the UI -- for example, whether to treat a given group as a layer, or whether path nodes are cusp/flat/whatever
* seems to have a smaller filesize vs "[[PlainSVG]]" for some odd reason

"Saving document as 'plain SVG' actually invokes exporter. All objects will be reconstructed from parsed data, but overall object hierarchy will be preserved." -- quote from the documentation.

From my perspective,
* inkscape svg is basically the same as plain svg, just with a couple of extra commands (in separate namespaces) added, which the inkscape tools use to keep track of their work
* if you edit an inkscape svg in any other SVG editor, then it should appear as any other plain SVG, if not, then you can safely remove all references to inkscape: or sodipodi:, and just be left with the plain svg
* however, if you then re-edit the SVG in inkscape (after hand editing, for example) 'without' removing the references to inkscape in the object that has been edited (for an example if you edit a path created using the inkscape star tool), then inkscape will re-generate the SVG path d="" attributes using the information that 'it' has stored under its namespace, and therefore getting rid of any editing to the path of that you, the user have done.

Below is an incomplete list of what is contained in the inkscape: and sodipodi: (preserved for backwards compatibility with its functions) namespaces

*<svg>
** inkscape:output_extension
** inkscape:version
** (sodipodi:docbase)
** (sodipodi:docname)
** sodipodi:modified
** sodipodi:version
*<sodipodi:namedview>
** bordercolor
** borderopacity
** id
** inkscape:cx
** inkscape:cy
** inkscape:pageopacity
** inkscape:pageshadow
** inkscape:window-height
** inkscape:window-width
** inkscape:zoom
** pagecolor
** inkscape:current-layer
*<svg:Gradients>
** inkscape:collect
*<svg:path >(in patten defs)
** sodipodi:cx
** sodipodi:cy
** sodipodi:rx
** sodipodi:ry
*<svg:path> (in spiral)
** sodipodi:argument
** sodipodi:cx
** sodipodi:cy
** sodipodi:expansion
** sodipodi:radius
** sodipodi:revolution
** sodipodi:t0
** sodipodi:type
*<svg:path> (in star)
** inkscape:flatsided
** inkscape:randomized
** inkscape:rounded
** sodipodi:arg1
** sodipodi:arg2
** sodipodi:cx
** sodipodi:cy
** sodipodi:r1
** sodipodi:r2
** sodipodi:sides
** sodipodi:type
*(tiled clones)
** inkscape:tiled-clone-of
** inkscape:tile-cx
** inkscape:tile-cy
** inkscape:tile-h
** inkscape:tile-w
*<svg:g> (id=layer)
**inkscape:groupmode
**inkscape:lable
*(connectors)
**inkscape:connector-avoid:
**inkscape:connector-type
**inkscape:connector-start
**inkscape:connector-end
*(others)
** sodipodi:nodetypes?

[[Category:User Documentation]]