- Inkscape Devel - Inkscape Mailman

SVG closing path syntax
by Tavmjong Bah 07 Dec '12

07 Dec '12

Hi, At today's SVG working group meeting we talked a bit about path syntax in regards to how paths are closed. It has been proposed that if the last point in in the last path command is missing that the first point in the path be used: M x,y ... C x1,y1 x2,c2 z would be the same as M x,y ... C x1,y1 x2,2, x,y z The advantage of the proposed syntax change is that if relative path commands are used, one can ensure that the path is closed properly without introducing the little closing line segment that can result from rounding error (if the last point doesn't fall exactly on top of the first). What do people think about this? Tav

2 1

0.48.4
by Josh Andler 06 Dec '12

06 Dec '12

Hey All, Johan has fixed the outstanding bug that has been holding 0.48.4 up. I'm announcing that people have 1 week left to backport any fixes for that release and all changes should be completed by December 12th. Thanks to everyone for all of your work to make Inkscape and our community better. Looks like we may be able to pull off a holiday gift to our users after all. Cheers, Josh

3 2

Seeking input on moving forward
by Josh Andler 06 Dec '12

06 Dec '12

Hey all, As of right now there hasn't really been much headway on the renderer related bugs we have which will block 0.49 as well as no action on the security bug stopping all releases. 0.49 should be in feature freeze at this point so we can work towards releasing it (you know, being friendly to translators and all), but other than our blocker bugs, people are still happily working on other features and items that they're wanting merged in (connector cleanup, "spiro live", etc). Does anyone have any proposals on how we should move forward given the issues holding us back? Is it time that we move to using more branches as a project? One possible route would be to branch off 0.49 and allow open work to resume on trunk. Another is to create a "staging" branch that accepted merge proposals can all land in to get further testing. Note: After this experience, if things have known regressions, I feel strongly that they should not be merged into an actual "to be released" branch until those issue are resolved. I'm open to suggestions. Development shouldn't stagnate, but at this point things aren't looking good with a feature freeze in place and no signs of our blockers getting taken care of. Cheers, Josh

7 11

assets revision
by Alexandre Prokoudine 05 Dec '12

05 Dec '12

Hi, Folks from GNOME design team just asked me about ways to "hide" unused assets like templates and color swatches, so out of interest I've had a look, and it seems to me that indeed we could let go of some stuff. E.g. for templates that would be: - all desktop_* except probably 1600x1200 (640x480 is useful in 2012? for real?) - no_borders and no_layers (sounds like someone should just need to master custom templates) - default_mm and default_pt (same as above) - fontforge_glyph (obsoleted by typography_canvas) What do you think? Alexandre Prokoudine http://libregraphicsworld.org

6 6

Rotating objects around their center
by Pander 05 Dec '12

05 Dec '12

Hi all, I would like to rotate objects around their center by altering the Inkscape SVG of an image. Since the object have already been translated, I need to merge the rotate with that. I have posted an example here in September: http://www.inkscapeforum.com/viewtopic.php?f=16&t=12761 but until now, nobody was able to help me. What do I need to do in order to rotate as described in the example? Thanks, Pander

2 1

devlibs update (r39)
by Nicolas Dufour 04 Dec '12

04 Dec '12

Hi, The devlibs have just been updated to r39 in order to activate Visio file import on Windows (Wordperfect libs have been updated, and a new visio lib has been added). Note that the modifications also required some changes in the build.xml file, and that you need to update the trunk to revision 11925 so that Inkscape compiles correctly. The 0.48.x branch doesn't use libvisio, but also needs an update (revision 9931) to take the Wordperfect changes into account. Regards. -- Nicolas

4 5

Connector Work
by Martin Owens 04 Dec '12

04 Dec '12

Hey Devs, I've got a plan for getting last year's connector work into use. I've updated the branch to the latest trunk (damn you changes!) so I'd like to get this merged in because it removes 1110 lines and replaces them with 91. So it's a big cleanup of code that was never in use: https://code.launchpad.net/~doctormo/inkscape/knot-visio This branch should maintain the same functionality as we currently have, plus a focus on the next steps to improve the functionality. Testing is required and advice for more experienced cpp developers about the use of std::map instead of a more appropriate std::list structure which I'm hoping can be picked up in merge review. The next steps are the exciting parts. I thought the idea from last year about having a generic point anchor tool was really interesting. So the way the connector work will happen is, it'll simply use other non-connector functionality to achieve everything we want. The anchor tool would insert a point path, which would be displayed on screen with either an knot-anchor which would just move along with it, or some other visual identifier which would not appear in renders. It would be selectable using the near-detection and then groupable, transformable etc because it's a real point element on the canvas. The anchor tool would be useful for a few functionalities. For the connector work we would use the point to join connectors together on canvas, as custom points on shapes when grouped with them, act as flexible points where custom paths around objects are required. This offers the best combination of features while not requiring any custom attributes or elements and doesn't require a exo-canvas def addition (which would suck IMO). It's also groovy because the amount of code will be small and use lots of existing code to achieve what we want. Best Regards, Martin Owens Note: Apologies to all the wonderful responses in the thread last year, a week after my daughter was born and I fell of the productive Internet and only now is my time freeing up a bit.

3 12

Straigthening text after pdf import
by Jelle 03 Dec '12

03 Dec '12

Hello David, You're right, it involves using both split lines and remove manual kerns in that order. If you have for instance two columns of text, the import will collect it into one <text> object with several <tspan> and place every single character using a dx and dy position. To keep the whole thing in place, you need to split the lines, then remove the manual kernings. If you do the remove manual kerns first, you end up with a single column of text with tspan. The benefit is that you can edit the text more easily, but it doesn't look remotely like the pdf document. A function that would collect grouped text and place it into a single text with tspans in a similar way would be extremely useful, even if it doesn't allow for editing that well. Text search and retrieval would become a lot easier with it. I think however that a smarter algorithm that would collect characters in the same string and place them on a baseline defined by the tspan element and it's relative position to the text tag would be a giant step towards more useable PDF text import. And it seems the same goes for PS text. BTW if the pdf import comes across unknown characters, it will use that as escape codes and create a new tspan rather than using a undefined glyph to fill the hole (have that when "()" are in the original text generated from a Chinese version windows for instance. Probably some gb2312 to Unicode conversion bug.) Anyway,.. keep up the good work, typesetting hasn't been Inkscape's strong point traditionally, so any work on that is greatly appreciated. Cheers Jelle On Mon, 03 Dec 2012 10:44:31 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Split text goes the other way - it breaks strings into smaller pieces. > Maybe > you meant text -> Remove Manual Kerns? AFAIK there is no function that > merges two > <text>'s, other than by doing it manually: cutting one and pasting it > into the end > of the other. Which will generally move the second <text>. The "split > text" extension > also moves the component pieces, and does the entire <text> not just a > selected > substring, but I guess I could modify it to be better behaved. > There is another problem with some PS files - they drop all the spaces. > So that > "this is text" becomes the character set {t,h,i,s,i,s,t,e,x,t}. The > code I'm working > on will have an option to try to reinsert the spaces based on the > letter spacing. > Regards, > David Mathog > mathog@...1176... > Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

Straigthening text after pdf import
by Jelle 03 Dec '12

03 Dec '12

Hello David, You're right, it involves using both split lines and remove manual kerns in that order. If you have for instance two columns of text, the import will collect it into one <text> object with several <tspan> and place every single character using a dx and dy position. To keep the whole thing in place, you need to split the lines, then remove the manual kernings. If you do the remove manual kerns first, you end up with a single column of text with tspan. The benefit is that you can edit the text more easily, but it doesn't look remotely like the pdf document. A function that would collect grouped text and place it into a single text with tspans in a similar way would be extremely useful, even if it doesn't allow for editing that well. Text search and retrieval would become a lot easier with it. I think however that a smarter algorithm that would collect characters in the same string and place them on a baseline defined by the tspan element and it's relative position to the text tag would be a giant step towards more useable PDF text import. And it seems the same goes for PS text. BTW if the pdf import comes across unknown characters, it will use that as escape codes and create a new tspan rather than using a undefined glyph to fill the hole (have that when "()" are in the original text generated from a Chinese version windows for instance. Probably some gb2312 to Unicode conversion bug.) Anyway,.. keep up the good work, typesetting hasn't been Inkscape's strong point traditionally, so any work on that is greatly appreciated. Cheers Jelle On Mon, 03 Dec 2012 10:44:31 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Split text goes the other way - it breaks strings into smaller pieces. > Maybe > you meant text -> Remove Manual Kerns? AFAIK there is no function that > merges two > <text>'s, other than by doing it manually: cutting one and pasting it > into the end > of the other. Which will generally move the second <text>. The "split > text" extension > also moves the component pieces, and does the entire <text> not just a > selected > substring, but I guess I could modify it to be better behaved. > There is another problem with some PS files - they drop all the spaces. > So that > "this is text" becomes the character set {t,h,i,s,i,s,t,e,x,t}. The > code I'm working > on will have an option to try to reinsert the spaces based on the > letter spacing. > Regards, > David Mathog > mathog@...1176... > Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Knot Handles
by Martin Owens 03 Dec '12

03 Dec '12

Hey Gang, I'm trying to understand knots, I've introduced a bug with my changes that mean knots are created correctly, but then don't disapear when the focus changes. I can't find enough information about their internal operation to know if they handle this internally or if I should be implementing a LEAVE case in the item handle (which the code never had before, so how did it work before?) Best Regards, Martin Owens

1 1