- Inkscape Devel - Inkscape Mailman

Layer verbs
by Kris De Gussem 03 Jun '12

03 Jun '12

Hi all Anyone who knows what happened to the verbs SP_VERB_LAYER_TOGGLE_LOCK and SP_VERB_LAYER_TOGGLE_HIDE? They are defined at lines 2450-2454 in verbs.cpp but do not seem to be used anymore. Could they be deleted or is some other change needed here? Kind regards K.

2 2

New snap modes proposals
by Valerie 01 Jun '12

01 Jun '12

Here's a few snap modes that could be useful: 1. Snap to parallel If there are one or several angled guides around, any straight line you're drawing will snap to a direction parallel to the direction of those guides. It's like drawing paraxial lines, except not just constrained to horizontal and vertical lines. Useful if you need to draw a lot of diagonal lines for example. (by snapping, it means it will snap when the angle you're drawing approaches that angle. You won't be constrained to just drawing towards those directions) 2. Snap to orthogonal Same principle as the above, except in a direction orthogonal to existing guides. 3. Snap to node alignment When you're drawing an object with straight lines, any new point will snap to align to existing points of that line. I'm asking this because creating open-ended rectangles and more complicated straight-line shapes (examples: folder-like shape, thick U shape etc.) are a pain. Right now I have to either: - create several rectangles - align - combine - open up any extra segments Or: create nearly as many guides for snapping as the number of lines I want to draw (and then I have to delete them) Or: do a so-so job, open up the align dialogue and tediously align each group of nodes In fact, this snapping is the default behaviour I wish I'd have for paraxial drawing mode, but a snap mode should make a decent compromise for everyone. 4. Snap to guide point direction This one requires a guide point object first. When you're drawing a straight line, the line will snap in the direction of that point. Useful for perspective drawing, especially if the vanishing points are very far off from the drawing area.

1 0

IconWidget unused code?
by Alex Valavanis 31 May '12

31 May '12

Hi All, The code in src/ui/widget/icon-widget.[cpp,h] doesn't appear to be used anywhere. I searched for header inclusion, and use of the IconWidget class, and I don't see anything in trunk or 0.48.x. In fact, the C++ source looks rather like a placeholder file that was never completed. Can anyone shed some light on this? The file is contributing to the GTK+ 3 build failure, so if it's not used and not usable, am I OK to delete it? Thanks, AV

2 2

Regression in filters Editor
by Ivan Louette 31 May '12

31 May '12

Seemingly a recent regression in Filters Editor : https://bugs.launchpad.net/inkscape/+bug/1006816 ivan

1 0

Grid and Guide UI
by John Smith 31 May '12

31 May '12

Is there a reason for the differences between the UI for Grid and Guides ? Currently: a) Guides are visually "on" by default - but there are no actual guides. Menu "View->Guides" initially does nothing - since there is no guide to show/hide. b) Grids are visually "off" by default. Menu "View->Grid" creates and shows a grid if there is no grid. c) Guides are created/deleted via the Edit menu d) Grids are created/deleted via the Document Properties dialog. Comments in the code refer to some sort of backwards compatibility // show guides if not specified, for backwards compatibility // hide guides if not specified, for backwards compatibility Propose to change the Guide UI to match the Grid UI as below. 1. Guides would be "off" by default (if not specified in the doc) 2. Toggling "View->Guides" would create guides (same as "Edit->Create Guides Around the page") if there is no existing guide. 3. Add a button : "Document Properties->Guides->Remove Guides" 4. Remove menu item : "Edit->Create Guides Around the page" 5. Remove menu item : "Edit->Delete All Guides" https://bugs.launchpad.net/inkscape/+bug/1005055

8 15

Re: [Inkscape-devel] InkScape Help !!
by Ted Gould 30 May '12

30 May '12

Hey Suresh, I'm going to go ahead and CC inkscape-devel on my reply. That list, in general, is more likely to get you a timely e-mail than sending it directly to me. Plus it helps everyone learn together. I hope that's okay. On Thu, 2012-05-10 at 03:14 -0700, $uresh... wrote: > Ted, I am using InkScape for vector drawing, mostly I will generated > Vector graphics, generate svg file, and parse the file using C++ > coding and load the final value to CNC machine. By default, when there > is a group of object, by default matrix apply to only group not a > single object, so in some complex drawing with group, group and sub > group to find the object property I have to move to the parent group > and apply the value to group, well this is time taking and in some big > vector image, my binary hand and crash, because i traverse the svg, > find the root parent and apply parent property to child object.. > > For ex. > > Parent -> Child 1 (transform) -> child, in this case i need to > traverse upto the child parent that is Child 1 and if there is any > transform, I will strore it and apply it. > > Now I want to find out how can reduce the whole method using some > simple logic? Is there any way to simplified this process, so that i > will have exact object property of that group. In general, this is the way that SVG is structured, so that is how Inkscape represents it as well. What you're basically asking for is the rendered version that flattens the stack. I'm not sure exactly what you need as the final output, but if you could get it from the renderer directly that might be a solution for you. I'm not that familiar with the renderer code as it's been updated heavily recently, but if you think it might be, reply to the list with your questions. If not, I'd recommend not going up the stack, but in fact down it and keeping the matrix transformations themselves in a stack. So then you effectively have a cache of last few matrices as you move down. Computing the entire stack for each object is much more costly. Good luck! Ted

1 0

Embedded inline graphics and SVG ?
by Ivan Louette 30 May '12

30 May '12

I pick this up from the announcement of Xara Designer 8. This is a great feature but I don't know if this is compatible with svg. Freehand had it already a long time ago, and DTP programs like QuarkXPress also (but the later can also embed bitmap images on text lines, which is a must !) " Designer MX now allows you to embed 'inline graphics' in text using a simple Paste operation. Embedded graphics are great for really small items on the line such as symbols, icons etc, and are treated just like a 'character', in other words they flow and follow the same formatting rules as a character embedded in the text. " ivan

3 2

libpoppler shenanigans
by Chris Mohler 29 May '12

29 May '12

Hi, I had some issues when compiling current bzr against current libpoppler. I've attached a patch of modifications I made - I wouldn't apply it though: First item is that it seems like #define POPPLER_NEW_COLOR_SPACE_API isn't getting set in the configure script, and I don't have enough autotools-fu to figure out why. The test around line 20770 looks OK to me. So I crammed a define POPPLER_NEW_COLOR_SPACE_API 1 into pdf-parser.cpp (which is obviously the absolutely wrong thing to do). The next 57 changes are also in pdf-parser.cpp. It seems poppler's error() function now takes an additional first argument of type ErrorCategory [1]. I changed all error types to 'errInternal', since I'm guessing these aren't getting reported anywhere anyway. The final hack is that GfxFont no longer has a function 'getOrigName()'. It seems 'getName()' takes care of this now [2], so I removed that call from svg-builder.cpp. So, I doubt the patch is of any real value unless you're wanting to play around with current poppler on linux. On the upside, PDF import works just like in 0.48 with poppler shipped by Mint 12/Ubuntu Oneiric (0.16?). Of course the shipped -dev package doesn't have the xpdf headers, hence my willingness to muck about with poppler from git ;) Chris [1] http://cgit.freedesktop.org/poppler/poppler/tree/poppler/Error.h#n54 [2] http://cgit.freedesktop.org/poppler/poppler/tree/poppler/GfxFont.h#n199

2 2

Mesh tool added to trunk
by Tavmjong Bah 23 May '12

23 May '12

Hi, My Mesh branch suffered from serious bit rot. This is good as it shows how fast Inkscape code is progressing. But it also required several days of work to get the mesh branch in sync... not so good. I have thus merged the branch with trunk so I won't have to go through this pain again. One major change I made was to create a separate Mesh tool. The editing mode for meshes is significantly different from that for linear and radial gradients that I think this makes the most sense. By default, the Mesh tool is not shown. You can enable it at compile time by editing the file widgets/toolbox.cpp to define WITH_MESH. To actually see meshes, you must have compiled and linked to a version of Cairo greater to or equal to 1.11.4. Cairo version 12.0 would be preferred as 1.11.4 has bugs that cause frequent Inkscape crashes. Note, meshes are to be considered experimental. The SVG working group has endorsed their inclusion in SVG2 but the exact syntax has not been fixed. Inkscape is the only program/browser/renderer that supports the proposed SVG mesh syntax. Also, the UI for meshes is rather primitive at the moment. Please play with the meshes and give your feedback. Bug fixes and interface improvements will be greatly appreciated! Tav

4 4

Re: [Inkscape-devel] Mesh tool added to trunk
by Valerie 23 May '12

23 May '12

> What would be your recommendation regarding PPA builds? Enable or > disable the feature? Please enable it! Those of us using the PPA already know that it's an unstable build, and many of us look forward to testing this feature! :D

1 0