Sorry for posting here if the user list if better. And sorry about the
subject if it has been talked about before. I couldn't get sourceforge
to add me to the inkscape user mail list and sourceforge was timing out
on all my archive searches with no results.
I remember reading that there was a patch or something to inkscape to
support wishblade and robocraft users. Has that been integrated into
the inkscape application? Is that what the DXF is all about?
Wishblade users can not use DXF directly (needing the robocraft software
to import DXF and change it to some sort of native (and maybe
proprietary) GSD). Is there a way to get inkscape to save images in GSD
in order to simplify the process?
Ideally, I would prefer to skip bringing up the wishblade application.
In my set up, I do all my work in linux (GIMP/INKSCAPE) and only the
plotting in Windows. If I could do everything in linux it would
simplify the flow of work greatly. Has anyone figured out how the
craftrobo is communicated to in order to use it with common open source
linux plotting software?
Better yet, has anyone figured out how the wishblade has been crippled
in order to use it with common open source linux plotting software?
I'm interested in setting up a git mirror of Inkscape SVN; who's the person in charge of our server currently? We'll need to have a fairly current version of git, libsvn, and the libsvn perl bindings installed to do this.
I've just merged the first code drop from Nick into SVN; I was hoping to
avoid any regressions, but at this point I think it's more important to
start merging now since Niko and Nick are starting to touch the same
code and I want to avoid too much divergence.
Things that work:
- blend modes can now easily be selected for objects, just like blur
- background accumulation buffer is enabled as-needed
- the filter UI dialog has very very basic filter editing capabilities
- Niko's work in r15171 (non-destructive filter update) needs to be
re-integrated with the new filter metawidget, which replaces the old
- the blur slider in the filter metawidget needs to be made percentage
like the slider it replaced
- add filter metawidget to layers dialog too, for layers
- fix flakiness for "Filter" "blend mode"
- flesh out filters dialog, parameter editing/connections, etc.
I think we'll need to work out who wants to work on what with the
metawidget at this point, depending on what you guys are each most
comfortable spending time doing, and on your respective current states
I've imported a 400x400 pixel TIFF image into an inkscape drawing, and
it comes out as 112.89 x 112.89 mm, which translates to a resolution of
roughly 90 dpi.
Where does this number come from? Shouldn't inkscape honour the dpi
information that is embedded in the TIFF image?
Alternatively, for images that don't have a "built-in" resolution,
inkscape should ask for a "native" size of the image or use a changeable
Also I noticed that some imported images have width and height xml
attributes while others don't. All this came to my attention when I
worked with a SVG file with 20 imported images of about 10MB each (TIFF
uncompressed) which bogged down my computer. I tried substitutung the
TIFFs with scaled-down (by .25) working copies, which worked fine for
those images that had width and height attributes (the others came out a
fourth of the size),
I'm just wondering how Inkscape arrives at the "native" size of an
image, and I wanted to know if others agreed with my notion that in a
vector drawing program the resolution of imported bitmaps was of high
It would also be nice if Inkscape could somehow reload image properties
if the original bitmap had changed (by scaling or cropping, for instance).
Is anyone actually working on fixing the font problems (ie, no styles
except the very basic ones)? This is a total show-stopper for professional
use. If no one is working on it, is there a guide to how to start on
working with the Inkscape code, submitting patches etcetera?
I'm not sure that I'll have much time to work on it but I am a programmer
and I have worked with Linux fonts quite a lot over the years. I really
like Inkscape and use it for design work (real, paid design work) quite a
lot but it always hits a wall when a client is already using use a font
which Inkscape can't handle but has to be incorporated, like Helvetica
Black, which happened yesterday.
There is almost nothing else which causes me to have to revert to
Illustrator now other than font handling and I'm starting to really resent
Illustrator because of it.
So I've finally got my work on switching the scripting extensions over
to being a call with parameters instead of a parsed string on the
command line. At the same time I've made them asynchronous, which has
some nice side effects. Basically, this all involved reworking large
portions of the scripting code -- which brings the possibility of
breaking things. Two areas in specific that I'm worried about:
-- win32. Some of the functions I've used had notes on what does and
doesn't work on win32, but the documentation was sparse, and I'm
concerned it was incomplete.
-- internationalization. I know we've had problems in the past with
this code and different locales of filesystem and UI. I believe I kept
all that code in place -- but history means that those with the complex
setups should be extra observant when noticing how their SVN builds run.
So other than those concerns, enjoy everyone. I hope this will add a
lot of usability to the scripts, especially some discoverability to the
I changed SPStyle to use SPFilterReference for linking up filters, the
same as filters use to link up to each other. This simplified SPStyle
code (got rid of ad-hoc hreffing, etc) and fixed at least one bug: now
filters are no longer lost when you undo an effect from Effects menu.
Of course there may be gotchas, so please report to me any crashes and
misbehaviors in filters linking (but not rendering - that is Niko's
domain now, my changes should not affect that). If all goes smoothly I
will similarly switch SPStyle's paintservers (gradients and patterns)
which will fix a bunch of other long-standing bugs.
Inkscape. Draw Freely.
It looks like recent trunk has begun putting single quotes around font
names with spaces in them; I believe this is fine in terms of the CSS
spec, except that recent released versions of Inkscape can't parse that
and end up using the default font (generally bitstream vera) instead.
Okay... first off, I nuked my svn checkout, xmingw, and my gtklibs...
Then brought everything back up-to-date and clean at that.
Cross-compiled for win32 and fired up inkscape on the win32 box. The
error I reported yesterday persisted (about not finding python25.dll). I
manually moved the dll file from the main inkscape dir into the python
subdirectory where python.exe resides. This solved problem of not being
able to find the dll.
However, effects still do not work. When I try to run effects
(interpolate is my example here) I now get output stating:
"python: can't open file 'share\extensions\interp.py': [Errno 2] No such
file or directory"
For the sake of trying to find a workaround (like the dll), I copied the
"share\extensions" directory structure with the contents into that
python dir as well (hey it worked for the dll). Unfortunately, this did
not fix it.
It seems like this may be more related to our library upgrade and new
python than the changes Ted made. I really want to make sure that people
will still be able to use effects on win32, and it seems like the sooner
we can know if there's a problem, the better.
Anyone else building for/on win32 having a different experience? Again,
note that I'm cross-compiling, not compiling natively.
Side note: Bob, the gtkrc file copied to "inkscape\etc\gtk-2.0" has the
correct change I suggested. But, the gtkrc file that is in
"inkscape\share\themes\MS-Windows\gtk-2.0" does not have the change and
it is the one inkscape actually uses.
P.S. Ted, you're getting CC'd because I want you to know that I plan on
testing your changes on win32 asap... and also to know that I will bug
you if your changes don't work on win32. ;)
I'm currently working on a patch to add support for native file dialogs for windows users. It's worked out pretty well, and I'm almost finished. I have one slight problem though: parent windows.
In the GTK version, sp_file_open_dialog (in file.cpp) is called from inside FileVerb::Perform in verbs.cpp. But how is it possible to get the GdkWindow object of the windows in which the verb was invoked? If I have this I can add it as an extra parameter to sp_file_open_dialog, to enable both the GTK, and Win32 file dialogs to be correctly set as child windows of the document's window.