- Inkscape Devel - Inkscape Mailman

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

[Recolor] Addition\Removal of nodes handled
by Arshdeep Singh 25 Sep '13

25 Sep '13

Hi all, I just pushed the changes that successfully handle the addition and removal of nodes. --- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

1 0

Re: [Inkscape-devel] Release and Website
by Bryce Harrington 24 Sep '13

24 Sep '13

On Tue, Sep 10, 2013 at 11:08:34AM +0200, Tavmjong Bah wrote: > > On Mon, Sep 9, 2013 at 4:32 PM, Martin Owens <doctormo@...400...> wrote: > > > On Mon, 2013-09-09 at 15:46 -0700, Josh Andler wrote: > > >> In addition too that, we will need to bring a copy of cairo and pixman > > >> in-tree for a while to ensure the new renderer will work everywhere. > > I don't really like the idea of bringing cairo and pixman into the tree. > For Windows and Mac, aren't they already included somehow? For Linux, by > the time of release, the distros should already be up-to-date with the > latest Cairo assuming that 1.14 is released in mid-October as planned > (see cairo mailing list 5 Sept). Is it only the downscaling bug that necessitates bringing these in-tree? Or are there other bugs needing new cairo/pixman features? Also, anyone happen to have a good demonstration of the problem they should show me? I'd like to improve the test case I wrote for this, and would help to see some real-world examples of where people have run into the bug. > > > So bug #804162 is solvable by bringing cairo and pixman into tree. That > > > brings us down to 10 bugs. > > > > > > Probably best to put us into a freeze, to deal with these bugs (and > > > probably some others). Is there a reason to not plan for this kind of > > > release process after GSoC has ended? > > Definitely need to wait for GSoC to end... and the a little bit longer. What percentage of the bugs have owners so far? This early in the release, a focus on just getting owners for the unowned ones might be the most productive thing to do... Bryce

2 2

Refactoring low level calculations on shapes
by Markus Engel 24 Sep '13

24 Sep '13

Hi, when working through the code I found lots of ugly-looking sections, especially things that have got to do with geometry. Here, I just tried rewriting the code that calculates the shape of an SPEllipse: http://bazaar.launchpad.net/~engelmarkus/inkscape/cppify/revision/11735 Is this the right way to go? Using 2geom wherever you can? Regards, Markus

2 1

Inkscape in Git
by Martin Owens 24 Sep '13

24 Sep '13

I've written a guide to how our developers can use git while developing inkscape: http://staging.inkscape.org/en/develop/using-git-repositories/ I've modified the required regular documentation to link these pages in too, we should have no problems allowing people to use git. The hosting provider we use for inkscape's code is launchpad. I like launchpad and I also think it would be way too much work to move inkscape to a less-useful project host like github or savanna just for git based remotes. Hopefully this kind of compromise on the client side can allow developers to not feel put out about our choice in repository technology.

6 7

Website: Debugging Page
by Martin Owens 24 Sep '13

24 Sep '13

Hey Devs, I'm calling on those who know to help write out new debugging page here: http://staging.inkscape.org/en/develop/debugging/ It needs to contain the information on the wiki here: http://wiki.inkscape.org/wiki/index.php/Debugging_Inkscape As well as information about logging (enabling, different log options), using gdb and links to where to get gdb help or a gui for gdb. Anything extra such as compile flags to improve logging and using cout or g_warning or g_info statements in code and when it's good to use them. I'd also like something about how to use the multiple packages we have in the trunk ppa system to narrow down a problem. I think SUV has this magic already, allowing other bug hunters and devels to know how to set that up would be very useful. Best Regards, Martin Owens

3 3

Launchpad Administrator changes for Inkscape
by Bryce Harrington 24 Sep '13

24 Sep '13

The Launchpad administration team for Inkscape handles commit access requests, and various other duties on the launchpad website. We keep the team limited to six people, which means adding a new admin requires swapping with one of the others. Ted Gould has decided to step back from the team, and allow Krzysztof to take on adminship. Welcome Krzysztof, and many thanks Ted for your service! Bryce P.S. a few other admins are due to renew membership in October; if they choose not to renew, then we may need to ask for volunteers to fill those slots. I will follow up later if this is the case.

4 3

SPGenericEllipse "d" attribute
by Tomasz Boczkowski 23 Sep '13

23 Sep '13

Hi all, While fixing bug #1227193 i have encoutered strange behaviour of SPGenericEllipse. When a new ellipse is drawn, the "d" attribute in corresponding svg:path element is set by SPGenericEllipse::write and contains arcs. However in SPGenericEllipse::update_patheffect, triggered by document idle handler, "d" attribute is regenerated from SPCurve and has other value. Instead of two arcs there are four curve elements. I would like to address this issue. Since those are my first steps in inkscape development, I have some quesions. 1) Should I add arcto method to SPCurve and make both SPGeneralEllipse methods generate the same "d" attribute value? 2) Why there are two different methods that generate "d" attribute value? Should one of them (sp_arc_set_elliptical_path_attribute or sp_svg_write_path call in update_patheffect) be removed? 3) Should static function sp_arc_set_elliptical_path_attribute be c++-fied to private member method? Regards, Tomasz Boczkowski

2 1

Last Report
by Jan Darowski 23 Sep '13

23 Sep '13

Hi guys! On saturday i commited merge of last big part of my GSoC project. It included a lot of fixes, procedural templates support and example of a procedural template (Empty Page). Right now, I'm working on updating wiki pages related to my project. Of course, if anyone of you has any suggestions for fixes or cleanups related to things I've been working on, I'll be glad to include them after the GSoC. Thanks for this cool experience, I hope to have time to still contribute to this project after summer is over. Slagvi, Jan Darowski

1 0