Loading ...
Sorry, an error occurred while loading the content.

Re: Determining viewport size

Expand Messages
  • domenico_strazzullo
    Hi Helder, If you are using width and height = 100% on the outmost svg then you can use getComputedStyle: return
    Message 1 of 5 , Aug 13, 2010
    View Source
    • 0 Attachment
      Hi Helder,

      If you are using width and height ="100%" on the outmost svg then you can use getComputedStyle:

      return parseInt(window.getComputedStyle(document.documentElement, null).width);

      or, if you care about ASV in IE:

      if (window.getComputedStyle) {
      return parseInt(window.getComputedStyle(document.documentElement, null).width);
      }
      else {
      return window.innerWidth;
      }

      if not, then you will have to use the rect suggested by David. It may be clunky but then again, given that window.innerWidth/innerHeight are very useful in conjunction with the onresize event, which is legal on the svg element, but which is not shouldered by suitable size properties and/or methods of the Window Object, it does the job. Mind you, I think that window.innerWidth/innerHeight are implemented de facto in all browsers, like you say, but then it's understandable that svg viewers don't have to implement them.

      window.getComputedStyle shouldn't be affected by the viewBox or "preserveAspectRatio" settings because the style width and height values are computed in actual pixels and returned as type String. window.getComputedStyle is expensive compared to window.innerWidth/innerHeight

      Note that, to my knowledge, the onresize event doesn't trigger for Firefox.

      I don't know how to address window.getComputedStyle in Batik.

      > (That is, could one expect the properties to be made standard in a short-to-medium term?)

      Even if they were, it then depends on a viewer's self-definition, as belonging to the browsers family or not. Then there is also another important consideration: what is to be considered as standard? Traditionally a standard was defined scholarly upon observation of methods commonly used in a trade or discipline, to make official a widespread construction or creation technique, at least the one that prevails on others. Or, following the dictionaries: "something considered by an authority or by general consent as a basis of comparison, an approved model". window.innerWidth/innerHeight came about in '97 with Netscape and were progressively adopted by the browsers industry, meaning they ARE standards. A specification which fails to officialize standards is simply failing to its vocation.

      Domenico



      --- In svg-developers@yahoogroups.com, "ddailey" <ddailey@...> wrote:
      >
      > Hi Helder,
      >
      > When you figure it out, please let me know (or better yet add it somewhere in http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html :)
      >
      > I've just typically been lazy and drawn a <rect width="100%" height="100%" x="0%" y="0%" fill="none" /> and then measured it using getBBox, but that's both clunky seeming and maybe won't work right with viewports.
      >
      > cheers
      > David
      >
      > ----- Original Message -----
      > From: heldermagalhaes
      > To: svg-developers@yahoogroups.com
      > Sent: Tuesday, August 10, 2010 1:08 PM
      > Subject: [svg-developers] Determining viewport size
      >
      >
      >
      > Hi everyone,
      >
      > It seems a simple question, although I'm not being able to find an easy answer: how can one determine the actual (screen) viewport size?
      >
      > I remember using innerWidth/innerHeight in the past (window object properties) but AFAIK these are not standard: at least, "Window size and position information" isn't addressed in the current Window Object specification [1]. Also, for example, these properties aren't supported by Batik [2] and probably other "pure" SVG implementations. Nevertheless, they seem to be supported by every Web browser that I'm aware of, so could this be seen as a Batik et. al. limitation? (That is, could one expect the properties to be made standard in a short-to-medium term?)
      >
      > One could also try getting limit coordinates (using a combination of the "width"/"height"/"viewBox" properties) and later do some maths to transform them to screen coordinates but intuitively this will fail unless "preserveAspectRatio" [3] is set to "none" (which would force the whole viewbox to be used but isn't often used as the graphics will appear stretched).
      >
      > Please shed some light into this matter and/or point me in the right direction: maybe I'm just missing something... ;-)
      >
      > Cheers,
      > Helder
      >
      > [1] http://www.w3.org/TR/Window/
      > [2] http://xmlgraphics.apache.org/batik/status.html#ecmascript
      > [3] http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute
      >
      >
      >
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • Jimmy Zhang
      VTD-XML 2.9, the next generation XML Processing API for SOA and Cloud computing, has been released. Please visit
      Message 2 of 5 , Aug 15, 2010
      View Source
      • 0 Attachment
        VTD-XML 2.9, the next generation XML Processing API for SOA and Cloud computing, has been released. Please visit https://sourceforge.net/projects/vtd-xml/files/ to download the latest version.

        * Strict Conformance
        #VTD-XML now fully conforms to XML namespace 1.0 spec
        * Performance Improvement
        #Significantly improved parsing performance for small XML files
        * Expand Core VTD-XML API
        #Adds getPrefixString(), and toNormalizedString2()
        * Cutting/Splitting
        #Adds getSiblingElementFragment()
        * A number of bug fixes and code enhancement including:
        #Fixes a bug for reading very large XML documents on some platforms
        #Fixes a bug in parsing processing instruction
        #Fixes a bug in outputAndReparse()


        [Non-text portions of this message have been removed]
      • heldermagalhaes
        Hi Jimmy, ... Thanks for the update. Nevertheless, please create a new thread [1] instead of replying to an existing post [2]: this will give more visibility
        Message 3 of 5 , Aug 17, 2010
        View Source
        • 0 Attachment
          Hi Jimmy,


          > VTD-XML 2.9, the next generation XML Processing API for SOA and Cloud computing, has been released.

          Thanks for the update. Nevertheless, please create a new thread [1] instead of replying to an existing post [2]: this will give more visibility to the (newly created) thread and reduce the noise at the same time (completely different matters in same threads is weird, simply changing the message subject is insufficient). ;-)


          Cheers,
          Helder


          [1] http://tech.groups.yahoo.com/group/svg-developers/post
          [2] http://tech.groups.yahoo.com/group/svg-developers/message/63966
        Your message has been successfully submitted and would be delivered to recipients shortly.