October 2012 - Inkscape Devel

Report from the GSOC mentor's conference
by Tavmjong Bah 24 Oct '12

24 Oct '12

Hi all, I have just gotten back from attending the Google Summer of Code (GSoc) mentor's meeting at Google's headquarters. It was quite interesting to here about other groups experiences with the program. My major conclusion from attending the conference is that Inkscape is not taking full advantage of the GSoC program. Almost everybody at the conference knew about and used Inkscape. This is in contrast to many of the other groups that I had never heard of. Given our popularity, our group of core developers seems very small. I thinks that this is perhaps why we are under-performing in GSoC; we just don't have the people to do a good job of preparing for the program. Here are some things I picked up: * Recruitment: We should be starting now! Most successful students have already had some significant experience with the software they will work on. Our two-patch rule is a good step in this direction but is probably not enough. * Application: We should have an application form with questions that test passion and competence. Here are some sample questions from other groups: - What computer do you use? - What editor do you use? - What code have you written? - Do you use IRC, mailing lists? - Do you have a mentor in mind? Have you contacted them? - Provide a time line for your work. - How well do you know Inkscape? Include a drawing you have made. - What vacations/exams will overlap with the GSOC period? Indirect questions work best. The "Why do you want to work for us?" questions aren't very useful. The application should test the ability to read and follow instructions. * Coding period: Require frequent and public discussions. Public discussions work best as then there are multiple people who can answer questions. Some groups have two mentors for each project. This is especially helpful when time-zone issues make communication difficult. Require frequent commits. It is important to gauge a student's progress as well as insure the quality of the code. A number of projects use websites that allow easy commenting on the code by reviewers: http://codereview.stackexchange.com/ github has code review built in Weekly status reports. Merge code for final pass. Be tough!! * Links to a few other projects: https://www.gnu.org/software/hurd/community/gsoc/student_application_form.h… https://drupal.org/node/59037 http://www.di.ens.fr/~baghdadi/TXT_blog/5_advices_to_get_your_proposal_acce… Tav

1 0

Compiling on Windows
by Arshdeep Singh 24 Oct '12

24 Oct '12

Hello all, Just curious about whether anyone recently setup inkscape on Windows 7 ? I am following the instructions on the wiki, to no avail. Build tool successfully builds the application but the inkscape.exe invokes nothing on being run. -- demicoder

3 2

Reverting devlibs updates
by Nicolas Dufour 22 Oct '12

22 Oct '12

Hi all, Unfortunately the recent changes in the devlibs have introduced major regressions when opening and saving files on win32. I've just reverted the changes in Inkscape revision 11820 and uncommitted the devlibs r36 (the new stable revision is thus r35). Details in https://bugs.launchpad.net/inkscape-devlibs/+bug/1069806 If someone has clues on how to solve it, it would be very helpful. Regards, -- Nicolas

1 0

Build on Windows, .exe not running
by Arshdeep Singh 22 Oct '12

22 Oct '12

I followed the instructions to build inkscape on Windows (in my case Windows 7 Home). The build process was successful.The 'inkscape' folder formed in the repo directory contains the .exe (executable) inkscape.exe, which fails to run despite the build process finishing without errors. The busy sandtimer cursor shows but no application is launched. Even the task manager does not show any process of the name inkscape during the time the sandtimer shows. Question: a.) Is it necessary to make an installer to be able to run the inkscape application ? b.)If not the above case, has anyone faced such a situation ? Thanks. -- demicoder

2 1

Powerstroke wrap-up
by Johan Engelen 21 Oct '12

21 Oct '12

Hi all, I've lost track of all the problems with powerstroke. Please send me again the bugs you have found (with a test file!) or the UI ideas we definitely need for release. I have been working on "extrapolate by arcs matching path curvature", but I think it will take me too long to make that work reliably before release. There are still too many bumps along that road... I've committed the code, but it is disabled. Thanks a bunch! Johan

7 29

GtkHandleBox deprecated
by Alex Valavanis 21 Oct '12

21 Oct '12

Hi All, The GtkHandleBox widget is deprecated since GTK+ 3.4 and will eventually be removed completely. We currently use it to provide "tear-off" toolboxes, so we'll eventually have to rework our code somehow. Some possible solutions: 1. Get rid of "tear-off" functionality completely, and just have fixed toolboxes... probably the easiest option! 2. Switch to using GDL and putting all toolboxes into a dockable dialog. 3. "Adopt" the GtkHandleBox code and maintain a fork of it (as we did with GtkRuler) 4. Something radical, new and exciting..!? In any case, this is probably not something we want to do for Inkscape 0.49 because it involves a major reworking of a prominent UI feature! Any thoughts? Alex

3 2

Convert to CMYK
by john Culleton 20 Oct '12

20 Oct '12

There are wiki and other instructions about using Scribus to convert an Inkscape doc to CMYK by importing the svg file into Scribus. Has this process changed for 48.2 Inkscape? John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

2 1

[Win32 devlibs] gtkmm stack update
by Nicolas Dufour 19 Oct '12

19 Oct '12

Hi, I've just updated the gtkmm stack in the win32 devlibs with the following libs: * pangomm-2.28.4 * glibmm-2.28.2 * atkmm-2.22.6 * gtkmm-2.24.2 Additionally, the build.xml file needed to be updated so that Inkscape can compile with gtkmm 2.24. Windows devs, don't forget to update both the trunk (revision 11810) AND the devlibs (revision 36)! Regards, -- Nicolas

1 0

Narrow/Condensed fonts, font-stretch, any real utility?
by mathog 18 Oct '12

18 Oct '12

SVG style has a font-stretch parameter, however, as near as I can tell it does not do anything. Set it to Normal or Condensed and nothing changes, for either "Arial" or "Arial Narrow". When a condensed font (Arial Narrow) is specified font-stretch says "Normal" even though the font used is actually condensed. Just to make life really miserable, FontConfig matches "Arial Narrow" on linux to "DejaSans", it only gives "DejaVuSansCondensed" if the font name used is "Arial Narrow:width=75" or "Arial:width=75". Near as I can tell Inkscape does not pick up from the font name alone that "Arial Narrow" is a condensed font. It is possible to force the issue by editing the SVG to font-family:Arial Narrow:width=75; in style, in which font-stretch will be set to Condensed. However on linux it is of little use because both of the Deja fonts are so much wider than "Arial Narrow" that the rendered text invariably overruns whatever text follows it. (This was with separate <text> sections, imported from an EMF file. If the pieces are put together with sequential <tspan>s then the text shifts around, but it does not overlap.) Copying the Arial Narrow file ARIALN.TTF from a Windows system to the linux font directory let Inkscape render text in that font at the proper size, but this isn't a general solution since it isn't a "free" font. Other SVG viewers (ie, Firefox) also seem to be mostly "miss" when it comes to rendering condensed/font-stretch SVG. What's the consensus - is this style parameter supposed to do more, in particular, emulate somehow a narrow or wide font from the base font? Is it best to just avoid condensed fonts altogether? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 4

Re: [Inkscape-devel] Powerstroke wrap-up
by Carlos Lopez Gonzalez 18 Oct '12

18 Oct '12

On Date: Wed, 17 Oct 2012 09:53:59 +0200 Jasper van de Gronde wrote: Now there's the real problem. I even asked a question related to this on >math.stackexchange, as it was driving me crazy. Essentially the problem >is that curves with zero-length handles do tend to have infinite >curvature at the endpoint(s) with a zero-length handle, but the >curvature grows very quickly over a very short length of the segment. So >visually, you hardly see anything. Put differently, the slope has a >non-zero derivative at the endpoint, while the norm of the derivative is >zero, so the slope changes by some finite amount over an infinitesimally >small length, leading to infinite curvature, but a finite (and typically >quite small) change in slope. > >So essentially you have the extremely weird situation where a slope that >looks very smooth and (almost) straight, can actually have infinite >curvature at its endpoints (I think in principle this can also happen >elsewhere, but that's less of a problem in this context). > >The problem with taking an approximation of the path is that I'm not >entirely sure how "stable" this is. So would taking a slightly different >approximation give you a completely different curvature, or is there >some "natural" curvature that can be defined? In fact, I've just tried >fitting a quadratic curve through the first 1/3 of a B?zier curve with a >zero-length handle (at the first node), and I can get a huge range of >curvatures, without a big difference in fitting quality. > >Of course this can always be "solved" by simply prescribing an >approximation method. One thing you could try is to basically take a >finite difference approximation to the curvature over a predefined range >of the curve (if the SVG spec would do something like this, the range >would probably have to be specified in the spec). For example, take the >angle of the curve at t=0 and t=1/3, take the difference and divide by >the arc-length. You could experiment with the range, or even try to do a >"higher order" approximation. I'm not entirely sure what this would >accomplish though. > >I've not read the full conversation but in Synfig, when it is needed to evaluate the tangent (and by perpendicularity the normal) at the start or end point of a bezier with a tangent small than a certain small length (zero-length tangent condition) we don't evaluate the derivative of the bezier exactly on the start or end of the bezier but in a fixed small earlier or later bezier index. We use 0.025 as that value. See CUPS_TANGENT_ADJUST usage in the code for the outline layer: https://github.com/synfig/synfig/blob/master/synfig-core/src/modules/mod_ge… It works reasonably well in most of the cases. I hope it helps. Cheers Carlos

1 0