October 2013 - Inkscape Devel

Devlibs, GTK3, latest TDM-GCC
by Johan Engelen 19 Nov '13

19 Nov '13

Hi all, To the devlibs gurus: what is the status of GTK3 devlibs and, can we try and make them compatible with the latest TDM-GCC? It'd be nice to be able to use the latest gcc so we can use more C++11 in the future. I'm not sure how much help can I can provide, but if supplied with sufficiently detailed instructions, I don't mind compiling a lot. Cheers, Johan

2 5

Re: [Inkscape-devel] Version number
by Jared Meidal 08 Nov '13

08 Nov '13

My vote is for Inkscape 5, pointing to maturity of the .4x.x line, and to demonstrate overall reliability and maturity of the application. My secondary vote, would be for Inkscape 0.91, moving toward a 1.0 release. Overall it would be great to update a features-to-version-number page to help map where we are, and where going. --Jared > I wrote that in as more a placeholder, way, way back when. At the time > we had consensus that Inkscape wasn't mature enough in terms of features > and stability to justify calling it 1.0. I wanted to keep that as a > goal in the roadmap, and to tie it to something tangible. SVG 1.0 > seemed like a logical place to put a pin in, but there wasn't a huge > amount of thought put into it. It could easily have been "Switch to > Cairo for rendering." > > 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...) > This sounds like a good approach. Might go to 0.91 just to avoid the > usual confusion people have with our 0.x0 releases (i.e. people will > call it version 0.9. > > * 0.49.0 --> Inkscape 9 (followed by Inkscape 9.1, 10.0...) > Seems like tooo big of a jup. > We also discussed date based version numbers. At the time it was quite > a fad and a lot of projects were adopting that. Seems less widely used > now, except by projects that follow strict time-based release > schedules, like distributions. > > 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. > Yep. > Bryce > > > > Just IMHO, > > > > --Jared

10 18

Gradients with objectBoundingBox coordinates not being preserved or rendered correctly
by Bryan Hoyt | Brush Technology 08 Nov '13

08 Nov '13

If I create a gradient in Inkscape, the default coordinate space is userSpaceOnUse, as opposed to objectBoundingBox (see https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/gradientUnits). This is ok, but if I edit a gradient manually (via a text editor or the XML editor) to change it to objectBoundingBox coordinates, I would like it to stay that way. objectBoundingBox gradients are very useful if you want to animate or otherwise interact with the SVG using javascript in a browser -- the gradient will move relative to the object, and you don't have to write extra complicated code to try and keep it lined up. Currently, *a)* Inkscape initially renders the gradient nodes in the correct position, but does not render the gradient colours themselves. So the object has a flat colour. *b) *As soon as I drag one of the endpoints, it reverts to userSpaceOnUse coordinates. Which means that it becomes quite difficult to edit my SVG file in Inkscape ever after! Ideally, the object would be coloured correctly, and if I move a node or endpoint, it would remain in objectBoundingBox coordinates. Better yet, there would be a way to switch to objectBoundingBox coordinates from within the GUI, to avoid having to calculate the conversion maths in the XML editor. How hard would those things be to fix? - Bryan -- Bryan Hoyt, *Software Developer* -- Brush Technology *Ph:* +64 3 741 1204 *Mobile:* +64 21 238 7955 *Web:* brush.co.nz

5 9

Lattice deformation 2 video
by Jabiertxo Arraiza Cenoz 04 Nov '13

04 Nov '13

Hi to all, here are a video with improvements in lattice deformation live effect. read credits and link to launchpad in youtube. http://www.youtube.com/watch?v=YlK9L88_tWE

2 3

clang-format
by Johan Engelen 01 Nov '13

01 Nov '13

Hi all, clang-format seems like a great tool to reformat our whole codebase once and for all, and keep it that way. I've added a configuration file "_clang-format" to trunk, hoping that others can have a look at it too and tweak the settings for our project. Can you have a look at this Krzysztof? (my bigger ambition is to run clang-format on the whole codebase after we branch-off the next release) Thanks, Johan

3 5

clipping and filters, import and export for formats other than SVG?
by mathog 30 Oct '13

30 Oct '13

SVG supports both clipping and filters. Some other formats do as well, for instance, EMF+, (although the supported filters do not match very well between SVG and EMF+). I can see how one would convert those features from other graphics formats to SVG during import (more or less). However, for output to another file type I do not see where either the clipping or filters would be passed, perhaps buried in style? I thought that maybe the clipping was applied upstream somehow, so that the driver level would just draw what was left, but could not test the idea because it seems that clipping has some problems in Trunk right now. For instance, I found this SVG example on the web: http://svg-whiz.com/svg/clipRect.svg and while it loaded into Inkscape (linux or Windows) without throwing a warning or error, and the contents show up in the XML editor, nothing is visible on the screen. That example works in 0.48.4, but not r12721. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

5 10

Re: [Inkscape-devel] clipping and filters, import and export for formats other than SVG?
by Krzysztof Kosiński 30 Oct '13

30 Oct '13

2013/10/30 mathog <mathog@...1176...>: > On 30-Oct-2013 11:51, Krzysztof Kosiński wrote: >> >> 2013/10/30 Martin Owens <doctormo@...400...>: >>> >>> I'd take our workspace at 1:1 and use that. Otherwise it's not really a >>> useful value since the svg isn't being used as a fragment. >> >> >> Perhaps we should pick some totally arbitrary default values in this >> case, such as 640x480px. > > > Arbitrary for sure, since it is not specified in the SVG. > > Use the default page size? The default page size depends on the locale, so I'd rather not use that. Regards, Krzysztof

3 2

message: 8 svg width 100%
by Jelle Mulder 30 Oct '13

30 Oct '13

Krzysztof, <svg width='100%' height='100%' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'> This actually is valid SVG and can be quite useful for web design (I would use only one direction BTW). I always found it a pity Inkscape does so little with % as part of the beauty of SVG is the use of such values for scaling of objects. I believe % are not accepted in Inkscape and setting the size of an object to 50% will just scale the object rather than make it set to 50% values. Use case for it is for web designs that align objects to a centre point, scale rects to 20% of the right edge of the screen etc. It is valid SVG, but probably a lot of work to implement. Now though I always have to handcode that kind of stuff, so it would be way cool to let Inkscape set those values. Basically all you need to know is the size of the user screen, which can't be that hard either. Think how easy it would be to use % for doing hatch patterns, using nothing but a dash array and a line in a clip area the size of the object the hatching should be in. One line, line hatch + dash array, two lines + dash array, cross hatch with patterns. It renders fine in a browser. At least Inkscape can figure out that 100% should display the document in the screen resolution in this example. Cheers, Jelle On Thu, 31 Oct 2013 00:36:14 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Message: 8 > Date: Wed, 30 Oct 2013 17:36:04 +0100 > From: Krzysztof Kosi?ski <tweenk.pl@...400...> > Subject: Re: [Inkscape-devel] clipping and filters, import and export > for formats other than SVG? > To: su_v <suv-sf@...58...> > Cc: Inkscape Devel <inkscape-devel(a)lists.sourceforge.net> > Message-ID: > <CAFLw2WRCgm0w90+gqRAjx-oc3bnw6Z-KAmatfa2Z9==BWq940Q@...401...> > Content-Type: text/plain; charset=UTF-8 > 2013/10/29 su_v <suv-sf@...58...>: >> This SVG file has width=height=100% and no viewBox attribute: >> >> <svg width='100%' height='100%' xmlns='http://www.w3.org/2000/svg' >> xmlns:xlink='http://www.w3.org/1999/xlink'> >> >> which results in a miniscule (1x1 px) document page size with current >> trunk (rev >= 12554). Other than that, the drawing content and the >> clipped objects displays correctly AFAICT. > Does anyone know what are we supposed to do in this case? I don't > think it's even valid SVG. > Regards, Krzysztof

2 1

[icons.svg]How to add/use a new icon
by Maggio Mago 30 Oct '13

30 Oct '13

Hello everyone, How to add and use a new icon in Inkscape in C/C++ according to {$prefix}/share/inkscape/icons/icons.svg ? Maybe someone has already written an article on this issue. In advance thank you

3 2

Spurious warnings
by Johan Engelen 29 Oct '13

29 Oct '13

Hi all, I've been going through a (really small) number of compile warnings and stumbled upon this one: src/2geom/generic-interval.h: In member function 'Geom::Rect Inkscape::Filters::FilterPrimitive::filter_primitive_area(const Inkscape::Filters::FilterUnits&)': src/2geom/generic-interval.h:65:9: warning: 'y' may be used uninitialized in this function [-Wuninitialized] src/display/nr-filter-primitive.cpp:146:12: note: 'y' was declared here src/2geom/generic-interval.h:65:9: warning: 'x' may be used uninitialized in this function [-Wuninitialized] src/display/nr-filter-primitive.cpp:145:12: note: 'x' was declared here (GCC 4.6.1 (tdm-1) on Windows) The warning seems bogus to me, the value is certainly correctly initialized, and I've added code to check that everything that is assigned to it is also initialized. What fixes the warning is changing the first lines of that function Geom::OptRect const fa_opt = units.get_filter_area(); if (!bb_opt || !fa_opt) { return Geom::Rect (Geom::Point(0.,0.), Geom::Point(0.,0.)); } Geom::Rect const &bb = *bb_opt; Geom::Rect const &fa = *fa_opt; to Geom::OptRect const fa_opt = units.get_filter_area(); if (!bb_opt || !fa_opt) { return Geom::Rect (Geom::Point(0.,0.), Geom::Point(0.,0.)); } Geom::Rect const &bb = *bb_opt; Geom::Rect const &fa = *units.get_filter_area(); No joke... So, in conclusion: it will be impossible to compile with -Werror for now :'(, due to spurious compiler warnings that can't be avoided without hurting the code. (another one is templated functions with a signed comparison logic, that are then instantiated with unsigned template arguments...) Disappointing :-( Johan (PS. thanks for the help in fixing this)

2 2