Hello,



I recognized three different behaviours at three different browsers, when a

svg image is bigger than its embed tag.

ASV and firefox 3: Make the overlaying parts available by panning

Firefox 2: Provides scrollbars

Opera: Cuts off the overlaying parts



Does someone know how to get a unique behaviour (prefered the ff3/ASV

beahaviour) in an easy way?



Stefan

Stefan,



not sure of your intention, but viewbox is one way:

http://www.peepo.com



'bigger' seems a strange concept when relating SVG and html



cheers





Jonathan Chetwynd



j.chetwynd@...

http://www.peepo.com/



+44 (0) 20 7978 1764





On 1 Mar 2008, at 18:23, Stefan Heinrichsen wrote:



Hello,



I recognized three different behaviours at three different browsers,

when a

svg image is bigger than its embed tag.

ASV and firefox 3: Make the overlaying parts available by panning

Firefox 2: Provides scrollbars

Opera: Cuts off the overlaying parts



Does someone know how to get a unique behaviour (prefered the ff3/ASV

beahaviour) in an easy way?



Stefan











[Non-text portions of this message have been removed]

Stefan Heinrichsen wrote:

> I recognized three different behaviours at three different browsers, when a

> svg image is bigger than its embed tag.

> ASV and firefox 3: Make the overlaying parts available by panning

> Firefox 2: Provides scrollbars

> Opera: Cuts off the overlaying parts



Can you provide a link to an example? As far as I'm aware ASV has always

overridden the width and height of the SVG with the width and height of the

<embed>/<object> tag (as required by the SVG spec). As a result percentage

lengths in the SVG should be relative to the <embed> width/height if the SVG

doesn't have a viewBox, or if the SVG does have a viewBox attribute, the SVG

should fully scale.



Double checking IE with ASV 6 build 38363 on the following page, this seems to

be the case:



http://www.svgopen.org/2004/proceedings_en.html



Firefox 3 betas should now be doing the spec mandated overriding of the width

and height of the SVG just as ASV does. The behavior of Firefox 2 is just plain

broken I'm afraid (it shouldn't scroll).



I also checked the link above in Opera 9.50 beta build 9815 and Safari 3.0.4

(523.15) and they have the same broken behavior of Firefox 2 (scrollbars).



I've not noticed any SVG implementation that clips instead of

overriding/scrolling.



Hopefully Opera and Safari will soon fix their SVG implementations to do the

overriding thing, and Firefox 2 will fade fast after the release of Firefox 3.



Jonathan

--- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...> wrote:

>

> Firefox 3 betas should now be doing the spec mandated overriding of

the width

> and height of the SVG just as ASV does. The behavior of Firefox 2 is

just plain

> broken I'm afraid (it shouldn't scroll).

>

> I also checked the link above in Opera 9.50 beta build 9815 and

Safari 3.0.4

> (523.15) and they have the same broken behavior of Firefox 2

(scrollbars).



Jonathan,



This is great news - I had no idea.  This means that the large volume

of art on places like openclipart.org are going to be much more

directly usable for web page art in the future (if Opera and Safari

clean this up).



At the moment, I have to tidy up clip art by removing the width/height

attributes on the <svg> element and adding a viewBox.  With the proper

overriding, this would no longer be necessary.



Thanks,

Jeff

Jeff & Doug



is there, or more properly does the spec 'mandate', any way to get a

similar behaviour in pure SVG?



ie so that one can be sure that any SVG will fill, but not extend

beyond a common and predetermined width and height, using image or use.



regards



Jonathan Chetwynd



j.chetwynd@...

http://www.peepo.com/



+44 (0) 20 7978 1764





On 2 Mar 2008, at 01:17, Jeff Schiller wrote:



--- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...> wrote:

  >

  > Firefox 3 betas should now be doing the spec mandated overriding of

the width

  > and height of the SVG just as ASV does. The behavior of Firefox 2 is

just plain

  > broken I'm afraid (it shouldn't scroll).

  >

  > I also checked the link above in Opera 9.50 beta build 9815 and

Safari 3.0.4

  > (523.15) and they have the same broken behavior of Firefox 2

(scrollbars).



Jonathan,



This is great news - I had no idea. This means that the large volume

of art on places like openclipart.org are going to be much more

directly usable for web page art in the future (if Opera and Safari

clean this up).



At the moment, I have to tidy up clip art by removing the width/height

attributes on the <svg> element and adding a viewBox. With the proper

overriding, this would no longer be necessary.



Thanks,

Jeff













[Non-text portions of this message have been removed]

On Sun, 02 Mar 2008 02:17:39 +0100, Jeff Schiller

<jeff_schiller@...> wrote:



> --- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...> wrote:

>>

>> Firefox 3 betas should now be doing the spec mandated overriding of

> the width

>> and height of the SVG just as ASV does. The behavior of Firefox 2 is

> just plain

>> broken I'm afraid (it shouldn't scroll).

>>

>> I also checked the link above in Opera 9.50 beta build 9815 and

> Safari 3.0.4

>> (523.15) and they have the same broken behavior of Firefox 2

> (scrollbars).

>

> Jonathan,

>

> This is great news - I had no idea.  This means that the large volume

> of art on places like openclipart.org are going to be much more

> directly usable for web page art in the future (if Opera and Safari

> clean this up).



Well, the scrollbars would go away for <object> and <embed>. That's all.

If the svg content doesn't specify the viewBox the content will not scale

to the defined viewport, it will be clipped.



> At the moment, I have to tidy up clip art by removing the width/height

> attributes on the <svg> element and adding a viewBox.  With the proper

> overriding, this would no longer be necessary.



The viewBox would still have to be added. However, viewBox synthesizing is

a feature that could be added to SVG 1.2 Full if there's need for it. It's

rather trivial for the user agent to do, and it's still possible to do

using script I believe (or of course as you note, by manual editing).



Cheers

/Erik



--

Erik Dahlstrom, Core Technology Developer, Opera Software

Co-Chair, W3C SVG Working Group

Personal blog: http://my.opera.com/macdev_ed

Erik,



do you have a script that works in the general case?



It would be convenient, for a project under development...



cheers



  >>  It's  rather trivial for the user agent to do, and it's still

possible to do

using script I believe



Jonathan Chetwynd



j.chetwynd@...

http://www.peepo.com/



+44 (0) 20 7978 1764





On 7 Mar 2008, at 12:14, Erik Dahlstr�m wrote:



On Sun, 02 Mar 2008 02:17:39 +0100, Jeff Schiller

<jeff_schiller@...> wrote:



> --- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...>

> wrote:

>>

>> Firefox 3 betas should now be doing the spec mandated overriding of

> the width

>> and height of the SVG just as ASV does. The behavior of Firefox 2 is

> just plain

>> broken I'm afraid (it shouldn't scroll).

>>

>> I also checked the link above in Opera 9.50 beta build 9815 and

> Safari 3.0.4

>> (523.15) and they have the same broken behavior of Firefox 2

> (scrollbars).

>

> Jonathan,

>

> This is great news - I had no idea.  This means that the large volume

> of art on places like openclipart.org are going to be much more

> directly usable for web page art in the future (if Opera and Safari

> clean this up).



Well, the scrollbars would go away for <object> and <embed>. That's all.

If the svg content doesn't specify the viewBox the content will not

scale

to the defined viewport, it will be clipped.



> At the moment, I have to tidy up clip art by removing the width/height

> attributes on the <svg> element and adding a viewBox.  With the proper

> overriding, this would no longer be necessary.



The viewBox would still have to be added. However, viewBox

synthesizing is

a feature that could be added to SVG 1.2 Full if there's need for it.

It's

rather trivial for the user agent to do, and it's still possible to do

using script I believe (or of course as you note, by manual editing).



Cheers

/Erik



--

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: svg-developers-

unsubscribe@yahoogroups.com

-or-

visit http://groups.yahoo.com/group/svg-developers and click "edit my

membership"

----

Yahoo! Groups Links

Jonathan,

I'm afraid that the script solution isn't going to work when the images

are from another domain, but here's an example that works in Opera 9.5:



<svg xmlns="http://www.w3.org/2000/svg"

xmlns:xlink="http://www.w3.org/1999/xlink">

    <animation xlink:href="bricky.svg" width="400" height="400"

onload="fixup(this)"/>

    <script><![CDATA[

      function fixup(elm)

      {

        var svgns = "http://www.w3.org/2000/svg";

        var docelm = elm.contentDocument.documentElement;

        if(!docelm.hasAttributeNS(svgns, "viewBox"))

        {

          var viewbox = "0 0 " + docelm.getAttribute("width") + " " +

docelm.getAttribute("height");

          docelm.setAttributeNS(svgns, "viewBox", viewbox);

        }

      }

]]></script>

</svg>



You should put this image[1] in the same directory as the svg. If you want

you can replace "contentDocument" with "getSVGDocument()", but note that

getSVGDocument() has been deprecated by the SVG WG in favor of

contentDocument[2].



Of course one might also generate the viewBox based on the boundingbox of

the root element, which is likely to work better in some cases (though it

is hard to calculate the "true" boundingbox that includes filter effects,

stroke, markers etc).



Cheers

/Erik



[1] http://clipart.nicubunu.ro/svg/pacman/bricky.svg

[2] http://lists.w3.org/Archives/Public/www-svg/2008Feb/0060.html



On Fri, 07 Mar 2008 16:47:59 +0100, ~:'' ありがとうございました。

<j.chetwynd@...> wrote:



> Erik,

>

> do you have a script that works in the general case?

>

> It would be convenient, for a project under development...

>

> cheers

>

>  >>  It's  rather trivial for the user agent to do, and it's still

> possible to do

> using script I believe

>

> Jonathan Chetwynd

>

> j.chetwynd@...

> http://www.peepo.com/

>

> +44 (0) 20 7978 1764

>

>

> On 7 Mar 2008, at 12:14, Erik Dahlström wrote:

>

> On Sun, 02 Mar 2008 02:17:39 +0100, Jeff Schiller

> <jeff_schiller@...> wrote:

>

>> --- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...>

>> wrote:

>>>

>>> Firefox 3 betas should now be doing the spec mandated overriding of

>> the width

>>> and height of the SVG just as ASV does. The behavior of Firefox 2 is

>> just plain

>>> broken I'm afraid (it shouldn't scroll).

>>>

>>> I also checked the link above in Opera 9.50 beta build 9815 and

>> Safari 3.0.4

>>> (523.15) and they have the same broken behavior of Firefox 2

>> (scrollbars).

>>

>> Jonathan,

>>

>> This is great news - I had no idea.  This means that the large volume

>> of art on places like openclipart.org are going to be much more

>> directly usable for web page art in the future (if Opera and Safari

>> clean this up).

>

> Well, the scrollbars would go away for <object> and <embed>. That's all.

> If the svg content doesn't specify the viewBox the content will not

> scale

> to the defined viewport, it will be clipped.

>

>> At the moment, I have to tidy up clip art by removing the width/height

>> attributes on the <svg> element and adding a viewBox.  With the proper

>> overriding, this would no longer be necessary.

>

> The viewBox would still have to be added. However, viewBox

> synthesizing is

> a feature that could be added to SVG 1.2 Full if there's need for it.

> It's

> rather trivial for the user agent to do, and it's still possible to do

> using script I believe (or of course as you note, by manual editing).

>

> Cheers

> /Erik

>







--

Erik Dahlstrom, Core Technology Developer, Opera Software

Co-Chair, W3C SVG Working Group

Personal blog: http://my.opera.com/macdev_ed

Erik,



I have to say first that viewbox has taken me a long time to

understand at all.

it may be my introductory texts were not ideal....

the task of rapidly converting 'random' svg files to fit a window may

have helped me a little ~:"



does your script cater for the case where the content is outside the

window?

ie say x="-300"

thinks not..?



have to say at the moment feeling this is a minor issue....



regards



Jonathan Chetwynd



j.chetwynd@...

http://www.peepo.com/



+44 (0) 20 7978 1764





On 10 Mar 2008, at 10:37, Erik Dahlström wrote:



Jonathan,

I'm afraid that the script solution isn't going to work when the images

are from another domain, but here's an example that works in Opera 9.5:



<svg xmlns="http://www.w3.org/2000/svg"

xmlns:xlink="http://www.w3.org/1999/xlink">

<animation xlink:href="bricky.svg" width="400" height="400"

onload="fixup(this)"/>

<script><![CDATA[

function fixup(elm)

{

var svgns = "http://www.w3.org/2000/svg";

var docelm = elm.contentDocument.documentElement;

if(!docelm.hasAttributeNS(svgns, "viewBox"))

{

var viewbox = "0 0 " + docelm.getAttribute("width") + " " +

docelm.getAttribute("height");

docelm.setAttributeNS(svgns, "viewBox", viewbox);

}

}

]]></script>

</svg>



You should put this image[1] in the same directory as the svg. If you

want

you can replace "contentDocument" with "getSVGDocument()", but note that

getSVGDocument() has been deprecated by the SVG WG in favor of

contentDocument[2].



Of course one might also generate the viewBox based on the

boundingbox of

the root element, which is likely to work better in some cases

(though it

is hard to calculate the "true" boundingbox that includes filter

effects,

stroke, markers etc).



Cheers

/Erik



[1] http://clipart.nicubunu.ro/svg/pacman/bricky.svg

[2] http://lists.w3.org/Archives/Public/www-svg/2008Feb/0060.html



On Fri, 07 Mar 2008 16:47:59 +0100, ~:'' ありがとうございま

した。

<j.chetwynd@...> wrote:



  > Erik,

  >

  > do you have a script that works in the general case?

  >

  > It would be convenient, for a project under development...

  >

  > cheers

  >

  > >> It's rather trivial for the user agent to do, and it's still

  > possible to do

  > using script I believe

  >

  > Jonathan Chetwynd

  >

  > j.chetwynd@...

  > http://www.peepo.com/

  >

  > +44 (0) 20 7978 1764

  >

  >

  > On 7 Mar 2008, at 12:14, Erik Dahlström wrote:

  >

  > On Sun, 02 Mar 2008 02:17:39 +0100, Jeff Schiller

  > <jeff_schiller@...> wrote:

  >

  >> --- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...>

  >> wrote:

  >>>

  >>> Firefox 3 betas should now be doing the spec mandated overriding of

  >> the width

  >>> and height of the SVG just as ASV does. The behavior of Firefox

2 is

  >> just plain

  >>> broken I'm afraid (it shouldn't scroll).

  >>>

  >>> I also checked the link above in Opera 9.50 beta build 9815 and

  >> Safari 3.0.4

  >>> (523.15) and they have the same broken behavior of Firefox 2

  >> (scrollbars).

  >>

  >> Jonathan,

  >>

  >> This is great news - I had no idea. This means that the large volume

  >> of art on places like openclipart.org are going to be much more

  >> directly usable for web page art in the future (if Opera and Safari

  >> clean this up).

  >

  > Well, the scrollbars would go away for <object> and <embed>.

That's all.

  > If the svg content doesn't specify the viewBox the content will not

  > scale

  > to the defined viewport, it will be clipped.

  >

  >> At the moment, I have to tidy up clip art by removing the width/

height

  >> attributes on the <svg> element and adding a viewBox. With the

proper

  >> overriding, this would no longer be necessary.

  >

  > The viewBox would still have to be added. However, viewBox

  > synthesizing is

  > a feature that could be added to SVG 1.2 Full if there's need for it.

  > It's

  > rather trivial for the user agent to do, and it's still possible

to do

  > using script I believe (or of course as you note, by manual editing).

  >

  > Cheers

  > /Erik

  >



--

Erik Dahlstrom, Core Technology Developer, Opera Software

Co-Chair, W3C SVG Working Group

Personal blog: http://my.opera.com/macdev_ed











[Non-text portions of this message have been removed]

Jonathan,



If the content is outside the window that's usually the intention of the

author, at least in the Inkscape cases.



If the viewBox attribute isn't specified then any negative coordinate will

be outside the viewport (or "window"). This is the usual case for clipart

on openclipart.org.



Anyway, since you seemed to want the boundingbox variant, here it is:



var bbox = docelm.getBBox();

docelm.setAttributeNS(svgns, "viewBox", bbox.x + " " + bbox.y + " " +

bbox.width + " " + bbox.height);



As you can see on the example below this means that the shadow is clipped

a bit, since it is done using filters.



Cheers

/Erik



On Mon, 10 Mar 2008 11:45:38 +0100, ~:'' ありがとうございました。

<j.chetwynd@...> wrote:



> Erik,

>

> I have to say first that viewbox has taken me a long time to

> understand at all.

> it may be my introductory texts were not ideal....

> the task of rapidly converting 'random' svg files to fit a window may

> have helped me a little ~:"

>

> does your script cater for the case where the content is outside the

> window?

> ie say x="-300"

> thinks not..?

>

> have to say at the moment feeling this is a minor issue....

>

> regards

>

> Jonathan Chetwynd

>

> j.chetwynd@...

> http://www.peepo.com/

>

> +44 (0) 20 7978 1764

>

>

> On 10 Mar 2008, at 10:37, Erik Dahlström wrote:

>

> Jonathan,

> I'm afraid that the script solution isn't going to work when the images

> are from another domain, but here's an example that works in Opera 9.5:

>

> <svg xmlns="http://www.w3.org/2000/svg"

> xmlns:xlink="http://www.w3.org/1999/xlink">

> <animation xlink:href="bricky.svg" width="400" height="400"

> onload="fixup(this)"/>

> <script><![CDATA[

> function fixup(elm)

> {

> var svgns = "http://www.w3.org/2000/svg";

> var docelm = elm.contentDocument.documentElement;

> if(!docelm.hasAttributeNS(svgns, "viewBox"))

> {

> var viewbox = "0 0 " + docelm.getAttribute("width") + " " +

> docelm.getAttribute("height");

> docelm.setAttributeNS(svgns, "viewBox", viewbox);

> }

> }

> ]]></script>

> </svg>

>

> You should put this image[1] in the same directory as the svg. If you

> want

> you can replace "contentDocument" with "getSVGDocument()", but note that

> getSVGDocument() has been deprecated by the SVG WG in favor of

> contentDocument[2].

>

> Of course one might also generate the viewBox based on the

> boundingbox of

> the root element, which is likely to work better in some cases

> (though it

> is hard to calculate the "true" boundingbox that includes filter

> effects,

> stroke, markers etc).

>

> Cheers

> /Erik

>

> [1] http://clipart.nicubunu.ro/svg/pacman/bricky.svg

> [2] http://lists.w3.org/Archives/Public/www-svg/2008Feb/0060.html

>

> On Fri, 07 Mar 2008 16:47:59 +0100, ~:'' ありがとうございま

> した。

> <j.chetwynd@...> wrote:

>

>  > Erik,

>  >

>  > do you have a script that works in the general case?

>  >

>  > It would be convenient, for a project under development...

>  >

>  > cheers

>  >

>  > >> It's rather trivial for the user agent to do, and it's still

>  > possible to do

>  > using script I believe

>  >

>  > Jonathan Chetwynd

>  >

>  > j.chetwynd@...

>  > http://www.peepo.com/

>  >

>  > +44 (0) 20 7978 1764

>  >

>  >

>  > On 7 Mar 2008, at 12:14, Erik Dahlström wrote:

>  >

>  > On Sun, 02 Mar 2008 02:17:39 +0100, Jeff Schiller

>  > <jeff_schiller@...> wrote:

>  >

>  >> --- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...>

>  >> wrote:

>  >>>

>  >>> Firefox 3 betas should now be doing the spec mandated overriding of

>  >> the width

>  >>> and height of the SVG just as ASV does. The behavior of Firefox

> 2 is

>  >> just plain

>  >>> broken I'm afraid (it shouldn't scroll).

>  >>>

>  >>> I also checked the link above in Opera 9.50 beta build 9815 and

>  >> Safari 3.0.4

>  >>> (523.15) and they have the same broken behavior of Firefox 2

>  >> (scrollbars).

>  >>

>  >> Jonathan,

>  >>

>  >> This is great news - I had no idea. This means that the large volume

>  >> of art on places like openclipart.org are going to be much more

>  >> directly usable for web page art in the future (if Opera and Safari

>  >> clean this up).

>  >

>  > Well, the scrollbars would go away for <object> and <embed>.

> That's all.

>  > If the svg content doesn't specify the viewBox the content will not

>  > scale

>  > to the defined viewport, it will be clipped.

>  >

>  >> At the moment, I have to tidy up clip art by removing the width/

> height

>  >> attributes on the <svg> element and adding a viewBox. With the

> proper

>  >> overriding, this would no longer be necessary.

>  >

>  > The viewBox would still have to be added. However, viewBox

>  > synthesizing is

>  > a feature that could be added to SVG 1.2 Full if there's need for it.

>  > It's

>  > rather trivial for the user agent to do, and it's still possible

> to do

>  > using script I believe (or of course as you note, by manual editing).

>  >

>  > Cheers

>  > /Erik

>  >

>







--

Erik Dahlstrom, Core Technology Developer, Opera Software

Co-Chair, W3C SVG Working Group

Personal blog: http://my.opera.com/macdev_ed

Erik,



that does seem closer to my rather limited understanding,



however there's an additional issue, in that this discussion has so

far been limited to presumably viewbox.

as I review the very few openclipart examples with title it happens

that a g transform=matrix has been used on the whole document, or

even part of it in one case at least....



I did create a symbol version, but is there a simple way to include

operations like this via the DOM?

http://peepo.getmyip.com/~JonathanChetwynd/db/search.php?search=shield



put another way, would it all be a lot easier, if:

	 there was good documentation for authors and authoring tools.

	 the author understood the benefits of labelling the document and

it's parts with titles

	 the id's related simply to the title to make readable links

	 authoring tools are designed in such a way as to facilitate the

process of repurposing and accessibility.



kind regards



Jonathan Chetwynd



j.chetwynd@...

http://www.peepo.com/



+44 (0) 20 7978 1764





On 10 Mar 2008, at 11:50, Erik Dahlström wrote:



Jonathan,



If the content is outside the window that's usually the intention of the

author, at least in the Inkscape cases.



If the viewBox attribute isn't specified then any negative coordinate

will

be outside the viewport (or "window"). This is the usual case for

clipart

on openclipart.org.



Anyway, since you seemed to want the boundingbox variant, here it is:



var bbox = docelm.getBBox();

docelm.setAttributeNS(svgns, "viewBox", bbox.x + " " + bbox.y + " " +

bbox.width + " " + bbox.height);



As you can see on the example below this means that the shadow is

clipped

a bit, since it is done using filters.



Cheers

/Erik



On Mon, 10 Mar 2008 11:45:38 +0100, ~:'' ありがとうございま

した。

<j.chetwynd@...> wrote:



  > Erik,

  >

  > I have to say first that viewbox has taken me a long time to

  > understand at all.

  > it may be my introductory texts were not ideal....

  > the task of rapidly converting 'random' svg files to fit a window may

  > have helped me a little ~:"

  >

  > does your script cater for the case where the content is outside the

  > window?

  > ie say x="-300"

  > thinks not..?

  >

  > have to say at the moment feeling this is a minor issue....

  >

  > regards

  >

  > Jonathan Chetwynd

  >

  > j.chetwynd@...

  > http://www.peepo.com/

  >

  > +44 (0) 20 7978 1764

  >

  >

  > On 10 Mar 2008, at 10:37, Erik Dahlström wrote:

  >

  > Jonathan,

  > I'm afraid that the script solution isn't going to work when the

images

  > are from another domain, but here's an example that works in Opera

9.5:

  >

  > <svg xmlns="http://www.w3.org/2000/svg"

  > xmlns:xlink="http://www.w3.org/1999/xlink">

  > <animation xlink:href="bricky.svg" width="400" height="400"

  > onload="fixup(this)"/>

  > <script><![CDATA[

  > function fixup(elm)

  > {

  > var svgns = "http://www.w3.org/2000/svg";

  > var docelm = elm.contentDocument.documentElement;

  > if(!docelm.hasAttributeNS(svgns, "viewBox"))

  > {

  > var viewbox = "0 0 " + docelm.getAttribute("width") + " " +

  > docelm.getAttribute("height");

  > docelm.setAttributeNS(svgns, "viewBox", viewbox);

  > }

  > }

  > ]]></script>

  > </svg>

  >

  > You should put this image[1] in the same directory as the svg. If you

  > want

  > you can replace "contentDocument" with "getSVGDocument()", but

note that

  > getSVGDocument() has been deprecated by the SVG WG in favor of

  > contentDocument[2].

  >

  > Of course one might also generate the viewBox based on the

  > boundingbox of

  > the root element, which is likely to work better in some cases

  > (though it

  > is hard to calculate the "true" boundingbox that includes filter

  > effects,

  > stroke, markers etc).

  >

  > Cheers

  > /Erik

  >

  > [1] http://clipart.nicubunu.ro/svg/pacman/bricky.svg

  > [2] http://lists.w3.org/Archives/Public/www-svg/2008Feb/0060.html

  >

  > On Fri, 07 Mar 2008 16:47:59 +0100, ~:'' ありがとうございま

  > した。

  > <j.chetwynd@...> wrote:

  >

  > > Erik,

  > >

  > > do you have a script that works in the general case?

  > >

  > > It would be convenient, for a project under development...

  > >

  > > cheers

  > >

  > > >> It's rather trivial for the user agent to do, and it's still

  > > possible to do

  > > using script I believe

  > >

  > > Jonathan Chetwynd

  > >

  > > j.chetwynd@...

  > > http://www.peepo.com/

  > >

  > > +44 (0) 20 7978 1764

  > >

  > >

  > > On 7 Mar 2008, at 12:14, Erik Dahlström wrote:

  > >

  > > On Sun, 02 Mar 2008 02:17:39 +0100, Jeff Schiller

  > > <jeff_schiller@...> wrote:

  > >

  > >> --- In svg-developers@yahoogroups.com, Jonathan Watt <jwatt@...>

  > >> wrote:

  > >>>

  > >>> Firefox 3 betas should now be doing the spec mandated

overriding of

  > >> the width

  > >>> and height of the SVG just as ASV does. The behavior of Firefox

  > 2 is

  > >> just plain

  > >>> broken I'm afraid (it shouldn't scroll).

  > >>>

  > >>> I also checked the link above in Opera 9.50 beta build 9815 and

  > >> Safari 3.0.4

  > >>> (523.15) and they have the same broken behavior of Firefox 2

  > >> (scrollbars).

  > >>

  > >> Jonathan,

  > >>

  > >> This is great news - I had no idea. This means that the large

volume

  > >> of art on places like openclipart.org are going to be much more

  > >> directly usable for web page art in the future (if Opera and

Safari

  > >> clean this up).

  > >

  > > Well, the scrollbars would go away for <object> and <embed>.

  > That's all.

  > > If the svg content doesn't specify the viewBox the content will not

  > > scale

  > > to the defined viewport, it will be clipped.

  > >

  > >> At the moment, I have to tidy up clip art by removing the width/

  > height

  > >> attributes on the <svg> element and adding a viewBox. With the

  > proper

  > >> overriding, this would no longer be necessary.

  > >

  > > The viewBox would still have to be added. However, viewBox

  > > synthesizing is

  > > a feature that could be added to SVG 1.2 Full if there's need

for it.

  > > It's

  > > rather trivial for the user agent to do, and it's still possible

  > to do

  > > using script I believe (or of course as you note, by manual

editing).

  > >

  > > Cheers

  > > /Erik

  > >

  >



--

Erik Dahlstrom, Core Technology Developer, Opera Software

Co-Chair, W3C SVG Working Group

Personal blog: http://my.opera.com/macdev_ed











[Non-text portions of this message have been removed]

On Sat, 01 Mar 2008 22:23:22 +0100, Jonathan Watt <jwatt@...> wrote:

...

> Firefox 3 betas should now be doing the spec mandated overriding of the

> width

> and height of the SVG just as ASV does. The behavior of Firefox 2 is

> just plain

> broken I'm afraid (it shouldn't scroll).



Just to be clear, this[1] is the relevant part of the spec you're talking

about, right?



I've reported this as bug 316081 in the Opera bugtracker.



Cheers

/Erik



[1] http://www.w3.org/TR/SVG11/coords.html#ViewportSpace





--

Erik Dahlstrom, Core Technology Developer, Opera Software

Co-Chair, W3C SVG Working Group

Personal blog: http://my.opera.com/macdev_ed

Erik Dahlstr�m wrote:

> On Sat, 01 Mar 2008 22:23:22 +0100, Jonathan Watt <jwatt@...> wrote:

> ...

>> Firefox 3 betas should now be doing the spec mandated overriding of the

>> width

>> and height of the SVG just as ASV does. The behavior of Firefox 2 is

>> just plain

>> broken I'm afraid (it shouldn't scroll).

>

> Just to be clear, this[1] is the relevant part of the spec you're talking

> about, right?



Yup.



> I've reported this as bug 316081 in the Opera bugtracker.



Great, thanks.



> Cheers

> /Erik

>

> [1] http://www.w3.org/TR/SVG11/coords.html#ViewportSpace

>

>

Hi Stefan,

   I have a control for panning and zooming of a pure SVG file of 100%

width and height, with the control kept always on focus. It works for

Firefox 2 and Opera 9 and higher on Windows and Mac. You can find it

on "http://alzt.tau.ac.il/~dagan/tools/". Look for the part entitled

"Zoom and Pan".

   Good luck, Samy



--- In svg-developers@yahoogroups.com, Stefan Heinrichsen

<gelbemauer@...> wrote:

>

> Hello,

>

> I recognized three different behaviours at three different browsers,

when a

> svg image is bigger than its embed tag.

> ASV and firefox 3: Make the overlaying parts available by panning

> Firefox 2: Provides scrollbars

> Opera: Cuts off the overlaying parts

>

> Does someone know how to get a unique behaviour (prefered the ff3/ASV

> beahaviour) in an easy way?

>

> Stefan

>