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}
(189) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{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: Chris Mohler <cr33dog@gm...>  20121017 23:13:19

On Wed, Oct 17, 2012 at 4:09 PM, mathog <mathog@...> wrote: > The only font description in an EMF file is the name, so if > "Arial Narrow" can mean two different things, there would be no way to > determine > which was intended. I created this EMF in Illustrator, using the Arial>Narrow variant. Does the EMF list it any differently? ...and wait. I've just discovered that the font that's reporting itself (in XP) to be Arial>Narrow is in fact really Arial Narrow>Gras (Bold). So my earlier hints might be a waste of time :( Sorry for the noise... Chris 
From: mathog <mathog@ca...>  20121017 21:09:52

On 17Oct2012 13:55, Chris Mohler wrote: > On Tue, Oct 16, 2012 at 4:01 PM, mathog <mathog@...> wrote: >> Inkscape does not pick up from the font name alone that "Arial >> Narrow" >> is a condensed font. > > Is the font in question "Arial Narrow">"Regular" or > "Arial">"Narrow"? Hmm, well, double clicking on it in Windows it says: Arial Narrow OpenType Font, Digitally Signed, TrueType Outlines Typeface name: Arial Narrow File size: 170 KB Version: Version 2.37 (C) 2006 The Monotype Corporation. All Rights Reserved. fclist v shows weight: 80(i)(s) width: 75(i)(s) whereas regular Arial is: weight: 80(i)(s) width: 100(i)(s) > I've seen both variations in the wild  the former > won't be picked up as a condensed font in any software I know of, > while the latter may or may not (IMHO that should have named it > "Arial>Condensed" instead). The only font description in an EMF file is the name, so if "Arial Narrow" can mean two different things, there would be no way to determine which was intended. Thanks, David Mathog mathog@... Manager, Sequence Analysis Facility, Biology Division, Caltech 
From: Chris Mohler <cr33dog@gm...>  20121017 20:55:10

On Tue, Oct 16, 2012 at 4:01 PM, mathog <mathog@...> wrote: > Inkscape does not pick up from the font name alone that "Arial Narrow" > is a condensed font. Is the font in question "Arial Narrow">"Regular" or "Arial">"Narrow"? I've seen both variations in the wild  the former won't be picked up as a condensed font in any software I know of, while the latter may or may not (IMHO that should have named it "Arial>Condensed" instead). Chris 
From: Jasper van de Gronde <th.v.d.gronde@hc...>  20121017 07:54:19

On 161012 20:24, Johan Engelen wrote: > On 16102012 13:43, Jasper van de Gronde wrote: >> ... >>> 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. Now I get it. Yes, but... (see below). >> 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? Exactly right. >>> 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? ;) Yes, you can do that, but that's basically a pretty convoluted way of doing the same thing as what I did in a slightly different way. Basically what happens is that the denominator typically stays zero for "longer" then the numerator, unless you have a completely straight line (segment). >> >> 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... 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 zerolength handles do tend to have infinite curvature at the endpoint(s) with a zerolength 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 nonzero 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 zerolength 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 arclength. 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. 