- Inkscape Devel - Inkscape Mailman

xlink:href eternal files
by Jelle Mulder 13 Nov '13

13 Nov '13

Hello guys, I was wondering how much work it would be to get Inkscape to use external file objects in the xlink:href context. I would be way cool if that would be possible and it would make my life so much easier. Now I have to hand code it and rendering is only possible in browsers. But if it would be possible to <use> it in Inkscape and have the result be translated to all those other formats such as PDF it would create its own use case. Just sticking some objects from a library of objects together and separating the logic and the content of a project in Inkscape would be really useful. Granted, the problem arising is the amount of nesting to be available to a file, but if the nesting of linked objects goes too deep (more than 2 steps), it may be an option to copy them to the defs. It would also be useful to then be able to move them from the defs into an external file as to create libraries of objects. Obviously the Symbols tool basically uses this principle for the external libraries of objects, which get rendered in it, so my guess is that Inkscape basically is already capable of it. Giving the option to collate such projects together into a single file or vice versa, ripping them apart would be an added benefit. Cheers, Jelle

1 0

Namespace pollution (r12782)
by Krzysztof Kosiński 13 Nov '13

13 Nov '13

Hello r12782 introduces a third-level namespace called "Tools", i.e. Inkscape::UI::Tools. There are some problems with this: 1. While this does follow current practice, I don't think the current practice is any good. The only result of having such deeply nested namespace hierarchies is the need to tediously type this all out, since if there actually is a naming conflict they prevent, it's a symptom of bad design / naming. 2. "Tools" is pluralized, while "Dialog" and "Widget" are not. This is inconsistent. It is sufficient to put all UI code in Inkscape::UI. This would also remove any doubt over whether to use e.g. "Inkscape::UI::Dialog::Print" (which makes the name as used within the namespace ambigous - "Print" what?) or "Inkscape::UI::Dialog::PrintDialog" (which is redundant) - one would simply use "Inkscape::UI::PrintDialog". In general, 2 levels of namespaces are entirely sufficient. XML tree goes into Inkscape::XML, UI code goes into Inkscape::UI, object (SP) tree goes into Inkscape::SVG (in the future), and so on. Regards, Krzysztof

3 3

Convert a rect to a path problem
by Jabiertxo Arraiza Cenoz 12 Nov '13

12 Nov '13

Hi to all, first sorry for this big mail. I want to convert a SP_RECT to path. This rect isnt selected and dont want to select it. The svg is a document with only a group and inside the SP_RECT. I test it whith two object inside and the same error. The code i use is: if ( SP_IS_RECT(subitem) ) { SPDocument *doc = subitem->document; Inkscape::XML::Document* xml_doc = doc->getReprDoc(); Inkscape::XML::Node *repr = xml_doc->createElement("svg:path"); /* Transformation */ repr->setAttribute("transform", subitem->getRepr()->attribute("transform")); /* Style */ gchar *style_str = (gchar *) sp_style_write_string(subitem->style); repr->setAttribute("style", style_str); g_free(style_str); /* Mask */ gchar *mask_str = (gchar *) subitem->getRepr()->attribute("mask"); if ( mask_str ) repr->setAttribute("mask", mask_str); /* Clip path */ gchar *clip_path_str = (gchar *) subitem->getRepr()->attribute("clip-path"); if ( clip_path_str ) repr->setAttribute("clip-path", clip_path_str); /* Rotation center */ repr->setAttribute("inkscape:transform-center-x", subitem->getRepr()->attribute("inkscape:transform-center-x"), false); repr->setAttribute("inkscape:transform-center-y", subitem->getRepr()->attribute("inkscape:transform-center-y"), false); /* Definition */ gchar *def_str = sp_svg_write_path(SP_RECT(subitem)->getCurve()->get_pathvector()); repr->setAttribute("d", def_str); g_free(def_str); Inkscape::XML::Node *parent = subitem->getRepr()->parent(); gint pos = 0; char const *id = subitem->getRepr()->attribute("id"); pos = subitem->getRepr()->position(); // remember id gchar *title = subitem->title(); gchar *desc = subitem->desc(); subitem->deleteObject(false); // add the new repr to the parent parent->appendChild(repr); repr->setPosition(pos > 0 ? pos : 0); repr->setAttribute("id", id); SPObject *subitem = doc->getObjectByRepr(repr); if (title && subitem) { subitem->setTitle(title); g_free(title); } if (desc && subitem) { subitem->setDesc(desc); g_free(desc); } if (repr) { Inkscape::GC::release(repr); repr = NULL; } //item_list = g_slist_append(item_list,subitem); //continue; } And the backtrace error is: ** Message: need to add dynamic switch ** Message: need to add dynamic switch ** Message: need to add dynamic switch ** (inkscape:3452): CRITICAL **: virtual unsigned int Inkscape::XML::SimpleNode::position() const: assertion `_parent != NULL' failed Program received signal SIGSEGV, Segmentation fault. 0x00000000005b879d in sp_group_perform_patheffect (group=0x7e63660, topgroup=0x7e63660, write=true) at ../../jabiertxof/src/sp-item-group.cpp:846 846 parent->appendChild(repr); (gdb) bt #0 0x00000000005b879d in sp_group_perform_patheffect (group=0x7e63660, topgroup=0x7e63660, write=true) at ../../jabiertxof/src/sp-item-group.cpp:846 #1 0x00000000005c638d in sp_lpe_item_update_patheffect (lpeitem=0x7e36a50, wholetree=true, write=true) at ../../jabiertxof/src/sp-lpe-item.cpp:381 #2 0x00000000005c67b1 in SPLPEItem::remove_child (this=0x7e63660, child=0x6dd53a0) at ../../jabiertxof/src/sp-lpe-item.cpp:709 #3 0x00000000005b7149 in SPGroup::remove_child (this=0x7e63660, child=<optimized out>) at ../../jabiertxof/src/sp-item-group.cpp:142 #4 0x000000000086ca1b in Inkscape::XML::CompositeNodeObserver::notifyChildRemoved (this=0x6dd5410, node=..., child=..., prev=0x0) at ../../jabiertxof/src/xml/composite-node-observer.cpp:49 #5 0x000000000087a017 in Inkscape::XML::SimpleNode::removeChild ( this=<optimized out>, generic_child=<optimized out>) at ../../jabiertxof/src/xml/simple-node.cpp:479 #6 0x00000000005dcfae in sp_repr_unparent (repr=0x6dd53a0) at ../../jabiertxof/src/xml/repr.h:104 #7 SPObject::deleteObject (this=0x7e36a50, propagate=false, propagate_descendants=false) at ../../jabiertxof/src/sp-object.cpp:454 #8 0x00000000005b8795 in deleteObject (propagate=false, this=0x7e36a50) at ../../jabiertxof/src/sp-object.h:464 #9 sp_group_perform_patheffect (group=0x7e63660, topgroup=0x7e63660, write=true) at ../../jabiertxof/src/sp-item-group.cpp:844 ---Type <return> to continue, or q <return> to quit--- #10 0x00000000005c638d in sp_lpe_item_update_patheffect ( lpeitem=lpeitem@...3051...=0x7e63660, wholetree=wholetree@...3051...=true, write=write@...3051...=true) at ../../jabiertxof/src/sp-lpe-item.cpp:381 #11 0x00000000005c7187 in SPLPEItem::addPathEffect (this=0x7e63660, value=<optimized out>, reset=true) at ../../jabiertxof/src/sp-lpe-item.cpp:509 #12 0x00000000007669cb in Inkscape::LivePathEffect::Effect::createAndApply ( name=0x12285d8 "bend_path", doc=<optimized out>, item=0x7e63660) at ../../jabiertxof/src/live_effects/effect.cpp:294 #13 0x000000000098b4f8 in Inkscape::UI::Dialog::LivePathEffectEditor::onAdd ( this=0x72cee80) at ../../jabiertxof/src/ui/dialog/livepatheffect-editor.cpp:423 #14 0x00007ffff5212748 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 #15 0x00007ffff04e86e0 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x00007ffff04f9966 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x00007ffff05016bc in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x00007ffff0501852 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x00007ffff68e0b45 in ?? () ---Type <return> to continue, or q <return> to quit---q from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.soQuit (gdb) Any help is welcome and thanks for read the mail. Regards, Jabier.

2 3

Buildd mails
by Markus Engel 10 Nov '13

10 Nov '13

Hi devs, when moving some files around I seem to have broken make check accidently. I forgot to regenerate POTFILES.in. This should work again tomorrow, I just committed the new file. Sorry for causing the noise. Regards, Markus

1 0

How can I Help Speed Up the Inkscape 0.49 Release?
by Shlomi Fish 08 Nov '13

08 Nov '13

Hi all, how can I help speed up the Inkscape 0.49 release? I'm interested in doing that and have some free time. Regards, Shlomi Fish -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/bits/Can-I-SCO-Now/ - "Can I SCO Now?" The gods help them that help themselves. ( Aesop ) Please reply to list if it's a mailing list post - http://shlom.in/reply .

2 2

Re: [Inkscape-devel] Version number
by Jared Meidal 08 Nov '13

08 Nov '13

My vote is for Inkscape 5, pointing to maturity of the .4x.x line, and to demonstrate overall reliability and maturity of the application. My secondary vote, would be for Inkscape 0.91, moving toward a 1.0 release. Overall it would be great to update a features-to-version-number page to help map where we are, and where going. --Jared > I wrote that in as more a placeholder, way, way back when. At the time > we had consensus that Inkscape wasn't mature enough in terms of features > and stability to justify calling it 1.0. I wanted to keep that as a > goal in the roadmap, and to tie it to something tangible. SVG 1.0 > seemed like a logical place to put a pin in, but there wasn't a huge > amount of thought put into it. It could easily have been "Switch to > Cairo for rendering." > > I can see the next major release after 0.48.x as a candidate for change as the "9'er" may lend itself toward a new scheme. > > > > * 0.49.0 --> 0.90.0 (followed by 1.0, 1.1, 2.0...) > This sounds like a good approach. Might go to 0.91 just to avoid the > usual confusion people have with our 0.x0 releases (i.e. people will > call it version 0.9. > > * 0.49.0 --> Inkscape 9 (followed by Inkscape 9.1, 10.0...) > Seems like tooo big of a jup. > We also discussed date based version numbers. At the time it was quite > a fad and a lot of projects were adopting that. Seems less widely used > now, except by projects that follow strict time-based release > schedules, like distributions. > > There have been a lot of excellent developments to be release in the next release, including C++, cairo, alignment/distribution along with new possible builds on win64-bit (Partha's help), and native Mac OS X (some almost-ready builds are out there). If these all reach maturity for the release the new builds are providing an increase audience and userbase. A changing version numbering scheme could reflect the developers' acknowledgement of this and demonstrate the activity of the software project. > Yep. > Bryce > > > > Just IMHO, > > > > --Jared

10 18

Gradients with objectBoundingBox coordinates not being preserved or rendered correctly
by Bryan Hoyt | Brush Technology 08 Nov '13

08 Nov '13

If I create a gradient in Inkscape, the default coordinate space is userSpaceOnUse, as opposed to objectBoundingBox (see https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/gradientUnits). This is ok, but if I edit a gradient manually (via a text editor or the XML editor) to change it to objectBoundingBox coordinates, I would like it to stay that way. objectBoundingBox gradients are very useful if you want to animate or otherwise interact with the SVG using javascript in a browser -- the gradient will move relative to the object, and you don't have to write extra complicated code to try and keep it lined up. Currently, *a)* Inkscape initially renders the gradient nodes in the correct position, but does not render the gradient colours themselves. So the object has a flat colour. *b) *As soon as I drag one of the endpoints, it reverts to userSpaceOnUse coordinates. Which means that it becomes quite difficult to edit my SVG file in Inkscape ever after! Ideally, the object would be coloured correctly, and if I move a node or endpoint, it would remain in objectBoundingBox coordinates. Better yet, there would be a way to switch to objectBoundingBox coordinates from within the GUI, to avoid having to calculate the conversion maths in the XML editor. How hard would those things be to fix? - Bryan -- Bryan Hoyt, *Software Developer* -- Brush Technology *Ph:* +64 3 741 1204 *Mobile:* +64 21 238 7955 *Web:* brush.co.nz

5 9

wmf-inout bug
by Johan Engelen 06 Nov '13

06 Nov '13

Hi all, Clang found a potential bug. In /src/extension/internal/wmf-inout.cpp, line 1408: int32_t width, height, colortype, numCt, invert; if( (iUsage != U_DIB_RGB_COLORS) || !(dibparams = wget_DIB_params( // this returns pointers and values, but allocates no memory dib, &px, &ct, &numCt, &width, &height, &colortype, &invert )) ){ Now if the first condition is true ("(iUsage != U_DIB_RGB_COLORS)") the second part will not be executed, and thus all those ref'd variables will go un-initialized. I'd appreciate it if someone with more knowledge about wmf-inout.cpp would have a look and fix the code (it's pretty ugly to put the initialization call in the if-condition...) Thanks! Johan

2 3

Image Gallery thumbnails
by Jared Meidal 06 Nov '13

06 Nov '13

Martin, The beautiful thumbnails have disappeared! 😊 http://staging.inkscape.org/en/community/gallery/ Any possibility of restoring them? --Jared

2 1

Re: [Inkscape-devel] Bug Counts on Website
by Jared Meidal 05 Nov '13

05 Nov '13

Martin, The staging site states there are 4 Blockers/4865 Fixed, but the linked Launchpad pad page only lists 3/4866! Is sync off or delayed? --Jared > On Sat, 2013-10-19 at 02:14 +0200, Krzysztof Kosi?ski wrote: > > Is there some way to change the background color? The background for > > blocker bugs is so light that it's hard to read the number, while the > > background for fix released bugs should be green, I think :) > > So there are two colour controls. Firstly the CSS, I can make the yellow > darker so it's readable. > > Secondly the counts, changing the low count to forty million bugs should > make it green. Whatever the number of bugs, it's bound to be lower than > forty million. > > Martin,

3 3