- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 26 Mar '12

26 Mar '12

Alright, I haven't made a full diagram of guide transformations using handles, but looking at the different tiling types, I am now convinced at least that it is at least possible. So, with that in mind, I bring you YATTIP (Yet Another Tiling Tool Interface Proposal): http://postimage.org/image/nhwdn9x29/ http://postimage.org/image/m1lvj06sn/ By popular (?) demand, this is now a tool again! (with a possible extra dialogue for extra options). The "handles" approach actually resolves a number of things. In fact, when choosing a guide, you now simple start with the following defaults: - P1 for wallpaper - Simple-rotation and scaling for radial tiling - Simple translation for line tiling (but all Frieze types are available) Double-clicking a "tile" changes the toolbar into the tile edit mode. Using either the handle or a drop-down in the toolbar, you can then change the tiling type. Since for wallpapers, most people will be using P1 anyway, this approach should be satisfactory. Other features I had proposed are still there: - Guide points and other guide types - Excluding parts of a tile's exterior and fusing all the tiles - Tile stacking should be still possible from a dialogue Any major comments before I completely redo the wiki content again?

2 1

Some clipboard functions
by Romain de Bossoreille 24 Mar '12

24 Mar '12

Hi, A 200% code question, thanks to the one (or two, or three... !) who will give me an answer! I'm looking very closely to the clipboard implementation to follow understanding its behaviour (cf. http://wiki.inkscape.org/wiki/index.php/Clipboard), an amazing work have been done but I've a question (in src/ui/clipboard.cpp): Inkscape::XML::Node *ClipboardManagerImpl::_copyNode(Inkscape::XML::Node *node, Inkscape::XML::Document *target_doc, Inkscape::XML::Node *parent) void ClipboardManagerImpl::_pasteDocument(SPDesktop *desktop, SPDocument *clipdoc, bool in_place) void ClipboardManagerImpl::_pasteDefs(SPDesktop *desktop, SPDocument *clipdoc) SPCSSAttr *ClipboardManagerImpl::_parseColor(const Glib::ustring &text) On my understanding, those functions should not be implemented in the Clipboard class because 1) they are not using any functions dedicated to the Clipboard and so 2) they are codes that could be needed for other puposes than clipboard (and I wonder whether some are duplicated elsewhere in the project). If my opinion/understanding is confirmed, implementing them in a more global namespace should be a better way to avoid dupplicated functions (now or in the future) and provide better code hierarchy ('util' functions?). Or at least setting them as static to show they are not dedicated only to the clipboard management. Does any "Inkscape developper expert" have an opinion on it? -- *Romain de Bossoreille*

2 2

Powerstroke rounded joins
by Johan Engelen 24 Mar '12

24 Mar '12

Hi all, After busting my brain for two evenings, I've succeeded in creating properly rounded joins for powerstroked paths... The quick explanation: - for constant stroke width paths: looks like SVG rounded joins (circular arc) - for non-constant width paths, it is not possible to round with a circle and keep the curve smooth (tangents will not match). So the rounding is done with an elliptical arc, for which the tangents *do* match. There are many possible ellipses, and I decided for the one with minimum eccentricity. This converges to a circle for constant stroke width. Please test and tell me if it is bugged. (bzr rev 11111) Cheers, Johan

2 4

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 24 Mar '12

24 Mar '12

Alright, I've had the time to take a better look at Veronika's diagrams. They're really well-done, I feel like I finally understand what's going on! (quite a feat considering the headaches I've amassed from trying to figure out what's happening from several other sites) It's easier to see how handles would work thanks to those. Here's an example toggling between P1, P2, PM and PMM. http://www.freeimagehosting.net/kouh5 (hopefully you can tell the pair, symmetry and rotation handles) With an additional handle for glide reflection, it should be possible to connect all shapes with rectangular base tiles. I'm not sure how to fit in P3 and P4 though. What's more, it may be possible to convert between most of the triangle tiles by clicking on a corner, and dragging around to choose the number of tiles in that corner (3, 4, 6, 8 or 12). The shape of the tile would have to be updated automatically. The problem is that the users may then be tempted to drag other handles around to convert between pair, symmetry and rotate to play around, but the resulting output may not correspond to a tillable symmetry. There should be a method of warning in that case. Also, to make things less confusing, it may be possible to force one corner to be a "primary rotation corner" (the corner with the largest amount of tiles touching it) and a "secondary rotation corner." Does anyone feel up to trying to make a diagram with all 17 tilings as well as conversion methods between them? If you somehow manage to do that, I'll try to make a new tiling GUI proposal around it.

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 24 Mar '12

24 Mar '12

Ah-hah! People keep telling me about draggable handles, but I never was able to figure out what they meant (it's just me being clueless, not other people's faults). I think I'm beginning to see what people are talking about. Simple example: - Base tile: Rectangle for P1. At the side of each edge, you see a handle. The ones on the left and right are the same, the ones on the top and bottom are the same. Maybe parallel arrows. They symbolize "translation" (though I am going to go with another name, like "pair handle", because one side forms a pair with another) - By either dragging the handle or doing some other operation, the "pair" handle becomes say... a symmetry handle. So now the default behavior of that side is symmetry (also breaking the "pair" behavior of the other side). It can also be changed into anti- symmetry (using the center of the side). In the same way, there are edge handles. By manipulating it, the rectangle corner can become say... a triangle corner (and this is why I used "pair" rather than "translation": a pair behavior can be maintained). Alright, the main "issue" here is that I'm the one who doesn't know how to handle such behavior (since, as I've already explained, I'm pretty clueless about wallpaper tiling actually). Can someone more familiar with wallpaper tiling look into how feasible it is to transform from one tiling to another without erratic behavior? Is it possible to transform from one type to any other? If it's feasible, then I'll have to redo the whole thing proposal again. xD This time probably re-integrating guides and the actual tiling into one interface... ----- Original Message ----- From: Mark Schafer <mschafer@...2596...> To: Valerie <valerie_vk@...36...> Cc: Sent: Saturday, March 24, 2012 6:05 AM Subject: Re: [Inkscape-devel] New tiling interface proposal I can see that a set of thumbnail pics showing the principle tiling layouts is useful for initial selection of a specific tiling. And your approach looks very good. But ideally that would create the interactive draggable handles on the canvas for users to interact with - and ideally modifiable to create all tilings simply from these widgets. That way a new user can select a tiling style to being to operate with (or see many choices) - and an advanced user can simply begin and manipulate the tiling to their desired outcome. This approach would argue for a simple UI where initial selection (or toggling of selection) can start/modify the current tiling on canvas. So not taking up alot of room on the UI seems preferable. Perhaps a drop down image selection ? I would add that the initial tile and its handles could be in 'bold' and the reflections etc be drawn 'weaker' and so the effect of handle manipulation can be more clearly adjusted interactively. A weaker 'reflection' also allows you an excuse to operate with simpler proxy copies of the original - which could be replaced with proper curves etc on handle release. To further control the amount of drawing, a "preview generations" numeric field could indicate how many of the tiling 'reflections' to actually draw. E.g. 1 would show only the first level 'reflections' of the tile, and a 2 would show a further level. 1 or 2 would probably suffice in most cases to visually see the effect of the tiling at a useful scale for design. Then - similar to the preview button on existing extensions - making it could then extend out to some kind of boundary. As you say a rectangle, or perhaps a clipping region of some kind, or a defined number of 'reflections' of the tile operator. Ideally the tile generator would be a widget which could be modified at any time - similar to existing tools like the box. Just my 2 cents. Thanks for having a go at this - its coming along very well - I'm very much looking forward to the result. Mark... On 3/24/2012 6:10 AM, Valerie wrote: >> http://i.imgur.com/DMCvU.png > Oh phew, thank you so much for making that! I was trying to make something like that too but a bit different, and some of those symmetries were starting to make me feel Very cross-eyed. > > Basically I was thinking that a table for all the tiling types > (both wallpaper and Frieze) with the following visual guides would > be useful: > 1. The base tile guide with no transformation indicators > 2. The base tile guide with indicators (use can toggle indicators > on and off) > 3. The preview when creating the guide (either what you did here, > or Thorsten's previews) > 4. An outline preview of extra tiles (can be toggled on and off, > shows basically the outline of those extra tiles as you've made here) > 5. My idea was to also make base tile guides that show you which > tile side ends up reflected on which side. This is meant to help > a person who wants to program the "guide points" feature: > - Two "corresponding" sides will be represented by dotted lines of > the same colours. (example: for simple translation, the left and > right sides would be dotted lines of one colour, and the up and > down sides of another colour). An arrow marks the "direction" of > each side. > - Each side that transforms onto itself is represented by a full > line. It is marked either by a single arrow (if the transformation > is in the same direction) or two arrows in opposite directions (if the tile is flipped) > 6. Base tiles again, this time with examples of guide points > and guide segments. > > (yeah, that makes a lot...) > >> I do have to throw out there at this point, the proposed UI >> for tiling at http://wiki.inkscape.org/wiki/index.php/Tiling_tool is incredibly complex. One of the benefits to a dedicated tool is actually being able to manipulate parameters on-canvas. > Are you reading the latest version (there were many versions...)? > Because all the things that can be manipulated on canvas Are manipulated on-canvas... The dialogue is only choosing options > (there are a lot of options... much more than your average LPE, > even), the number of copies, and hitting "apply" (none of which > are really on-canvas interactions). > > I've thought of the use of tile shadow outlines to help users see > what will be rendered. The problem is dynamics. They make the > tile outlines unpredictable in the first place... That's why I came up > with extra render "target" options, so users can choose to render > over a specific, non-rectangular area, or even better, to render > as a target's pattern (if .svg allows that), so users can then > manually control any offsets with the pattern tool. > > Now, I was actually thinking about on-canvas handles for > manipulating dynamics, but that's a whole other can of worms... > (and given the time needed to render dynamic tiles, I'm not so > sure it's such a good idea to have them updated live...) > > I'm open to suggestions though. I've made a number of mock-ups > proposals for tilings until now, and this is just the latest iteration > (the... fifth I think? If I count the few ideas I first had a few years > ago). If someone has a general direction in mind (beyond "it has > to be a tool"), I can try to see if I can work out something. > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 23 Mar '12

23 Mar '12

> http://i.imgur.com/DMCvU.png Oh phew, thank you so much for making that! I was trying to make something like that too but a bit different, and some of those symmetries were starting to make me feel Very cross-eyed. Basically I was thinking that a table for all the tiling types (both wallpaper and Frieze) with the following visual guides would be useful: 1. The base tile guide with no transformation indicators 2. The base tile guide with indicators (use can toggle indicators on and off) 3. The preview when creating the guide (either what you did here, or Thorsten's previews) 4. An outline preview of extra tiles (can be toggled on and off, shows basically the outline of those extra tiles as you've made here) 5. My idea was to also make base tile guides that show you which tile side ends up reflected on which side. This is meant to help a person who wants to program the "guide points" feature: - Two "corresponding" sides will be represented by dotted lines of the same colours. (example: for simple translation, the left and right sides would be dotted lines of one colour, and the up and down sides of another colour). An arrow marks the "direction" of each side. - Each side that transforms onto itself is represented by a full line. It is marked either by a single arrow (if the transformation is in the same direction) or two arrows in opposite directions (if the tile is flipped) 6. Base tiles again, this time with examples of guide points and guide segments. (yeah, that makes a lot...) > I do have to throw out there at this point, the proposed UI > for tiling at http://wiki.inkscape.org/wiki/index.php/Tiling_tool > is incredibly complex. One of the benefits to a dedicated tool > is actually being able to manipulate parameters on-canvas. Are you reading the latest version (there were many versions...)? Because all the things that can be manipulated on canvas Are manipulated on-canvas... The dialogue is only choosing options (there are a lot of options... much more than your average LPE, even), the number of copies, and hitting "apply" (none of which are really on-canvas interactions). I've thought of the use of tile shadow outlines to help users see what will be rendered. The problem is dynamics. They make the tile outlines unpredictable in the first place... That's why I came up with extra render "target" options, so users can choose to render over a specific, non-rectangular area, or even better, to render as a target's pattern (if .svg allows that), so users can then manually control any offsets with the pattern tool. Now, I was actually thinking about on-canvas handles for manipulating dynamics, but that's a whole other can of worms... (and given the time needed to render dynamic tiles, I'm not so sure it's such a good idea to have them updated live...) I'm open to suggestions though. I've made a number of mock-ups proposals for tilings until now, and this is just the latest iteration (the... fifth I think? If I count the few ideas I first had a few years ago). If someone has a general direction in mind (beyond "it has to be a tool"), I can try to see if I can work out something.

2 1

Release of binaries
by Johan Engelen 23 Mar '12

23 Mar '12

Hi all, Apparently, there is a policy to release binaries at the same time, instead of simply uploading them to Sourceforge whenever they become available. I would like to see this changed to the latter option. I see no point in why people on one platform would have to wait for binaries becoming available on the other. Thanks for your consideration, Johan

5 6

QR code request.
by john Culleton 23 Mar '12

23 Mar '12

I note that Inkscape offers the Datamatrix bar code as an option. However another 2d bar code is now in common use, the QR code which can be read by many handheld devices. I wonder if a QR generator could be added to Inkscape, perhaps as a GSOC project. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

3 2

Additional print file outputs.
by john Culleton 23 Mar '12

23 Mar '12

The printer Lightning Source Inc. will only accept print files for book covers in the form of PDF X/1-a:2001 or TIFF. Neither is available from Inkscape 0.48.2. While conversion of a png file is available through ImageMagick or GraphicsMagick this requires use of the the command line which the current generation has been taught to fear. So I wonder if one or both options could be built in to a future version of Inkscape. Perhaps this could be a GSOC project. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

1 0

0.48.3.1 Windows installer
by Krzysztof Kosiński 23 Mar '12

23 Mar '12

Hello all I have a Windows installer ready, and it seems to work correctly. It is 36 MB, so too big to send via email. Where should I upload it so that others might test? Regards, Krzysztof

8 10

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 22 Mar '12

22 Mar '12

> Yes, the Rosetta group has two basic patterns: simple rotations > (restricted to angles that evenly divide into 360) and rotation plus > reflection - I didn't see the reflection option in your design, perhaps > I missed it. It's in the Tiling dialogue mock-up for Radial tiling, and in the description of the work sequence for the "Add tiling type" section. I guess I should make a table with the transformation options, and add the Frieze options while I'm at it. On the previews: I'm actually trying to keep the guides themselves as uncluttered as possible where extra indicators are concerned. That's because one look at the detailed wikipedia base tiles convinced me that they're more confusing than helpful. As I said, there already are previews, before you create the guides. I think that they're enough to give users an idea of what's going on. Besides, the shapes themselves usually give a clue as to what the transformation will be (if it's a triangle, you know that it isn't simple translation). The guides can be transformed like any other object, so you can resize, rotate and flip them like normal objects. I believe the guide points feature is more useful than giving more indicators on the guides themselves: at the end of the day, when the user is designing a seamless tile, what he needs to know most is how a line going out of the tile will connect to the next tile. What happens to the corner of the base tile isn't as useful. Here's the description again: > When a guide point is created on one side of a guide, counterparts > are automatically created on all other sides of the basic guide. All > changes to the original will be reflected onto the new tile. > What's more, you can click and drag this guide to create a guide > segment. By snapping a node on a guide point and snapping its > handle to the end of the guide segment, and by repeating the > operation with the node's counterpart, the user can create smooth > transitions from one tile to the next. Guide points can be moved along the corners of the guides. When you do so, all its counterpoints are updated dynamically. I guess the current mock-ups aren't clear enough, I'll have to make a few new ones. Look at this program: http://www.cgl.uwaterloo.ca/~csk/software/penrose/ Unlike this program, the guide points can be moved along the sides of the guide. Like this program, by dragging on some of them, a segment is created that also appears on all the guide points' counterparts. Do you understand the concept now? You can know exactly how a line going out of the tile will go back in. As for the tiling shadow, the problem is how many tiles will be displayed. Controlling the number of tiles must be done from the tiling dialogue rather than from the tiling guide tool. I guess I could add a "show tiles outline" option to the tiling dialogue.

4 6

Re: [Inkscape-devel] Inkscape GIS
by Stefan de Konink 21 Mar '12

21 Mar '12

On 17-03-12 20:55, Brylie Oxley wrote: > Thank you for suggesting Mapnik Stefan! :-) Inkscape would be a suitable > GUI for a Mapnik based cartography solution. I do not think that > Inkscape and Mapnik are necessarily in opposition, do you? The major problem is, if you look at cartography to SVG is that data is not offered in layers you would actually use in regular print. The output of mapnik is actually a set of drawing commands. So your audience might require two approaches; - ability to get an arbitary piece of a map, and the ability to interactively edit the stylesheet, see output etc. Inkscape could help here because stylesheets contain a lot of SVG elements you want to edit along the map; the result of this operation is a stylesheet, and a set of icons. - the ability to get arbitrary data in layers and be your own renderer, stack layers, assign decimation, add colours etc. this would be closer to having a shapefile in a solution like Illustrator and modifying it. Opposed to mapnik this step requires the editor to do 'layer' operations theirselves. Stefan

1 1

Running Inkscape from non-default location (Ubuntu)
by Jeremy Villalobos 21 Mar '12

21 Mar '12

Hello: I checked out and built Inkscape 0.49x on Ubuntu following the Guide's instructions http://wiki.inkscape.org/wiki/index.php/CompilingUbuntu But when I run the program from the non-standard location, the 0.48x version pops up (the one instaleed with the repo manager) What env vars do I have to set/modify to run the program from the non-default location. Or does 0.49x has the wrong version being reported ? thanks Jeremy

4 3

PLEASE UNSUBSCRIBE
by a kayzar 20 Mar '12

20 Mar '12

1 0

Mathematical Art for teenagers
by veronika 19 Mar '12

19 Mar '12

Hi, I am a PhD candidate in Computer Science at the University of Victoria (Victoria, BC, Canada) and I am interested in the GSoC program. I am interested in the exploration of Math through the creation of Digital Art and how this can be used in classrooms and after school clubs to promote interest in Math and develop skills particularly among students in the age range 13 to 18. I have conducted an after school club with students in which we used Inkscape, Scratch/BYOB and various applets. Some of the results from this club can be seen in my blog: http://visquest.blogspot.ca. There are several projects that I would be interested in working on. One area is to take a topic such as Tessellations and fill out the tool set as needed to make these projects accessible for young teenagers. There is an excellent web site (http://www.tessellations.org) which describes many techniques for creating tessellations and there is a tutorial for performing the basic steps in Inkscape (http://www.digitalartforall.com/1267/inkscape-creating-tessellations/), together these make a very good starting point. Some of the places where students stumble are 1) Understanding commands such as Path-Division and Path-Union 2) Performing Translation and Rotation so that the pieces line up correctly (need a way to mark an alignment guide on both pieces based on style of tessellation) 3) The Tiling dialog is very complicated and does not support an iterative approach. Another area is to look at the learning potential for something like the Spirograph extension (or L-System extension or many other extensions) and how it could be improved. For example, there is quite a lot of interesting math to explore with hypertrochoid and epitrochoid curves, however, the current dialog approach does not give the user an intuitive understanding of how the circles move relative to one another. In contrast, the Spiromath applet (http://www.mathplayground.com/Spiromath.html) gives nice visual feedback about the relative motion but is very limited in its drawing capabilities. A fun project would be to turn the Spirograph extension into a tool, extend it to allow for shapes other than circles and give more direct control over things like pen position, number of revolutions (including the ability to rewind if it has gone too far) etc. I am interested in using Inkscape in my thesis research as a key part of a Mathematical Art environment and would welcome the opportunity to work with a mentor. I am interested in gaining experience developing tools and extending the user interface. Kind regards, Veronika -- View this message in context: http://inkscape.13.n6.nabble.com/Mathematical-Art-for-teenagers-tp4632081p4… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 1

Re: [Inkscape-devel] Mathematical Art for teenagers
by Valerie 19 Mar '12

19 Mar '12

Hi Veronica! Alright, now I understand why you were asking about the visual references for the tiling guides. I was approaching the issue from a "need as little prior knowledge as possible" approach, while you are interested in an educational approach. That could be solved simply enough. There could be an option to toggle indicators and markers on and off, and maybe show "neighbouring tiles." I'll try to add such options to the existing mock-up. :)

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 19 Mar '12

19 Mar '12

Thanks for the link! - The Frieze groups are definitely interesting! I'll add those to the current mock-ups once I have the time. They should help make border designs easier. - The Rosetta groups seem to be just Simple Rotations and Symmetry + Rotations though. Am I missing something? I'm not sure what you mean by rotation points, reflection lines etc. that can be moved though. They don't exist as separate points, they're just the borders and corners of the guides. A guide defines the shape of the base tile. You modify the guide itself, not points along the guide. (example: simple translation has a rectangle guide. You can easily change the dimensions of this rectangle, though it will stay a rectangle). Are you referring to my notion of guide points? Guide points are separate points that when added to one side of a guide, create counterparts on other relevant sides of the guide, so you know where you add lines in a way to create seamless transitions from one tile to the next. They're made so that a user would need 0 knowledge of wallpaper geometry when creating seamless tiles: they just need to connect to the guide points. I should have made a visual reference of guides and guide point behavior for each tiling type, but the truth is, I'm pretty confused about tiling behaviour myself. :S That's the whole reason I tried to come up with an interface that basically requires 0 prior knowledge. x) ------------------------------ Message: 6 Date: Sat, 17 Mar 2012 11:55:16 -0700 (PDT) From: veronika <vmi@...2827...> Subject: Re: [Inkscape-devel] New tiling interface proposal To: inkscape-devel(a)lists.sourceforge.net Message-ID: <1332010516483-4628619.post@...2730...> Content-Type: text/plain; charset=us-ascii You have covered the topic very well. Another example to look at is the Kali applet: http://www.scienceu.com/geometry/handson/kali/index.cgi?group=wt For Tiling along the Path you could support the seven Frieze groups and for Rotational tiling you could support the Rosette groups. In the guides for a given symmetry group, you could show the rotation points (along with their degree) as well as reflection lines, glide reflection lines and translation directions and lengths. I think you briefly describe these ideas in your document but since there is quite a lot going on here it may be useful to spell it out in detail for each symmetry group. The user should be able to move these guide lines and points as long as they stay within the constraints of the chosen symmetry group. Below is a picture of guides for symmetry p6m (colours just used for visibility but should conform to guidelines elsewhere): http://inkscape.13.n6.nabble.com/file/n4628619/wallpaper.png The book "The Symmetry of Things" by Conway, Burgiel and Goodman-Straus has some very nice visualizations for reference. -- View this message in context: http://inkscape.13.n6.nabble.com/New-tiling-interface-proposal-tp4570734p46… Sent from the Inkscape - Dev mailing list archive at Nabble.com. ------------------------------ Message: 7 Date: Sat, 17 Mar 2012 21:03:47 +0100 From: Stefan de Konink <stefan@...2063...> Subject: Re: [Inkscape-devel] Inkscape GIS To: brylie@...2823..., Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> Message-ID: <4F64EE23.3050006@...2063...> Content-Type: text/plain; charset=UTF-8; format=flowed On 17-03-12 20:55, Brylie Oxley wrote: > Thank you for suggesting Mapnik Stefan! :-) Inkscape would be a suitable > GUI for a Mapnik based cartography solution. I do not think that > Inkscape and Mapnik are necessarily in opposition, do you? The major problem is, if you look at cartography to SVG is that data is not offered in layers you would actually use in regular print. The output of mapnik is actually a set of drawing commands. So your audience might require two approaches; - ability to get an arbitary piece of a map, and the ability to interactively edit the stylesheet, see output etc. Inkscape could help here because stylesheets contain a lot of SVG elements you want to edit along the map; the result of this operation is a stylesheet, and a set of icons. - the ability to get arbitrary data in layers and be your own renderer, stack layers, assign decimation, add colours etc. this would be closer to having a shapefile in a solution like Illustrator and modifying it. Opposed to mapnik this step requires the editor to do 'layer' operations theirselves. Stefan ------------------------------ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel End of Inkscape-devel Digest, Vol 70, Issue 16 **********************************************

2 1

Problem using GDB on Windows
by veronika 18 Mar '12

18 Mar '12

Hi, I am new to Inkscape development and I am trying to use gdb on Windows. Using the latest source from trunk (via bazaar), I followed the instructions on the wiki, modified the build.xml and did a full re-build. I have no problem building the executable and launching the executable but when I try to debug it, I get an error immediately after the main window opens: warning: HEAP[inkscape.exe]: warning: HEAP: Free Heap block 1621e0d8 modified at 1621e258 after it was freed Program received signal SIGTRAP, Trace/breakpoint trap. 0x772504e5 in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll The backtrace appears at the end of this post. I have tried both the gdb executable that comes with devlibs and the one installed with mingw - both give the same result. I have been able to use gdb with Inkscape on Linux with no problem. Any suggestions? Has anyone else encountered this problem? Thank you for your help. Veronika [New Thread 3380.0x3a8] [New Thread 3380.0x10cc] [New Thread 3380.0x12a8] [New Thread 3380.0xa44] [New Thread 3380.0xf6c] [New Thread 3380.0x774] warning: HEAP[inkscape.exe]: warning: HEAP: Free Heap block 1621e0d8 modified at 1621e258 after it was freed Program received signal SIGTRAP, Trace/breakpoint trap. 0x772504e5 in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll (gdb) backtrace #0 0x772504e5 in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll #1 0x0028e8e8 in ?? () #2 0x7720a383 in ntdll!AlpcMaxAllowedMessageLength () from C:\Windows\system32\ntdll.dll #3 0x1621e0d8 in ?? () #4 0x771b35a7 in ntdll!RtlReleasePebLock () from C:\Windows\system32\ntdll.dll warning: (Internal error: pc 0x4a in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x4a in read in psymtab, but not in symtab.) #5 0x0000004b in ?? () warning: (Internal error: pc 0x4a in read in psymtab, but not in symtab.) #6 0x771b3492 in ntdll!LdrLoadAlternateResourceModuleEx () from C:\Windows\system32\ntdll.dll #7 0x1621e330 in ?? () #8 0x7725169e in ntdll!RtlValidateHeap () from C:\Windows\system32\ntdll.dll #9 0x0e9e0000 in ?? () #10 0x7720ab9a in ntdll!AlpcMaxAllowedMessageLength () from C:\Windows\system32\ntdll.dll #11 0x0e9e0000 in ?? () #12 0x771b3492 in ntdll!LdrLoadAlternateResourceModuleEx () from C:\Windows\system32\ntdll.dll #13 0x1621e330 in ?? () #14 0x75b198cd in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll #15 0x0e9e0000 in ?? () #16 0x6aa0178a in sigc::signal_base::~signal_base() () from c:\veronika\research\inkscape\src\trunk\inkscape\libsigc-2.0-0.dll #17 0x00429b92 in ~signal1 (this=0x1621df04, __in_chrg=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:2736 #18 ~signal (this=0x1621df04, __in_chrg=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:3641 #19 SPObject::sp_object_finalize (object=0x1621dec8) at src/sp-object.cpp:199 #20 0x63a46492 in g_object_unref () from c:\veronika\research\inkscape\src\trunk\inkscape\libgobject-2.0-0.dll #21 0x00429791 in sp_object_unref (object=0x1621dec8, owner=0x0) at src/sp-object.cpp:270 #22 0x0042a12f in SPObject::deleteObject (this=0x1621dec8, propagate=false, propagate_descendants=false) at src/sp-object.cpp:494 #23 0x00c11b93 in deleteObject (propagate=<optimized out>, this=<optimized out>) at src/sp-object.h:471 #24 MarkerComboBox::create_marker_image (this=0x1619c928, psize=22, mname=0x13493180 "Arrow1Lend", source=0x124b4e40, drawing=...) at src/widgets/stroke-marker-selector.cpp:345 #25 0x00c12238 in MarkerComboBox::add_markers (this=0x1619c928, marker_list=0x16114e00, source=0x124b4e40) at src/widgets/stroke-marker-selector.cpp:306 #26 0x00c126bb in MarkerComboBox::sp_marker_list_from_doc (this=0x1619c928, source=0x124b4e40) at src/widgets/stroke-marker-selector.cpp:263 #27 0x00c12bfe in MarkerComboBox::init_combo (this=0x1619c928) at src/widgets/stroke-marker-selector.cpp:126 #28 0x00c13883 in MarkerComboBox::MarkerComboBox (this=0x1619c928, id=0x1621e0d8 "K", __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at src/widgets/stroke-marker-selector.cpp:68 #29 0x00b2e69e in sp_stroke_style_line_widget_new () at src/widgets/stroke-style.cpp:471 #30 0x00739b28 in Inkscape::UI::Dialog::FillAndStroke::_layoutPageStrokeStyle (this=0x16150978) at src/ui/dialog/fill-and-stroke.cpp:123 #31 0x0073a30a in Inkscape::UI::Dialog::FillAndStroke::FillAndStroke (this=0x16150978, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at src/ui/dialog/fill-and-stroke.cpp:64 #32 0x00db4a10 in getInstance () at src/ui/dialog/fill-and-stroke.h:35 #33 Inkscape::UI::Dialog::PanelDialog<Inkscape::UI::Dialog::Behavior::DockBehavior>::create<Inkscape::UI::Dialog::FillAndStroke> () at src/ui/dialog/panel-dialog.h:186 #34 0x004fd024 in Inkscape::UI::Dialog::(anonymous namespace)::create<Inkscape::UI::Dialog::FillAndStroke, Inkscape::UI::Dialog::Behavior::DockBehavior> () at src/ui/dialog/dialog-manager.cpp:68 #35 0x004fdf65 in getDialog (name=3267, this=0x13207190) at src/ui/dialog/dialog-manager.cpp:236 #36 Inkscape::UI::Dialog::DialogManager::getDialog (this=0x13207190, name=3267) at src/ui/dialog/dialog-manager.cpp:224 #37 0x004fe106 in Inkscape::UI::Dialog::DialogManager::showDialog (this=0x1621e0d8, name=3267) at src/ui/dialog/dialog-manager.cpp:257 #38 0x00d6e4e7 in operator() (this=0x1326fe9c, _A_a1=<optimized out>, _A_a2=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/functors/ptr_fun.h:147 #39 operator()<SPAction*&, void*&> (this=0x1326fe98, _A_arg1=<optimized out>, _A_arg2=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:103 #40 operator()<SPAction*&> (this=0x1326fe94, _A_arg1=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/adaptors/bind.h:1122 #41 operator() (this=0x1326fe90) at c:/devlibs/include/sigc++-2.0/sigc++/adaptors/bind.h:1110 #42 sigc::internal::slot_call0<sigc::bind_functor<-1, sigc::bind_functor<-1, sigc::pointer_functor2<SPAction*, void*, void>, void*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, SPAction*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void>::call_it (rep=0x1326fe78) at c:/devlibs/include/sigc++-2.0/sigc++/functors/slot.h:103 #43 0x00470dc9 in emit (impl=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:773 #44 emit (this=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:2668 #45 sp_action_perform (action=0x13276560) at src/helper/action.cpp:164 #46 0x00539226 in SPDesktop::show_dialogs (this=0x124d4d20) at src/desktop.cpp:1845 #47 0x004374eb in sp_namedview_window_from_document (desktop=0x124d4d20) at src/sp-namedview.cpp:845 #48 0x0045b6da in sp_file_new (templ=...) at src/file.cpp:136 #49 0x0045ba2e in sp_file_new_default () at src/file.cpp:182 #50 0x00403b25 in sp_main_gui (argc=1, argv=0xeb3a908) at src/main.cpp:976 #51 0x00ef218f in main (argc=1, argv=0xeb3a908) at src/main.cpp:711 -- View this message in context: http://inkscape.13.n6.nabble.com/Problem-using-GDB-on-Windows-tp4628229p462… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 6

Problematic documentation changes in r10697
by Krzysztof Kosiński 18 Mar '12

18 Mar '12

Revision 10697 moved most of the documentation from .cpp to .h files. This means extensive recompilation whenever a documentation change is made, and therefore it discourages improving documentation for no obvious gain. If there was a desire to have all the docs in one file, they should have been moved to the .cpp file with the help of commands such as @class and @var. Unfortunately this revision mixes the pointless moves with useful fixes, so I can't simply revert it. Regards, Krzysztof

1 0

New tiling interface proposal
by Valerie 17 Mar '12

17 Mar '12

I redid the whole thing... again. http://wiki.inkscape.org/wiki/index.php/Tiling_tool This is the first among my proposals with a consistent behavior from start to finish (at least, I think so), and doesn't look like a badly-proportioned three-headed Frankenstein. A picture is worth a thousand words so.... this is the target behavior: http://wiki.inkscape.org/wiki/images/Tiling_interface_examples.png In fact, I now divide the tiling "tool" into 2 parts (then further divided the whole proposal into hopefully more manageable sub-parts): 1. A general tiling guide tool whose only interacting with the tiling process is to send it coordinates (the type that no-one wants to input manually). http://wiki.inkscape.org/wiki/images/Tiling_Guide_Toolbar.png 2. The tiling -process- is back in a dialogue. This is because no matter what I did, it wouldn't stuff into a toolbar, and having separate "tools" was becoming a bit ridiculous. However, all the things that need to be "on-canvas" (the guide, basically) is now on-canvas. The only numerical values you need to input manually are intuitive ones like the number of clones and maybe a start and finish angle. And values for dynamics, but I haven't figured out an on-canvas way to handle those as the same time as basic tile information... http://wiki.inkscape.org/wiki/images/Tiling_dialogue_proposal.png Also, this interface allows you to stack tilings, and could also integrate into whatever future Effects Stacking interface Inkscape comes up with. >From a single tile, you can define not only the interior tiles, but "edge" scenarios as well. The feature involved here is actually a simple cut, delete and join operation: Inkscape cuts the pattern along certain guides, deletes the parts that need deleting, and does a "Select all nodes" and "Join" operation. (of course, on this occasion, I discovered that Inkscape can't actually cut groups of objects yet, oh well) If you placed all the tile elements in a way to create seamless tiles (that's where Guide Points are supposed to help), then all the tiles will proceed to join up seamlessly, even with small variations (though not big ones). Hopefully this is a good start for others to come up with even better possibilities. Thoughts?

2 1

Inkscape GIS
by Brylie Oxley 17 Mar '12

17 Mar '12

Hello, My name is Brylie Oxley. I am a student at Sierra College in Nevada City, CA. I would like to apply for the GSoC program. I have been studying GIS at Sierra College, where the courses focus on proprietary tools. For libre GIS tools to be viable options, we need high quality cartographic tools. This is where I see Inkscape as an EXCELLENT candidate. With some effort and extension, Inkscape can be used as an integrated cartographic tool in a libre GIS workflow. The primary goal of the extension would be to enable Inkscape to receive/display information from one or more Libre Geospatial tools/data sources (such as QGIS, PostGIS, GeoServer, MapServer, OpenStreetMap, OpenLayers, and/or GRASS GIS.) Python would seem to be a good candidate language as there are already Python bindings in Inkscape, QGIS, and GRASS. The primary task of the extension would be to send/receive geodata, so most of the heavy lifting might be able to be done by existing modules (specifically GDAL/OGR.) http://grass.osgeo.org/wiki/GRASS_and_Python#Writing_Python_scripts_in_GRASS http://www.qgis.org/pyqgis-cookbook/ http://pypi.python.org/pypi/GDAL I feel that this is a very important step for the viability of libre geospatial and would appreciate any mentorship and feedback that this community can offer. Thank you very much for your time and consideration. --Brylie Oxley

2 1

EAN% barcode.
by john Culleton 17 Mar '12

17 Mar '12

My copy of 48.2 has the EAN5 barcode available. The latest version of the Tavmong Bah book does not list it. Is EAN5 part of the distro now? I remember adding it separately to 48.0. EAN5 is used for the price barcode on books, and is included with e.g., Scribus. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

5 5

Google Summer of Code 2012
by Josh Andler 16 Mar '12

16 Mar '12

Hi All, I just wanted to shoot out a message to let people know that we've been accepted as a mentoring organization again this year. If you know any college or graduate school students who would qualify and be interested, please let them know, we would like to talk to them. :) Cheers, Josh

1 0

Bug tracker maintenance
by Josh Andler 16 Mar '12

16 Mar '12

Hey everyone, If you're a developer and have a chance sometime soon, please visit the bug tracker to view what bugs are assigned to you. If you feel a bug assigned to you is wrongly assigned or that it is unlikely that you will work on that bug, please unassign yourself. We don't want to discourage anyone from taking on a bug because someone else's name is on it. As long as my LP-fu isn't bad (forget the stats on the bug page, I did it not including bugs marked "fix committed") the bug tracker currently has 1,791 open bugs (wishlist not included), 748 are marked as new, 167 marked High, and it appears that bugs w/ patches is at 84. Those numbers aren't horrible, but I'm sure there are a number of bugs that can probably be closed at this point. If you don't code, but want to help the project, you can give us a hand by trying to help us reduce the number of "New" bugs mentioned above. Trying to reproduce bugs is always helpful if they're not confirmed or if it looks like it was last confirmed a couple years back (or on old versions). I'm not sure if the tracker is as open as it was, but hopefully you can modify the status and such without needing to be a team member. If so, please review http://wiki.inkscape.org/wiki/index.php/Bug_management to find out how we do things. Any Qs, as always, please don't hesitate to contact me. Cheers, Josh

2 1

Re: [Inkscape-devel] Meeting: build system on Windows
by Johan Engelen 15 Mar '12

15 Mar '12

On 9-3-2012 10:00, Jasper van de Gronde wrote: > On 08-03-12 21:52, Johan Engelen wrote: >> Hi all, >> I would like to have an IRC meeting about the build system on >> Windows. >> >> Although I like buildtool, it cannot do parallel builds, so I am happy >> to change (back) to something else. And unify it with Linux if >> possible... >> I am trying cmake now, but it does not link without errors yet. It is >> not very encouraging to see the cmake build process get stuck on some >> intermediate step for a long while, seemingly checking something to find >> out it does not need to rebuild it. "btool" does this much much >> quicker... >> >> In any case, I'd like to discuss the options. Who's in? > > Depends on when the meeting is, but I wouldn't mind participating. > > And here's an alternative option: use buildtool on Linux as well. > Seriously. Yes, buildtool has its deficiencies, and it is much less > flexible than *make, but it is /so/ much easier to use and maintain (the > build file itself I mean, not buildtool). I'm completely unaware of the > issues involved in getting it to work on Linux, so perhaps it's just not > very feasible. Or perhaps I'm unaware of some of the issues buildtool > has on Windows. But I would hate to see buildtool go and be replaced by > some other monster of a build system just because it couldn't do > parallel builds (which should in principle be fixable). This of course triggered me to see if I could hack buildtool to do parallel builds. It turns out to be extremely easy to do so! See rev. 11087 Rebuild buildtool with "-fopenmp" and then you should be able to use the "-j" (20 parallel threads) option or e.g. "-j 4" (4 threads). Needless to say this speeds up a clean build tremendously on i7 2600K: 7 minutes. It is somewhat buggy, but who cares You have to run btool once more without "-j" to get a build done. Someone should be able to fix that... Cheers! Johan

2 1