You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(24) 
_{Nov}
(524) 
_{Dec}
(655) 

2004 
_{Jan}
(515) 
_{Feb}
(624) 
_{Mar}
(407) 
_{Apr}
(593) 
_{May}
(422) 
_{Jun}
(529) 
_{Jul}
(737) 
_{Aug}
(448) 
_{Sep}
(343) 
_{Oct}
(503) 
_{Nov}
(593) 
_{Dec}
(474) 
2005 
_{Jan}
(771) 
_{Feb}
(602) 
_{Mar}
(588) 
_{Apr}
(488) 
_{May}
(218) 
_{Jun}
(544) 
_{Jul}
(889) 
_{Aug}
(657) 
_{Sep}
(781) 
_{Oct}
(486) 
_{Nov}
(750) 
_{Dec}
(409) 
2006 
_{Jan}
(442) 
_{Feb}
(242) 
_{Mar}
(303) 
_{Apr}
(617) 
_{May}
(811) 
_{Jun}
(525) 
_{Jul}
(367) 
_{Aug}
(318) 
_{Sep}
(202) 
_{Oct}
(395) 
_{Nov}
(260) 
_{Dec}
(185) 
2007 
_{Jan}
(525) 
_{Feb}
(554) 
_{Mar}
(494) 
_{Apr}
(344) 
_{May}
(168) 
_{Jun}
(295) 
_{Jul}
(459) 
_{Aug}
(468) 
_{Sep}
(390) 
_{Oct}
(558) 
_{Nov}
(351) 
_{Dec}
(487) 
2008 
_{Jan}
(583) 
_{Feb}
(471) 
_{Mar}
(979) 
_{Apr}
(436) 
_{May}
(335) 
_{Jun}
(368) 
_{Jul}
(281) 
_{Aug}
(239) 
_{Sep}
(243) 
_{Oct}
(338) 
_{Nov}
(248) 
_{Dec}
(149) 
2009 
_{Jan}
(465) 
_{Feb}
(349) 
_{Mar}
(388) 
_{Apr}
(415) 
_{May}
(211) 
_{Jun}
(226) 
_{Jul}
(262) 
_{Aug}
(376) 
_{Sep}
(419) 
_{Oct}
(370) 
_{Nov}
(257) 
_{Dec}
(449) 
2010 
_{Jan}
(377) 
_{Feb}
(268) 
_{Mar}
(345) 
_{Apr}
(281) 
_{May}
(73) 
_{Jun}
(192) 
_{Jul}
(336) 
_{Aug}
(201) 
_{Sep}
(328) 
_{Oct}
(131) 
_{Nov}
(162) 
_{Dec}
(248) 
2011 
_{Jan}
(138) 
_{Feb}
(182) 
_{Mar}
(241) 
_{Apr}
(174) 
_{May}
(64) 
_{Jun}
(321) 
_{Jul}
(220) 
_{Aug}
(139) 
_{Sep}
(214) 
_{Oct}
(174) 
_{Nov}
(91) 
_{Dec}
(119) 
2012 
_{Jan}
(182) 
_{Feb}
(260) 
_{Mar}
(207) 
_{Apr}
(119) 
_{May}
(118) 
_{Jun}
(150) 
_{Jul}
(72) 
_{Aug}
(125) 
_{Sep}
(137) 
_{Oct}
(187) 
_{Nov}
(122) 
_{Dec}
(131) 
2013 
_{Jan}
(151) 
_{Feb}
(128) 
_{Mar}
(290) 
_{Apr}
(236) 
_{May}
(157) 
_{Jun}
(204) 
_{Jul}
(266) 
_{Aug}
(190) 
_{Sep}
(476) 
_{Oct}
(257) 
_{Nov}
(193) 
_{Dec}
(225) 
2014 
_{Jan}
(228) 
_{Feb}
(189) 
_{Mar}
(372) 
_{Apr}
(340) 
_{May}
(272) 
_{Jun}
(191) 
_{Jul}
(138) 
_{Aug}
(182) 
_{Sep}
(204) 
_{Oct}
(283) 
_{Nov}
(271) 
_{Dec}
(168) 
2015 
_{Jan}
(154) 
_{Feb}
(217) 
_{Mar}
(182) 
_{Apr}
(198) 
_{May}
(227) 
_{Jun}
(91) 
_{Jul}
(64) 
_{Aug}
(138) 
_{Sep}
(175) 
_{Oct}
(133) 
_{Nov}
(83) 
_{Dec}
(128) 
2016 
_{Jan}
(198) 
_{Feb}
(240) 
_{Mar}
(411) 
_{Apr}
(213) 
_{May}
(285) 
_{Jun}
(211) 
_{Jul}
(88) 
_{Aug}
(83) 
_{Sep}
(69) 
_{Oct}
(210) 
_{Nov}
(296) 
_{Dec}
(136) 
2017 
_{Jan}
(303) 
_{Feb}
(273) 
_{Mar}
(218) 
_{Apr}
(149) 
_{May}
(199) 
_{Jun}
(486) 
_{Jul}
(237) 
_{Aug}
(219) 
_{Sep}
(188) 
_{Oct}
(113) 
_{Nov}
(50) 
_{Dec}

S  M  T  W  T  F  S 


1
(4) 
2
(1) 
3
(6) 
4
(7) 
5
(2) 
6
(4) 
7
(5) 
8
(6) 
9
(3) 
10
(6) 
11
(5) 
12
(6) 
13
(15) 
14
(4) 
15
(10) 
16
(8) 
17
(4) 
18
(4) 
19
(2) 
20
(3) 
21
(4) 
22
(3) 
23
(2) 
24
(4) 
25
(12) 
26
(12) 
27
(9) 
28
(21) 
29
(13) 
30
(2) 
31




From: alvinpenner <penner@va...>  20121016 22:22:33

you can ignore the message that says "1 message has been excluded from this view by a project". most likely the reason no one replied is because they were not sure how to respond. I would recommend submitting this as a bug report at: https://bugs.launchpad.net/inkscape/ also, if at all possible, could you submit the svg file as an attachment rather than text?  View this message in context: http://inkscape.13.n6.nabble.com/nosubjecttp4965433p4965434.html Sent from the Inkscape  Dev mailing list archive at Nabble.com. 
From: pennec victor <v1nkscaper@gm...>  20121016 22:01:41

Hi, Did anybody reply to the message I sent the 20121009 23:28 ? http://sourceforge.net/mailarchive/forum.php?thread_name=CABe4m%3DzWXss3QbpXVWFmTaBMFgoStaZHzLuq8AYN0HOznC9rA%40mail.gmail.com&forum_name=inkscapedevel When I browse the sourceforge html interface (which sucks by the way) I see the following 1 message has been excluded from this view by a project administrator. If my message doesn't fit in the rules of the mailing list could you give me some pointers to other sites I could find any help. Thank you. V. 
From: mathog <mathog@ca...>  20121016 21:01:20

SVG style has a fontstretch 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 fontstretch 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 fontfamily:Arial Narrow:width=75; in style, in which fontstretch 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/fontstretch 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@... Manager, Sequence Analysis Facility, Biology Division, Caltech 
From: Johan Engelen <jbc.engelen@sw...>  20121016 18:25:01

On 16102012 13:43, Jasper van de Gronde wrote: > On 121012 23:11, Johan Engelen wrote: >> On 12102012 14:59, Jasper van de Gronde wrote: >>> ... >>> To deal with zerolength handles, the easiest (and correct) method is >>> probably to specify that the curvature is zero at the endpoint with the >>> zerolength handle (if both handles are zerolength, then the Bézier >>> curve forms a line segment). That this is correct can be derived from >>> the fact that the unit tangent vector at the endpoint with a zerolength >>> handle points in the same direction as the second derivative (so locally >>> it's a straight line). This is a consequence of l'Hôpital's rule btw. >> I don't think this is correct. > That observation /is/ :) > > Note that the case of two zerolength handles or two coinciding handles > of which one has zerolength gives a straight line (segment), though. So > for that case it makes perfect sense to have zero curvature throughout > (and this actually follows from the description below). Taking a very special case does not make for a very strong argument ;) ;) Technically I guess you are correct (perhaps depending on the definition of curvature?). I think we should use a more intuitive definition of curvature perhaps... If one would arclengthreparametrise a zerolength handle segment, would it result in zerocurvature? In other words: if one reparametrises a segment, does that change the curvature, without visual differences? >> It is possible to make segments with and >> without a zerolength handle that look exactly the same. > It should not be, in general. (Fewer degrees of freedom.) I meant: zerolength handle segment > nonzero length handles segment. That goes in the direction of increasing degrees of freedom, so at least no worries for that matter. But perhaps it is indeed mathematically impossible. See attachment. >> Also, as you >> are moving the handle closer and closer to the knot, it does not >> converge to zero curvature, in fact it tends to lead to higher curvature >> instead of lower curvature. > There is essentially a bit of instability here. Yes, if you approach it > from most angles, then the curvature increases. However, if you follow > l'Hôpital's rule to compute the unit tangent vector at t=0 (so the > derivative divided by the norm of the derivative), or (which is a bit > easier), the derivative of y w.r.t. x, then you see that the unit > tangent vector at t=0 points to the second handle. If you then take the > limit as P2 approaches P1 from the direction of P2 (or opposite), you > get zero curvature. > > Also (just as an observation), as the handle gets smaller, its influence > decreases. So although locally you have a very large curvature, it's > only over a very small portion of the curve. Does that mean that as the handle goes to zero, it's region of influence tends to zero too and hence perhaps it is not very indicative of the visual curvature any more? >> Wouldn't l'Hopital imply that you can get >> away by using +1 higher derivs instead? > You're completely right. (If you intended taking the derivative of the > numerator and denominator and dividing those.) However, higher > derivatives can (and will) still be zero in this case, so this > complicates things a bit. (simply do the same "trick" again in those cases? ;) > > However, if you make the first handle zerolength, and then compute the > limit of the curvature as t goes to zero, then you find that the > curvature is equal to det([P3P1,P4P1]) divided by something that is > zero at t=0 and positive for t slightly above zero, as long as P3P1 is > not zerolength. Thus, if det([P3P1,P4P1])=0, (all points and handles > on a line), then the curvature at t=0 is zero, and otherwise it is > infinite with the sign of det([P3P1,P4P1]). > > So, I stand corrected, the rule isn't zerolength=zerocurvature, but > rather, a zerolength P1P0 implies that the curvature at P0 is either > infinity, zero or +infinity, depending on the sign of > det([P3P1,P4P1])=0. (Assuming at least some point does not coincide > with P1.) > I have an example attached where there are two paths: one with zerolength handle, and one 'normal' path. They are visually *very* similar; if you zoom in you will notice a small difference in angle and the end of the path on the righthand side. I think the normal path has a nonzero curvature (it is not straight at the end), so I thought the zerolength path would have the same curvature. Now there are two different viewpoints to a solution:  math. SVG definition  user Don't know which one to take... Cheers, Johan 
From: Krzysztof Kosiński <tweenk.pl@gm...>  20121016 17:07:46

2012/10/16 Alex Valavanis <valavanisalex@...>: > Hi All, > > Is there a way of adding GTK+ 3 (and compatible libs) in Devlibs > without breaking GTK+ 2 compatibility? As far as I know, there isn't > a way of testing GTK+ 3 experimental builds in Windows. Presumably, > DLLs have some sort of equivalent to SOnaming to allow multiple > ABIincompatible versions of a library to be provided? The GTK+ 2 DLL is called libgtkwin322.00.dll. The GTK+ 3 DLL would then be called libgtkwin323.00.dll, so there should be no conflict. There could be some problems with the build process though (copying the correct libraries to the 'inkscape' directory). Regards, Krzysztof 
From: Jasper van de Gronde <th.v.d.gronde@hc...>  20121016 11:43:42

On 121012 23:11, Johan Engelen wrote: > On 12102012 14:59, Jasper van de Gronde wrote: >> ... >> To deal with zerolength handles, the easiest (and correct) method is >> probably to specify that the curvature is zero at the endpoint with the >> zerolength handle (if both handles are zerolength, then the Bézier >> curve forms a line segment). That this is correct can be derived from >> the fact that the unit tangent vector at the endpoint with a zerolength >> handle points in the same direction as the second derivative (so locally >> it's a straight line). This is a consequence of l'Hôpital's rule btw. > > I don't think this is correct. That observation /is/ :) Note that the case of two zerolength handles or two coinciding handles of which one has zerolength gives a straight line (segment), though. So for that case it makes perfect sense to have zero curvature throughout (and this actually follows from the description below). > It is possible to make segments with and > without a zerolength handle that look exactly the same. It should not be, in general. (Fewer degrees of freedom.) > Also, as you > are moving the handle closer and closer to the knot, it does not > converge to zero curvature, in fact it tends to lead to higher curvature > instead of lower curvature. There is essentially a bit of instability here. Yes, if you approach it from most angles, then the curvature increases. However, if you follow l'Hôpital's rule to compute the unit tangent vector at t=0 (so the derivative divided by the norm of the derivative), or (which is a bit easier), the derivative of y w.r.t. x, then you see that the unit tangent vector at t=0 points to the second handle. If you then take the limit as P2 approaches P1 from the direction of P2 (or opposite), you get zero curvature. Also (just as an observation), as the handle gets smaller, its influence decreases. So although locally you have a very large curvature, it's only over a very small portion of the curve. > Wouldn't l'Hopital imply that you can get > away by using +1 higher derivs instead? You're completely right. (If you intended taking the derivative of the numerator and denominator and dividing those.) However, higher derivatives can (and will) still be zero in this case, so this complicates things a bit. However, if you make the first handle zerolength, and then compute the limit of the curvature as t goes to zero, then you find that the curvature is equal to det([P3P1,P4P1]) divided by something that is zero at t=0 and positive for t slightly above zero, as long as P3P1 is not zerolength. Thus, if det([P3P1,P4P1])=0, (all points and handles on a line), then the curvature at t=0 is zero, and otherwise it is infinite with the sign of det([P3P1,P4P1]). So, I stand corrected, the rule isn't zerolength=zerocurvature, but rather, a zerolength P1P0 implies that the curvature at P0 is either infinity, zero or +infinity, depending on the sign of det([P3P1,P4P1])=0. (Assuming at least some point does not coincide with P1.) >> ... >> One possible way to specify the restriction for this kind of join would >> be to limit the arclength on either side of the join. The main problem >> is then joining the end points, as a line segment between the two is not >> guaranteed to not intersect the circles. Some experimentation suggests >> that it might be possible to define a sensible boundary using >> interpolation between the two end points that is guaranteed not to >> intersect either of the circles. > > I have no clue what you are saying here. :) Okay, turns out my assumption about how miterlimit worked was wrong, but I still think it makes sense. Basically, when using a miter join, the miter can get infinitely large. This causes all sorts of problems, so "miterlimit" was introduced. Basically this says: "a miter larger than so and so can't be good". The solution then is to fall back to a bevel join... I had assumed it would just "cap" the miter (as this would still prevent it from being insanely large, while preventing a sudden jump from miter to bevel). For the moment, assume that SVG had chosen to simply "cap" the miter. For example, one could restrict the length of both sides of the miter to the miterlimit and draw a straight line between the two. This should cause no further problems (at least in rendering, maybe there are other issues that caused the committee to not go down this route). Now, when joining using arcs, it seems to make even more sense to simply "cap" the join. Otherwise you can have a nice curved join one minute and a bevel (or miter) join the next, seems a bit weird to me. So suppose that you simply "cap" the join. How do you go about capping it? That brings us back to what I was saying. Because both sides of the join are curved, there is no guarantee that a straight line between the endpoints (of the limited sides of the join) does not cross either side of the join (which I think would look really weird). So you want some other kind of "cap". This is why I took a short look into finding a sensible cap by interpolating between both arcs. This looks promising, but a straightforward interpolation between the two arcs still has some problems. But feel free to ignore these fine points, the gist is that if one wanted to "cap" the join instead of falling back to a miter or bevel (and introducing discontinuous/unstable behaviour), then some thought needs to go into how to actually cap it. But of course it might just be simplest to fall back to a miter or bevel. 
From: Alex Valavanis <valavanisalex@gm...>  20121016 09:19:16

Hi All, Is there a way of adding GTK+ 3 (and compatible libs) in Devlibs without breaking GTK+ 2 compatibility? As far as I know, there isn't a way of testing GTK+ 3 experimental builds in Windows. Presumably, DLLs have some sort of equivalent to SOnaming to allow multiple ABIincompatible versions of a library to be provided? Cheers, AV 
From: Krzysztof Kosiński <tweenk.pl@gm...>  20121016 01:45:39

2012/10/16 Johan Engelen <jbc.engelen@...>: > Your solution works for guides, but will not work for example for grids > (oldstyle grid is not an XML element, it is part of spnamedview). Then this is also a change in the XML mapping of spnamedview. In this case, you just need to construct the child XML node for the grid and add it to the tree before calling the parent class build function (in this case SPObjectGroup::build, which will create and call invoke_build on its children). > I don't see why we have to make a whole object of this and do it on the fly > while creating the object tree. I think it is much simpler and better if we > do all backwards compatibility fixups at the start before creating all the > objects from it, in a centralized place. And do these things one after > another even: > > file XML load; > // 0.46 grids definition changed: > CanvasGrid::upgradeTo046(xml document); > // 0.50 guide and grid definition changed: > CanvasGrid::upgradeTo050(xml document); > SPGuide::upgradeTo050(...); > continue with XML parsing to create the SPObject tree > > This may break for exotic cases where things are lost in translation, but > there is no reason to strictly adhere to this stacking of compatibility > functions (first >0.46 and then >0.50) if it does not come natural. This would require each of these functions to traverse the entire XML tree, which is rather wasteful and requires repetitive code. If you want to do it this way, the tree should be traversed only once and the required conversion functions called whenever the current XML element has a matching element name or sodipodi:type atribute, preferably using a lookup in std::map or std::tr1::unordered_map. As long as the object upgrade functions are defined in the files of respective SPObjects and are only called by the file upgrade function on relevant XML nodes (e.g. they don't need to reimplement tree traversal), this may be a workable solution. Regards, Krzysztof 