Re: [svg-developers] Zoom Pan

2005-12-12 Thread Christophe Strobbe
At 18:39 8/12/2005, andre m. winter wrote:
hi,
  I don't see the drawback of disabling pan  zoom since you application
  will probably have a specific user interface for zooming  panning the
  map. Or do you mean with as a cartographer that there are a lot of GIS
  applications which currently use something similar? (I'm not a
  cartographer btw).
 

take a map and let users (or yourself) zoom in. once you know there is a
ctrl+drag, you never touch the archaic + and - buttons anymore. it
really makes a difference in usablility.

Except for people (e.g. with a mobility impairment) who
- can't use a mouse, or
- can't use mouse and keyboard at the same time.

When you think users, don't assume that everyone is fully able-bodied.

Regards,

Christophe


-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



 Yahoo! Groups Sponsor ~-- 
AIDS in India: A lurking bomb. Click and help stop AIDS now.
http://us.click.yahoo.com/9QUssC/lzNLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-12 Thread Andre M. Winter - Carto.net


 Except for people (e.g. with a mobility impairment) who
 - can't use a mouse, or
 - can't use mouse and keyboard at the same time.

 When you think users, don't assume that everyone is fully able-bodied.
   


yes, but a majority is. for them well suited interfaces are needed. for 
the others one may offer some additional tools or whatever.

with all respect to impaired people, if one builds an interface that 
fits to people with no ability to interact or to see it, then there is 
no need of starting thinking about. http://www.w3.org/WAI/ doesn't say 
to downgrade interaction  layout to the most impaired user, but to 
ensure that this one still is able to understand a minimum of the 
content. that is a big difference.

it's similar to try to make an interface run on 99% of the user agents 
out there. the h1hello world/h1 will make big problems ;-)

andré




-- 
___
andre m. winter,
  cartography for internet and multimedia applications
  schiessstand 4/1, a6091 goetzens, tyrol, austria
  tel.: ++43.5234.32732
  email: [EMAIL PROTECTED]

http://www.vectoreal.com/  SVG consulting and development
http://www.carto.net/  online cartography focusing on SVG
http://www.carto.at/ print and online touristic map solutions 




 Yahoo! Groups Sponsor ~-- 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/2jUsvC/tzNLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-12 Thread Christophe Strobbe

At 13:35 12/12/2005, andré wrote:
 
  Except for people (e.g. with a mobility impairment) who
  - can't use a mouse, or
  - can't use mouse and keyboard at the same time.
 
  When you think users, don't assume that everyone is fully able-bodied.
 


yes, but a majority is. for them well suited interfaces are needed. for
the others one may offer some additional tools or whatever.

Sure, whatever. Who cares?

with all respect to impaired people, if one builds an interface that
fits to people with no ability to interact or to see it, then there is
no need of starting thinking about. http://www.w3.org/WAI/ doesn't say
to downgrade interaction  layout to the most impaired user, but to
ensure that this one still is able to understand a minimum of the
content. that is a big difference.

Do you mean it's OK to disable + and - and replace them with Crlt+drag
for zooming? If that is what you imply with your argument about downgrading
(which I did not ask for), then your argument about downgrading falls flat.
Keeping + and - is not downgrading, but removing it amounts to exlusion
of certain groups (to which any of us might belong one day).

Regards,

Christophe


-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



 Yahoo! Groups Sponsor ~-- 
AIDS in India: A lurking bomb. Click and help stop AIDS now.
http://us.click.yahoo.com/VpTY2A/lzNLAA/yQLSAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-12 Thread Andre M. Winter - Carto.net
hi christophe

my intention is to have a full functional interface, as much as the 
actual technology permits (and reaches technically speaking some 
significant percentage of users). concerning map interfaces, my 
philosophy is to make them supernumerary, as much as possible. i can 
think about ~5 methods for zoom in and as much to pan around. i would 
never tell you to remove +/--buttons, but i wont be happy if someone 
sets zoomAndPan=disable if there is no good reason for. replacing 
zoomAndPan by +/--buttons is what i would call downgrading. having 
them *in parallel* is a richer interface and that's what i preach for here.

hoping to make things clearer...

andré





   

 Do you mean it's OK to disable + and - and replace them with Crlt+drag
 for zooming? If that is what you imply with your argument about downgrading
 (which I did not ask for), then your argument about downgrading falls flat.
 Keeping + and - is not downgrading, but removing it amounts to exlusion
 of certain groups (to which any of us might belong one day).

 Regards,

 Christophe


   


-- 
___
andre m. winter,
  cartography for internet and multimedia applications
  schiessstand 4/1, a6091 goetzens, tyrol, austria
  tel.: ++43.5234.32732
  email: [EMAIL PROTECTED]

http://www.vectoreal.com/  SVG consulting and development
http://www.carto.net/  online cartography focusing on SVG
http://www.carto.at/ print and online touristic map solutions 




 Yahoo! Groups Sponsor ~-- 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/2jUsvC/tzNLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-12 Thread Jeroen Vanattenhoven
Andre,

take a map and let users (or yourself) zoom in. once you know there is a

ctrl+drag, you never touch the archaic + and - buttons anymore. it

really makes a difference in usablility.


Is this impossible when disabling zoom and pan? Is it possible to work 
this out using JavaScript and event handlers?

yes, but what does an interface designed for ~800*600 be good for when

it gets fit in a 150*100 display? you know there is an interface, but

can you interact with it anymore?


I see that 800*600 isn't going to work on 150*100. I had webdesign in 
mind for desktop screens. Designing websites is pretty difficult for 
resolutions from 800*600 to 1600*1200. With SVG that problem is gone. 
Not if you are using 150*100 off course. I'm currently developing on 
PDA's and those screens are really small :) .

this is not the issue. 5 lines of code or 1200 don't harm the viewer.

look at what the Google Maps API passes to the browser. i think there is

a commitment towards the user of the map. if there is a possibility to

let them have a better user experience, then it's not nice if one just

cancels those possibilities. when you put an mapping system together,

the client side scripting is the easiest/cheapes anyway, even if it

produces a lot of code.


Yes, it will not harm the viewer. But when I can write something in 10 
lines, I won't use another method which takes 50 lines. Better for 
low-bandwidth connections and the program code will be easier to maintain.

are we at 6) ? :)
= Have you ever used rotation of a map? I will try this for the pda 
application when I turn the map according to the walking direction of 
the user. Seems like a rotate on the map element will do the trick?

7) I've been looking for a way to change the styles of a map (or user 
interface) on the fly. CSS doesn't work because I can't change the link 
to the CSS-file. Do you know any methods for this? One example is 
providing a night and a day map.

andré


Jeroen

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



 Yahoo! Groups Sponsor ~-- 
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/I258zB/QnQLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-12 Thread Jeroen Vanattenhoven
Andre,

 take a map and let users (or yourself) zoom in. once you know there is a
 ctrl+drag, you never touch the archaic + and - buttons anymore. it
 really makes a difference in usablility.

Is this impossible when disabling zoom and pan? Is it possible to work 
it out using JavaScript and event handlers?

 yes, but what does an interface designed for ~800*600 be good for when
 it gets fit in a 150*100 display? you know there is an interface, but
 can you interact with it anymore?

I see that 800*600 isn't going to work on 150*100. I had webdesign in 
mind for desktop screens. Designing websites is pretty difficult for 
resolutions from 800*600 to 1600*1200. With SVG that problem is gone. 
Not if you are using 150*100 off course. I'm currently developing on 
PDA's and those screens are really small :).

 this is not the issue. 5 lines of code or 1200 don't harm the viewer.
 look at what the Google Maps API passes to the browser. i think there is
 a commitment towards the user of the map. if there is a possibility to
 let them have a better user experience, then it's not nice if one just
 cancels those possibilities. when you put an mapping system together,
 the client side scripting is the easiest/cheapes anyway, even if it
 produces a lot of code.

Yes, it will not harm the viewer. But when I can write something in 10 
lines, I won't use another method which takes 50 lines. Better for 
low-bandwidth connections and the program code will be easier to maintain.

are we at 6) ? :)
= Have you ever used rotation of a map? I will try this for the pda 
application when I turn the map according to the walking direction of 
the user. Seems like a rotate on the map element will do the trick?

7) I've been looking for a way to change the styles of a map (or user 
interface) on the fly. CSS doesn't work because I can't change the link 
to the CSS-file. Do you know any methods for this? One example is 
providing a night and a day map.

 andré

Jeroen

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



 Yahoo! Groups Sponsor ~-- 
AIDS in India: A lurking bomb. Click and help stop AIDS now.
http://us.click.yahoo.com/9QUssC/lzNLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-12 Thread Andre M. Winter - Carto.net
hi,


  take a map and let users (or yourself) zoom in. once you know there is a
  ctrl+drag, you never touch the archaic + and - buttons anymore. it
  really makes a difference in usablility.

 Is this impossible when disabling zoom and pan?

no
 Is it possible to work 
 it out using JavaScript and event handlers?
   

yes. but this needs a lot of code. with ctrl+drag i was speaking about 
the viewer's build in functionality (ASV and squiggle). enable 
zoomAndPan and you have it, without any scripting.


 Yes, it will not harm the viewer. But when I can write something in 10 
 lines, I won't use another method which takes 50 lines. Better for 
 low-bandwidth connections and the program code will be easier to maintain.
   

when within your 10 lines, important interface elements are grayed out, 
then it's worth looking at the lines 11-50. btw bandwidth is not an 
argument. we are speaking about maps (aren't we?). in big mapping 
projects with ~1500 lines of code this part still makes not more than 
10% compared to the 90% of ... vector data.

 = Have you ever used rotation of a map? I will try this for the pda 
 application when I turn the map according to the walking direction of 
 the user. Seems like a rotate on the map element will do the trick?
   

no, i only turn my laptop when i need to find that little restet hole ;-/

more seriously, there should be no problem turning the map. you will get 
problems with your interface if you have one and with text placement. 
depending on your coordinate system turning itself is a funny thing...


 7) I've been looking for a way to change the styles of a map (or user 
 interface) on the fly. CSS doesn't work because I can't change the link 
 to the CSS-file. Do you know any methods for this? One example is 
 providing a night and a day map.
   

there have been people playing on this, it works somehow depending on 
the viewer. as i don't like CSS, i never came across this. btw, CSS 
isn't very well supported in the mobile SVG viewer world.

andré



-- 
___
andre m. winter,
  cartography for internet and multimedia applications
  schiessstand 4/1, a6091 goetzens, tyrol, austria
  tel.: ++43.5234.32732
  email: [EMAIL PROTECTED]

http://www.vectoreal.com/  SVG consulting and development
http://www.carto.net/  online cartography focusing on SVG
http://www.carto.at/ print and online touristic map solutions 




 Yahoo! Groups Sponsor ~-- 
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/I258zB/QnQLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-08 Thread Andre M. Winter - Carto.net
hi Jeroen,

 Zoom  Pan operations on SVG maps are quite common. Mostly those 
 operations are implemented changing the viewBox attributes. 

the problem is that viewBox manipulations are incompatible with 
currentScale/Translate because on every setting of new viewBox values 
currentScale/Translate gets set to 1,0,0 whatever they may have been set 
before. you should never mix those two methods, unless you know exactly 
what you do (btw i never saw an example doing that and this may be a 
stong enough argument...)


 Is it 
 possible to achieve the same effect using currentScale and 
 currentTranslate? 

yes.

 Not for example on the root svg element, which mostly 
 represents a user interface, but on the svg element which represents the 
 map. 

no, that cannot work because currentScale/Translate always act on (or 
represent the state of) the outermost svg, the root element. the way to 
go is to have your main content zoomed as ever you want and apply 
inverse transformations (for gs) or inverse screenCTMs (for inner 
svgs) to the parts that are acting as fixed interface containers.

 If so, why haven't I seen it yet?
   

because it is tricky. there are samples out there but these are not easy 
to break down in a 5-lines sample script. all this is explained in book 
coming out feb 2006, but it will be in german first (but you should be 
able to read it, judging based on your last name...) here is a short 
description http://www.huethig.de/shop/product.html?id=146899top=1, 
the companion website will go online jan 2006 at http://svg.carto.net/ 
(may be offline these times).

in order to not let you here without an answer, i'll try to give short 
hints.

first you need an svg doc with content and interface elements, something 
like this helps you to get an interface that will always be expressed in 
screen coordinates (pixel).

svg width=100% height=100% ...!--viewBox here --
svg id=myMap width=100% height=100%
viewBox=437000 –4788000 146000 226000/
...
/svg
svg id=myInfoBlock ... viewBox=0 0 180 520 /
...
/svg
/svg



if you want do a zoom from the interface centered on the actual 
position, you call this:


function myDoZoom(val){
var myOldScale = myDocElem.currentScale;
var oldTranslate = {
x : myDocElem.currentTranslate.x,
y : myDocElem.currentTranslate.y
}

myDocElem.currentScale *= val; // RELATIVE FACTOR

myDocElem.currentTranslate.x = myViewportWidth / 2
– (myDocElem.currentScale / myOldScale)
* (myViewportWidth / 2 – oldTranslate.x);
myDocElem.currentTranslate.y = myViewportHeight / 2
– (myDocElem.currentScale / myOldScale)
* (myViewportHeight / 2 – oldTranslate.y);
}


a pan may look like this (here with a fixed jump factor, but a 
zoom-dependent factor would be better


function myDoPan(myX,myY){
var myCurrTransl = myDocElem.currentTranslate;
var myStep = 30;
myX *= myStep;
myY *= myStep;
myCurrTransl.x += myX;
myCurrTransl.y += myY;
}


a reset to the initial view is the easiest one:


function myDoReset(){
myDocElem.currentScale = 1;
myDocElem.currentTranslate.x = 0;
myDocElem.currentTranslate.y = 0;
}


now how to make your inner svg (your interface element) stay in place? 
that's not that hard. the values 0 and 200 being the upper left anchor 
of the container element, it being width=520 and height=180. the 
function needs to be called onzoom on the root element.



function myHandleZoomPan(evt){
var myInfoBlock = document.getElementById('myInfoBlock');
myInfoBlock.setAttributeNS(null,'x',
(200 – myCurrTransl.x) / myDocElem.currentScale);
myInfoBlock.setAttributeNS(null, 'y',
(0 – myCurrTransl.y) / myDocElem.currentScale);
myInfoBlock.setAttributeNS(null,'width',180/myDocElem.currentScale);
myInfoBlock.setAttributeNS(null,'height',520/myDocElem.currentScale);
}


if your interface container is a group, the function looks a bit different:


function myHandleZoomPan(evt){
var myCurrTransl = myDocElem.currentTranslate;
var myTransform = 'scale(' + 1 / myDocElem.currentScale + ') '
+ 'translate(' + (–yCurrTransl.x)
+ ', ' + (–myCurrTransl.y) + ')';
document.getElementById('myInfoBlockGroup')
.setAttributeNS(null, 'transform', myTransform);
myUpdateDisplays();
}


hope this helps for a start, note that this is copypaste code out of 
the book i mentioned, there may be variables to be defined first. these 
example was tested on FF1.5, ASV3.x and Batik Squiggle 1.6.



-- 
___
andre m. winter,
  cartography for internet and multimedia applications
  schiessstand 4/1, a6091 goetzens, tyrol, austria
  tel.: ++43.5234.32732
  email: [EMAIL PROTECTED]

http://www.vectoreal.com/  SVG consulting and development
http://www.carto.net/  online cartography focusing on SVG
http://www.carto.at/ print and online touristic map solutions 




 Yahoo! Groups Sponsor ~-- 
1.2 million kids a year are victims of human trafficking. Stop slavery.

Re: [svg-developers] Zoom Pan

2005-12-08 Thread Jeroen Vanattenhoven
Andre M. Winter - Carto.net schreef:

First of all, thanks for the elaborate answer.

hi Jeroen,

  

Zoom  Pan operations on SVG maps are quite common. Mostly those 
operations are implemented changing the viewBox attributes. 



the problem is that viewBox manipulations are incompatible with 
currentScale/Translate because on every setting of new viewBox values 
currentScale/Translate gets set to 1,0,0 whatever they may have been set 
before. you should never mix those two methods, unless you know exactly 
what you do (btw i never saw an example doing that and this may be a 
stong enough argument...)

  

I see. The question I was actually posing was if the 
currentScale/Translate method would be easier then the viewBox method 
for maps inside user interfaces. Since currentScale/Translate only work 
on the outmost svg element, the viewBox method seems more appropiate.

no, that cannot work because currentScale/Translate always act on (or 
represent the state of) the outermost svg, the root element. the way to 
go is to have your main content zoomed as ever you want and apply 
inverse transformations (for gs) or inverse screenCTMs (for inner 
svgs) to the parts that are acting as fixed interface containers.
  

hehe, I'm actually belgian, but followed a german course the last two 
years, so it will probably be ok :).

because it is tricky. there are samples out there but these are not easy 
to break down in a 5-lines sample script. all this is explained in book 
coming out feb 2006, but it will be in german first (but you should be 
able to read it, judging based on your last name...) here is a short 
description http://www.huethig.de/shop/product.html?id=146899top=1, 
the companion website will go online jan 2006 at http://svg.carto.net/ 
(may be offline these times).

Could you comment on what you think is the most appropiate/easy way to 
provide zoom  pan for maps in SVG? I only have experience with the 
viewBox method.

Jeroen

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



 Yahoo! Groups Sponsor ~-- 
1.2 million kids a year are victims of human trafficking. Stop slavery.
http://us.click.yahoo.com/.QUssC/izNLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-08 Thread Jeroen Vanattenhoven
hello andre,

Andre M. Winter - Carto.net schreef:

hi Jeroen

the main differences are:

1) when you set zoompan with the viewBox, you have to forbid zoomAndPan 
through the viewer's functionality (ctrl+something for ASV and 
Squiggle). as a cartographer this is the biggest drawback. it is 
possible to rebuild this functionality, but this is hardcore and may 
only be helpful when having a mapserver behind that delivers SVG
  

I don't see the drawback of disabling pan  zoom since you application 
will probably have a specific user interface for zooming  panning the 
map. Or do you mean with as a cartographer that there are a lot of GIS 
applications which currently use something similar? (I'm not a 
cartographer btw).

3) with the viewBox-method your interface is scalable. that may be 
useful, but i think it is generally not (readability, etc).
  

Not in the sense that you will scale the browser window itself, but it 
does make sense when you want to provide a user interface which works on 
different resolutions of the displays of the user.

2) the viewBox-method rather fits for maps where a large part of your 
screen are devoted to the interface, whereas currentScale/Translate is 
better for applications with small interfaces and a bigger part for the 
map itself.
  

I agree.

4) Concerning the implementation I know the viewBox method requires 
quite some code, but it's far from being too much. When I saw your post, 
the amount of code required for the other method seemed to be similar. 
So that probably won't make a difference.

5) I forgot to ask: you mentioned that your book will first be 
available in german. So will it be available in english later? And can 
you provide a table of contents for the book? I can't find one on that 
website.

andré
  

Jeroen

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



 Yahoo! Groups Sponsor ~-- 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] Zoom Pan

2005-12-08 Thread Andre M. Winter - Carto.net
hi,
 I don't see the drawback of disabling pan  zoom since you application 
 will probably have a specific user interface for zooming  panning the 
 map. Or do you mean with as a cartographer that there are a lot of GIS 
 applications which currently use something similar? (I'm not a 
 cartographer btw).
   

take a map and let users (or yourself) zoom in. once you know there is a 
ctrl+drag, you never touch the archaic + and - buttons anymore. it 
really makes a difference in usablility.


 Not in the sense that you will scale the browser window itself, but it 
 does make sense when you want to provide a user interface which works on 
 different resolutions of the displays of the user.
   

yes, but what does an interface designed for ~800*600 be good for when 
it gets fit in a 150*100 display? you know there is an interface, but 
can you interact with it anymore?

 4) Concerning the implementation I know the viewBox method requires 
 quite some code, but it's far from being too much. When I saw your post, 
 the amount of code required for the other method seemed to be similar. 
 So that probably won't make a difference.
   

this is not the issue. 5 lines of code or 1200 don't harm the viewer. 
look at what the Google Maps API passes to the browser. i think there is 
a commitment towards the user of the map. if there is a possibility to 
let them have a better user experience, then it's not nice if one just 
cancels those possibilities. when you put an mapping system together, 
the client side scripting is the easiest/cheapes anyway, even if it 
produces a lot of code.


 5) I forgot to ask: you mentioned that your book will first be 
 available in german. So will it be available in english later? And can 
 you provide a table of contents for the book? I can't find one on that 
 website.
   


there is an english version planned, but i am still looking for an 
US/UK-based editor.

a TOC will go online soon. the book gets reviewed by the editor those 
days and after that the TOC will be definitive.



andré


-- 
___
andre m. winter,
  cartography for internet and multimedia applications
  schiessstand 4/1, a6091 goetzens, tyrol, austria
  tel.: ++43.5234.32732
  email: [EMAIL PROTECTED]

http://www.vectoreal.com/  SVG consulting and development
http://www.carto.net/  online cartography focusing on SVG
http://www.carto.at/ print and online touristic map solutions 




 Yahoo! Groups Sponsor ~-- 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/1U_rlB/TM
~- 

-
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/

* 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] zoom/pan svg image, only inside a frame

2005-07-19 Thread Bart
On 7/18/05, spanakimaria [EMAIL PROTECTED] wrote:
 How can I have an svg frame that can not be panned or zoomed, and an
 svg image inside the frame that allows zoom and pan?

An alternative to the reverse transforms suggested (which I believe can
be slightly buggy, I've read one viewers misimplements a CTM function,
possibly not screenCTM) is setting zoomAndPan=disable and
implementing dragging and zooming by interpreting mouse and key
events yourself - I have, to make dragging only work inside a viewport
that displays maps. It does mean you have to reimplement a bunch
of things that are already available, and that getting at viewport
coordinates is less accurate as you have to calculate that yourself too.

(See http://svg.scarfboy.com/newiface/test.svg but consider I'm actively
 working on that. If interested, I'll help make sense of the mess of code)

--Bart


-
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/

* 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] zoom/pan svg image, only inside a frame

2005-07-18 Thread Holger Will
spanakimaria schrieb:

 How can I have an svg frame that can not be panned or zoomed, and an
 svg image inside the frame that allows zoom and pan?

 Thanks,

 Maria

Hi Maria
i believe its not directly possible, what you can do is allow  zoom/pan 
on your outer svg frame, and then have a group holding the content that 
should not scale/translate.
you can then  iverses the transformation of the root element, and apply 
it to that group.
here is a simple example:

?xml version=1.0?
svg xmlns=http://www.w3.org/2000/svg;
 xmlns:xlink=http://www.w3.org/1999/xlink;  onload=reposition() 
onscroll=reposition() onzoom=reposition() onresize=reposition() 
viewBox=0 0 1024 768 
 script
 function reposition(){
var g=document.getElementById(fixedContent)
var m=document.documentElement.getScreenCTM()
m=m.inverse()
g.setAttribute(transform,matrix(+m.a+,0,0,+m.d+,+m.e+,+m.f+))
 }
 /script
 g
  rect x=0 y=0 width=1024 height=768/
 /g
g id=fixedContent
  rect x=0 y=0 width=200 height=768 fill=green/
/g
/svg

hth
Holger


-
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/

* 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/