- Inkscape Devel - Inkscape Mailman

Post-merge EMF work
by Krzysztof Kosiński 24 Oct '13

24 Oct '13

The cross-platform EMF/WMF support that was merged recently needs some cleanups. 1. libunicode-convert. I don't exactly see why this particular set of functions was separated into a mini-library; I would expect that to be part of libuemf. It is also somewhat misleadingly named. I would name these files e.g. ms-symbol-font-utils.[hc]. 2. I think libuemf should be in a separate directory, like libcola, not tucked away in src/extension/internal. 3. The new code should be made to conform to the Inkscape coding style. In most places it's a matter of running the code through astyle to fix the spacing, but in some cases manual adjustments are needed. For example, the function names in libunicode-convert are utterly non-descriptive ('isNon()' and 'CanUTN()' are not good names for library functions), and the return statements in src/extension/emf-inout.cpp incorrectly use parentheses around return values. http://staging.inkscape.org/en/develop/coding-style/ 4. Some functions, such as msdepua(), have a rather strange mode of operation, modifying the string in place. The interface of those should be changed so that they are easier to use. Regards, Krzysztof

4 5

OS X Mavericks and C++
by David Evans 24 Oct '13

24 Oct '13

OS X Mavericks (10.9) is released today (Free upgrade in App Store.) Please see the following email to MacPorts developers today concerning C++ compatibility and need to build with clang++. Note that inkscape (0.48.4) is a current issue because it doesn't build with clang++. I'm hoping that backporting the current upstream patches concerning clang compatibility for this branch will solve the problem. Dave Evans devans@...2376...

3 4

Re: [Inkscape-devel] Version number
by Jared Meidal 22 Oct '13

22 Oct '13

I've seen documentation of roadmaps and releases refer to the version numbering as possibly up for consideration of revision: "Evaluate changing the numbering scheme to a date-based one, or setting more realistic goals for major (1.0, 2.0) releases" <http://wiki.inkscape.org/wiki/index.php/Roadmap> I can see the next major release after 0.48.x as a candidate for change as the "9'er" may lend itself toward a new scheme. * 0.49.0 --> 0.90.0 (followed by 1.0, 1.1, 2.0...) * 0.49.0 --> Inkscape 9 (followed by Inkscape 9.1, 10.0...) There have been a lot of excellent developments to be release in the next release, including C++, cairo, alignment/distribution along with new possible builds on win64-bit (Partha's help), and native Mac OS X (some almost-ready builds are out there). If these all reach maturity for the release the new builds are providing an increase audience and userbase. A changing version numbering scheme could reflect the developers' acknowledgement of this and demonstrate the activity of the software project. Just IMHO, --Jared

3 2

Big epsilon in 2geom/coord.h
by Markus Engel 22 Oct '13

22 Oct '13

Hi, in 2geom/coord.h there is an epsilon defined as 1e-5. This is used in many ways, e. g. in Geom::are_near, . Now I'm wondering why this value is that big. This causes at least one problem, see the last two comments here: https://bugs.launchpad.net/inkscape/+bug/1231990 Is there any reason why "1e-18" has been commented out? Regards, Markus

2 1

how to save last tool selection?
by Yale Zhang 21 Oct '13

21 Oct '13

Hello. Does anyone know how I can save and restore the last tool selection on startup? You might ask why bother, but for my use case, I want Inkscape to always start out with the eraser tool selected when I'm using the eraser end of my pen (event source GDK_SOURCE_ERASER), to save me from having to tap the erase tool with the eraser end of the pen. Is there any reason why this isn't the default behavior? If saving the tool selection isn't implemented, can someone show how to programatically change the tool selection for the eraser to be the eraser? Appreciate your help, Yale

3 6

mouse and tablet touch input lose focus after using Wacom pen
by Yale Zhang 21 Oct '13

21 Oct '13

Hello. I think I've found another bug in either Inkscape or GTK: I have a Wacom Intuos 5 and whenever I use my pen, I can no longer use the mouse wheel or 2 finger touch to zoom in and out. It seems the problem is the window loses focus after using the pen. Has anyone else noticed this problem or can propose where to trace to fix the problem? I'm using the latest trunk version and Windows 8.1, but this problem also exists in 48.4. Thanks for helping, Yale

1 0

Bug Counts on Website
by Martin Owens 19 Oct '13

19 Oct '13

Hey Devs, I've got the django-cms-launchpad plugin working. The first integration is pulling in bug counts for certain bug queries. You can see an examples on this page: http://staging.inkscape.org/en/develop/ What I've done is added a launchpad bug count widget when editing the CMS. You can add them too. Just edit the page, edit the text widget and add a bug count as you might an image. It links back to launchpad if you click on it. The widget has options for what tags, milestones and other items you may want to search for. Not all fields are there yet, but I'm open to requests from our bug managers about what's important to get an over view of. The low/medium/high counts are for colouring. Below low it's grey/white, low>yellow>medium>orange>high>red and this can be used to give us a quick visual on whatever we want to track. Next feature for the django-cms-launchpad plugin is to format our blueprints into a roadmap page. This won't be a widget, but a page and targeted blueprints will be used to generate the list. Martin,

4 8

Version number
by Alex Valavanis 18 Oct '13

18 Oct '13

Hello All, A while ago, there was a discussion about the numbering of the next release. "0.49" doesn't exactly instill confidence in the completeness of the application. On the other hand, "1.0" could be misleading with respect to svg compliance. Other ideas were to use a date-based system "2013.10" or something. Any thoughts? AV

4 9

Only Three Blockers Left!
by Martin Owens 18 Oct '13

18 Oct '13

Hey Devs, This is the bi-weekly report on our release-hope goal: Blockers: 3 * High #1163449 Imported bitmap appear blurry when zoomed in * Medium #953992 Imported pattern fill disappers while transforming * Medium #1005892 Patterns applied to text objects are blurred If you can fix one of these, please do. We can use all the help to debug, locate the errors causing these regressions and fix them. These blockers are high priority for our project goals. We have 49 targeted bugs for the release: http://tiny.cc/q3y34w If you see something that you could easily fix, then this is a great way to make the next inkscape version better. I want to make a special mention of novalis' flowText fallback branch. It's going through review right now but I want to give my biggest amazed thanks to Novalis for tacking this difficult and long standing problem. See the review here: https://code.launchpad.net/~novalis/inkscape/fix-167335/+merge/190297 Keep up the good work everyone! Exciting to see so much work get done. Best Regards, Martin Owens

4 6

Re: [Inkscape-devel] W3C SVG test suite and trunk
by Guiu Rocafort 17 Oct '13

17 Oct '13

Hi. Sorry, my fault. Actually I thought i was sending the messages to the mailing list, but by mistake i only sent them to martin and alex. I send the messages again. ============ Email 1 ================== 2013/10/10 Alex Valavanis <valavanisalex@...400...>: > Well, I guess the easiest thing would be to organise the svg input > files for the rendering tests into two separate subfolders in > known-pass/testcases and known-fail/testcases. We can then just tell > the test runner to look in the appropriate folder: > > # cat run-svg-tests-good > runtests.py --directory=known-pass > > # cat run-svg-tests-bad > runtests.py --directory=known-fail > Ok, if I understood correctly, the idea here is to have known pass tests, and known fail tests. All test with the respective pass/fail test. If a known pass test changes from the reference image then we can assume we have a regression. If a known fail test changes from the reference we might have solved the problem, but since we can't automatically decide if it is already solved, we would need to check manually and add it to the known pass test if required. That sounds to me like a good compromise between automation and some manual work. The regressions would be detected automatically but the improvements would need to be checked manually. Thoughts about this ? ============ Email 2 ================== 2013/10/10 Martin Owens <doctormo@...400...>: > On Thu, 2013-10-10 at 16:14 +0100, Alex Valavanis wrote: >> two separate executable scripts > > Not yet. And while the python is pretty hairy (needs some code review) > it should be possible to make it do what you want without too many > issues. > > Guiu, Tav; what do you think? Would it be easy enough to modify and > would you like to patch it or should I? Yes, I think I could be able to modify the code to fit the current code to be added to the testings. I sent a message trying to shade some light on what needs to be done and trying to define the problem exactly. If we're happy with what I propose, I can start making the changes soon. There is some hairy code and rewriting some can do very good in the readibility of the code. Guiu > Martin, ========= Message 3 ============== Ok, sorry for sending that much messages, I just wanted to make a little summary about the work that would be needed. 1. Get the SVG 1.1 Second edition test files and extract the text. Jasper, in the link [1] you sent the files are from the Second edition of the test suite or the first one ? Are they up to date ? btw, I do actually think that removing the text is good, because if there is a problem with the text rendering code, it would affect a lot of tests. Removing the text from the tests we can isolate better what we are testing with each file. 2. Then, we would need to manually separate the tests in pass/fail. 3. Implement the code as explained in the message I sent before. Then add it to the tests in the current inkscape trunk to be executed every time someone makes a commit. 4. Then a way to make this information public would need to be done. But we can discuss this while the first points are made. [1] https://svn.code.sf.net/p/inkscape/code/gsoc-testsuite/tester/testcases/svg… If we're happy with that and we agree that this is a good solution, I can start working on this soon. Cheers Guiu Rocafort I'm sorry about that Guiu 2013/10/11 Martin Owens <doctormo@...400...>: > On Fri, 2013-10-11 at 01:01 +0200, Guiu Rocafort wrote: >> If we're happy with that and we agree that this is a good solution, I >> can start working on this soon. > > You need to send this information to the devel mailing list. I recommend > compiling your two emails into one and replying to all as it fits to > have this sent to everyone. > > Martin, > -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

5 9