Hey folks; I had submitted a second proposal last Friday, and though I was
very busy this weekend, I now have found the time to ask for input on the
I noticed nobody replied to my earlier message, so I'll just reintroduce
myself. I've been using Inkscape for years, and have done a fair amount of
work in it. This alone doesn't qualify me for application to the GSoC, so
I'll just leave this link to Nanoblok, a project I've worked on for quite
noticed a couple of files written in that language in the source, but I most
likely won't be using that when working with what I want to do, and I
What I want to do is, well, to enhance the export system of Inkscape, make
it more intuitive and integrated by merging the Export As and Save As
dialogs together into a single pane, with selection features that were
developed for the bitmap exporter also being able to work with vector export
One problem with the current system this would solve is that Save As might
make the user feel they can reload using that format and not lose anything,
whereas the only original document with all their settings and information
would be an Inkscape SVG. So, by labeling all other formats, both bitmap and
vector, as Export, and placing them under a single dialog, there is less
confusion, as well as the opportunity to more easily add additional formats
This is all illustrated and detailed here, in the following public Google
At any rate, let me know what you think of this!
Please see https://bugs.launchpad.net/inkscape/+bug/562592. There is a
pretty important bug in the PDF export. Currently, paths with
transparency are misaligned.
Does someone know more about this?
I've already done some digging, but I'm stuck. I'd greatly appreciate
someone else's help.
This list contains fixes between 4/7 @ 2:22pm PDT - 4/14 @ 11:15am PDT.
Only fixes to "true bugs" (i.e. no website/translation/docs/etc. bugs).
Pts BugID Fixer Description
6 555488 Johan Engelen PDF + LaTeX export doesn't work with text...
18 168275 Johan Engelen wrong PDF export with rectangles
6 479964 Johan Engelen "Fit Page to Selection" doesn't take arrow...
24 334800 Jon Cruz Input device configuration not saved on...
3 456248 JazzyNico SVG with media output fails with special...
6 196195 Jon Cruz Input devices dialog strangeness
6 166659 Johan Engelen Bounding box does not include long miters
3 362271 JazzyNico solarize on raster effect
I upload inkscape builds for windows to modevia from time to time and i'm glad to do this. No doubt about that.
But I'm on vacation from 22. of April till 16. of May and i'm not able to upload these builds during this time.
Can someone do this during my vacation? He or she must have access on modevia.com to do this.
I can try to do this, but i'll travel through Florida and i don't know if i can establish a reliable internet connection. So it would be nice if someone could do this during my vacation.
I've tried pretty hard in the past to come up with a combination of gtk and
that works, but I never got stable results. I'm really curious what
of Boehm features and glib/gtk features you are using?
I guess that since you don't require specially built glib/gtk you aren't
the allocator specifiers or build-time allocation settings of glib? Perhaps
use Boehm only for your own glib-independent memory pools?
One of my dreams is to have a nice garbage-collected C development setup,
but it seems to require every library to be rebuilt of LD_PRELOAD'ed in some
tricky way... I'd love to know roughly what you've done.
I just committed an improved bbox calculation when
SPItem::RENDERING_BBOX precision is requested. Now it correctly includes
This fixes an important bug: when creating a pattern from selected
objects, the bbox calculation was not accurate enough for paths with
butt caps. This meant it was not easy to make a pattern of a plus to
create a hatch fill pattern. (the plusses would not connect with each
other) Now this works as easy as it should.
I have also increased the precision of the bbox calculation for fitting
the canvas to the selection and for turning the selection into a marker.
Note that the improved RENDERING_BBOX calculation takes more time than
before (in fact, RENDERING_BBOX used to be the same as