A new method for quick and precise adjustment of colors is added in
this version: color gestures. It works on the selected objects by
grabbing the fill or stroke color swatch in the selected style
indicator (on the left of the statusbar) and dragging it in various
directions as described below. Note that this only works when the
swatch displays a flat color; it does not work for a swatch showing
"None", "N/A", or displaying a gradient (although you can select one
or more gradient stops in Gradient tool and color-adjust them by color
gestures just as you would do for objects). Color gestures can work on
fill or stroke, depending on which swatch in the selected color
indicator you drag.
Color gestures work in HSL color space. Dragging without any keyboard
modifiers adjusts the hue channel, dragging with Shift adjusts
saturation, and dragging with Ctrl adjusts lightness.
The adjustment is done by rotating the color swatch away from the
original direction which is assumed to be NE at 45 degrees (i.e. from
the swatch into the document window). That is, once you click and drag
the color swatch, imagine a line going from the point where you
clicked in the NE direction, across the entire Inkscape window. By
dragging below or to the right of that line, you decrease the
corresponding color channel, to the minimum at the lower edge of the
window; by dragging it above or to the left, you increase it, to the
maximum at the left edge of the window. If you hover your mouse
exactly over the 45 degrees line, the change will be zero.
Note that you can easily vary the precision of your adjustment. If you
drag close enough to the swatch, each small movement results in a big
change of the color. If you need a finer adjustment, just drag farther
away from the swatch, towards the center of the Inkscape window or
even to its upper right corner, where minute movements will produce
very small changes in the color. In fact, this method gives you more
color precision than even the color wheel in the Fill and Stroke
dialog, unless you expand that dialog to fill the entire screen which
is rarely practical.
Watch the statusbar which will indicate, as you drag, the channel you
are adjusting, the original value of that channel, and the new value.
You can switch channels while you drag. That is, you don't need to
restart dragging from the swatch if you want to adjust all three
channels - you can do it in one drag, pressing and releasing Ctrl and
Shift as necessary. Note that when you change the keyboard modifiers
during drag, the position of the zero-change line is temporarily set
to the current position of the mouse; this is done so that there are
no sudden changes in color if you are switching modifiers away from
the original 45-degree line.
For example, you can select a green rectangle and first turn it into
greenish-blue by dragging away from the Fill swatch and slightly above
the 45 degrees line; then, without releasing the mouse, press Ctrl and
drag a bit to the right to darken the color; then press Shift, release
Ctrl, and adjust saturation. You can press or release Ctrl and Shift
as many times as necessary during a single drag; when you are finally
satisfied with your color, release the mouse to commit the change.
Apart from precise adjustments, you can use color gestures to quickly
perform common color transformations:
* Ctrl+drag the swatch to the right and down to color all selected
* Ctrl+drag the swatch upwards and to the left to color all
selected objects white.
* Shift+drag the swatch to the right and down to desaturate the
color of selected objects.
* Shift+drag the swatch upwards and to the left to maximize
saturation of the color of selected objects.
Note that when several objects or gradient stops with different colors
are selected, the selected style indicator shows their averaged color.
If you adjust that color by gesturing, the changed color will be
assigned back to all selected objects/stops, in effect eliminating any
difference between them. If you want to adjust many different-colored
objects preserving their relative differences, use the color modes of
the Tweak tool or color adjustment extension effects.
This new technique requires some getting used to, but once you get the
idea it is quite convenient, fast, and precise.
Inkscape. Draw Freely.
I will search the archives tonight as I have no way of contacting Kees.
I think I might be able to write/modify a program to log serial/USB port
activity on Windows computers. We could then translate the commands into
a Linux program, this would give people the option to run the cutters
Aaron Spike wrote:
> Stéphane ANCELOT wrote:
>> The version you can find on my website is an enhanced version of the
>> GSoC version dxf2svg.
>> dxf2svg is GPL licensed , since I did not have had any answer from the
>> author , I made available this slightly enhanced version through my website.
>> However, you can copy and modify the above code (I wrote it, I grant you
>> to do so ...).
> Sounds like you should start with this enhanced version rather than
> backing up and working on the GSoC version. We should ask Kees Cook to
> remind us what the security issues were, or possibly we could find that
> info on the mailing list and save him the bother.
> Aaron Spike
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> Inkscape-user mailing list
I'm getting an error building Inkscape svn, it fails in the link phase with an undefined symbol:
In function `Inkscape::Extension::Internal::PdfImportDialog::_setPreviewPage(int)':
/home/chris/inkscape/inkscape/src/extension/internal/pdfinput/pdf-input.cpp:544: undefined reference to `CairoOutputDev::setCairo(_cairo*)'
Can anyone suggest what I am doing wrong?
I just moved from Kubuntu 7.04 to Kubunti 7.10 and for various reasons its a clean install not an upgrade. Previously I had Inkscape building fine. I believe I have all the dependencies, since autogen and configure don't moan at me about anything.
Attached is the relevant error. Happy to supply more details on request.
Chris Lilley mailto:chris@...157...
Interaction Domain Leader
Co-Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
Looking at the roadmap of 0.46 I found:
* (DONE) Convert use of gboolean to bool where feasible
* (DONE) Switch from use of TRUE/FALSE to true/false
When I search the source, I see *a lot* of gboolean and TRUE/FALSE. I
will start switching code to bool when i see it.
I could not find a text saying that we should use bool or gboolean.
Similar issue is 'char' or 'gchar'.
Where can I read which types to use?
On 10/24/07, Kurt Hutchinson <kelanslists@...400...> wrote:
> I had a thought while reading the description. Since you can switch
> which HSL component you're modifying during the drag, it might be nice
> to have a modifier key that means "no change", so you can reposition
> the mouse cursor without affecting anything.
Yes. I thought about that too. But the only modifier left is Alt, and
we'll again get an outcry of those who can't use Alt :) Still, since
this is not such a crucial functionality, I think Alt is OK for that.
Inkscape. Draw Freely.
As far as I can see, the only way to change a the name of a gradient is to
do it in the XML editor.
With the new on-canvas editing ability, would it be feasible to have the
ability to change the name of the current gradient in the tool control bar
for the gradient tool? If this is not a good place for it, where would be a
I would like to say that I am not much confortable with the filters
implementation I was working on some time ago. I need help to make it work
better. I know that there are bugs that are due to my incomplete broken
implementation, but I am stuck because I still don't understand exactly how
the filters infrastructure work
I don't know how to properly implement zooming, nor rotation. Look at
feturbulence. It does not rotate correctly.
I also don't know whether I am using the best approach. I have used a pixmap
buffer where I render the feturbulence effect and I have an "updated" flag.
Then, if some parameters are changed (on sp-feturbulence.cpp) I set this
flag to false. When the render method is called, it checks the updated flag
and only recalculates the effect when the updated flag is false (and then
sets it to true).
When zooming, I will have to free the current pixmap buffer and create
another one of greater size and recalculate it. It seems to me that zooming
will have great slowdowns if I continue working that way. Any body know any
kind of "design pattern" that I should be using to implement the zooming? I
feel that I am walking the wrong way. And I keep scared about the
possibility of not being able to fix these filters before next release
deadline. So, what I mean is that I really need help to make this stuff work
Felipe Sanches, "JucaBlues"
I found that a small bug in the Oct 18 build where the opacity for an object
I had two object sharing the same gradient. One object was more opaque than
the other even though the opacity for both was 100.
I checked the XML editor and found that whilst both objects had Opacity:1,
one of them had fill-opacity:0.71.
I don't know how to reproduce this. It only happened once in an entire
On a side note, I had been getting very confused when making a stop on a
gradient transparent. I would change the Alpha value and the gradient would
reflect the change, but later I would see the alpha value would be 255
instead of what I had set and what I saw on the graduent. It took me ages
to spot that the alpha value was being replaced with the Master Opacity. Is
this something that is still being worked on?
View this message in context: http://www.nabble.com/Opacity-Bug--tf4664986.html#a13326117
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
you can download Inkscape development versions. I can still get
development versions for Windows that are only a few days old, but the
latest autopackages for Linux is from 06-Sep-2007 12:02.
Why? I'd like to test it on Linux.
I posted this a couple of weeks before but never got a reply... So I'm reposting it once again:
While working with some text in Inkscape, I found an unpleasant behaviour of the text selection field (the field above the font selection drop down menu): it is case sensitive. When I type "Arial" in it and hit enter, the selected text's font is changed to arial as it should. But if I type "arial" or "ARIAL", then I get a warning that the font is not found/installed.
The expected behaviour is that no matter what case I enter in (like aRiaL) it must find the font I'm looking for (this is the behaviour of Illustrator, Indesign, Corel, Photoshop, Openoffice and many other programs).
Although it is not a real bug, it is IMO a usability issue.
By the way, I'm on Windows XP sp2. Is it the same on Linux? Mac? And should I fill a feature request or a bug report?