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

interesting ?"WVG anything more than an hijack of SVG"?

Expand Messages
  • michael bolger
    Came across this message at microsoft_list..(link at svgx.org/subjects.html) interesting.... michael bolger -hope they do not mind that I have copied to
    Message 1 of 6 , Oct 31, 2003
    • 0 Attachment
      Came across this message at microsoft_list..(link at svgx.org/subjects.html)
      interesting.... michael bolger
      -hope they do not mind that I have "copied" to here?


      "Ian" <anonymous@...> wrote in message
      news:E47B05AB-3ADA-4B66-9474-37BE6802CFD2@......
      > Is WVG anything more than an hijack of SVG? What does it add? Why not go
      with a standard?


      This is definitely a FAQ. I've addressed this in a comment on my blog, but
      I'm also going to go in to more depth when i get back to Redmond.

      Here is an excerpt from my post:
      http://www.haloscan.com/comments.php?user=jbeda&comment=150#61721

      "Wrt SVG, I like SVG a lot. We have a rendering model that is very similar
      to SVG so moving content back and forth between WVG (Windows Vector
      Graphics) and SVG should be pretty straightforward. The advantage of WVG,
      when writing Avalon applications, is that it integrates seamlessly with the
      rest of the UI platform and conforms to the programming model conventions
      that our users expect (think VB and WinForms). Since XAML=objects, we can't
      make our markup persistance format be different than our programming model,
      and the programming model/APIs are king."

      Also, I think that the term WVG is confusing and not really helpful:
      "I was just informed (apprently I didn't get the memo) that WVG is a term
      that we are no longer using. We've scrubbed the docs to remove it as it is
      confusing what the difference is between WVG and XAML in general. WVG was
      originally meant to be the subset of XAML elements for doing vector
      graphics. It is essentially the Shapes, Image, Video and Canvas. However,
      the definition was never very strict, and I agree that, in the long term, it
      makes sense to think of the vector graphic specific elements as just part of
      the Avalon stuff built on top of XAML."

      Basically, the reasons are this:
      1) We are more than just a markup langugae. A fundamental part of XAML is
      that it has a direct and straightforward to the programming model. The
      specific syntax of SVG doesn't lend itself to this. Even if it were
      technically possible, we want the vector graphics programming model (when
      not accessed from markup) to be consistent across the entire WinFX API.
      2) The interop between the vector graphic parts of XAML/Avalon and the rest
      of the UI model is much more granular than it would be with SVG.
      Specifically, with SVG, you must have a top level <svg> tag whenever you
      embed it in any host. Vector graphics ends up being a different model that
      exists inside of a box. We wanted to make this line much blurrier. For
      instance, you can put a <Rectangle> element in flow with text without a
      <Canvas> element. To do this with SVG/XHTML, you would have to put an SVG
      tag in there and deal with all of the discontinuities between the XHTML
      model and the SVG model. (They are similar -- but not the same)
      3) We are also more than just a markup and element tree. We also expose a
      drawing context for doing custom control drawing. We don't force users in
      to the declarative model. However, we wanted to make sure that we used the
      same objects and concepts both in the declarative model and the imperative
      model. For instance, SVG has an idea of a pint server. You have to combine
      this with another set of properties to fill a shape. Early on in Avalon, we
      had a Paint object and a Brush object. The Brush object held on to the
      Paint object. This was much closer to the SVG model. However, it confused
      the hell out of users to see these two different objects. We decided to
      work around the markup issues (for instance we don't have a FillOpacity
      property and instead ask users to change the propert on the Brush itself)
      and merge these two objects. If you look through the SDK you can see the
      term Paint here and there.

      There are more reasons, but they aren't coming to mind right now. Watch my
      blog and I'll try to post up there as a FAQ on Avalon Media.

      Joe Beda
      http://www.eightypercent.net

      "Ian" <anonymous@...> wrote in message
      news:E47B05AB-3ADA-4B66-9474-37BE6802CFD2@......
      > Is WVG anything more than an hijack of SVG? What does it add? Why not go
      with a standard?



      [Non-text portions of this message have been removed]
    • Mike McCullough
      An MS insider s view of WVG and SVG?! This is indeed very interesting. ... svgx.org/subjects.html) ... not go ... blog, but ... similar ... of WVG, ... with
      Message 2 of 6 , Nov 1, 2003
      • 0 Attachment
        An MS insider's view of WVG and SVG?! This is indeed very
        interesting.

        --- In svg-developers@yahoogroups.com, "michael bolger"
        <michael@s...> wrote:
        > Came across this message at microsoft_list..(link at
        svgx.org/subjects.html)
        > interesting.... michael bolger
        > -hope they do not mind that I have "copied" to here?
        >
        >
        > "Ian" <anonymous@d...> wrote in message
        > news:E47B05AB-3ADA-4B66-9474-37BE6802CFD2@m...
        > > Is WVG anything more than an hijack of SVG? What does it add? Why
        not go
        > with a standard?
        >
        >
        > This is definitely a FAQ. I've addressed this in a comment on my
        blog, but
        > I'm also going to go in to more depth when i get back to Redmond.
        >
        > Here is an excerpt from my post:
        > http://www.haloscan.com/comments.php?user=jbeda&comment=150#61721
        >
        > "Wrt SVG, I like SVG a lot. We have a rendering model that is very
        similar
        > to SVG so moving content back and forth between WVG (Windows Vector
        > Graphics) and SVG should be pretty straightforward. The advantage
        of WVG,
        > when writing Avalon applications, is that it integrates seamlessly
        with the
        > rest of the UI platform and conforms to the programming model
        conventions
        > that our users expect (think VB and WinForms). Since XAML=objects,
        we can't
        > make our markup persistance format be different than our
        programming model,
        > and the programming model/APIs are king."
        >
        > Also, I think that the term WVG is confusing and not really helpful:
        > "I was just informed (apprently I didn't get the memo) that WVG is
        a term
        > that we are no longer using. We've scrubbed the docs to remove it
        as it is
        > confusing what the difference is between WVG and XAML in general.
        WVG was
        > originally meant to be the subset of XAML elements for doing vector
        > graphics. It is essentially the Shapes, Image, Video and Canvas.
        However,
        > the definition was never very strict, and I agree that, in the long
        term, it
        > makes sense to think of the vector graphic specific elements as
        just part of
        > the Avalon stuff built on top of XAML."
        >
        > Basically, the reasons are this:
        > 1) We are more than just a markup langugae. A fundamental part of
        XAML is
        > that it has a direct and straightforward to the programming model.
        The
        > specific syntax of SVG doesn't lend itself to this. Even if it were
        > technically possible, we want the vector graphics programming model
        (when
        > not accessed from markup) to be consistent across the entire WinFX
        API.
        > 2) The interop between the vector graphic parts of XAML/Avalon and
        the rest
        > of the UI model is much more granular than it would be with SVG.
        > Specifically, with SVG, you must have a top level <svg> tag
        whenever you
        > embed it in any host. Vector graphics ends up being a different
        model that
        > exists inside of a box. We wanted to make this line much
        blurrier. For
        > instance, you can put a <Rectangle> element in flow with text
        without a
        > <Canvas> element. To do this with SVG/XHTML, you would have to put
        an SVG
        > tag in there and deal with all of the discontinuities between the
        XHTML
        > model and the SVG model. (They are similar -- but not the same)
        > 3) We are also more than just a markup and element tree. We also
        expose a
        > drawing context for doing custom control drawing. We don't force
        users in
        > to the declarative model. However, we wanted to make sure that we
        used the
        > same objects and concepts both in the declarative model and the
        imperative
        > model. For instance, SVG has an idea of a pint server. You have
        to combine
        > this with another set of properties to fill a shape. Early on in
        Avalon, we
        > had a Paint object and a Brush object. The Brush object held on to
        the
        > Paint object. This was much closer to the SVG model. However, it
        confused
        > the hell out of users to see these two different objects. We
        decided to
        > work around the markup issues (for instance we don't have a
        FillOpacity
        > property and instead ask users to change the propert on the Brush
        itself)
        > and merge these two objects. If you look through the SDK you can
        see the
        > term Paint here and there.
        >
        > There are more reasons, but they aren't coming to mind right now.
        Watch my
        > blog and I'll try to post up there as a FAQ on Avalon Media.
        >
        > Joe Beda
        > http://www.eightypercent.net
        >
        > "Ian" <anonymous@d...> wrote in message
        > news:E47B05AB-3ADA-4B66-9474-37BE6802CFD2@m...
        > > Is WVG anything more than an hijack of SVG? What does it add? Why
        not go
        > with a standard?
        >
        >
        >
        > [Non-text portions of this message have been removed]
      • frankhileman
        Some of these reasons (programming model and object model) are the same reasons we could not use the SVG object model in our VS integration. It just was not
        Message 3 of 6 , Nov 1, 2003
        • 0 Attachment
          Some of these reasons (programming model and object model) are the
          same reasons we could not use the SVG object model in our VS
          integration. It just was not compatible with what was needed (by VS)
          or expected (by users). But it was not a lack of desire for
          standardization.

          Frank Hileman
        • davewissenbach
          ... svgx.org/subjects.html) ... not go ... blog, but ... similar ... WVG, ... with the ... conventions ... we can t ... model, ... The statement that moving
          Message 4 of 6 , Nov 2, 2003
          • 0 Attachment
            --- In svg-developers@yahoogroups.com, "michael bolger" <michael@s...>
            wrote:
            > Came across this message at microsoft_list..(link at
            svgx.org/subjects.html)
            > interesting.... michael bolger
            > -hope they do not mind that I have "copied" to here?
            >
            >
            > "Ian" <anonymous@d...> wrote in message
            > news:E47B05AB-3ADA-4B66-9474-37BE6802CFD2@m...
            > > Is WVG anything more than an hijack of SVG? What does it add? Why
            not go
            > with a standard?
            >
            >
            > This is definitely a FAQ. I've addressed this in a comment on my
            blog, but
            > I'm also going to go in to more depth when i get back to Redmond.
            >
            > Here is an excerpt from my post:
            > http://www.haloscan.com/comments.php?user=jbeda&comment=150#61721
            >
            > "Wrt SVG, I like SVG a lot. We have a rendering model that is very
            similar
            > to SVG so moving content back and forth between WVG (Windows Vector
            > Graphics) and SVG should be pretty straightforward. The advantage of
            WVG,
            > when writing Avalon applications, is that it integrates seamlessly
            with the
            > rest of the UI platform and conforms to the programming model
            conventions
            > that our users expect (think VB and WinForms). Since XAML=objects,
            we can't
            > make our markup persistance format be different than our programming
            model,
            > and the programming model/APIs are king."
            >

            The statement that moving content between WVG/XAML and SVG should be
            pretty straightforward is quite interesting. If converting content
            between SVG and XAML/SVG is straightforward, then it follows that
            Microsoft could easily adopt SVG as a document interchange format,
            suitable for the same uses as PDF, only as an open standard. So a
            decision by Microsoft not to use SVG as an interchange format looks
            very much like an to attempt exclude interoperability with other
            operating systems.

            Dave
          • frankhileman
            You may be right, but I am not so sure. The XAML thing is not an interchange format -- it is the format that will be produced and edited by their designer. MS
            Message 5 of 6 , Nov 2, 2003
            • 0 Attachment
              You may be right, but I am not so sure. The XAML thing is not an
              interchange format -- it is the format that will be produced and
              edited by their designer. MS has certain ways of producing an object
              model, that is not a 1-1 correspondence with the SVG object model.
              Having gone through VS designer integration I can tell you that the
              SVG object model is not good for that. Nevertheless it is probably
              not that hard to convert the graphics part from XAML to SVG and vice-
              versa. But they would not want to use SVG as the native desginer
              output, because of the messy transition to and from the other. Also
              they want to be able to intermingle graphics and other things, and
              they are not using CSS. I am not speaking for MS but I have a good
              hunch about what happened there.

              SVG is great for portable graphics, but maybe not as good for
              portable graphics engines; that is, if you want to create a
              different type of object model, SVG then becomes an interchange
              format, and not the native format.

              Frank Hileman

              --- In svg-developers@yahoogroups.com, "davewissenbach"
              <davewissenbach@c...> wrote:
              > The statement that moving content between WVG/XAML and SVG should
              be
              > pretty straightforward is quite interesting. If converting content
              > between SVG and XAML/SVG is straightforward, then it follows that
              > Microsoft could easily adopt SVG as a document interchange format,
              > suitable for the same uses as PDF, only as an open standard. So a
              > decision by Microsoft not to use SVG as an interchange format looks
              > very much like an to attempt exclude interoperability with other
              > operating systems.
              >
              > Dave
            • frankhileman
              Having said that (my last post), I think you are right that MS does try to discourate interoperability for things like office documents. They have public
              Message 6 of 6 , Nov 2, 2003
              • 0 Attachment
                Having said that (my last post), I think you are right that MS does
                try to discourate interoperability for things like office documents.
                They have public formats now but they will always use their own
                formats.
              Your message has been successfully submitted and would be delivered to recipients shortly.