- Inkscape Devel - Inkscape Mailman

Download method, roadmap brainstorm, percentage in SVG root and objects, units
by Jelle Mulder 28 Nov '14

28 Nov '14

Hello people, On behalf of your Chinese users I'd like to ask to make sure there are multiple channels to download the new Inkscape versions as bittorrents are blocked by at least two ISP's here. Anything remotely social gets blocked in this socialism the Chinese way state. I agree that the new release will get quite some attention as it has been ages since the last major release and Inkscape is well known as one of the FOSS must haves. In case of 0.91 it will also gets known very fast there are important perks such as the greater speed of operation and a plethora of other improvements and new tools. So we can expect a lot of downloads in the first two months and then a gradual decrease in intensity. I do however expect an increase overall as 0.91 is greatly more productive tool than 0.48 and Inkscape has become more useful as a serious replacement for other tools. For the roadmap I would like to ask how feasible it would be to add javascript and SMIL to the renderer? There was a javascript plugin for 0.48 that I never managed to get to work. The instructions were in Portugese, but the idea of being able to use javascript sure was a good one. Add SMIL to it and you're all set for development of animation tools. On the GUI side, I would like to ask how possible it would be to have the GUI be constructed with SVG objects. That would allow enthusiasts to radically revamp the GUI and make specialised versions with limited tool sets for special tasks (think of Inkscape for kids) or change the GUI depending on tasks at hand (animation GUI, cutter GUI, etc.). If the Inkscape renderer would support javascript and SMIL it would open a whole world of web designers to use their skills to create slick GUI's that scale to whatever resolution in the future. I personally use percentages in both SVG root and for objects. Currently it means using Notepad++ to create groups to position things percentage wise and changing sizes. The use case here is having a layout adopt to whatever resolution of the user and display objects you want with scaling backgrounds and positioning absolutely sized objects in the center of the page. It would be great if Inkscape would support that natively and the hassle of hand editing SVG code wouldn't be a necessity anymore. I'm also quite exited by the idea that I won't have to contend with the dumb 90dpi or 96dpi setting, but can use whatever setting is my fancy. Having to work with 3.45xxx pixels per MM is really horrible. Setting that to 10 and just use a viewport would make my life a lot easier. Considering the new resolutions of screens for mobiles that go up 551 ppi these days, having 90 or 96 dpi defaults with lots of decimals to position something doesn't make much sense to me anyway. Having a higher dpi setting would allow for working with whole numbers in files and might also increase speed of rendering due to that I would imagine. Also nice for those working with print btw. My two cents, Jelle

1 0

clarification for new user faq re faking italics
by Brynn 28 Nov '14

28 Nov '14

Hi Friends, We just need a couple of final clarifications for the new user faq. And fyi, I think we've decided to wait until after 0.91 comes out, to publish it on the live site. This is one, and the other will be in a separate message. The old item "Bolding has no effect on some fonts" says: Some fonts are available with in an unique, "normal" variant (i.e. no italics or bold). Nonetheless, Inkscape currently displays four styles available for them: Normal, Italics, Bold, Bold Italics. Italics is correctly faked by inclining the font but bolding cannot be faked at this point. Since the font itself does not have a Bold variant, the result would likely be of poor quality anyway. You should rather consider using a font with a real Bold variant. When I re-wrote it, I wrote that italics can only be "faked" not "correctly faked" because in my experience, I have not been able to correctly fake an italicized font by skewing (which I assume is meant by "inclining"). (To me, italicized text doesn't just lean over, but sort of curves over.) Can anyone speak to whether skewing is a correct italics or not? Thank you very much!

4 3

final clarifications for new user faq re SVG renderers
by Brynn 28 Nov '14

28 Nov '14

Hi Friends, And there's a 3rd item to clarify, if someone has a chance. and please note that these can all wait until after 0.91 is released! The faq item "Inkscape and renderer X show my SVGs differently. What to do?" mentions the Adobe SVG Plugin, which of course has been discontinued a few years ago. The text is below. Can "Adobe SVG plugin" just be deleted? If so, does the rest of the item need to be rewritten? I do see this question from time to time, in forums, so it's worth keeping the faq item. Just want to have a correct answer :-) "That depends on X. We accept Batik and Adobe SVG plugin as authoritative SVG renderers because they are backed by some of the the authors of the SVG standard and really care about compliance. This may not be true for other renderers. So if you are having a problem with some renderer, please try the same file with either Batik or Adobe, or better yet, with both (they are free and cross-platform). If you still see a discrepancy with Inkscape rendering, we want to look into it. Please submit a bug; don't forget to attach a sample of the problem file to the bug report, and ideally include screenshots too" Thank you very much!

2 1

clarification for new user faq re flowed text
by Brynn 28 Nov '14

28 Nov '14

Hi Friends, Oh crap -- I just let that last message go without switching it to plain text. REALLY SORRY!! This is the 2nd clarification we need for the new user FAQ. The old item re flowed text is shown below. It's the part about the SVG specification that we think has probably changed. And we don't know exactly what should be said. I think Maren suggested Tav might be able to address this. Thank you very much! "When flowed text support was added to Inkscape, it was conformant to the then-current unfinished draft of SVG 1.2 specification (and was always described as an experimental feature). Unfortunately, in further SVG 1.2 drafts, the W3C decided to change the way this feature is specified. Currently SVG 1.2 is still not finished, and as a result, very few SVG renderers currently implement either the old or the new syntax of SVG 1.2 flowed text. So, technically, Inkscape SVG files that use flowed text are not valid SVG 1.1, and usually cause problems (errors or just black boxes with no text). However, due to the utility of this much-requested feature, we decided to leave it available to users. When the final SVG 1.2 specification is published, we will change our flowed text implementation to be fully conformant to it, and will provide a way to migrate the older flowed text objects to the new format. Until that is done, however, you should not use flowed text in documents that you intend to use outside of Inkscape. Flowed text is created by clicking and dragging in the Text tool, while simple click creates plain SVG 1.1 text; so, if you don't really need the flowing aspect, just use click to position text cursor instead of dragging to create a frame. If however you really need flowed text, you will have to convert it to regular (non-flowed) text by the "Convert to text" command in the Text menu. This command fully preserves the appearance and formatting of your flowed text but makes it non-flowed and SVG 1.1-compliant. "

2 1

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