May 2013 - Inkscape Devel - Inkscape Mailman

[SVG WG] Variable width strokes
by Tavmjong Bah 17 May '13

17 May '13

Hi Johan and others, The SVG Working Group discussed variable width strokes last night. A number of questions came about how it should be implemented in SVG. As we have this implemented via the Power Stroke (PS) LPE it would be interesting to get some feedback from Johan and others about these topics: 1. How should the position of the points where the widths are defined be described along the path? PS uses a real number where the integer part gives the node (numbered from the start of the path) and the fractional part the fractional distance between that node and the next node. The WG seems to favor defining the position using a property via the distance along the path defined either as a percentage of the total length or in absolute units. The argument is that then the same property could be assigned using CSS to multiple paths (e.g. a large number of lines that represent hair). On the other hand, having node based positioning would allow a use as shown in: https://people.mozilla.com/~bbirtles/variable-width-stroke/variable-width-s… 2. How should the widths be defined? PS uses absolute user units. The WG seems to favor using a percentage of the stroke width. This would allow quick adjustment of the whole path thickness. 3. Should the widths be symmetric or asymmetric about the path? PS uses symmetric widths. The WG wants to eventually allow asymmetric strokes but maybe not at the time. 4. Should negative numbers be allowed? PS allows negative numbers. The WG seems to favor allowing negative strokes if asymmetric strokes are allowed. 5. How should smoothing be done? PS provides four different algorithms. The WG seems to favor for the moment one smoothing algorithm (Catmull-Rom?) with maybe a linear smoothing. There was some discussion of allowing the algorithm to change along the path. 6. Questions about end-cap and line-join: PS has discontinuities with the various end-caps. Illustrator has continuous edges (at least with round end-caps). Tav Discussion on www-svg: http://lists.w3.org/Archives/Public/www-svg/2013May/0002.html Minutes of last nights meeting: http://www.w3.org/2013/05/09-svg-minutes.html Illustrator end-caps: http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0101.html

8 14

manage
by Martin Owens 16 May '13

16 May '13

What is the difference between manage and Gtk::manage ? ui/dialog/document-properties.cpp:290 Gtk::HBox *space = manage (new Gtk::HBox); ui/dialog/document-properties.cpp:95 _page_page(Gtk::manage(new UI::Widget::NotebookPage(1, 1, true, true))), Use of manage in my own code produces ‘manage’ was not declared in this scope even when every head has been included from the dp code. very odd. I'm also having trouble with ButtonBox: error: no matching function for call to ‘Gtk::ButtonBox::ButtonBox()’ even with include gtkmm/buttonbox.h What is going on? Martin

2 2

Requesting an account for http://wiki.inkscape.org/wiki/index.php/Inkscape
by Shlomi Fish 15 May '13

15 May '13

Hi all, I would like to request an account for the Inkscape wiki: http://wiki.inkscape.org/wiki/index.php/Inkscape I want the username of "Shlomif" like in http://en.wikipedia.org/wiki/User:Shlomif . Some stuff about me: * http://www.shlomifish.org/ - home page. * http://www.shlomifish.org/open-source/ - contributions to open source software. * http://www.shlomifish.org/art/ - some art I created in Inkscape and other programs. ---- The reason why I'd like the account is to fix typos as I run into them like in: [IRC] <rindolf> Hi all. <rindolf> Typo: http://wiki.inkscape.org/wiki/index.php/Python_modules_for_extensions#cubic… - "looses" here should be "loses". <rindolf> Hi all. How do I register? http://wiki.inkscape.org/wiki/index.php?title=Special:UserLogin&returnto=Py… ? <christoffer> rindolf thanks I have fixed the typo <rindolf> christoffer: thanks, and you're welcome. [/IRC] Thanks and regards, Shlomi Fish -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ "Star Trek: We, the Living Dead" - http://shlom.in/st-wtld There is no IGLU cabal! The former cabalists are trying to prove the correctness of a program that proves the correctness of proofs of other programs. Please reply to list if it's a mailing list post - http://shlom.in/reply .

1 0

sp-color-icc-selector.cpp
by Arshdeep Singh 14 May '13

14 May '13

Hello devs, I want to divert your attention to the function void getThings( cmsUInt32Number space, gchar const**& namers, gchar const**& tippies, guint const*& scalies ) { {_("Cyan"), _("Magenta"), _("Yellow"), _("Black"), "", ""}, -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

1 1

Re: [Inkscape-devel] Inkscape-devel Digest, Vol 84, Issue 10
by Carlos Lopez Gonzalez 13 May '13

13 May '13

Hi! Maybe you find interesting how Synfig implements the variable width along a path. Initially Synfig tied the width controls to the stroke points so you can vary the width from control point to control point of the stroke. This is useful in many cases but produces problems for those cases where the stroke has many points and the wanted width variation is smooth from the start of the stroke to the end. Also, when the number of control points is small and you want to have many control widths you become forced to add more unwanted control points to add variable width there. So we came in with the Advanced Outline: http://wiki.synfig.org/wiki/Advanced_Outline_Layer The advanced outline responds to those questions this way: 1. How should the position of the points where the widths are defined be described along the path? It has two options. a) Homogeneous: position of the width control is total length stroke based. b) Non Homogeneous: position of the width control is based on the number of beziers and inside each bezier it is length based. So for three beziers (4 points if the stroke is open) a position of 0.5 means the middle length of the second bezier. But for four beziers (5 points if the stroke is open) a position of 0.5 means coincidence with the third control point of the stroke (regardless the length of each bezier) 2. How should the widths be defined? We use a multiplier of the global width of the stroke. A value of 1.0 (neutral multiplier) will use the global width of the stroke. Negative values are allowed. 3. Should the widths be symmetric or asymmetric about the path? We use symmetric. It is easy to extend to asymmetric. 4. Should negative numbers be allowed? Yes 5. How should smoothing be done? We use a 5th degree spline smooth function in linear combination with a linear interpolation. An extra parameter (smoothness) allows to change between full smooth to linear. Details here: https://github.com/synfig/synfig/blob/master/synfig-core/src/synfig/valueno… 6. Questions about end-cap and line-join We have discontinuities in the tangent depending on the interpolation smoothness value. When interpolation is full smooth its tangent is continuous. When interpolation is linear, tangent is not continuous. One latest addition non mentioned in the wiki yet, is the inclusion of a internal parameter of the width control: lower and upper boundaries. Those values (default lower=0.0 and default upper=1.0) defines how is the width control placed along the stroke. This solution was applied when we found that the width control points moved when you extend a stroke in drawing mode. Extending the stroke implies in the worst case to increase the number of bezier points and/or the overall length of the stroke. In those cases it is impossible to keep the width control points in place, so we added the lower and upper boundaries to adjust those values when the stroke is extended to keep the width control points in place form the point of view of the old stroke (before extend). So when you extend a stroke, the width control points boundaries are modified from the defaults to the calculated values to keep them in place. For example, one width control point that is placed at a position of 0.5 from the point of view of the original stroke (at its middle of a 0.0 to 1.0 boundaires), when the stroke length is doubled, the width control point position doesn't change (it remains to be 0.5) but the boundaries goes from (0.0, 1.0) to (0.0, 2.0). This is very important when you deal with device inputs where the user doesn't create the stroke in one time, but in several and consecutive hand drawn strokes that are joined together in a single object. Maybe you wonder why do we want to have a single object after the extension of the stroke: keeping one single object allows to animate the width control position along all the extended stroke without troubles, and at the same time it keeps the width control position in place after extend. Finally, Advanced Outlines supports dashes with custom tips for each side of the dash segment and variable width within the dash segment length. I hope those comments helps you to decide about Powerstroke and to give suggestions to SVG Working Group. Cheers! >________________________________ >Date: Fri, 10 May 2013 07:55:03 +0200 >From: Tavmjong Bah <tavmjong@...8...> >Subject: [Inkscape-devel] [SVG WG] Variable width strokes >To: inkscape-devel(a)lists.sourceforge.net >Message-ID: <1368165303.2239.145.camel@...16...> >Content-Type: text/plain; charset="UTF-8" > > >Hi Johan and others, > >The SVG Working Group discussed variable width strokes last night. A >number of questions came about how it should be implemented in SVG. As >we have this implemented via the Power Stroke (PS) LPE it would be >interesting to get some feedback from Johan and others about these >topics: > > >1. How should the position of the points where the widths are defined be >described along the path? > > PS uses a real number where the integer part gives the node (numbered >from the start of the path) and the fractional part the fractional >distance between that node and the next node. > > The WG seems to favor defining the position using a property via the >distance along the path defined either as a percentage of the total >length or in absolute units. The argument is that then the same property >could be assigned using CSS to multiple paths (e.g. a large number of >lines that represent hair). On the other hand, having node based >positioning would allow a use as shown in: > >https://people.mozilla.com/~bbirtles/variable-width-stroke/variable-width-s… > >2. How should the widths be defined? > > PS uses absolute user units. The WG seems to favor using a percentage >of the stroke width. This would allow quick adjustment of the whole path >thickness. > >3. Should the widths be symmetric or asymmetric about the path? > > PS uses symmetric widths. The WG wants to eventually allow asymmetric >strokes but maybe not at the time. > >4. Should negative numbers be allowed? > > PS allows negative numbers. The WG seems to favor allowing negative >strokes if asymmetric strokes are allowed. > >5. How should smoothing be done? > > PS provides four different algorithms. The WG seems to favor for the >moment one smoothing algorithm (Catmull-Rom?) with maybe a linear >smoothing. There was some discussion of allowing the algorithm to change >along the path. > >6. Questions about end-cap and line-join: > > PS has discontinuities with the various end-caps. Illustrator has >continuous edges (at least with round end-caps). > >Tav > > >Discussion on www-svg: > >http://lists.w3.org/Archives/Public/www-svg/2013May/0002.html > >Minutes of last nights meeting: >http://www.w3.org/2013/05/09-svg-minutes.html > >Illustrator end-caps: >http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0101.html > >

1 1

Expand a Widget Gtk2 and Gtk3
by Martin Owens 12 May '13

12 May '13

Hey guys, I've been struggling with getting my designed UI into code and I need some help. I have a Gtk::Toolbar with a few buttons a space widget and then a few more buttons. The goal is to set h_expand on the space widget in Gtk2 and push the two sets of buttons to either side. The code for Gtk3 is fairly strait forward but C++ isn't letting me call child_set_property and set_expand doesn't do anything; so I'm stuck. Code: http://paste.ubuntu.com/5655252/ P.S. I'm used to using glade, do we not use it because it's a bad dep or because inkscape was made before glade existed? Thanks for your help. Best Regards, Martin Owens

3 5

Canonprinter Debian 7 and Inkscape
by Axel Richter 11 May '13

11 May '13

Hey devs, how can i print my art with my canon out? Nothing go when i press the printerbutton. please help me thanks Axel Richter

1 0

Re: [Inkscape-devel] Something special about Cairo glyph draws?
by Krzysztof Kosiński 10 May '13

10 May '13

2013/5/8 mathog <mathog@...1176...>: > Hi, > > One more question regarding cairo drawing within inkscape. I have most of > the > text_decoration for CSS 2 and CSS 3 implemented (for drawing, assuming it is > already > in the SVG; dotted, dashed, and wavy are only represented with more lines > for the moment, > see attachment) but cannot get the text_decoration_color field to "take". > The color data > gets all the way to drawing_text.cpp, where the decoration render code does > this: > > ct.save(); > > // The next call is SUPPOSED to change the pen color - it does not > ct.setSource( > _nrstyle.text_decoration_color.color.v.c[0], > _nrstyle.text_decoration_color.color.v.c[1], > _nrstyle.text_decoration_color.color.v.c[2], > 1.0 > ); > std::cout << "DEBUG RGB {" > << _nrstyle.text_decoration_color.color.v.c[0] << "," > << _nrstyle.text_decoration_color.color.v.c[1] << "," > << _nrstyle.text_decoration_color.color.v.c[2] << "}" > <<std::endl; > > // code that draws underline, strike-through etc. here > > ct.restore(); > > > The output of the program shows: > > ... > DEBUG RGB {0,0,0} > DEBUG RGB {0,0,0} > DEBUG RGB {0.25098,0.878431,0.815686} > DEBUG RGB {0.25098,0.878431,0.815686} > DEBUG RGB {1,0.647059,0} > DEBUG RGB {1,0.647059,0} > DEBUG RGB {0,0.501961,0} > DEBUG RGB {1,0,0} > DEBUG RGB {0,0,1} > ... > > which looks to me like the colors are OK, but on the screen all of the lines > are the same color as the text. The > line draws are between the save and restore too, so that part is working > properly, just not the change in color. > > Any idea what is wrong with this approach? Cairo will only actually draw the pixels once you call cairo_stroke or cairo_fill. Before then, the target surface is not modified - only the context's path information is. If the decoration is a different color, you need to call this operator twice - once for text and the second time for the decoration. One more remark; I don't think implementing this functionality "manually" is the right approach. Pango, the text layout library we're using, has built-in support for decorations, but for historical reasons we are not using the layouts generated by Pango. The proper way to add these features would be to pass along the Pango layout down to the display tree level and then use Pango-Cairo to display it. This would have some additional benefits, e.g. we could configure hinting and antialiasing properties for the displayed text. https://developer.gnome.org/pango/stable/PangoMarkupFormat.html https://developer.gnome.org/pango/unstable/pango-Cairo-Rendering.html Regards, Krzysztof

1 0

Patch for Bug #1060837
by Arshdeep Singh 10 May '13

10 May '13

Dear devs, Please test my patch. https://bugs.launchpad.net/inkscape/+bug/1060837 I suggest an improvement where scales can be accommodated (like they have been for CMYK in the patch ) for different Spaces as well. the 'getThings' function fetches the requisite the data. We can add scales information pertaining to these for every space. -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

1 0

Seeking ideas on layer handling with symbols
by Sebastian Götte 08 May '13

08 May '13

Hi, I'm currently working on a GSoC proposal to add PCB layout and schematics editing capabilities to Inkscape (it's not as hard as it sounds). In a PCB layout, you have a number of (physically stacked) layers (one copper layer on each side of the board, possibly multiple copper layers *inside* the board, green solder mask on both sides on top of the copper layers and white print on top of the solder mask for markings etc.). I'm currently unsure on how to map these layers to SVG. It appears obvious to map these to Inkscape layers/SVG groups. This does not work too well however, since all components on the board span multiple layers (pads for the pins on the copper layer, cut-outs for the pads on the solder mask and a package outline and part id/number on the silkscreen). If a component is moved, all parts of it (on any layers) need to be moved simultaneously, and in fact, normally it does not make sense to even select the parts of a component individually. My problem is that this would essentially require cross-group groups, i.e. groups whose elements can be elements of other groups not part of the group, which clashes with XML's tree structure. Currently, I have two and a half ideas on how to address this issue: 1) I implement PCB layers as something different to Inkscape's layers that is just denoted by an object property (I don't like this). This attribute would be pretty similar to the z-order attribute that will be include in SVG 2. 2) I find some way of "linking" multiple groups on multiple layers (I don't like this either, it's easier but more "hackish"). I'm currently leaning towards the second option since I can imagine the first will require a *lot* of work (though I will still look into that further). Perhaps you have some ideas on how this could be implemented in pre-2.0 SVG. Thanks, Sebastian

6 7