November 2014 - Inkscape Devel

Units update
by Tavmjong Bah 26 Nov '14

26 Nov '14

Hi, It has been hard to keep track of everything going on with units in the past couple of days. I've got some comments about what has been done and where we should be headed. Please add your comments. 1. 'display_units' I think we all agree that inkscape:document-units is meant to be 'display_units'. Johan's changing of 'doc_units' to 'display_units' should make this much clearer. Thanks Johan! (BTW, I change 'units' to 'page_size_units' last week for similar reasons.) 2. 'svg_units' I am not sure about what this actually means. The comment is: // Units used for the values in SVG Is this the suppose to be the unit identifier used inside the SVG file? The only time that would be useful is if the 'user unit' has a real world value of 1px otherwise unit identifiers don't mean what users would expect them to. Or is this the unit identifier in the root 'width'/'height'. In this case, I think it might be useful to take a step back and look at the a more global picture. The root SVG values of 'width' and 'height' along with the 'viewBox' establishes the scale for the drawing. Typically one has: <svg width="20mm" height="20mm" viewBox="0 0 20 20" ...> where the 'user unit' is equivalent to 1mm. But one could also have a valid file with: <svg width="20mm" height="20mm" viewBox="0 0 40 40" ...> where the 'user unit' is equivalent to 0.5mm. We really should support arbitrary scaling (including non-isotropic). So instead of an 'svg unit' we should have an 'svg scale'. (Our rendering already supports arbitrary scaling so it would be a shame if our GUI didn't too, see the example SVG below.) 3. % values on root 'width' and 'height' I saw something on IRC about % values on the root SVG 'width' and 'height'. This is actually a very common use case for web designers where the SVG is to automatically fill a space. Inkscape treats % values on the 'width' and 'height' by using the values from the 'viewBox' (or if there is no 'viewBox' it assumes all values are in pixels). Here is an example of where 'width' and 'height' are in % and the scaling is non-isotropic. Inkscape renders it just fine: http://tavmjong.free.fr/SVG/TEST_IMAGES/root_percent.svg 4. Precision The SVG spec says that values like length are floats and this is indeed what we use internally in Inkscape. I am wondering if we should change this to double as it would make internal calculations more precise. This might avoid some of the rounding errors when switching units back and forth from say 'mm' to 'pc'. We allow the user to set the numerical precision to up to 16 digits. This makes little sense given that floats are good to only 6 or 7. 5. Converting between 90/96 dpi I think our focus here is to do the minimum possible to convert an SVG file between 90 and 96 dpi. Trying to scale everything inside the file is rarely going to work satisfactory for a file of any complexity. Here are some things we should try (I am brain storming here): a. Add a 'viewBox' If a file has been created to a specific size using only user units, say A4 at 90dpi, using on user-units then one can set the SVG root to be: <svg width="210mm" height="297mm" viewBox="0 0 744.09448819 1052.3622047" ...> b. Absolute sizes are really only important for producing printed matter. We could add a 'dpi' factor. Values must be converted in PDF/PostScript export from 90 or 96dpi to 72dpi. The conversion factor could be user selectable. (Although adding a 'viewBox' as above should take care of this.) c. Grids and guides and ? These currently are defined in external units (no consideration of transforms, viewBox, etc.). Guides should be easy to auto adjust using the SVG scale (as defined above). Grids may be too (but I haven't tried yet). Note: We will need to update grids and guides when we do the coordinate flip so if we do need a more sophisticated solution we can do it at the same time. d. Use internally of 'unit identifiers'. If absolute unit identifiers ('mm', 'in', 'pt', etc.) have been used internally (other than on the root SVG element), then these do need to be scaled to account for a switch between 90dpi and 96dpi. This is not a problem for pre-0.91 Inkscape created files. To keep it from being a problem in 0.91 Inkscape files, we need to disable saving 'font-size' with a 'pt' unit identifier. Tav

4 6

Next Inkscape board meeting
by Tavmjong Bah 26 Nov '14

26 Nov '14

Hi, We'll be having an IRC meeting today (Wednesday, November 26th, 20:00 UTC). The agenda and IRC channel info can be found at: http://wiki.inkscape.org/wiki/index.php/Board_Meetings Everybody is welcome to join the discussion. We'll continue the discussion of the Hackfest we'll be holding before the LGM meeting in Toronto as well as discussing fund raising, testing, etc. You can read more about the Hackfest at: http://wiki.inkscape.org/wiki/index.php/Hackfest2015 Hope to see you there, Tav

1 0

[glocke01@...400...: Fwd: wiki account]
by Bryce Harrington 24 Nov '14

24 Nov '14

Could someone set George up? George - the list is configured to reject email from non-members; we had too much spam being sent to us from spammers. Bryce ----- Forwarded message from George Locke <glocke01@...400...> ----- Date: Mon, 24 Nov 2014 12:48:34 -0500 From: George Locke <glocke01@...400...> To: inkscape-devel-owner(a)lists.sourceforge.net Subject: Fwd: wiki account Perhaps you don't want the riffraff getting wiki accounts, but I'd like to have one. The wiki itself says I should contact the developer's list in order to get an account. I tried to email the list, and was bounced. Now here I am. I'm not an Inkscape developer and don't want to be added to the list, I just want a wiki account so I can add something to a particualr talk page, as described below. Thanks, George Locke ---------- Forwarded message ---------- From: <inkscape-devel-owner(a)lists.sourceforge.net> Date: Mon, Nov 24, 2014 at 12:42 PM Subject: wiki account To: glocke01@...400... You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at inkscape-devel-owner@...460... ---------- Forwarded message ---------- From: George Locke <glocke01@...400...> To: inkscape-devel(a)lists.sourceforge.net Cc: Date: Mon, 24 Nov 2014 12:42:32 -0500 Subject: wiki account Hi, I tried to edit a wiki page and foudn that the only way to create an account was to "email the developer list," so I am doing so. Preferably, my u/n would be "flies". Thanks, George Locke PS the page I wanted to change was http://wiki.inkscape.org/wiki/index.php/PythonEffectTutorial , or more specifically the discussion page, where I was going to indicate that the installation instructions reference a <inkscape>/extensions directory that, on my install, Windows 0.48, is located at <inkscape>/shared/extensions. ----- End forwarded message -----

2 1

Units in LivePathEffects
by Johan Engelen 23 Nov '14

23 Nov '14

Hi Jabier, I just discovered that you added a "default unit" to LivePathEffect::Effect class. Unfortunately, we will have to remove that, or at least make a drastic change there. A LivePathEffect is meant to be a purely mathematical function, that depends as little as possible on the rest of Inkscape. To work with units, one would have to know the full item2document transform times the SVG units used, and use that in the effect calculation. I'm really not sure if we should do this. What the code is doing now is wrong if an item has a transform applied to it. regards, Johan

2 1

inkscape wiki account request
by Guiu Rocafort 23 Nov '14

23 Nov '14

Hello, Can someone create an user for me in the wiki. I want to update some very outdated pages. Specially about the one about multi-page support which has been dropped from svg 2.0. Thanks Guiu

2 1

C++11 for Experimental Branch?
by Tavmjong Bah 22 Nov '14

22 Nov '14

Hi, I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11? I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4). Tav

9 26

Windows: 64bit GTK3 buildfile
by Johan Engelen 22 Nov '14

22 Nov '14

Hi all Windows devs, If you're interested in testing and helping with moving Inkscape towards GTK3: I just committed build-x64-gtk3.xml that you can use to build Inkscape on Windows with GTK3. btool -file build-x64-gtk3.xml This works for me using the latest devlibs. Let us know if you have problems. Your help is very much appreciated. cheers, Johan

3 5

Website Menus
by Martin Owens 22 Nov '14

22 Nov '14

Dear Website Users, Some of you may have experienced the menu explosion bug that the website has come down with. I've put in place a fix for both javascript (so it won't cause an infinite loop) and for the menus themselves which were getting progressively worse as the caches refreshed. Please test and don't hesitate to make a bug[1] if you notice anything wrong. Best Regards, Martin Owens [1] https://bugs.launchpad.net/inkscape-web

3 4

GTK application with high dpi support
by Johan Engelen 21 Nov '14

21 Nov '14

Hi all, Does anybody know a GTK application that supports high-dpi monitors, on Windows or Mac? I'd like to know, so I can see how they got things to work well. Thanks so much, Johan

2 1

0.91 Blockers
by Josh Andler 20 Nov '14

20 Nov '14

This is to follow up on Bryce's earlier Hard Freeze announcement to bring attention to our blockers once more. https://bugs.launchpad.net/inkscape/+bugs?field.milestone%3Alist=21423field… #384688 - Long Standing Bug. Offset on text objects causes rendering/geometry artifacts. Pretty nasty and very easy to run into... I know I personally have a handful of files affected by it. Would really be nice to get fixed, but if it were the last blocker it should be re-milestoned. #953992 - Regression. Imported pattern disappears on transform. This is a renderer regression which is why it's marked as a blocker. It is still an issue in 0.91.x but is no longer affecting trunk. Is anybody interested looking into backporting this? If not, we're fine to bump the milestone forward since 0.92 will have it resolved. #1245989 - Regression. Canvas ends up 1x1px on certain documents. This is a weird issue and also affects XAML import (1235809). However, Inkscape can't directly produce files with this issue w/o the XML Editor being used. Apparently we used to create an A4 canvas in these situations, now it's 1x1 px (happened with templates due to the units refactoring). Logically, doing it to drawing size would be the best "fix" (I agree with comment #5 in 1235809). #1387864 - Regression. THE BIG BLOCKER is the one on document units. Tavmjong posted to the list about this with the subject of "Hard Freeze for 0.91: Inkscape Units". At this point there appears to be two obvious paths forward, 1) Possibly reverting back to the old superficial behavior when switching "Default units" (Tav's question at the end of his message pertained to this), or 2) hide/remove the "Default units widget" for 0.91 and potentially make Inkscape unusable to a sizable portion of our userbase. Obviously 1 is ideal, but we're left with the question of how feasible it is to get back that functionality in a way we're reasonably confident won't break 0.91 so close to release. Cheers, Josh

1 0