- Inkscape Devel - Inkscape Mailman

GSOC spatial indexing - renderer
by Vangelis Katsikaros 29 Mar '10

29 Mar '10

Hello I have briefly described in the past my thoughts on how the render can be improved by introducing spatial indexes. The render has to find which shapes intersect with the user's viewport. Currently this is done by a full scan in display/sp-canvas.cpp:871 in sp_canvas_group_render() right? (Krzysztof gave some hints in another thread some days ago). The idea is to implement an index, so that the renderer performs the range query faster than the full scan. Some basic ideas on the project. * The index is going to be a standard one like R-star (used in oracle, postgis, sqlite). * This R-trees can support 3 dimensions without any performance penalty (if the index has many dimensions performance deteriorates and other kind of indexes perform better). If we do this project we can implement a third dimension (time), for future usage, and leave it there until Inkscape goes into animation. * It would be better if the project is hosted in lib2geom. In this way Inkscape's code base undergoes the minimal changes (ideally no more than a few lines of code). * The index should be disk based (so that it can be saved and reused when Inkscape opens the same file again) * There should be a way to identify the shapes of the SVG uniquely (either XML elements or elements from another abstraction Inkscape uses). Can anyone give me some pointers on how I should work for this issue? Any ideas are welcome. Regards Vangelis __________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://mail.yahoo.gr

2 2

Frost is upon us
by Joshua A. Andler 29 Mar '10

29 Mar '10

Hey all, I propose moving to Frost on Tuesday if nobody opposes. To be clear, the main delay in moving forward was an improper usage of Poppler and it blocking us from having "make check" being run. Thank you to Krzysztof for addressing our poppler issue, and Ted for pushing forward with the "check" issues (both make and dist). Given that the main hurdle has been jumped over, I'm comfortable saying that we should push forward to Frost now. We are NOT at Feature Freeze and we don't need to uber-restrict commits yet... but we need to tone down the "radical" nature of commits. Frost will have us achieve: Most development complete. Release Notes should be >90% filled in. Bug Hunt: 300 points Post inkscape-0.48-alpha.tar.gz The following outstanding issues are being actively worked on: *Krzysztof's Node Tool rewrite bugs and issues. *Jon's wicked custom Swatch issues. *Tavmjong's LinuxFund text tool work. The following outstanding issues HAVE to be addressed to not be cut: *Jon's swatches MUST be initially editable in the F&S dialog. *Jon's new Input Devices dialog needs whatever polish to be good enough. *Jon's "UX" work (specifically UI placement should be looked at). *Tavmjong's LinuxFund text tool work (yes it hasn't been committed, but we can only accept so much depending on when code lands). *Felipe Sanches' color management work. The "not real" (device) cmyk thing MUST be addressed prior to release. I'm not saying to remove, but perhaps disable, it is a part of the SVG spec, but it's not how the CMYK workflow actually works. Notes: Tavmjong's work can thankfully be pulled in partially... if we have new and working widgets for the text tool, we should take them when available rather than wait. Jon has put an extraordinary amount of effort into refactoring stuff for the swatches. 0.48 is a multi-point release in that we're anticipating 0.49 dev to be lengthy... if there are bugs (which are committed to be worked on), I'm not against a release with them. No offense, but, we're just like every software vendor out there in this case saying that we know there are issues and are committed to fix them... but feeding our audience takes priority. If you have any issues, comments, or something to address... please speak up! Cheers, Josh

3 3

Feature Suggestion: Automatic layer size adjustment
by Michael Grosberg 29 Mar '10

29 Mar '10

I think it would be nice if some GSOC student were to work on such a feature: Currently you can't draw outside a layer's boundary, and you have to tell GIMP to adjust the boundary yourself. I think an option can be added that, when set to "on", lets GIMP handle that in such a way: 1. any time a layer is moved, GIMP will after the operation set the layer boundary to include the entire canvas. 2. On save, GIMP will autocrop all layers. what do you think?

2 2

Axonometric grid scaling bug
by Radek 28 Mar '10

28 Mar '10

Hello all, some time ago I've encoutered a bug in inkscape resulting in incorrect updating of axonometric grids. I have fixed it myself, then I've filed a bug report with a patch included: https://bugs.launchpad.net/inkscape/+bug/429776 Apparently it hasn't been noticed by any of developers, so I decided to try here. I think that this bug is quite severe for the axonometric grid functionality (conditions in which it appears to be working properly are actually a corner case), it makes the feature hardly usable. I hope that someone will take a look at the bug report and commit the fix. The bug has been reported against 0.46, but I can provide a patch ported to 0.47 if it helps. Radek

1 0

GSoC 2010 Cairo canvas
by Krzysztof Kosiński 28 Mar '10

28 Mar '10

Hello all I will limit myself to two possibilities of a GSoC project for this year: Cairo rendering and SP layer improvements. I think they have the biggest potential impact. This mail discusses the first one. In order to use Cairo rendering in Inkscape, we need a Cairo-based canvas widget to replace the current SPCanvas / NRArena. They appear to be originally derived from GnomeCanvas. Canvas widgets are a rather common beast in the FOSS world, so even if we decide none of the existing ones are satisfactory for us, we have a large body of work from which we can derive inspiration. This page has links to several existing canvas implementations. I have not analyzed all of them yet, but will keep you informed about any important http://live.gnome.org/ProjectRidley/CanvasOverview Here are some requirements for our canvas. 0. Based on Cairo. 1. Model/view split: objects displayed on the canvas can exist without it. 2. Widgetless rendering: it should be possible to render completely in memory, for example for console-mode PDF export. 3. No excessive ties to Inkscape - implemented as a library, perhaps using a few well-defined portions of the existing codebase (e.g. 2geom). 4. Canvas primitives should be sufficient to render SVG. There are many things to discuss, but here's the first one: Tiling reduces the area of the screen that needs to be redrawn, but increases the number of drawing operations. We could instead have a tile-less system that would compute the affected bounding box and redraw it in one go, instead of redrawing many tiles. What do you think? Regards, Krzysztof

6 13

Node tool & hash maps
by Joshua A. Andler 26 Mar '10

26 Mar '10

I just ran across the following and figured I would pass the link on since it is a comparison of various hash map implementations and their performance. http://incise.org/hash-table-benchmarks.html Are we using unordered w/ integers? If so, we may want to explore other options. Oh, and someone in the notes also pointed out: https://edge.launchpad.net/libmct Cheers, Josh

2 2

GSoC (Student Idea) - Graphical Script Extension Editor
by Andrew Simmons 26 Mar '10

26 Mar '10

Hello, I would like to make it easier for Inkscape users to create their own script extensions, especially effects (ie. scripts that operate on the current image). *Ideally* this would involve creating some kind of visual programming language to allow users to drag-and-drop high-level SVG editing commands with intuitive icons into a editor field to create their program - without having to write a single line of code. *Practically* there is no way I could code something so complex in the time-span. Thus I think I should focus on automating as much of the ScriptingHOWTO section as possible. This would (possibly) include: - A graphic tool to generate INX files? - Creating some useful python functions (eg. "addStar()") to allow users to create their script quickly? - An interactive function navigator? Would this be a viable summer of code project? I haven't used GTK+ before nor created an Inkscape extension (yet) Thanks, Andrew Simmons

3 2

GSoC - transformation anchors - before apply
by Zhenfeng Zhao 26 Mar '10

26 Mar '10

Hello, I am interested in working on the "transformation-anchors" project in GSOC this year. I am a graduate student in Computer Science in Canada. I knew Inkscape would win GSOC projects this year, as usual. :-) Congrats. I hope it is not too late to say Hi here. Inkscape is one of my favorite open source software. I also have strong interests and work experiences in image processing, image editors. I have developed a vector-based graphics editor from scratch before. That graphics editor uses customized XML formats, have OOP architecture design to deal with all shapes/primitives with object classes, and allow SVG and DXF (Solidworks drawing file) import and export. Therefore, it seems Inkscape GSoC projects are most interesting and relevant to me. The project, transformation-anchors, seems interesting and doable to me. Wiki docs are very helpful. It is impressive that GUI mock-up has already been posted several months before the Gsoc actually starts. I will read and plan in further detail. I have similar work before, to have the default rotation center to be the geometric center of all shapes. Anchor coordinates are a part of the object (drawing) attributes. It can be adjusted, so that geometrical transformations, rotation, translation, scaling, and shearing, can be performed with the updated center. In this project, there will be some GUI modification, e.g. enable and disable buttons, display coordinates and values, take XY input from users, and allow undo and redo. Maybe some nice intuitive and simple designs will help on these. There may be some refactoring to do, but I am not sure. In this stage, I hope to understand more for this project. Please kindly share comments. I will draft a full proposal in about 10 days. Technically, this project seems doable to me. Besides that I am good in C++, which may be a basic requirement, I have done some work using the following. XML: I have used it for many projects, using C++, Python, C# and Java. Libraries used: .NET, DOM, JDOM, Minidom. SVG: I have written a SVG viewer before. GTK+: I have experience with it. It is the most complex GUI widgets that I have used. SVN: I used it at work before. Regards, Zhenfeng. On Wed, Mar 24, 2010 at 12:12 AM, < inkscape-devel-request(a)lists.sourceforge.net> wrote: > Send Inkscape-devel mailing list submissions to > inkscape-devel(a)lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > or, via email, send a message with subject or body 'help' to > inkscape-devel-request(a)lists.sourceforge.net > > You can reach the person managing the list at > inkscape-devel-owner(a)lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Inkscape-devel digest..." > > > Today's Topics: > > 1. Re: bzr question (Marcin Floryan) > 2. Re: bzr question (Ted Gould) > 3. Re: Inkscape-Aqua for Snow Leopard (~suv) > 4. Re: Inkscape-Aqua for Snow Leopard (Stuart Edwards) > 5. Re: Inkscape-Aqua for Snow Leopard (Stuart Edwards) > 6. Re: GSoC 2010 Cairo canvas (Krzysztof Kosi?ski) > 7. Re: GSoC 2010 Cairo canvas (Krzysztof Kosi?ski) > 8. Re: Hello everybody & GSoC Open Asset Import Library (Carl Worth) > > >

5 9

What about to use translations.launchpad.net? May be useful...
by Aurélio A. Heckert 26 Mar '10

26 Mar '10

Hi all, What you think about to use the web based launchpad's l10n system? https://translations.launchpad.net/inkscape I think that will be really more ease to get collaboration from our users. Gwibber is using this system. Cool? Aurium -- Aurélio A. Heckert http://colivre.coop.br/Aurium GNU/Linux User #312507 http://counter.li.org - - - - - - - - - - - - - - - - - - - - - - - - - Ilustração Vetorial Livre: http://InkscapeBrasil.org Coop. de Tecnologias Livres: http://Colivre.coop.br - - - - - - - - - - - - - - - - - - - - - - - - - "Windows 7: a new era of restrictions." http://windows7sins.org Antes de imprimir esta mensagem reflita sobre a sua responsabilidade com a preservação do Meio Ambiente.

5 4

KML import status
by Will Holcomb 25 Mar '10

25 Mar '10

I was looking through the GSoC possiblities and I'm particularly interested in the KML import project: https://blueprints.launchpad.net/inkscape/+spec/kml-svg-translation I see reference to a project proposal being developed, however the link is now dead: http://socghop.appspot.com/student_proposal/show/google/gsoc2009/piotrekk/t… Given that project is still open, I assume that the proposal didn't go forward for some reason. I was wondering if anyone had further information as to why. I've been thinking quite a bit about the hyperlocal movement and I've been trying to come up with a reasonable way for users to add more complex structures to maps than what is available in browser-based drawing programs. It seems like this is a strong possibility, is there still interest in developing this feature? -Will

2 1