Article:		SVG: A Sure Bet
Subject:		State the current situation not just the possible future...
Date:		2003-07-17 06:40:03
From:		ethan estes
I have a real problem with your views on reality of the ease of use of xml. First off I deal with a ton of IsoDraw files and have worked with web cgm. My experience with SVG is very similar-"Get back to me when it does more than create zoomable maps." The technology is slow in the browser-Adobe's reader specifically. BTW: YOU STILL NEED TO DOWNLOAD A COMPANY's PLUG-IN TO VIEW SVG. You still need a graphics app of some sort to make them like illustrator (for anything complex and useful.) Corel has some software out but it is similar to isoDraw in that you have to buy their server etc. They are not cheap either. You need these apps to build things like Wiring diagrams-the real ones not the simplified versions floating around the web that are so easy to make. Your markets are fragmented-multiple versions for different markets ie SVG Tiny. This technology is really only good for an audience who excepts all it's limitations and playback performance issues because the see the promise of it. It does have promise but you need to be a little more honest on it's current state to the people in the trenches working with this stuff. I watch the format all the time and not once has it been a viable format to move intelligent graphic data around in our workflows. And again you have a long way to go to get to the usability of flash files.

Previous Message

Next Message

• State the current situation not just the possible future...
  2003-07-21 11:46:57 Rob Williamson [Reply]
  
  Two points to add to this long string....

  
  Point 1: Clarifying an Small Misconception

  
  I just need to clarify something regarding building SVG applications using the Corel Smart Graphics Studio. You do not, in fact, need a Corel Server to deploy a data driven SVG application. We have a component called, "Process Builder" that allows developers to visually build run-time connections with data and logic without having to write ASP or JSP code (or actionscript for that matter). If you want to build these processes quickly and deploy them on a server that includes some added functions (like image serving, or CGM-SVG conversion) then you need a server.

  
  However, the output of the product is open standard XSLT, SVG, and ECMA that you are free to deploy on the application server of your choice to the viewer of your choice. Our environment does not use any custom extenstions not usable by other viewers or authoring tools.

  
  Again, this speaks to the value of SVG and the underlaying technologies....choice! As long as you are careful to not use proprietary extenstions then you are able to view it and use it in any tool in the 'content' delivery workflow.

  
  Point 2: An observation on this thread

  
  The real opportunity that Corel is seeing is not in making SVG as the be all and end all of XML and W3C browser technology that will replace the desktop as we know it. While this would be fantastic, if the entire SVG community budgets were all added up probably wouldn't be 1/10th of the R&D budget of Microsoft so extending the technology in this direction seems a little aggressive in this early phase of the technology. Exciting, to be sure....but aggressive.

  
  However, what SVG is today is a powerful and low cost enterprise tool for accessing XML data being exposed through Web Services (or ODBC, or HTTP, etc). All enterprises want is:
  1) an assurance that it solves their needs - which are rarely all that complex
  2) that it will interoperate with other vendors seamlessly - without proprietary extenstions or compiled code

  
  That's it....very simple. That is why I am so pleased with the potential of the vendors in this community and the sense of sharing that came out of the SVG open. Now we just need to make sure we don't fall prematurely into any pitfalls resulting in 'proprietarizing' SVG during *any* step in the content flow, from server side databases to client-side interfaces.
  
  
  

• State the current situation not just the possible future...
  2003-07-17 18:11:03 Paul Prescod [Reply]
  
  Ethan says: "Get back to me when it does more than create zoomable maps"

  
  SVG already does animation, video, rendering of arbitrary XML, restyling and is fully scriptable and programmable. It is not even close to CGM.

  
  Ethan says: "YOU STILL NEED TO DOWNLOAD A COMPANY's PLUG-IN TO VIEW SVG."

  
  This is true, for now, if you do not already have the SVG viewer (which you will probably get as a side effect of downloading Acrobat once ASV6 ships). But SVG is being directly implemented in at least one browser: Mozilla. I can't predict if or when Microsoft will follow suit but we know that their Visio group is interested in SVG.

  
  Ethan says: "It does have promise but you need to be a little more honest on it's current state to the people in the trenches working with this stuff."

  
  The amazing thing about the response to the article is that I really meant to be clear that SVG is not ready to take on Flash yet: " It is already clear that SVG will own those markets long before it gets close to replacing Flash and PDF in their core markets"..."Note again how SVG can win without fighting Flash or PDF."
  
  
  

  • Mozilla "support" for SVG (State the current situation not just the possible future...)
    2003-07-18 08:42:12 Damian Cugley [Reply]
    
    Mozilla has, sadly, with the best possible intentions, put SVG support back several years.

    
    First, changes to the plug-in API made Mozilla incompatible with Adobe's SVG viewer 3.

    
    Second, the built-in SVG support does not handle a large subset of SVG, is missing many features.

    
    It does not help that the Mozilla plan for showing SVG in an HTML document is that the SVG code be mixed in with the HTML document, as opposed to living in a separate resource linked to with an 'object' or 'img' element. There is no way to write a document that will work with both these approaches.

    
    Mozilla is my regular web browser, but when I want to run SVG demos, I have to fire up Internet Explorer to do it. Sad.

    
    
    
    

    • Mozilla "support" for SVG (State the current situation not just the possible future...)
      2003-07-19 11:27:00 Paul Prescod [Reply]
      
      

      First, changes to the plug-in API made Mozilla incompatible with Adobe's SVG viewer 3.

      
      

      This has surely done more to hurt Mozilla than SVG. But anyhow, ASV6 will be released soon and that annoying period will be behind us.

      
      

      Second, the built-in SVG support does not handle a large subset of SVG, is missing many features.

      
      

      Standard-build Mozilla's do not have any SVG support and probably will not until the development has reached a more mature point. In the meantime, the plugin suffices.

      
      

      It does not help that the Mozilla plan for showing SVG in an HTML document is that the SVG code be mixed in with the HTML document, as opposed to living in a separate resource linked to with an 'object' or 'img' element. There is no way to write a document that will work with both these approaches.

      
      

      I expect that Mozilla will be able to display standalone SVG resources or OBJECT-embedded resources in addition to SVG mixed with HTML. But until the Mozilla implementation is mature it does not make much sense for Mozilla to prevent the Adobe implementation from handling OBJECT tags. Nevertheless, mixed namespace documents are undoubtably the future we should be working towards. That's what XML was designed to support and newer SVG features move more and more in that direction. It isn't an issue of either/or. We need both inline and out-of-line SVG.