- Inkscape Devel - Inkscape Mailman

Website Mirror System (Video)
by Martin Owens 02 Dec '14

02 Dec '14

Dear Inkscape Develpers, Submitted for your review is the Inkscape Website mirror system. https://inkscape.org/en/gallery/item/2600/ I'm interested in hearing from potential hosts and what they want to see in terms of credit as well as the more technical aspects of the system. Martin,

3 2

remove of DPISWITCH extension from tunk
by Jabiertxo Arraiza Cenoz 30 Nov '14

30 Nov '14

Hello i want to remove the DPISWITCH extension from trunk. Why? I find displacements problems in clip-mask, -inverse displacement-. So because we are thinking to handle the DPI on export/print... If DPI is customizable on export, maybe is a good point to allow by default 96 but a free input box. Regards.

2 2

Visual Align interaction proposal
by Fernando Cuenca Margalef 30 Nov '14

30 Nov '14

Hi folks, I've seen the nice visual alignment development, I will love it! But I find the interactionvery overloaded of buttons in the video. And I think it becames so complex and not coherent with the old functions. I send you attached an alternative proposal to implement such nice feature in next Inkscape version. Considering the simplest way and more coherent with Inkscape. Thanks to all for the great work with this amazing piece of software, Fernando

2 1

Fwd: Re: Roadmap brainstorming for 0.92 and forward
by Liam White 29 Nov '14

29 Nov '14

---------- Forwarded message ---------- From: "Liam White" <inkscapebrony@...400...> Date: Nov 29, 2014 2:18 PM Subject: Re: [Inkscape-devel] Roadmap brainstorming for 0.92 and forward To: "Alexander Brock" <a.brock@...2965...> Cc: > What's the difference between an SPObject and an SPItem? Which svg > elements translate into an SPItem, which into an SPObject? > > Alexander SPItems are generally visible objects. SPObjects that are not SPItems are the rest of the objects and are not renderable.

2 1

Volunteers needed: 0.91 Release Marketing
by Bryce Harrington 29 Nov '14

29 Nov '14

Hi all, As the developers put the final touches on the 0.91 release, it's high time to plan a media blitz to get this announced to all our users. I'd like to recruit and organize a formal team to do marketing for Inkscape. This'll involve writing copy, planning announce strategies, notifying news sites, coordinating with parallel fundraising efforts, and more. We'll be organizing an online IRC meeting soon to coordinate these activities. Sound like fun? Ryan Lerch, Josh Andler, and myself are already signed on; we've been through the release announcement process before so we're old hands. But we're looking for new ideas and fresh blood, so that we can go beyond what we've achieved in the past. Interested? Reply to this email and introduce yourself! Bryce P.S. Inkscape's past marketing teams have left us a wealth of notes we can use to build from. Two items in particular: http://wiki.inkscape.org/wiki/index.php/Announcing_Releases http://wiki.inkscape.org/wiki/index.php/Inkscape_coverage

5 9

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