April 2015 - Inkscape Devel - Inkscape Mailman

Save and User Manual
by Roger Sharp 17 Apr '15

17 Apr '15

As a Tech Writer, UX tester, and newbie Inkscape user: Regarding Bit Barrel’s comments, I agree about not having both ‘Save As’ and ‘Export.’ Confusing. Photoshop uses Export for saving pieces of the art such as paths. Also, the User Manual (or Guide?) looks very good BUT it is not searchable. It would be easy to take the current pages (.html or .xml) and import/convert them into a navigable, searchable compiled Help file (whether Web Help or compile .chm file). And, even though I’ve set preferences to Remember Last Window Geometry, it doesn’t remember the dialog layout, i.e., Layers Dialog, the Undo Dialog, etc. ( Version 0.48). Sharpart

11 25

Oh dear, the import export discussion ;-)
by Jelle Mulder 17 Apr '15

17 Apr '15

Hi all, I think Gez posted the most compelling reason to get rid of pdf and the like in the save as dialog. Inkscape will happily destroy the multipage document with prepress ready infromation with its own export file. If all you do with it is edit an image that doesn't need to go to print that's fine, but I guess those that are accustomed to using Adobe software with its extended pdf files that enable editing it with retaining all the extra stuff Adobe puts into to it to enable a prepress work flow in their own format will have been swearing at the current method. I saw multipage support on the todo list. Would be a nice start for better pdf support. CMYK is another one of the desires related to that. But even then I would really suggest making SAVE only save to Inkscape native and get the rest where it belongs in the export formats with their limited support. I haven't worked in print for quite some time now, but used to dabble around with postscript fill rasters quite a lot to get different effects on similar ink percentages. When using 2 colour print and a varnish, you could create really nice effects with that. None of such information would be maintained in an Inkscape PS export either. They are lossy export filters. Hence they should be in the export menu. The work flow in Inkscape is not ideal when you destroy half the info with a program that seems to claim to save all those file types as if it where native. Whether you put opening a file in the import or open dialog doesn't matter all that much as long as it is clear that the output file is an export or information gets lost by saving it as InkSVG. While following the discussion on SVG2 it became clear that the focus there is web content and for that Inkscape pretty much does everything you'd desire. However, as it turns out Inkscape is a really good and useful vector editor that has found its way into the prepress world and others despite its shortcomings in those fields, I would really like to see a work flow philosophy that reflects those shortcomings for the casual and first time users to prevent them from totally screwing up their work. Otherwise they will be disappointed. I guess that is what drove the Gimp to separate it as well. No Johan,.. it's not okay. Its like boiled and poached eggs. Similar results but different using the same tools and ingredients. But the end result differs through the method. Jelle

4 4

Hackfest 2015 - Topics
by Tavmjong Bah 15 Apr '15

15 Apr '15

Hi, So far we have eight people signed up for the Toronto hackfest. We still have room for more! Our fund raising campaign is doing well. Sponsorship is available for active developers and other Inkscape community members, see: http://wiki.inkscape.org/wiki/index.php/Hackfest2015_Attendees I've prepared a "Topics" wiki page to keep track of things that we should discuss and/or work on at the hackfest. Please add your ideas... even if you are not able to attend. The topics page is at: http://wiki.inkscape.org/wiki/index.php/Hackfest2015_Topics Tav

8 15

Using Inkscape for D3.js managed scene (Was: Donating through Gratipay)
by anatoly techtonik 14 Apr '15

14 Apr '15

On Sun, Apr 12, 2015 at 2:45 AM, Brynn <brynn@...3133...> wrote: > > [Off Topic - I'll be interested to look up D3.js, to perhaps add it to the > new page I'm making for the Inkscape website, about animation and Inkscape > (first draft and still under development: > http://staging.inkscape.org/en/learn/animation-and-inkscape). :-) ] > For the page from the website of graphics tool it looks overburdened with text. =) As for D3.js I am going to try this tutorial. Looks real from here. http://christopheviau.com/d3_tutorial/d3_inkscape/ -- anatoly t.

2 2

donations, Flattr ?
by Brynn 08 Apr '15

08 Apr '15

Hi Friends, A recent message from a happy Inkscape user on IF (http://www.inkscapeforum.com/viewtopic.php?f=30&t=18639) wonders if Inkscape should have a Flattr account? Although this is the first I've heard of Flattr, and I'm not sure if Inkscape's license, mission, etc. will permit; I'm curious myself. I thought it would be worth asking about :-) Should or could Inkscape use this kind of fundraising? (Flattr: https://flattr.com/) Thanks, brynn

5 9

Making Inkscape faster by avoiding excessive updates
by Krzysztof Kosiński 07 Apr '15

07 Apr '15

Hello List Whenever something is changed in the document, Inkscape does the following: 1. Store the change in the DOM tree (aka SP tree). 2. Write the change to the XML, also storing undo data. 3. In response to this XML change, update / recompute the values in the DOM tree. This means that when a path is changed in the node editor, the following happens: 1. Geom::PathVector is constructed from the UI nodes. 2. A path string is constructed. 3. Path string is written to XML. 4. XML observer catches the XML write event. 5. Path string which was just written is parsed, and Geom::PathVector is created. I guess you can see where this is inefficient. Note however that due to the fact we support "output precision" (i.e. by default the values written into the file have at most 8 digits after the decimal point, so we lose any precision above that), the PathVector created in step 5 is different than the vector created in step 1. One way to improve Inkscape's performance is to avoid the readback step after every change. In many cases, it leads to large portions of the DOM tree being unnecessarily recomputed. However, not doing readback is rather dangerous - if what we write does not actually parse back to what we have, we end up with data corruption - we are displaying a document that does not match the one that we would display when reopening the file. Therefore, the way to go would be to have the development version always do readback, while the release version would just assume it wrote the correct data. In the case of paths and other coordinate values, I think we should always store them with full double precision, taking advantage of the double-conversion library (I incorporated it into in 2Geom), and only allow reducing the precision in a separate output filter. What do you think? Best regards, Krzysztof

2 2

[Fwd: Website Feedback]
by Martin Owens 05 Apr '15

05 Apr '15

3 4

Roadmap planning to 1.0
by Bryce Harrington 03 Apr '15

03 Apr '15

Several months ago we brainstormed ideas for the roadmap. Everything people suggested should now be collected here, categorized but not prioritized or ordered: http://wiki.inkscape.org/wiki/index.php/Roadmap One thing we seem to be in consensus about is to get releases out more swiftly. To do this, I think what we should do is a) minimize the number of objectives for each release, and b) stagger the types of objectives in each release, so we rotate what team is in the spotlight each release. With that in mind, what do you guys think about organizing our next few releases with the following focii? Inkscape 0.92 ~ Infrastructure Focus Inkscape 0.93 ~ Maintenance Focus Inkscape 0.94 ~ Feature Focus Inkscape 0.95 ~ Stability Focus Inkscape 1.0 ~ Documentation Focus I anticipate we'd pick a couple objectives for each release that are appropriate to the focus area, plus a smaller, secondary objective unrelated to the focus. For 0.92, I'm thinking we've enough in the hopper that we should expedite it. What do you guys think? Bryce

7 8