- Inkscape Devel - Inkscape Mailman

Inkscape Trademark Policy
by Bryce Harrington 05 Feb '14

05 Feb '14

Hi all, One of the Inkscape Board's actions in 2013 was to establish a trademark policy for the Inkscape name and logo. With the Software Freedom Conservancy's help we've completed the registration and documented under the About menu item on the website: http://inkscape.org/en/about/trademark-policy/ The motivation for doing this was due to questions that kept cropping up from people wanting to use it for legitimate purposes (e.g. using our unmodified logo on merchandise), and from people noticing our trademark used illegitimately (e.g. selling unrelated software using our name or logo). We wanted a policy that would provide clear guidance for all these uses, that would be liberally permissive for non-commercial and FOSS-friendly commercial uses, while prohibiting obviously fraudulent uses. Along with this, I've added a FAQ entry (below) with a brief summary. Bryce == FAQ: How are the Inkscape name and logo protected? == The Inkscape name is trademarked under U.S. Trademark Law, and held and administered by the Software Freedom Conservancy. Our policy is available on the website, and describes the conditions under which you can use our name and logo. We've aimed to make our requirements reasonable and friendly: We want to avoid things like other groups claiming to be or represent us when they don't, or to distribute our software in ways that aren't consistent with our license. The logo is similarly trademarked and covered by our trademark policy. We're cool with people creating derivative works that help promote Inkscape or make it fit in with a given user interface style, but we don't want to see it abused by companies that might incorporate it into their own logos. For merchandising, you are welcomed to use our unmodified logo; for anything else, please contact the Inkscape Board for permission.

2 1

Re: [Inkscape-devel] Making inkscape usable in valgrind grumble
by mathog 05 Feb '14

05 Feb '14

On 03-Feb-2014 20:01, Krzysztof Kosiński wrote: > In the long term, I think the consensus is that we should move away > from garbage collection and towards explicit memory management with > smart pointers. In the short term, I'm afraid there is little we can > do about this. The initial pieces of the puzzle are already in place > with the C++ification work on the SP tree. Apparently the current GC does not call destructors when it automatically removes memory. Inkscape has code in gc-finalized to tack a destructor onto an entry, but it isn't easy to see how often it is employed (grep shows "Finalized" in only a handful of source of files), and gc-finalized.h lists several caveats, which say that there are lots of situations where it might never act even if invoked. > GC is mainly used in code related to XML and undo handling. Removing > GC there requires modifying every piece of code that creates or > deletes XML nodes - at least 277 places according to grep. Speaking of that section, is there some debugger trick for keeping track of the objects that that code creates and deletes? I've been trying to follow it in gdb but since the memory pointers move around from run to run, and just running gdb seems to change what inkscape does (probably because mouse events are caught in strange ways, or windows overlap), it is really tedious. I ask because my text decoration mods blow up in style.cpp in sp_style_paint_server_ref_modified() when a certain simple object is selected on the drawing surface and then copied - but not if it is cloned. That object is just this: <text style="font-size:40px;fill:none;stroke:url(#MyPattern);stroke-width:5;" y="40"><tspan>A<tspan style="text-decoration:underline">B</tspan></tspan></text> The copy (==^C) triggers an insane amount of activity which passes in and out of style.cpp, where signals are attached and detached, apparently to/from the same objects much of the time, until eventually it drops into the function mentioned above with a PaintServer server that no longer matches the ones in style->stroke and style->text_decoration_stroke (which match each other), which triggers the crash. (After having previously been in that same function maybe a dozen times without issue.) It is my impression that there is vastly more activity for this simple copy then there is in just reading in that section of the file in the first place. (It definitely calls sp_style_write_string() at least 2 times for each of the styles in the section being copied, probably because execution control is through the setting and resetting of modified flags, rather than by doing a single "atomic" 1:1 copy.) Conversely, this object: <text style="font-size:40px;fill:url(#MyPattern);stroke:none" y="40"><tspan>A<tspan style="text-decoration:underline">B</tspan></tspan></text> copies without issue. It too triggers a lot of activity, including redundant sp_style_write_string() calls, but somehow it avoids whatever pitfall the first one falls into. As far as I can tell the implementations for style->text_decoration_fill and style->text_decoration_stroke are symmetrical, so why one crashes, and the other doesn't is pretty mysterious at present. It has something to do with the paintServer href, since there are no problems with text_decoration_stroke when it does not use a pattern or a gradient. Tracing execution in this region is no fun since much of it is driven by signals that trigger calls to stored references to functions. I can watch it creating patterns, objects, and styles, but figuring out which is which solely from their pointers, which change from run to run, is not a lot of fun. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

New to Inkscape
by gagan 04 Feb '14

04 Feb '14

Hey all, I am a new user here at Inkscape and don't know what to do. I want to contribute to this projects as a developer; can anyone help me out where to start. Thanks in advance -- Thanks Gaganjyot http://codeify.wordpress.com "Jai Sai Naath"

3 2

LGM 2014 Leipzig
by Tavmjong Bah 04 Feb '14

04 Feb '14

Hi, If the Inkscape board were to offer some financial support to attend LGM (April 2-5 in Leipzig, Germany)[1] who would be interested in attending the meeting? There will be people from Gimp, FontForge, Scribus, etc. as well as a number of SVG Working Group members there. At the moment, I am the only one I know from Inkscape (besides Alexandre Prokoudine and Sirko Kempter, both LGM organizers) who is signed up to attend. Tav [1] http://libregraphicsmeeting.org/2014/

1 0

Future plans for XML namespaces in Inkscape and SVG 2
by Jarek Foksa 03 Feb '14

03 Feb '14

Are there any plans for Inkscape to move away from XML namespaces when SVG 2, HTML 5 and Web Components will become widely supported and XML namespaces will get deprecated? If this is the case, I think it would be great opportunity to clean up the current namespace mess. Ideally, I would like to see all vendors of SVG editors to agree on a common “editor” namespace that would be implemented with HTML 5 data- attributes and custom elements. My proposal: 1. Drop “dc:", "cc:" and "rdf:" namespaces and remove any elements and attributes using them as this is just useless noise. 2. Drop "xlink:" namespace prefix (as defined by the SVG 2 spec). 3. Convert all elements in “inkscape:" and "sodipodi:" namespace to custom elements with "editor-" prefix (as defined by Web Components spec) 4. Convert all attributes in “inkscape:” and "sodipodi:" namespace to data- attributes (as defined by HTML 5 spec). For example following SVG 1.1 document generated by current stable version of Inkscape: <svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" version="1.0" width="1000" height="2000" viewBox="0 0 1000 2000"> <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10" guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="1366" inkscape:window-height="689" id="namedview1530" showgrid="false" inkscape:zoom="0.57" inkscape:cx="542.23281" inkscape:cy="1495.4813" inkscape:window-x="0" inkscape:window-y="27" inkscape:window-maximized="1" inkscape:current-layer="svg2"/> <image sodipodi:absref="/image.png" xlink:href="image.png" width="950" height="632"/> <path inkscape:connector-curvature="0" d="M 60,10 L -40,-45"/> </svg> ... could become this in future when saved as SVG 2 document: <graphics width="1000" height="2000" viewbox="0 0 1000 2000"> <defs> <editor-namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10" guidetolerance="10" pageopacity="0" pageshadow="2" windowwidth="1366" windowheight="689" id="namedview1530" showgrid="false" zoom="0.57" cx="542.23281" cy="1495.4813" windowx="0" windowy="27" windowmaximized="1" currentlayer="svg2"> </editor-namedview> </defs> <image data-editor-absref="/image.png" href="image.png" width="950" height="632"/> <path data-editor-connector-curvature="0" d="M 60,10 L -40,-45"/> </graphics> Some related documents: - Custom elements: http://w3c.github.io/webcomponents/spec/custom/ - Proposal for improving SVG DOM: http://dev.w3.org/SVG/proposals/improving-svg-dom/ - Data attributes: http://www.whatwg.org/specs/web-apps/current-work/#embedding-custom-non-vis… Do you think this has any chance to get adopted by Inkscape? If not, do you have any alternative plan to improve the way how Inkscape stores non-standard data in SVG documents in the upcoming post-XML future?

5 8

wiki account
by Masanori Kanazu 03 Feb '14

03 Feb '14

Hi, I would like to contribute to the translation of Inkscape wiki into Japanese. I already finished translating these two articles. http://wiki.inkscape.org/wiki/index.php/Inkscape_for_Adobe_Illustrator_users http://wiki.inkscape.org/wiki/index.php/AdobeToolMap Could you please create a wiki account with username "mkanazu" for me? regards, Masanori Kanazu

2 1

Future plans for XML namespaces in Inkscape and SVG 2
by Jelle Mulder 03 Feb '14

03 Feb '14

Hi all, If anything I think the namespaces et al should be optional by using export switches. That would allow every user to create his own specified exports. Currently the is the Inkscape SVG file and plain SVG and optimised SVG, but I think it would be way more useful if there were just two kinds of SVG files. Inkscape native and export, the latter of which could be optimised with switches. If you'd then have a list of templates for optimisation (with a description on what it is used for)that would set these switches for the users, it would facilitate the user to find the right flavor of SVG. Currently you'll have to handcode a lot to create the right flavor and using such export facilities would simplify the process. In any case removing the XML namespaces doesn't feel like a good option as long as many people are using legacy software to get their SVG to parse right. Blink of all parsers imho is NOT the default to go with when it comes to parsing SVG and there are more things done with SVG than just produce content for the Android platform. SVG 2 seems still very much in flux and I would suggest not doing anything drastic until the recommendation level is reached, regardless of what a juggernaut like Google is doing. I guess they're flexible enough when it comes to exploiting standards for their own benefit as do all the others to try and push things their way, but that is basically what standards are for. To force the monopolists to adhere to standards. Not the other way around. Google in that respect can have a look at what happened to MS the past decade. And it may very well be the opening that MS would like to see if Google would divert. There are several products Google tried and dropped as well, without a blink. Please stick to the standard with tenacity. Any decent developer can handle the bloat. Oh,.. and... Happy Chinese New Year! Jelle Mulder

1 0

Waf build system, second try
by Krzysztof Kosiński 01 Feb '14

01 Feb '14

Hello everyone, I conducted an experiment in building Inkscape with Waf, redoing the work I did a long time ago with a newer version (1.7.15) and using more of its features. A correct build of Inkscape, with internal libraries built separately, "inklib" built as a shared library, Bazaar revision fetching and .po file compilation, requires less than 250 lines of Python script (!!!). I read on some mailing lists that Debian refused to package some software using Waf, because Debian considers shipping the "Waf binary" to be incompatible with the DFSG. I circumvented this problem by adding the Waf source distribution to the tree, which is a little bigger, but DFSG-compliant and works exactly the same. The code will be up shortly at lp:~tweenk/inkscape/waf-build, if anyone wants to check it out. Regards, Krzysztof

10 28

Re: [Inkscape-devel] Waf build system, second try
by Johan Engelen 31 Jan '14

31 Jan '14

Hi Isobel, I'll be on vacation for a week, can't give a detailed answer now. But I am not the right person to ask anyway :) I think _building_ is the easy part, but getting all the include flags correct for all platforms is not. (which is "configuration" that you mean?) An example of what would be nice to have is the ability to specify additional compiler flags for each folder. Current architecture's biggest problem is that it is not crossplatform. Note that on Windows, cygwin is cumbersome and not something we want to do. ciao, Johan ----- Reply message ----- From: "Isobel Knowles" <ik5@...2950...> To: "Johan Engelen" <jbc.engelen@...2592...> Cc: <inkscape-devel(a)lists.sourceforge.net> Subject: [Inkscape-devel] Waf build system, second try Date: Fri, Jan 31, 2014 00:14 On Thu, 30 Jan 2014 20:11:14 +0100 Johan Engelen <jbc.engelen@...2592...> wrote: > > On 30-1-2014 20:02, Isobel Knowles wrote: > > PS. My offer to write some 'nice' makefiles is still open. > > No-one is stopping you :-) > Make us dazzle... > > :) > Johan Dear Johan, OK. Before I do, do you think you could tell me what it is you want from the build? What are the essentials and what are the nice-to-haves? Where do you see the problems in the current architecture and what are its strengths? I'm only after some pointers so I don't set off in the wrong direction. I'll start the ball rolling with these: - Documentation. People who are new to Inkscape should find it easy to edit the makefiles. - Separate configuration and build cleanly so when the configuration phase doesn't do what you want for one reason or another, it is straight-forward to manually configure the build options in one or two files. - Separate compilation and installation/packaging. Installation is generally performed as root, and all too often in GNU software libtool and the like get their teeth into a 'make install', turning it into compilation job. This is wrong. - An ordinary build job should do the minimum work in the minimum time. For this I propose a flat makefile structure, perhaps composed of included makefiles. Parallel makes like this perform correctly and have no scalability issues whereas recursive makefiles are beset with problems and complication. - It should be simple to modify build flags and make alternative targets for debugging purposes. I wouldn't describe it as dazzling, but it's a start. Yours, Is.

1 0

Copying text with pattern stroke and fill + text decoration issue
by mathog 30 Jan '14

30 Jan '14

Hi all, After adding pattern fill and stroke support for text decoration I found that if both text decoration and a pattern are active, then trying to copy a text object with that combination crashes inkscape. That is, in rough terms, if the input file contains: <text > <tspan style=" pattern fill " > A <tspan style="text-decoration:underline">B</tspan></tspan></text> it loads and renders properly. But if "AB" is selected as an object (not as the text) and "^c" to copy, it crashes in style.cpp in sp_style_paint_server_ref_modified because "server" is not the same as style->getStrokePaintServer() (or style->getTextDecorationStrokePaintServer(), but these last two are identical in the test cases.) That is (sorry about the wrap): (gdb) print *server $1 = {<SPObject> = {_vptr.SPObject = 0x8a13e48, cloned = 0, uflags = 0, mflags = 0, xml_space = {set = 0, value = 0}, hrefcount = 1, _total_hrefcount = 1, document = 0x9232a80, parent = 0xa082ad8, children = 0xa086210, _last_child = 0xa086210, next = 0xa0c2ea8, id = 0xbadc000 "Packedcircles", repr = 0xbbb26f0, refCount = 4, style = 0xa096200, _release_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0xa0f6d48}, <No data fields>}, <No data fields>}, _delete_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _position_changed_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _modified_signal = {<sigc::signal2<void, SPObject*, unsigned int, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = { callback_list_ = 0x0}, impl_ = 0xa0765e8}, <No data fields>}, <No data fields>}, _successor = 0x0, _collection_policy = SPObject::ALWAYS_COLLECT, _label = 0x0, _default_label = 0x0}, swatch = false} (gdb) print *style->getTextDecorationStrokePaintServer() $2 = {<SPObject> = {_vptr.SPObject = 0x8a13e48, cloned = 0, uflags = 0, mflags = 0, xml_space = {set = 0, value = 0}, hrefcount = 7, _total_hrefcount = 7, document = 0x9232a80, parent = 0xa082ad8, children = 0x0, _last_child = 0x0, next = 0xa099530, id = 0xa059ab0 "pattern5506", repr = 0xbbb5ff0, refCount = 1, style = 0xa07be48, _release_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0xa0ccfc0}, <No data fields>}, <No data fields>}, _delete_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _position_changed_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _modified_signal = {<sigc::signal2<void, SPObject*, unsigned int, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = { callback_list_ = 0x0}, impl_ = 0xa0e8fd0}, <No data fields>}, <No data fields>}, _successor = 0x0, _collection_policy = SPObject::ALWAYS_COLLECT, _label = 0x0, _default_label = 0x0}, swatch = false} It seems like the objects are put together differently when they are copied than when they are just read in. The clue comes from the "pattern5506" above. That ID isn't in the original file, it is somehow created during the copy operation. Can somebody tell me where that is happening? The object construction when the file is opened or reverted is in style.cpp, if the copy feeds through there too, I guess the question becomes "where is the SVG created" that is fed into it. If the text-decoration just uses solid colors and fills there are no issues copying a complex formatted text object with text decorations. It is only when patterns and text decorations are both present that things go south. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0