January 2016 - Inkscape Devel

Notification popup on inapplicable command
by Daniel Beardsmore 29 Jan '16

29 Jan '16

One aspect of Inkscape that is confusing is that it is possible to issue commands that have no effect because they are inapplicable, e.g. requesting to unlink a clone, on an object that is not a clone. Where such inapplicable commands are given with the keyboard, there is no notification that the command did nothing, and when no visual change would have occurred even when it did succeed, the results can be especially confusing. Ideally, all menu items and toolbar buttons would be dynamic, i.e. disabled when inapplicable, but I'm thinking that it would also make sense to show a floating notification bar that notifies the user that the command failed because it did not apply, e.g. "Object is not a clone". ---------------------------------------------- This e-mail was sent from my Desktop Computer®

2 2

Re: [Inkscape-devel] Toolvar dinamic
by Jabier Arraiza 28 Jan '16

28 Jan '16

This is a attemp to make extended toolbars widget dinamic. Currently in Spray Tool. https://inkscape.org/en/gallery/item/7431/ Feedback are welcome. Cheers, Jabier. El lun, 25-01-2016 a las 11:09 +0100, Vladimir Savic escribió: > Disabling is required, that´s for sure, but we should really watch > out that > toolbar doesn´t grow up to big (long). :) > > Cheers, > Vlada > > On Mon, Jan 25, 2016 at 10:42 AM, Jabier Arraiza <jabier.arraiza@...3301..... > er.es> > wrote: > > > Hi Vlada, currently we don't add or remove widgets on the fly from > > toolbox, but we can disable if a knife, for example, is selected. > > Anyway i try to hide/show widgets to be sure. > > > > Cheers, Jabier. > > > > > > El lun, 25-01-2016 a las 10:21 +0100, Vladimir Savic escribió: > > > Hi Jabier, > > > > > > I don´t think we could afford one more icon in toolbox. There > > > are, > > > from > > > usability point of view, two possible but not so trivial to > > > implement > > > solutions: > > > > > > 1) Implement Icon grouping on main toolbar > > > 2) Dynamically changing secondary toolbar. Similar to path tool > > > modes > > > (BSpline, Spiro, Bezier etc.), but with other settings that > > > change > > > depending on modus.. I´m in favour of this one because there are > > > other > > > other tools that could benefit from this change. For example, > > > Mash > > > gradient > > > and regular gradient tools could be merged. Erase could have > > > knife > > > (similar > > > to a path tool with zero width), freehand erase (what we > > > currently > > > have) > > > and guides slicing (the one you have proposed already). Any of > > > those > > > should > > > have different options. Erase must have at least Width slider, > > > Knife > > > should > > > offer an option to Crear una sucesion de segmentos rectos, > > > segmentos > > > paraxiales etc. I´ve copied those Spanish names from screen. :) > > > > > > Regards, > > > Vlada > > > > > > On Mon, Jan 25, 2016 at 9:47 AM, Jabier Arraiza <jabier.arraiza@...3314...67... > > > arke > > > r.es> > > > wrote: > > > > > > > Yes, one more icon :) > > > > > > > > > > > > El lun, 25-01-2016 a las 00:31 -0700, Brynn escribió: > > > > > "Hy Brynn. I like more a new tool but ¿Is enought interesant > > > > > to > > > > > get > > > > > some > > > > > toolbox pixels? > > > > > > > > > > There is a problem on open paths also in boolean operations, > > > > > not > > > > > only > > > > > in potrace related code in eraser tool. If the proyect go on, > > > > > we > > > > > try > > > > > to > > > > > solve this open path problem. > > > > > > > > > > Cheers, Jabier." > > > > > > > > > > Thanks for the info about open path/boolean. Several > > > > > "mysteries" > > > > > solved by > > > > > that comment :-) > > > > > > > > > > I'm not sure what you mean by "toolbox pixels". Do you mean > > > > > that > > > > > the > > > > > toolbox would need to be bigger, to make room for another > > > > > icon/button? > > > > > > > > > > Or is something technical that goes over my head? > > > > > > > > > > All best, > > > > > brynn > > > > > > > > > > -------------------------------------------------- > > > > > From: "Jabiertxo Arraiza Cenoz" <jabier.arraiza@...2893...> > > > > > Sent: Sunday, January 24, 2016 4:44 AM > > > > > To: "Brynn" <brynn@...3133...>; "Inkscape-Devel" > > > > > <inkscape-devel(a)lists.sourceforge.net> > > > > > Subject: Re: [Inkscape-devel] Google Summer of Code (GSoC) > > > > > 2016 - > > > > > Call for > > > > > mentors & help with ideas page > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > ---- > > > > ------------- > > > > Site24x7 APM Insight: Get Deep Visibility into Application > > > > Performance > > > > APM + Mobile APM + RUM: Monitor 3 App instances at just > > > > $35/Month > > > > Monitor end-to-end web transactions and take corrective actions > > > > now > > > > Troubleshoot faster and improve end-user experience. Signup > > > > Now! > > > > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/414 > > > > 0 > > > > _______________________________________________ > > > > Inkscape-devel mailing list > > > > Inkscape-devel(a)lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > >

5 18

GSOC Proposal changed, from "Eraser tool improvements" to "Slice toolbar items"
by Jabier Arraiza 28 Jan '16

28 Jan '16

Based on the list feedback, I Just changed my proposal to slice items. Any english speaker are welcome to fix: http://wiki.inkscape.org/wiki/index.php/Development_Project_Ideas#Slice _toolbar_items http://wiki.inkscape.org/wiki/index.php/Google_Summer_of_Code#P3._Slice _toolbar_items Cheers, Jabier.

1 0

Fwd: Inkscape Hackfest: Who will attend?
by Sebastian Faubel 27 Jan '16

27 Jan '16

Hello everybody, me and my colleague would be interested in attending, too. We'd like to work on implementing a C++ based extension loader.. :) All the best, Sebastian *Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg, Germany | Phone: +49 821 8854401 | Fax: +49 821 8854410 | www.semiodesk.com This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Semiodesk GmbH is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. 2016-01-27 10:52 GMT+01:00 Marc Jeanmougin <marc@...3062...>: > I am definitely interested too! > -- > Mc > > On 01/26/2016 01:58 PM, Tavmjong Bah wrote: > > > > Hi, > > > > We are planning an Inkscape hackfest[1] in Leeds just before the Libre > > Graphics Meeting[2] in London. To help plan this event we need to have > > an idea of how many people would attend. Please reply here or send a > > private email to me if you are interested. As with last years > > hackfest[3], travel support will be offered to developers and others > > active in the Inkscape project ($500-$2000). > > > > Dates: > > Hackfest: 11-13 April 2016 (tentative) > > LGM: 15-18 April 2016 > > > > Tav > > > > [1] http://wiki.inkscape.org/wiki/index.php/Hackfest2016 > > [2] http://libregraphicsmeeting.org/2016/ > > [3] http://wiki.inkscape.org/wiki/index.php/Hackfest2015 > > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > >

1 0

Win32 devlibs update
by Nicolas Dufour 26 Jan '16

26 Jan '16

Hi all, The win32 devlibs have just been updated (rev. 54) to fix the following reports: - Bug #1530286 "Inkscape fails to build on Window with GC errors", - Bug #1156664 "Compile against external libpotrace". The build.xml files also changed in rev. 14559, so don't forget to update the devlibs and run "btool clean" before compiling! Regards, -- Nicolas

5 32

Differences in union result between commandline and the GUI?
by eric schleicher 22 Jan '16

22 Jan '16

Hello. getting familiarized with using inkscape from the commandline in preparation for developing some automation and connectors in nodejs. Running some simple examples, I noticed that there seem to be some differences between the output created by the commandline and what the UI create (on the exact same input assets). I've attached a photo here noting the most obvious differences I've observed I'm wondering if anyone might be able to shed some light on the why i might be seeing these differences and whether there is a way to address them do that the output from the commandline is faithful to the both the original and the version created by the union operation in the UI. The path union operation from the UI is flawless, but not so from the command line so this was a very unexpected result. Are these types of deviations common, or perhaps is this something that can be addressed with different settings/arguments. for reference, where command used: ./inkscape --file 'c:\users\user\dog.svg' --select 'top' --verb 'SelectionUnion' --export-plain-svg='c:\users\user\dog-plain.svg' Run from a poweshell session on windows 8.1 with Inkscape 0.91 r13725 (Jan 30 2015) The original (path, not text) [image: Inline image 2] A Comparison of the two Otherwise this seems to be a bug. Interested to learn more, Eric

2 1

Specifying color fonts
by Tom Lechner 22 Jan '16

22 Jan '16

Hi, Is there currently in Inkscape a way to specify exact fonts, like specific font files? If I understand right, would this mean support of "user fonts" as specified by CSS3 Fonts? I've been working on using color fonts made from font layers (where each color layer is a different font file), but the layer fonts I can find all specify family names and styles in such a way that it seems impossible to specify them in Inkscape. Is there any planned native support for color fonts, either manually layered, or opentype svg/colr/cpal color fonts? -Tom ---- laidout.org tomlechner.com

2 1

Inkscape 0.92 and Converting Inkscape to CMake
by Bryce Harrington 19 Jan '16

19 Jan '16

CMake is a key goal for the Inkscape 0.92 release. We're close, but some important work still remains. Are you familiar with CMake? It's important not only that we convert the codebase, but that we also install our developers (i.e. YOU!!) with adequate cmake know-how to be able to update stuff as needs arise. Is CMake something you've not yet learned? I've written up a little Inkscape-specific tutorial / class to give you the basics. Please put it on your near-term todo list: http://wiki.inkscape.org/wiki/index.php/Working_with_CMake Once you're ready to tackle some cmake work, please take a look at my write-up of cmake tasks that I think we need to get done: http://wiki.inkscape.org/wiki/index.php/CMake_Tasks I've organized that page by tasks that I feel we need to get done for 0.92, versus ones that have to be done post-0.92 (since they'd break the autoconf stuff), and minor tasks that can be safely done whenever. Thanks for lending a hand to helping with the CMake work. My dream is that by achieving this conversion, we'll be able to unify a lot of our platform-specific packaging. Effort that currently is divided between linux, osx, and win32, will be able to be merged so we can better collaborate with packaging generally. Bryce

2 2

Re: [Inkscape-devel] Quality of gradients.
by mathog 14 Jan '16

14 Jan '16

(revised version of message sent originally only to Gez.) On 09-Jan-2016 12:33, Gez wrote: > For my professional work, the way inkscape renders gradients is a show- > stopper. The quality of my work suffers if I don't apply one of those > tedious workarounds discussed in this thread. The EMF export function supports simple gradients as descriptions (high & low color values, scale and direction of linear gradient) and so are not quality limited in this manner. Perhaps in some instances you could export to EMF and then render from that in another application which doesn't have the 8bit limit? Unfortunately there is no exact support for radial gradients in the EMF or EMF+ standards. Currently Inkscape emulates such gradients in EMF files with many small single colored elliptical slices. The best one could do with EMF would be to use the peculiar "triangle" gradient mode (Google "GRADIENT_FILL_TRIANGLE") to emulate a radial gradient. Then instead of rings it would be a lot of small wedges, each with its own part of the gradient. At the moment there is no code in Inkscape to do this. (EMF+, which is not yet supported at all in inkscape but is coded into libUEMF, has something called a "Path Gradient Brush" which is essentially a bunch of these triangle gradients merged, so that instead of specifying a lot of triangles, one specifies a center point and a path.) Going this route would be a one way trip, since the code for working back from multiple triangle gradients to a radial one would need to be pretty clever to look for and detect this sort of clustering and arrangement of gradients, especially since those EMF records need not be consecutive in the file. (Going from EMF+'s Path Gradient Brush to an SVG radial gradient would be easier because it would not have the multiple record problem.) Also an awful lot of these triangles might be needed to get a smooth looking radial gradient, that is, one that doesn't look like a set of nested polygons resulting from "contour lines" of constant colors. Perhaps slightly varying the angle in each slice would hide that effect a bit? Anyway, for future reference: EMF Triangle gradient (look about 1/3 down from the top) http://www.flounder.com/gradientfiller.htm EMF+ Path Gradient Brush http://www.codeproject.com/Articles/20018/Gradients-made-easy Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Licensing issues with Scour (aka 'Optimized SVG' output)
by Eduard Braun 12 Jan '16

12 Jan '16

Hi all, I'm posting here today hoping that we can finally resolve some licensing issues which recently emerged regarding the Scour extension for Inkscape (also know as 'Optimized SVG' output). I'll try to summarize the issue as good as possible so everybody is up to speed: * Right now we bundle an old version of Scour that is dual-licensed with Apache 2.0 license and GPLv2+. This dual licensing was only introduced in a very recent commit [1] when the original author Jeff Schiller agreed to re-license his code under the terms of GPLv2+ after license issues in Inkscape were brought up in a previous discussion [2]. However at this point there were multiple contributions to the Scour codebase by other authors who did not accept to re-license their contributions. This is why the re-licensing is likely to be void and the the current maintainer of Scour (Tobias Oberstein) decided not to apply the dual-licensing when switching over to GitHub with the project [3]. * I recently updated the Scour extension for Inkscape and want to merge these changes [4]. Obviously I followed Tobias Obersteins decision not to apply the dual-licensing, so the new version only has the Apache 2.0 License. * The open question now is: Can we bundle the Scour code with Inkscape and how to we do it? In my opinion this should not be a problem since Scour is an external module that is *indepentent* from Inkscape, e.g. license incompatibilities do not play a role here which is also the opinion of Tobias Oberstein (see [5] for details and references). Also most project members seem to agree (see comments in the merge request [4]) However If we don't want to follow this reasoning we have to decide on alternatives (especially since the code currently in trunk might well have an invalid license). I hope we can once and for all resolve this issue! Best Regards, Eduard [1] http://bazaar.launchpad.net/~scouring/scour/trunk/revision/222 [2] https://sourceforge.net/p/inkscape/mailman/message/32342425/ [3] https://github.com/codedread/scour [4] https://code.launchpad.net/~eduard-braun2/inkscape/scour/+merge/278387 [5] https://github.com/codedread/scour/issues/7

5 13