Basic SVG question - scaling
John M. Dlugosz
"here's how to make it work", other than a note that <IMG> tags are not
supported.
I fiddled around and got the rudiments to work: an illustration created
using InkScape to show in a HTML4.1 document. In the mean time I got
some spectacular failures: it seems that reloading a document doesn't
clean up everything, and sometimes you have to close the tab and load
from scratch. Funny, I figured hitting reload would always mean exactly
the same thing.
Anyway, now I'm having problems with it scaling. If I use ctrl+ to make
the main text bigger, I get larger text within the SVG but the rest of
the drawing, or the text positions, do not change!
Second, if I don't specify a size in the OBJECT tag (directly or using
the css equiv) it doesn't pick up the size from the SVG file but gives a
stupid default. If I do give numbers up front, they need to match the
saved InkScape in pixels. If I try using pt or em, I get a larger
object placeholder but the contents are unaffected.
With a PNG file, I can scale it to fit a desired spot by using height
and width of the <IMG> tag. How can I do the same thing with a SVG file
in an <OBJECT> tag?
--John
Boris Zbarsky
> Anyway, now I'm having problems with it scaling. If I use ctrl+ to make
> the main text bigger, I get larger text within the SVG but the rest of
> the drawing, or the text positions, do not change!
Yep. Known limitation of text zoom.
> Second, if I don't specify a size in the OBJECT tag (directly or using
> the css equiv) it doesn't pick up the size from the SVG file but gives a
> stupid default. If I do give numbers up front, they need to match the
> saved InkScape in pixels. If I try using pt or em, I get a larger
> object placeholder but the contents are unaffected.
Again, yep. This should hopefully be fixed in Gecko 1.9.
-Boris
VK
John M. Dlugosz wrote:
> With a PNG file, I can scale it to fit a desired spot by using height
> and width of the <IMG> tag. How can I do the same thing with a SVG file
> in an <OBJECT> tag?
By not using OBJECT tag. Why are you using such disconvenient
workaround?
VK
"To render data types they don't support natively, user agents
generally run external applications. The OBJECT element allows authors
to control whether data should be rendered externally or by some
program, specified by the author, that renders the data within the user
agent."
What <object> tag does is defining a separate graphics context on the
page driven by another application. A requirement to UA to
proportionally scale an alien dynamic graphics context theoretically
may have place but practically is an overboard. I may believe that
Mozilla team will implement <object> scaling for directly embedded SVG
documents (after all both UA and Cairo engines are under their
control). Leaving apart an obvious mususe of <object> tag: can we
expect then in upcoming releases scaling of Flash movies and applets by
standard Ctrl+ / Ctrl- ? :-)
A legitimate use for <object> in application to SVG is then you don't
want to use the native SVG support but (say for compatibility reasons)
you want to use a 3rd party viewer like Adobe SVG viewer or Corel SVG
viewer. In such case you also have to accept the limitation of a fixed
graphics context imposed by <object> tag.
Unless the above is the case you should include SVG into DOM tree so it
would be covered by the regular UA rendering mechanics (with necessary
fall-back / replacement features for alternative UA's if it's a
web-solution and not an intranet one).
More of useful viewing:
<http://jsnet.sourceforge.net/tmp/svg/>
( try Ctrl+ / Ctrl- on Firefox 1.5>
try on IE - as a quick sample no VML fallback was provided
)
Jeremy
> Unless the above is the case you should include SVG into DOM tree so it
> would be covered by the regular UA rendering mechanics (with necessary
> fall-back / replacement features for alternative UA's if it's a
> web-solution and not an intranet one).
>
> More of useful viewing:
> <http://jsnet.sourceforge.net/tmp/svg/>
> ( try Ctrl+ / Ctrl- on Firefox 1.5>
> try on IE - as a quick sample no VML fallback was provided
> )
>
I think it would be more accurate in your fallback text to say "You are
using any browser other than Mozilla, so it won't work". -moz-binding
is cool, but it's not really an option if you want to support other
browsers with native SVG (such as Opera and Safari).
Additionally, embedding directly into the DOM tree is not currently
practical, as it requires the document to be served as XHTML which at
its current state has many deal-breaking drawbacks.
This leaves <object> as the only portable alternative at the moment.
Jeremy
VK
> I think it would be more accurate in your fallback text to say "You are
> using any browser other than Mozilla, so it won't work". -moz-binding
> is cool, but it's not really an option if you want to support other
> browsers with native SVG (such as Opera and Safari).
You must be did not read my last post well: I said <q>as a quick sample
no VML fallback was provided</q>
Despite it is not how we normally do it, but as a quick'n'durty demo:
<http://jsnet.sourceforge.net/tmp/svg/2/>
try Ctrl +/- on a Gecko-based browser
try font size change option on IE
Now can we drop the hypocrisy for just a minute? Any feature - however
cool it was - is worthless for web-projects if it doesn't have an
equivalent on IE6.0 or higher. Somewhere in my strictly private blog I
may (if I want) show something like "see what this UA can do and your
IE cannot" - but only privately. Sorry but I don't take of being called
a person pushing some UA-exclusive solution into wide use. Right the
opposite: any solution doesn't exist for me as long as it's not
supported by IE; and any solution doesn't exist for me if it's
supported by IE only. That was this way for me since NN3/IE3.
I "did not hear - did not see" behaviors and ViewLink until XBL came. I
did wait for a VML counterpart for 7 years and hell it was a long
waiting because the possibilities are amazing. Yet I will not jump to
support now any nightly revelations of every single UA producer
(Safari/Canvas in mind). There are SVG specs and VML specs: and that is
plenty enough of choice for any producer, at least for the next few
years.
> Additionally, embedding directly into the DOM tree is not currently
> practical, as it requires the document to be served as XHTML which at
> its current state has many deal-breaking drawbacks.
In the linked samples SVG/VML graphics element are nodes in the
document tree. I don't know how more directly one can "embed into the
DOM tree". If you mean textual inclusion of SVG markup into (X)HTML
file then no, you cannot do it with bindings/behaviors.
> This leaves <object> as the only portable alternative at the moment.
I presume you don't care about ~80% of your visitors, which is your
free choice of course. I don't have a luxury of the choice.
John M. Dlugosz
That is what I found in the documentation and tips. Using IMG does not
work. It says so right here
<https://bugzilla.mozilla.org/show_bug.cgi?id=276431>.
What =should= I be using, if not OBJECT?
Example page is
<http://www.dlugosz.com/Repertoire/refman/Classics/handle/cow_usage.html#toptop>.
TIA,
--John
VK
> work. It says so right here
> <https://bugzilla.mozilla.org/show_bug.cgi?id=276431>.
That 's an utterly wrong solved equation with wrong arguments (by
holding on the math interpretation of the matter).
> What =should= I be using, if not OBJECT?
= binding / behavior = twinpairs as suggested in this thread.