- Inkscape Devel - Inkscape Mailman

measurement tool
by Dmitry Kirsanov 28 Sep '13

28 Sep '13

The new tool is nice, but how do I set the origin to anything other than the lower left corner? I want to use it to measure distances between arbitrary points. There must be a shortcut (such as Shift+click) to set the origin, and the current origin must be indicated on the screen at all times while the tool is active. The shortcut to set the origin must be added to the tool's statusbar hint. Also, "Font size" must be removed from the tool's controls - it's pure UI preference, not something you change in the document, so its presence here is quite confusing. I'd suggest placing it into the tool's page in Preferences. There's a funny bug: when I drag with Ctrl to snap and stretch the angle to 180 degrees, the circle arc turns into an ellipse.

6 11

Rev 1 Maths
by Martin Owens 28 Sep '13

28 Sep '13

Hail Devs, In display/sodipodi-ctrl.cpp:133 has some interesting maths. It does int((float(value) - 1.0) / 2.0 + 0.5) ... which is a bit redundant. My tests in python show that this produces the same output as int(float(value) / 2.0)) for all ints and floats. But this code has been there since MentalGuy committed rev 1. and It's passed through 2 developers since who thought it was sane. So I guess I need to make sure this isn't some C++ trick before I simplify it. Best Regards, Martin Owens

3 3

Update on the Metadata refactoring
by Christoffer Holmstedt 28 Sep '13

28 Sep '13

Hi everyone In the beginning of the summer I set out to refactor the metadata code for Inkscape. In the end this turned out to be a bit bigger project than expected (as always? ;) ) but here is a short update. The last update was from the beginning of July which showed a GUI mockup [1] for the metadata tab. After that the gui was to be implemented in Inkscape but we weren't sure if the mockup was what we really wanted. Therefore in July/August we moved to python to be able to faster create and iterate over a prototype. The prototype can be found at github [2]. The goal in the long run is to create a C or C++ library with Gtk+ container which is ready for use in e.g. Inkscape that can handle everything that has to do with attribution and licenses. Related to this, work has also been done with a firefox plugin [3] and with mediagoblin. Code can be found on Github [4]. The short term goal here is to be able to show the "lifespan" of an image, "Creation -> Upload -> Download -> Create a derivative work -> Upload", and the attribution and license should stick with the image. So when it comes to the metadata refactoring it's pretty far away at the moment for pushing to trunk in Inkscape. I've now started my full time studies again so my goal for the fall is to at least take care of some bugs and try to learn a little bit more about the Inkscape codebase. [1] http://commonsmachinery.se/2013/07/inkscape-a-new-gui-to-manage-metadata/ [2] https://github.com/commonsmachinery/rdf_metadata [3] http://commonsmachinery.se/2013/09/pasting-images-attribution/ [4] https://github.com/commonsmachinery Regards -- Christoffer Holmstedt

1 0

videos
by Jabiertxo Arraiza Cenoz 27 Sep '13

27 Sep '13

Hi to all. I made videos of two brach: BSpline+Spirolive: http://www.youtube.com/watch?v=BvDBXXaY6Og#t=157 Bend From Clipboard: http://www.youtube.com/watch?v=owBLWJ2RvLA Thanks Vinícius for the idea! Regards, Jabier.

4 5

[Units] Comments
by Tavmjong Bah 27 Sep '13

27 Sep '13

Hi, First, congrats to Matthew for some very nice work. I've just given the latest code a quick test and I've got a few comments. I certainly haven't thought thing through carefully but I would be interested in what others think. I start by opening a new (from Templates) Letter in landscape mode. 1. The Template dialog tells me I am about to create a 612x792 pixel drawing. But the size of the drawing in the SVG file is set to 11in x 8.5in. Pixels are no where to be seen. 2. I create a default grid. The grid spacing is in "pixels" or 1/90 of an inch. I would expect it to be in fractions of an inch (1/4 or 1/10). 3. I set the grid to 1/4 of an inch with major grid line every 4 lines. Looks good. Now I create a rectangle 1 in x 1 in. Ooops, it is 0.99999988 x 0.99999988 according to the XML dialog. 4. I use the XML dialog to set it to exactly 1 x 1. Hmm, why isn't it 1in x 1in? 5. Ah ha, the viewBox is set to 0, 0, 11, 8.5. This means that the "user unit" aka "px" is equivalent to 1 inch. Maybe this isn't so bad, but it means I can't mix different units inside the SVG file. If I use "1in" for a dimension, it will be interpreted as 90 user units or 90 inches. My 20 "pt" text is stored as 0.277777776px in the SVG file (and shows up as 19.99 in the font-size widget). My thinking is that it might be better to set the viewBox to 0, 0, 792, 612 and then explicitly use dimensions with "in" if that is what the user wants. Tav

9 33

[Bend from Clipboard] Presentation and request for help with selection
by Jabiertxo Arraiza Cenoz 26 Sep '13

26 Sep '13

Hello to all. I made a new branch [1:bendFromClipboard] that make a bend liveeffect with a full draw in clipboard using pen or pencil stroke. It use the combo box in pen/pencil toolbox. I have this on mind time ago but need to credit Vinícius for the videos about his "Trace Pixel Art" feature, that refresh me. The code is working, need review -im not a c++ developer- and has one bug with selection. I explain: When all is done i call to "selection->set(obj)". "obj" exist but this code is ignored. I test it with second optional parameter to true and the same. Thanks in advance for test, reviews, help and feedback. Jabier. [1:https://code.launchpad.net/~jabiertxof/inkscape/bendFromClipboard]

2 1

Re: [Inkscape-devel] Staging website - graphics sources
by Jared Meidal 26 Sep '13

26 Sep '13

>> Jared, >> >> The deed is done, if you check >> http://staging.inkscape.org/en/community/gallery/ you'll find my new >> brochure django-cms plugin being used. It pulls in an rss feed, allows >> you to control how indexed entries are enabled from different sources. > Sorry, but I don't see how showing arbitrary images on our website is > going to benefit the project. > > Alexandre I'm new to this Inkscape dev community, but one thing I greatly appreciate about the project (besides it being inherently FLOSS) is that what flows from it being opensource is the user and dev community. Therefore, I see this dynamic user gallery, which is not strictly curated, as a natural outflowing of the philosophy and use of the project itself. I hope that makes sense, and it may not be where everyone else is at, but I think it's a natural bridge to connect the userbase artwork into how we want to represent the software. By not filtering (or curating, or soliciting) the images we run the risk of hosting "arbitrary images," but so far I see it worthwhile, and at the same time strengthening our bond between devs and users. If we had a simple way to showcase excellent artwork examples, and had those assets already available, I would be happy to consider another solution. But feeding the activity of an another active site into ours is the best I've currently seen to solve this. (If any artists are out there listening and want to submit artwork for the website, I would think now is the time and place to do so!) Let me know any other ideas Alexandre! --Jared

6 8

Staging website - graphics sources
by Jared Meidal 26 Sep '13

26 Sep '13

As I've worked piecemeal through small content updates on the staging.inkscape.org website I seen we need new graphic assets, especially for homepage banners, screenshots, and community gallery areas. The gallery on the existing website has operated as a timeline of version development and features. I think the new website gallery could be presented more as an showcase of artwork/design. But where should these images come from so this can be populated? My query in simple form is: from where should we source images for the new staging website? And how should permission-seeking work for using others' art? I've compiled below some areas where I see this could be crowd-sourced. Sources already linked within Inkscape webpages: http://commons.wikimedia.org/wiki/Category:Created_with_Inkscape http://wiki.inkscape.org/wiki/index.php/Galleries http://inkscape.deviantart.com/favourites/ There has been a lot of great examples of vector graphics creation through Inkscape posted socially online. I consider this a great choice in how we could populate our Gallery in our staging website. Here are some examples. https://plus.google.com/u/0/+inkscape/posts https://plus.google.com/u/0/118402182869057763137/posts http://www.inkscapeforum.com/viewforum.php?f=8&sid=3e55a03d23c1acdbf67a9b90… [facebook is a page also, but doesn't seem to attract the same activity of art postings) Most artists seem to be very willing to share their art publicly. But again, what is the best manner (existing method?) of posting these on our websites with appropriate credit/permission? I appreciate any feedback, and then I'm willing to work at bringing our site to life a little more with these graphics. --Jared

4 11

Re: [Inkscape-devel] Units / display scale factor
by Jelle 26 Sep '13

26 Sep '13

Bryce, Is it possible to just set the amount of pixels per unit in Inkscape? The use case is as follows. I have a work flow that uses files created in Inkscape and I want to use 10px per mm. Why? Well,.. that way I can easily use these files in a web site editor where clients can edit the file and give it back to me. At this moment I have to contend with the insane 3.45etc. pixels per mm, bloating my files by a factor 9 or so and conversion errors on their way back into Inkscape that goes all Inches again. Writing a script for that is hell and it makes operations on the browser client a tad slow as it has to contend with constant conversions from 3.45etc. to wanted scale, to back to Inkscape hardcoded 90pdi, back to mm etc. Relations get lost and anyone manually checking the SVG code cracks his head (okay, 12mm border on a A4 page, so the x,y should be where again? 3.45etc. and that times 12, makes..ehm. Okay,.. calc,.. calc,.. now the right side should be exactly..duh). Would be so nice if it was just 120 left and 1980 right. I can dream those numbers and checking that is easy. My code would start making sense and I have no conversion loss. This whole sad nonsense would be over if I could just use a pixel / unit setting in Inkscape that allows me to define exactly how many pixels I want to use in the SVG file for what amount of unit. Wouldn't matter if those would be Inches, Meters, Zorkmits or whatever as long as I can define those lengths somewhere. I would think that for vector graphics, a pixel per unit setting should be fairly straightforward and we can prevent this hapless Inches to mm or whatever conversion swapping, work at much better precision (integers!), probably speed up things a bit with it and lo and behold create a wee bit cleaner files. For people that make icons it would be nice as well I bet to be able to set a 10 px:1 pixel ratio and have nice clean files. For anyone in the metric system, using a pixel per metric unit setting would be an absolute bliss. I could finally read my files and I would think that viewPort settings are intended to do just this. Define the friggin scale it is in. Cheers, Jelle Mulder > > Message: 4 > Date: Wed, 25 Sep 2013 14:54:40 -0700 > From: <ian_bruce@...2136...> > Subject: Re: [Inkscape-devel] Units / display scale factor > To: Bryce Harrington <bryce@...961...> > Cc: inkscape-devel(a)lists.sourceforge.net > Message-ID: <20130925145440.7405c192.ian_bruce@...2136...> > Content-Type: text/plain; charset="us-ascii" > > On Wed, 25 Sep 2013 11:23:07 -0700 > Bryce Harrington <bryce@...961...> wrote: > >> Really, there are (at least) three different ways the unit system >> touches the real world. > > Thanks for this well-thought-out explanation; it clarifies the situation > considerably. > > I think a modified version of my "display scale factor" proposal can > accommodate all the cases you describe; see attached image. > > The improvement is to let the user explicitly specify the three ratios > between screen/drawing/export units (although this obviously involves > only two degrees of freedom). "Export" would mean PDF or similar, if the > image was intended for paper, or PNG/JPG/GIF, if it was intended for > electronic display. > > The "zoom factor" setting would still be present; this would be > multiplied with the "screen units" setting when displaying the document > on a monitor, so that 100% zoom would produce the specified > screen:drawing unit ratio. It would have no effect on the drawing:export > unit ratio. > >> First is the physical measurements of the page. For instance, if >> you're going to fold a 8.5"x11" paper into forths and want a logo to >> appear in the middle of the cover, you're going to care about seeing >> position in document inches. > > In this case, you would set the drawing:export ratio at 1:1 , so that > the measurements would come out right in the PDF or PostScript file. > > The screen:drawing ratio can be set to any value that is convenient for > working on the document, without having any effect on the eventual paper > image. > >> Second is the physical measurement of the monitor. If you're making >> assets for a website or buttons for a cell phone UI, you'll care about >> display pixels, display mm's, etc. and probably don't care about paper >> at all. It's possible you care about the dpi of some product display >> that you don't have access to (so don't just assume the attached >> monitor's dpi is the one the user cares about.) > > Here again, you would set the drawing:export ratio at 1:1 , specified in > either "px" or "mm", depending on how you wanted to measure the image. > > The screen:drawing ratio could also be set at 1:1 , if this provided an > appropriate view of the image, or some larger value, for detailed work > on icons, etc. > >> Third is the physical measurement of the thing the drawing is >> conceiving. If you're drawing a map, then you'll care about km's and >> miles. You may care about how many printed page inches or cm's >> correspond to how many miles or km's. > > In this case you would set the drawing:export ratio at 1km:3cm , or > 5miles:2inches , or something like that. > > If the screen:export ratio is set to 1:1 , the drawing should appear on > the monitor at the same size as it eventually will on a paper map, or > whatever the target output is. > >> Personally, this third use case is the one I care about, but when I >> was doing the original units system it became clear that the SVG spec >> cared mostly about the first one, and somewhat the second, and it >> wasn't at all clear how to handle the third. > > It seems to me that <g transform="scale(x)"> nodes, possibly with > Inkscape-specific attributes, could be used to control the relationship > between document/image/display units, for the SVG tree, but this would > require further thought. > >> Indeed, it seems there is even difficulty in trying to make it handle >> #1 and #2 in a user-intuitive way. At the least, it all made me very >> confused. > > Leaving aside for the moment the question of how to do this in an > SVG-compliant way, does my proposal above (and attached image) make > sense to you? Does it adequately address the situations you've > described, or any others that you can think of? > >> I wonder if perhaps what we should do here is ignore SVG's units and >> consider the three (or more) use cases that users have, and think from >> their POV what would work best. > > I agree with that. Decide first what the Inkscape UI should be like, and > how it should control exported image sizes, and figure out later how to > map that onto standard (or proposed, as <tavmjong@...8...> says) SVG. > >> Establish different unit systems "modes" and let the user toggle which >> units mode to use in the Inkscape UI while drawing. > > Does it really require "modes", or does allowing the user to explicitly > control the screen/drawing/export unit ratios provide all the control > that is actually needed? > > > -- Ian Bruce >

2 1

[Recolor] Status
by Arshdeep Singh 26 Sep '13

26 Sep '13

Hi all, The Recolor Wheel is up and running. You can check the same through my latest commit: http://bazaar.launchpad.net/~moduli16/inkscape/recolor/revision/12392 Bugs left: + Alpha and brightness values to be included in final color updation. Working on this currently. -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

3 2