- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Inkscape 0.48.5 Released
by Jon A. Cruz 09 Sep '14

09 Sep '14

On Jul 19, 2014 9:20 AM, Partha Bagchi <partha1b@...400...> wrote: > > I would think that any build (Mac/Windows/Linux) uses external libraries since Inkscape depends on gtk+ and friends. Only difference, on Linux it comes with the OS and so the user does not have to do the legwork while for the other 2 OSes, one has to build the dependencies. > Kinda, sorta on Mac. Some libraries do come with the system but may be optionally included with the distributed program. Others require a developer to explicitly include them. Also, the standard for applications on OSX is for each app to include its own copies of external libs, but infernally as part of the application bundle itself. For the end user on a Mac no extra legwork is needed as all external libs are internal in the "application binary". It's also common to end up with multiple app versions side-by-side by simply changing the name on one app package before copying the next into the Applications folder.

1 0

Please check r13544 or later for problems at unit change
by mathog 08 Sep '14

08 Sep '14

One of the changes I introduced at revision 13544 was a modification of scaleChildItemsRec() so that it no longer recurses into groups to apply scaling changes associated with a change of units. This was breaking EMF import of clipped objects. That happened because during the recursion the coordinates of the clipped objects were changed directly, not by a transform. Since the clipping object (in defs) was not similarly scaled this broke the clip. See for instance: https://bugs.launchpad.net/inkscape/+bug/1348417 In the changed version the scaling change is applied as a transform at the group level, and all the coordinates within that group are not directly modified, so the clipping object and clipped objects are still at the same scale and they continue to work together. Since EMF import of clipped objects always works like (pseudocode): <g (clip reference)> clipped objects </g> applying the transform at the group level fixes the problem in that context. I suspect that scaleChildItemsRec() is still going to cause problems for any SVG object other than a group that looks something like (pseudocode): <(not a group) (a clip or mask ref) x=100 y=100 (other stuff) > when the document units are changed because it will change the 100's to something else, and not modify the referenced clipping object. I have not confirmed this though. In any case, would the people who worked on document units please see if my changes at revision 13544 break anything when the document units are changed? I did some preliminary testing and it looked OK, but I don't really know what test cases to use to explore all the edge cases. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

5 13

Re: [Inkscape-devel] Please check r13544 or later for problems at unit change
by mathog 08 Sep '14

08 Sep '14

On 07-Sep-2014 02:45, alvinpenner wrote: > two comments: the pre-existing bug has been reported at Bug 307656 and > Bug > 1366434. It appears to be related specifically to the rectangle tool > F4. > However there are two new regressions which are not related to F4. > > First one: rev 13544 has broken one of the fixes for Bug 1240455, > comment > 24: > https://bugs.launchpad.net/inkscape/+bug/1240455/comments/24 > > using Extensions->Render->Grids->Grid and using the default spacing of > 10 > px. > - case 1 : open Inkscape with default units of px, draw default Grid > - case 2 : open Inkscape, change units to mm, draw default Grid > > the expectation is that these two grids will look the same relative to > the > page size. Rev 13534 shows the expected behavior, rev 13546 does not. > > Second one: > - open Inkscape, draw two objects, a rectangle and a star, or ellipse > - select both of them > - change document units > - the expectation is that the shapes should not change size > - Rev 13534 shows the expected behavior, rev 13546 does not. I will revert that change in a little bit. Actually I'm going to add a parameter to the call, so that it can work one way (so that it works like it does now) for a call from EMF import, and as it did before when called from elsewhere (only one other place that I know of.) This is a short term hack until the actual problem is sorted. And I think the actual problem is in those parts of Inkscape which fail when the scale is applied to a top group. It is perfectly valid SVG to do: <g (scale to whatever conversion one wants)> (bunch of objects in completely arbitrary units. </g> All transform operations up the stack must be applied to an object. If some part of Inkscape only shows units properly when the top level scale is not present, then it is not correctly applying those transforms. How is it not that part of Inkscape that is broken? Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 1

Old Website will be Decommissioned
by Martin Owens 06 Sep '14

06 Sep '14

Dear Inkscape Devels, This is a warning that the old inkscape website currently at dev.inkscape.org will be decommissioned by November. Please make sure that any important information has been moved to the new django-cms website by then and let me know as soon as possible if you need help making this happen. Best Regards, Martin Owens

4 3

VALS Semester of Code
by Tavmjong Bah 06 Sep '14

06 Sep '14

Hi, Do we want to participate in "VALS Semester of Code"? http://semesterofcode.com/?p=22 We should be able to come up with one or two good ideas. Deadline is Sept 12th. Tav

2 2

Website Upgrade (1.2) Tonight
by Martin Owens 06 Sep '14

06 Sep '14

Dear Develoeprs, The inkscape website (inkscape.org) may be unavailable from 1am UTC (9pm EST) for a period lasting about half an hour. This upgrade will take us from django 1.5 to 1.6.5, django-cms from 1.4.2 to 3.0, haystack from 2.0 to 2.2, Whoosh 2.4 to 2.6 and finally inkscape-web from 1.1 to 1.2. The upgrade process involves a bunch of manual steps to the database and command line and I hope these will be completed shortly after upgrading the code. My thanks to Hachmann, jazzynico, Brynn and others in helping prepare this release. After the upgrade, content will be uploadable to inkscape.org and you may wish to populate your user account with some of your svg files to get the ball rolling. Also available will be the ability to upload Addon tarballs and inkscape release builds (exe files/tarballs etc) which can be used instead of sourceforge or your friendly file dumping service. Please see me directly if you need an increased quota to upload large release files. I'm going to start everyone off with 10MB quota to start gently. The idea for most users is to upload svg files which aren't that big. But we can increase this for different auth groups as needed. Any questions, reply here. Best Regards, Martin Owens

4 6

LPE Powerstroke
by Johan Engelen 05 Sep '14

05 Sep '14

Hi all, Release is getting closer, and we need to decide what parts of Powerstroke we are going to release. After release, it will be very annoying for users if we change the output of Powerstroke for certain input parameters. So we have to avoid having to do that. Ideas: - remove reflection-based extrapolated miters (my original extrapolation), add the arc extrapolation miter - remove CubicBezierFit and CubicBezierJohan interpolators, add Catmull-Rom interpolator thanks for input. I hope to work on this soon. -Johan

3 13

Re: [Inkscape-devel] LPE Powerstroke
by Johan Engelen 05 Sep '14

05 Sep '14

On 4-9-2014 3:52, Liam White wrote: > On Wed, Sep 3, 2014 at 5:36 PM, Johan Engelen > <jbc.engelen@...2592... <mailto:jbc.engelen@...2592...>> wrote: > > Ideas: > - remove reflection-based extrapolated miters (my original > extrapolation), add the arc extrapolation miter > > I like this, the arc extrapolation miter is stable and produces > consistently better results than the reflection-based miter. I have committed the change that enables Extrapolated Arc (used to be only available with specialized build) and removes Extrapolated (mirroring) from the UI. The code to deal with the old extrapolation setting still works, for people that use it in their files. I am not sure if we should keep that code around or not. It won't hurt too much for now, but may become a maintenance burden. (and I don't like having such undocumented features) The arc extrapolation definitely has issues, and needs to be improved (I feel). cheers, Johan

1 0

Report from the London SVG WG Face-to-Face meeting.
by Tavmjong Bah 05 Sep '14

05 Sep '14

Hi, I've just posted a blog with a report about the SVG Working Group's recent face-to-face meeting. You can find it at: http://tavmjong.free.fr/blog/?p=1100 Thanks to the Inkscape board for helping to fund my participation. Tav

1 0

Gtk+ 3 build bit-rot alert!
by Alex Valavanis 05 Sep '14

05 Sep '14

Hello All, I thought I'd quickly check how we're doing with the Gtk+ 3 build in Ubuntu Utopic, and was unpleasantly surprised to see that: (a) A tonne more symbols that have been deprecated in Gtk+ 3.10 (principally, GtkAction) (b) We have a few regressions, and have resumed use of some deprecated symbols that we had previously replaced. (e.g., GtkHBox) I have updated bug #1016020 with the latest build log (20k lines caused by deprecation warnings!!) and summarised the failures in the description. Obviously, (a) isn't our fault, but we should try to regain the progress we had made! (b) is more of a concern, since we're actually moving backwards! Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0? In the meantime, can I please request that from now on, everyone runs a strict build with both Gtk+ 2 and Gtk+ 3 before merging in any new features, so that we can ensure that we're not introducing any new warnings? Thanks, AV [1] https://bugs.launchpad.net/inkscape/+bug/1016020

7 13