Re : [svg-developers] onmousedown() and onclick() at the same time
Ok, I get it. Thanks for you response.
De : ddailey [EMAIL PROTECTED]
À : svg-developers@yahoogroups.com
Envoyé le : Mercredi, 3 Décembre 2008, 22h37mn 31s
Objet : Re: [svg-developers] onmousedown() and onclick() at the same time
Hi Julie,
I think what is happening when you put an alert in the middle of it all is this:
first the onmousedown is received, evt.type is then mousedown
next an alert fires
then to get rid of the alert the user has to move the mouse off of the group
(which received the mousedown)
so the click (which actually consists of a mousedown followed by a mouseup --
without any intervening mouseout event, I believe), is never actually received
by the group.
David
- Original Message -
From: julie gautier
To: svg-developers@ yahoogroups. com
Sent: Wednesday, December 03, 2008 3:23 PM
Subject: Re : [svg-developers] onmousedown( ) and onclick() at the same time
Hi,
There's something I really don't understant, if somebody could help me : in the
javascript code David sent, if I add an alert in the 'all' function :
if (evt.type== click){
alert(evt.target. nodeName) ;
}
else{
alert(evt.type) ;
evt.currentTarget. firstChild. nextSibling. setAttributeNS( null,fill ,red)
}
then I have the following alerts : 'mousedown', 'mouseup' and the circle turns
red.
If I comment the alert(evt.type) , I have the alert : 'circle' and the circle
turns red.
Could someone explain to me why this only line makes the click not fired
anymore ??
Thanks in advance.
_ _ __
De : Dailey, David P. david.dailey@ sru.edu
À : svg-developers@ yahoogroups. com
Envoyé le : Mercredi, 3 Décembre 2008, 18h29mn 48s
Objet : RE: [svg-developers] onmousedown( ) and onclick() at the same time
Take a look at the following; it lets different events on parts of the group be
registered and responded to.
Hope it helps
David
svg xmlns=http://www.w3. org/2000/ svg width=100%
xmlns:xlink= http://www.w3. org/1999/ xlink
script![CDATA[
xmlns=http://www.w3. org/2000/ svg
xlink=http://www.w3. org/1999/ xlink
function all(evt){
if (evt.type== click) alert(evt.target. nodeName)
else evt.currentTarget. firstChild. nextSibling. setAttributeNS( null,fill
,red)
}
//]]
/script
g onmousedown= all(evt) ; onmouseup=all( evt)
circle onclick=all( evt) fill=black r=5 cx=55 cy=55/
circle onclick=all( evt) fill=black r=5 cx=100 cy=100/
/g
/svg
From: svg-developers@ yahoogroups. com [mailto:svg- developers@ yahoogroups.
com] On Behalf Of jgfa92004
Sent: Wednesday, December 03, 2008 6:07 AM
To: svg-developers@ yahoogroups. com
Subject: [svg-developers] onmousedown( ) and onclick() at the same time
Hi,
I have the following svg code :
g onmousedown= down(evt) ; onmouseup=up( evt);
circle onclick=alert( 'circle1' ) fill=black r=5 cx=5 cy=5/
circle onclick=alert( 'circle2' ) fill=black r=5 cx=0 cy=0/
/g
My problème is that the onclick event is never called, apparently
because of the onmousedown and onmouseup events called in the first g.
What should I do to be able to call another function when a circle is
clicked ?
Thanks a lot.
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
-
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click edit my
membership
Yahoo! Groups Links
* To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
* Your email settings:
Individual Email | Traditional
* To change settings online go to:
http://groups.yahoo.com/group/svg-developers/join
(Yahoo! ID required)
* To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Re: [svg-developers] Re: Report on SVG Viewer Performance
On Thu, 04 Dec 2008 06:12:30 - Frank Bruder [EMAIL PROTECTED] wrote: Great work so far. Just three comments: - You identify your platform and the user agents you've tested, but since Batik is a Java application it would make sense to also state which JVM version was used. (Smack head on table) You're right, I should have thought of that. I'll add it. - Your testing method does not necessarily measure a relevant benchmark. A scripting engine which queues events in such a way that interval and timeout events always are executed in the correct order would get perfect scores, no matter how much time the rendering takes. In the second call to setInterval() you could create a Date object each time and use that for measuring, to account for the possibility that the longer interval might be delayed in accordance with the shorter interval. Furthermore a user agent could switch to rendering only every other frame when the animation speed would otherwise slow down too much. Video player software commonly does this. I'm not sure I understand your issue here. The interval events for the animation and the sampling are two independent timers (or at least they appear to be). So the order of events doesn't appear to have any relevance (unless I'm really misunderstanding you). I actually use the Date.getTime() method on each call to the sampling routine to measure the actual elapsed time between my samples. In a previous life, I had seen how much the actual interval could vary relative to the expected interval. I need to make sure that I am clear about this in the text. You are correct, I can't actually measure rendering in the script, so I'm making the assumption that each update is a render. So, this is a potential issue that I need to document. - Finally I'd like to note that a normal distribution in fact is an absolutely unreasonable assumption for a variable which can not be negative. A gamma distribution is more like it. I stand corrected. My statistics is not what it used to be (and possibly never was). Just to make sure, is a calculated standard deviation still a useful measure of variation in a gamma distribution? The main point of this assumption was to give me a measure of the variability. I really appreciate the time you have taken to read and comment on this article. Thank you, G. Wade --- In svg-developers@yahoogroups.com, G. Wade Johnson [EMAIL PROTECTED] wrote: I have just posted a second draft of my Results of Profiling Scripting Animation in SVG on my website at http://anomaly.org/wade/projects/svg/profiling/ I would appreciate any input from anyone who has the time to read and comment on it. I will try to incorporate any comments (and some changes to the charts) into a final version over the next few days/weeks. I also plan to put a little time into styling, so it doesn't look quite so bland. I hope to add more specific profiling over time to compare different aspects of scripting SVG. Any input would be appreciated. G. Wade -- All things are possible, given enough time and caffeine. -- Danny Hoover -- To vacillate or not to vacillate, that is the question ... or is it? - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click edit my membership Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[svg-developers] Re: onmousedown() and onclick() at the same time
Hi again,
I still have troubles getting things work...
Here is my entire code, if you could help.
This is a circle in a 'zone' where it's possible to zoom by drawing a
selection rectangle.
I desesperatly try to make the 'click' event fired to launch another
action (here : change the color of the circle) when the user clicks
on the circle but I can't do it.
In the following code the zoom works but the 'click' event is never
fired.
If I comment all the code into the if (evt.type == mousedown)
statment, it works : the circle turns red (but obviously, the zoom
doesn't work anymore) ! And I really can't find why.
Thanks again for your help.
?xml version=1.0 standalone=no?
!DOCTYPE svg PUBLIC -//W3C//DTD SVG
1.0//EN http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd;
svg onload=init() width=600.0px viewBox=0 0 6000.0 6000.0
height=600.0px xmlns=http://www.w3.org/2000/svg;
xmlns:xlink=http://www.w3.org/1999/xlink; id=carte
script type=text/ecmascript
![CDATA[
function init()
{
carto = document.getElementById(carte);
}
var zoom = false, click = false, node = '', xsvg = 0, ysvg = 0, xsvg2
= 0, ysvg2 = 0;
function all(evt) {
if (evt.type == click){
document.getElementById(symb0).setAttributeNS
(null,fill,red);
}
else if (evt.type == mousedown){
//document.getElementById(symb0).setAttributeNS
(null,fill,blue);
click = true;
node = evt.target.ownerDocument.getElementById('zone');
xsvg = getTrueCoordX(evt.clientX);
ysvg = getTrueCoordY(evt.clientY);
node.setAttributeNS(null,'x',xsvg);
node.setAttributeNS(null,'y',ysvg);
node.setAttributeNS(null,'width','0');
node.setAttributeNS(null,'height','0');
node.setAttributeNS(null,'stroke-width',''+getTrueCoordR(10));
node.setAttributeNS(null,'visibility','visible');
}
else if (evt.type == mousemove){
if (click) {
zoom = true;
xsvg2 = getTrueCoordX(evt.clientX);
ysvg2 = getTrueCoordY(evt.clientY);
w = Math.abs(xsvg2-xsvg);
h = Math.abs(ysvg2-ysvg);
node.setAttributeNS(null,'x',Math.min(xsvg,xsvg2).toString());
node.setAttributeNS(null,'y',Math.min(ysvg,ysvg2).toString());
node.setAttributeNS(null,'width',w.toString());
node.setAttributeNS(null,'height',h.toString());
}
}
else if (evt.type == mouseup){
if (click zoom) {
x = Math.min(xsvg,xsvg2);
y = Math.min(ysvg,ysvg2);
w = Math.abs(xsvg2-xsvg);
h = Math.abs(ysvg2-ysvg);
if (w h)
largeur = w;
else
largeur = h;
if (x+largeur 6000)
largeur = 6000 - x;
if (x+largeur 0)
x = 0;
if (y+largeur 6000)
largeur = 6000 - y;
if (y+largeur 0)
y = 0;
vb = carto.getAttribute('viewBox');
vbatt = vb.split(' ');
wvb = parseFloat(vbatt[2]);
viewport=x.toString() + ' ' + y.toString() + ' ' +
largeur.toString() + ' ' + largeur.toString();
carto.setAttributeNS(null,'viewBox',viewport);
node.setAttributeNS(null,'visibility','hidden');
k = wvb / largeur;
}
click = false;
zoom = false;
}
}
function getTrueCoordX(x) {
vb = carto.getAttribute('viewBox');
vbatt = vb.split(' ');
xvb = parseFloat(vbatt[0]);
wvb = parseFloat(vbatt[2]);
return (xvb+x*(wvb/600));
}
function getTrueCoordY(y) {
vb = carto.getAttribute('viewBox');
vbatt = vb.split(' ');
yvb = parseFloat(vbatt[1]);
hvb = parseFloat(vbatt[3]);
return (yvb+y*(hvb/600))
}
function getTrueCoordR(r) {
vb = carto.getAttribute('viewBox');
vbatt = vb.split(' ');
wvb = parseFloat(vbatt[2]);
return (r*wvb/6000);
}
]]
/script
g onmousemove=all(evt); onmousedown=all(evt);
onmouseup=all(evt);
rect x=0 y=0 fill=white width=6000.0
height=6000.0/
circle onclick=all(evt); fill=midnightblue
r=532 id=symb0 cx=3338 cy=1677/
rect fill=none stroke-width=10 id=zone
visibility=visible stroke=rgb(100,100,100) x=0 y=0 width=0
height=0/
/g
/svg
--- In svg-developers@yahoogroups.com, ddailey [EMAIL PROTECTED] wrote:
Hi Julie,
I think what is happening when you put an alert in the middle of it
all is this:
first the onmousedown is received, evt.type is then mousedown
next an alert fires
then to get rid of the alert the user has to move the mouse off of
the group (which received the mousedown)
so the click (which actually consists of a mousedown followed by a
mouseup -- without any intervening mouseout event, I believe), is
never actually received by the group.
David
- Original Message -
From: julie gautier
To: svg-developers@yahoogroups.com
Sent: Wednesday, December 03, 2008 3:23 PM
Subject: Re : [svg-developers] onmousedown() and onclick() at the
same time
Hi,
Re: [svg-developers] Re: Report on SVG Viewer Performance
On Thu, 04 Dec 2008 07:12:30 +0100, Frank Bruder [EMAIL PROTECTED] wrote: Great work so far. Just three comments: ... - Your testing method does not necessarily measure a relevant benchmark. A scripting engine which queues events in such a way that interval and timeout events always are executed in the correct order would get perfect scores, no matter how much time the rendering takes. In the second call to setInterval() you could create a Date object each time and use that for measuring, to account for the possibility that the longer interval might be delayed in accordance with the shorter interval. Furthermore a user agent could switch to rendering only every other frame when the animation speed would otherwise slow down too much. Video player software commonly does this. I would agree that doing DOM modifications and checking how long it took before it could do the next update/modification isn't necessarily very accurate. If little or no rendering is done at all, then you'd probably get a very high score. There's no guarantee that the DOM modifications actually result in a new rendering before the next update call. This is what Frank is getting at about dropping frames, there's no guaranteed framerate. Second, the Date objects / timers that are used can have varying resolution/quality in browsers, and across platforms. That may skew results. Third, in any case why would you need a framerate higher than the screen refreshrate? For the DOM modifications sure, they should be expected to run as fast as possible. But unless you run with vertical sync disabled you'll not see the frames that are produced in excess of the screen's refreshrate, and if you do get the extra frames then you may well see tearing problems. So yes, it's good if the DOM modifications are as fast as possible, and yes it's good if the viewer can produce frames faster than it needs to actually draw them on screen, but I don't think that you're measuring actual rendering framerates. Another justified question would be: if you're not going to see the frames anyway, why should valuable CPU time be wasted rendering them? Anyway, you may want to check out the SVGSVGElement.currentFps[1] DOM API in the just released[2] Opera 10 for comparison. That property will provide the average framerate based on samples from when the svg was actually rendered to screen. And I want to add that performance testing is really important, and that the above points in no way invalidate your work. They're just things that may skew the results. What you see on your screen and in CPU and memory usage is what really counts IMHO, and it's clear that in that respect the SVG viewers keep improving at a steady rate. Cheers /Erik [1] http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/ [2] http://www.opera.com/browser/next/ -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click edit my membership Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[svg-developers] Re: Report on SVG Viewer Performance
if you're not going to see the frames anyway, why should valuable CPU time be wasted rendering them? The question is how sensitive is the human perception. Of course the screen refresh rate should take precedence but monitors (specially LCD, as CRT were already doing it for a while) are getting speedy (in terms of Hz, in comparison to CRT) again. Smoothness and flickering can be pretty tricky, as an interesting writing about the fact [1] explains. My personal experience shows that this is (apparently) not universal. For example I recall that, when I was using CRT monitors, I could easily distinguish between 75 and 85Hz, although most of my colleagues couldn't. (Honestly, I can't imagine how I was using a 60Hz monitor, even if this was about 10 years ago.) Similar effects using 3D action games: playing in a faster machine achieving a higher frame rate made all the difference to me, while most of my friends were not so affected (at least, according to themselves)... Just food for thought, Helder Magalhães [1] http://www.100fps.com/how_many_frames_can_humans_see.htm - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click edit my membership Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [svg-developers] Re: Report on SVG Viewer Performance
On Thu, 04 Dec 2008 15:28:40 +0100 Erik Dahlström [EMAIL PROTECTED] wrote: On Thu, 04 Dec 2008 07:12:30 +0100, Frank Bruder [EMAIL PROTECTED] wrote: Great work so far. Just three comments: ... - Your testing method does not necessarily measure a relevant benchmark. A scripting engine which queues events in such a way that interval and timeout events always are executed in the correct order would get perfect scores, no matter how much time the rendering takes. In the second call to setInterval() you could create a Date object each time and use that for measuring, to account for the possibility that the longer interval might be delayed in accordance with the shorter interval. Furthermore a user agent could switch to rendering only every other frame when the animation speed would otherwise slow down too much. Video player software commonly does this. I would agree that doing DOM modifications and checking how long it took before it could do the next update/modification isn't necessarily very accurate. If little or no rendering is done at all, then you'd probably get a very high score. There's no guarantee that the DOM modifications actually result in a new rendering before the next update call. This is what Frank is getting at about dropping frames, there's no guaranteed framerate. We would hope that we could get updates faster than the rendering. But if you don't then it is a result I would like to be able to measure. I had actually planned to go into more detail on this, but the article was getting so long that I was afraid mo one would be willing to read it. Second, the Date objects / timers that are used can have varying resolution/quality in browsers, and across platforms. That may skew results. I really need to put some tie into a sidebar on potential points of error in the measures. I mentioned a few, but they aren't coherent enough to show the biases I was aware of. Without that section, I really don't have a good place to add notes like these. I remember that the Javascript Date object in most browsers used to be lousy a decade ago. I should have mentioned that. Third, in any case why would you need a framerate higher than the screen refreshrate? For the DOM modifications sure, they should be expected to run as fast as possible. But unless you run with vertical sync disabled you'll not see the frames that are produced in excess of the screen's refreshrate, and if you do get the extra frames then you may well see tearing problems. So yes, it's good if the DOM modifications are as fast as possible, and yes it's good if the viewer can produce frames faster than it needs to actually draw them on screen, but I don't think that you're measuring actual rendering framerates. Another justified question would be: if you're not going to see the frames anyway, why should valuable CPU time be wasted rendering them? I, personally, only want a refresh rate fast enough to generate smooth animation. My goal was less to brag on a particular potential update rate than to explore some of the edges of what's possible. After reading a few of the emails here I don't seem to be clear enough on my intended goal. Anyway, you may want to check out the SVGSVGElement.currentFps[1] DOM API in the just released[2] Opera 10 for comparison. That property will provide the average framerate based on samples from when the svg was actually rendered to screen. Sounds really useful. I'll try to check it out when I dig out from under my current project.grin/ And I want to add that performance testing is really important, and that the above points in no way invalidate your work. They're just things that may skew the results. What you see on your screen and in CPU and memory usage is what really counts IMHO, and it's clear that in that respect the SVG viewers keep improving at a steady rate. I do want to thank you for your insights and comments. This project started as a quick test to see if a few of my pages were fast enough, but I've kind of moved in the direction of trying to put numbers to the idea that SVG is fast enough. I'm not really qualified to make that determination, but with the input I've gotten so far on this list, I hope to make something we can point to we people say that SVG would be too slow for animation or instrumentation or games or whatever. Thank you again for taking the time to comment. I'll incorporate your ideas where I can in the next revision. G. Wade -- Results are what you wanted, consequences are what you got. -- Michael VanDusen - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click edit my membership Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ * Your email settings: Individual Email | Traditional *
[svg-developers] Re: onmousedown() and onclick() at the same time
Hi Julie,
In your mousedown code you initialize the position and size of the
'zone' rectangle and place it under the mouse. When the mouseup comes
along, zone is the target and the circle never gets a click event.
In the 'zone' rect, put pointer-events=none
rect fill=none stroke-width=10 id=zone visibility=visible
stroke=rgb(100,100,100) x=0 y=0 width=0 height=0
pointer-events=none/
I haven't checked your previous posts closely, but maybe this was
thwarting your earlier attempts at getting the click event.
Curiously, using ASV3, the first click always fires a mousemove. Any
clicks after that did not. To get around this, I changed your mousemove
code to check that the mouse had actually moved (also avoids zooming to
zero width/height selections).
else if (evt.type == mousemove){
if (click) {
xsvg2 = getTrueCoordX(evt.clientX);
ysvg2 = getTrueCoordY(evt.clientY);
w = Math.abs(xsvg2-xsvg);
h = Math.abs(ysvg2-ysvg);
zoom = (w 0) (h 0);
node.setAttributeNS(null,'x',Math.min(xsvg,xsvg2).toString());
node.setAttributeNS(null,'y',Math.min(ysvg,ysvg2).toString());
node.setAttributeNS(null,'width',w.toString());
node.setAttributeNS(null,'height',h.toString());
}
}
Ken
-
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click edit my
membership
Yahoo! Groups Links
* To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
* Your email settings:
Individual Email | Traditional
* To change settings online go to:
http://groups.yahoo.com/group/svg-developers/join
(Yahoo! ID required)
* To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Re : [svg-developers] Re: onmousedown() and onclick() at the same time
Thanks a lot !
De : Ken Stacey [EMAIL PROTECTED]
À : svg-developers@yahoogroups.com
Envoyé le : Vendredi, 5 Décembre 2008, 5h34mn 03s
Objet : [svg-developers] Re: onmousedown() and onclick() at the same time
Hi Julie,
In your mousedown code you initialize the position and size of the
'zone' rectangle and place it under the mouse. When the mouseup comes
along, zone is the target and the circle never gets a click event.
In the 'zone' rect, put pointer-events= none
rect fill=none stroke-width= 10 id=zone visibility= visible
stroke=rgb( 100,100,100) x=0 y=0 width=0 height=0
pointer-events= none/
I haven't checked your previous posts closely, but maybe this was
thwarting your earlier attempts at getting the click event.
Curiously, using ASV3, the first click always fires a mousemove. Any
clicks after that did not. To get around this, I changed your mousemove
code to check that the mouse had actually moved (also avoids zooming to
zero width/height selections).
else if (evt.type == mousemove) {
if (click) {
xsvg2 = getTrueCoordX( evt.clientX) ;
ysvg2 = getTrueCoordY( evt.clientY) ;
w = Math.abs(xsvg2- xsvg);
h = Math.abs(ysvg2- ysvg);
zoom = (w 0) (h 0);
node.setAttributeNS (null,'x' ,Math.min( xsvg,xsvg2) .toString( ));
node.setAttributeNS (null,'y' ,Math.min( ysvg,ysvg2) .toString( ));
node.setAttributeNS (null,'width' ,w.toString( ));
node.setAttributeNS (null,'height' ,h.toString( ));
}
}
Ken
[Non-text portions of this message have been removed]
-
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click edit my
membership
Yahoo! Groups Links
* To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
* Your email settings:
Individual Email | Traditional
* To change settings online go to:
http://groups.yahoo.com/group/svg-developers/join
(Yahoo! ID required)
* To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
