Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

dSVG - A New Kind of Programming? 184

Posted by Cliff from the soliciting-your-thoughts dept.
Gord Bowman writes "For anyone familiar with XML and, specifically, with SVG (Scalable Vector Graphics), you may be aware that SVG is increasingly being used for the creation of data-driven Web applications. But everyone has been doing so by handcoding script and/or XSLT, without the benefit of an IDE to help. Seeing such a need for a tool, my company (Corel) set about creating one." and 'lo, dSVG was born. Gord Bowman is the lead developer of dSVG and would like you to take a look at the dSVG specs (you can find the link, in the full article) and offer your comments.

"It quickly became apparent that while getting a grasp of XSLT is difficult and time-consuming, even more time-consuming was all the scripting it took to create the level of interactivity required on the client via script. Thus we set about creating a library of generic script functions that would assist developers in creating their Web apps. But it didn't take long to realize that this was no good--you can't data-map and transform (via XSLT) functions like you can markup. And, unlike markup, it's much more difficult to auto-generate and customize script via an authoring tool. So I set about designing an XML markup language, implemented with script (so as to work in any SVG viewer), which would describe UI controls and behaviours, so as to facilitate the creation of SVG-based Web applications.

It was a programmer's dream. I was essentially being paid to develop a new kind of programming language. One that, like XSLT, is XML-based but is more procedural in nature and thus easier for the average developer to grasp. It's also easier for non-developers to grasp it, thus bringing SVG and application development to a whole new class of user. A year later, dSVG (Dynamic SVG) was unveiled to the public as part of the Corel Smart Graphics Studio. And as of yesterday, the full dSVG 1.1 Specification and Test Suite became available for download.

The UI controls were designed to allow complete customization of appearance, and to allow for use with forms without being tied to a forms-specific model. The behaviors were designed to be generic and higher level than DOM methods, so as to be more intuitive to non-developers. The resulting markup language allows data-driven Web applications to be created with little or no need for scripting.

While script is very useful and powerful, markup has many advantages:

- markup is more easily understood by non-developers
- markup can be easily data-mapped and transformed using XSLT
- markup can be easily generated via an authoring tool and customized by the author
- markup is semantically meaningful, promoting interoperability on the authoring side
- markup can be standardized, thus helping the adoption of SVG

dSVG was implemented with script so as to work in different SVG Viewers. However, Corel has proposed dSVG to the SVG Working Group in the hopes that through a collaborative effort, dSVG will lead to the eventual creation of standard markup for UI controls and behaviors. These could then be natively implemented, bringing about even more advantages:

- faster
- less data to transfer
- less need for a script engine on small devices (which can take up a significant part of the footprint)

The dSVG 1.1 spec and test suite was posted for download with the goal of allowing the developers and non-developers to experiment with the markup and to provide feedback. This feedback will help me to improve upon dSVG and will also help the SVG Working Group to better assess how the developer community feels about such standard markup being added to the spec for the purpose of developing SVG-based Web applications.

I hope you will take the time to read through the dSVG spec, try out the test suite, and perhaps even create some of your own content. As the creator, I am obviously passionate and excited about dSVG. And having seen how quickly even non-developers can create Web apps, I feel certain that XML-based programming makes sense and is the way of the future. But being a long-time reader of Slashdot, I would love to hear what the Slashdot community thinks. dSVG may not lead to world peace, but I think it has the potential to change the fundamental way in which Web applications are created.

I look forward to hearing your comments.

Sincerely,

Gord Bowman
Lead Developer, Corel Corporation"
This discussion has been archived. No new comments can be posted.

dSVG - A New Kind of Programming? More

dSVG - A New Kind of Programming?

Comments Filter:

  • Sounds great... (Score:5, Insightful)

    by Tet ( 2721 ) <slashdot@astCHEE ... .co.uk minus cat> on Saturday July 19, 2003 @01:05PM (#6479255) Homepage Journal
    ...now all we need are some browsers with native SVG support. With the Mozilla SVG [mozilla.org] project still seemingly no closer to delivering a shippable release, and no hope whatsoever of MS releasing an SVG enabled IE, looks like we're stuck with the Adobe plugin for now. Until we get past that, I doubt SVG will enter the mainstream (more's the pity).
    • Yeah, once we get SVG browser support we can look forward to SVG banner ads.

      • Sigh (Score:2)

        by jefu ( 53450 )
        Ah, someone as cynical as me.

        Still, I think SVG is likely to be a sufficiently valuable addition to browsers that it is worth pushing for.

    • Re:Sounds great...Less filling. (Score:1, Informative)

      by Anonymous Coward
      This sadly is unfortunately true. I have to do some of my SVG development using IE, and the Adobe SVG plugin (which hasn't been updated BTW). X-Smiles isn't really a browser in the sense Mozilla and IE is. All the rest is either outdated, or beta/alpha. Amaya with OpenGL has issues with my libraries. This overall is a sad state of affairs for something that's suppose to be a standard.

      • Adobe SVG viewer (Score:2, Informative)

        by ergo98 ( 9391 )
        The Adobe SVG viewer recently, and surprizingly, had a beta of version 6.0 come out. This can be found here [adobe.com]. Of course because the Mozilla folks changed the plug-in mechanisms, it still crashes Mozilla, but this is great news from Adobe as many rumors were that the entire SVG team was canned. Obviously that isn't true, and they continue to develop upon it. Corel, as you obviously know if you read even the summary of this article, has a great viewer out as well, along with a variety of tools for working wit

    • Re:Sounds great... (Score:4, Interesting)

      by bwt ( 68845 ) on Saturday July 19, 2003 @01:27PM (#6479388)
      I agree completely that browsers need to support SVG, and until this is more advanced, tools like the one in this article are getting ahead of things (not that that's necessarily bad). People should vote for Mozilla bug 122092: "Enable SVG support". Ultimately, this needs to be done without plugins -- its really just another image format.

      The Konqueror browser seems to have a push to get SVG going too: KSVG [kde.org], but it has a way to go ("Release 0.1 pending").

      There are a good set of SVG resources [protocol7.com] for Linux. The Apache Jakarta projects java SVG viewer, Batik is probably the farthest along.

      • Re:Sounds great... (Score:4, Insightful)

        by Anonymous Coward on Saturday July 19, 2003 @02:00PM (#6479558)
        People should vote for Mozilla bug 122092: "Enable SVG support"

        Voting doesn't write code. Writing code writes code. You can vote for it all you want, but if nobody writes it it won't make a difference.

        On the other side, if you write the code for it, and give it to Mozilla, then nobody will need to vote for it.

      • I agree completely that browsers need to support SVG, and until this is more advanced, tools like the one in this article are getting ahead of things

        According to this logic, Adobe is getting ahead of themselves making products that generate PDF until the browsers natively support PDF. PDF is handled by a plugin. SVG is handled by a plugin. They plugins come from the same company. So why is native browser support a necessary condition for SVG's success?

        That said, there are some advanced features that c

        • PDF is handled by a plugin. SVG is handled by a plugin. They plugins come from the same company. So why is native browser support a necessary condition for SVG's success?

          Because PDF tends to be used for standalone documents, where SVG tends to be embedded within a web page. This means that PDF is usable even without a plugin (by using an external application -- in this case, Acrobat Reader). Indeed, I use it like that, finding it more convenient than using the plugin. SVG, on the other hand, can't work li

          • This means that PDF is usable even without a plugin (by using an external application -- in this case, Acrobat Reader).

            The Acrobat Reader is basically the same as the Acrobat plugin. You have to download it and install it. You do the same thing with a plugin. Yes, a standalone viewer is different technically than a plugin but how does this affect the marketability of the underlying standards.

      • Integration! Integration! (Score:4, Interesting)

        by fm6 ( 162816 ) on Saturday July 19, 2003 @05:37PM (#6480996) Homepage Journal
        I agree. SVG lovers place too much emphasis on interactivity. Maybe someday SVG will challenge JavaScript, but right now that's less important than the fact that graphic support in current web browsers is screwed. Right now, most web graphics uses some kind bitmap. There's either lossless [w3.org] or lossy [jpeg.org] compression, but there's still too many bits, even if you have a fast connection. Nor do web sites like paying for the extra bandwith. SVG deals with this problem very neatly.

        (No, I didn't forget PNG [libpng.org]. It has some technical and ideological advantages, but browser support is still, well, incomplete.)

        So what's wrong with SVG plugins? They don't exploit the full power of SVG. It's not just a graphics format, it's an XML application. In other words, it's a markup language, just like HTML. A good XML-aware browser (something both IE and Mozilla pretend to be) shouldn't isolate SVG from the rest of the document.

        Consider the gif-filled Slashdot page you're looking at right now. They have gotten rid of a lot of bitmaps (though the left hand clickbar looks slightly less cool as a result). But they still use some weird little bitmaps [slashdot.org], plus a lot of weird tables and font kludges that are hard to maintain and tend to be browser dependent.

        There's a simple fix: put SVG support in the browser (it is a W3C invention after all) and allow indiscriminate embedding of XHTML and SVG in each other. (Not to mention any other XML applications the browser happens to support.) The Mozilla people know this [mozilla.org], but still consider SVG support experimental and non-standard. This has been the status quo for quite some time, and given AOL's abandonment of Gecko, is not likely to change.

        Maybe if Mozilla had concentrated on basic technological improvements like this and less on eye-candy and silly features... well, AOL, would probably still have screwed them over. But I might feel bad about it.

        KHTML looks to be the new leader in open-source web browsers. And their does seem to be a lot of interest in using the engine to render SVG [kde.org]. Alas, the KDE people still think of SVG as something you embed in something else.

      • It can be scripted and can contain scripts and fire events, it forms part of the page's object model, it's *not* like implementing 'just another image format'.

        Yeesh.
    • Goto Adobe's svg demo site with corel's plugin and it tells you you need adobe's. Goto Corel's svg demo site with Adobe installed and it tells you that you need Corel's.

  • Goodbye RFC, hello Slashdot (Score:5, Interesting)

    by Psychic Burrito ( 611532 ) on Saturday July 19, 2003 @01:11PM (#6479292)
    Shouldn't new standards be introduced using RFCs? I'm not sure if it's a good trend when they are presented first on Slashdot...
    • this is just a library ontop of the already existing RFC specifications. This is more or less a platform to create SVG images easier.

    • Re:Goodbye RFC, hello Slashdot (Score:5, Informative)

      by Homology ( 639438 ) on Saturday July 19, 2003 @01:28PM (#6479389)
      Shouldn't new standards be introduced using RFCs?

      Well, from download [corel.com] page we have :

      This file contains the proposal submitted to the World Wide Web Consortium (W3C) SVG Working Group to enhance SVG's support of enterprise application development for dynamic interfaces

      along with an EULA whose length put even the MS one to shame.

      However, I can't download the proposal without first agreeing to the EULA, so good riddance. If I was sufficiently interested I probably could look it up at W3C site.

    • Re:Goodbye RFC, hello Slashdot (Score:4, Informative)

      by Gord Bowman ( 689736 ) on Saturday July 19, 2003 @01:29PM (#6479399)
      dSVG is NOT a spec being proposed by the W3C. It's something we came up with ourselves for our product, and then proposed to the SVG Working Group. The concept of having "standard" markup for UI controls has been around a long time, but it hasn't happened yet. Maybe we're not asking enough people if it's what they really want or not. And if we want it, does it belong in SVG or should it be something larger and more generic in its own spec? And the idea of using XML for procedural programming is pretty new, I think. At least I had never found another example of it. Maybe someone else knows of one though. Regardless, I strongly believe in asking communities what they want rather than telling them what they want, and I also strongly believe in getting ideas and constructive feedback from people outside of the SVG-world. I couldn't think of a better forum than Slashdot to solicit that type of feedback.

      • Any patents involved? (Score:4, Insightful)

        by Homology ( 639438 ) on Saturday July 19, 2003 @01:49PM (#6479506)
        dSVG is NOT a spec being proposed by the W3C. It's something we came up with ourselves for our product, and then proposed to the SVG Working Group.

        Since this appear to be a product by a comercial company, it sort of begs the questions : Is any patents filed relating to this, or is any existing patent involved? This includes any technology necessary to implement dSVG.

        I apologize if I appear impolite, but I'm getting cynical as I age.

      • XML-RPC sounds pretty procedural to me.
        http://www.xmlrpc.com/
        I know this from PHP, my favorite scripting language so far.

      • Re:Goodbye RFC, hello Slashdot (Score:4, Interesting)

        by russcoon ( 34224 ) on Saturday July 19, 2003 @03:17PM (#6480183) Homepage
        Gord,

        Using XML for procedural programing isn't new. ANT comes to mind. Unfortunantly it turns out it's a really crappy language to program in (overly verbose, etc...). It does, however, make a decent glue language for putting down the declarative portions of a GUI.

        As for the usage of XML-ish markup to define widgets, that's also not really very new. XUL, GLADE, netWindows (my project) all come to mind. The problem is tying them to data and programatic constructs. It's nice to see you're taking a similar tack with your wiget set as we are, however I tend to think that the minute you start writing standards around your toolkit, you only decrease your room to improve in the future. The community, i hate to say it, really doesn't know what they want which is why innovation is so powerful. It takes independent thought and originality to come up with someone else's old hat, and it seems you have that in spades. The trick is to not imagine that the community at large is imbued with the same qualities. The world at large doesn't care. You have to reach people with a need for what you want to do. The are the only ones that really matter.

        A small dev team of people that grok what you're talking about and are interested in assisting you in making things better is usually going to yeild significantly better results than throwing something to the winding and seeing what takes off. In the worst case, you've satisfied the needs of the people that have needs in the first place, which isn't a bad place to be (although it can surely be obscure).

        Anyway, I'd like to talk with you more about your toolkit. Your email addr isn't in your profile, so you can reach me at alex@netWidows.org.

        Regards.
      • And the idea of using XML for procedural programming is pretty new, I think. At least I had never found another example of it. Maybe someone else knows of one though. CFML (Cold Fusion) has been around since '96 (IIRC). It is a tag-based procedural language. It suffered from its accessibility to non-programmers. I'm not a fan of obfuscation for obfuscation's sake, but CFMLs reputation was hurt by poorly implemented programs designed by amatuers. dSVG could suffer the same fate, but I don't really k

  • Windows only? (Score:3, Interesting)

    by Tumbleweed ( 3706 ) on Saturday July 19, 2003 @01:14PM (#6479307)
    Okay, so when are the Mac OS X and Linux versions due out? This is a pretty amusing situation - a development studio/language for something that isn't viewable without a plugin on its only supported OS?

    • Re:Windows only? (Score:2, Informative)

      by Gord Bowman ( 689736 )
      The final output runs in any standard SVG viewer, and some of them run on Mac and Linux (although not Corel's SVG Viewer yet, but only because we're concentrating on finishing up implementing the full SVG spec first). But yeah, CSGS is currently a Windows only product, and again, just because of limited resources right now--if there's enough of a market for selling CSGS for other platforms, I'm sure that would speed up our supporting them. If you would actually buy it if only it supported Linux or Max, plea

      • Re:Windows only? (Score:4, Insightful)

        by Tumbleweed ( 3706 ) on Saturday July 19, 2003 @01:51PM (#6479516)
        Personally, I would not buy the product no matter what platform it runs on because of the (sad) state of SVG support in the browser market, and the foreseen SVG support in the coming years. With IE not being updated for the next 2 years, only Mozilla, Opera, & KHTML variants will be likely to have any decent SVG support anytime soon, and even that is just a possibility, and hardly a foregone conclusion. Your product may be the greatest thing for SVG that has come along (not that that would be saying much, considering), but SVG support, for all _practical_ considerations, is nearly non-existent in browsers, and as a percentage of the surfing public goes, will remain so for years to come. Your product seems like a solution waiting for a market to develop. I don't think that market is GOING to develop for another 2 years, at the soonest. We'll have to wait and see if Microsoft deigns to include usable SVG support in the Longhorn-generation of IE, or whether they cripple & abandon it like they did PNG support. If the latter is the case, then your product may never be useful enough for Corel to continue to support unless Mozilla/Opera/KHTML-based browsers actually start taking significant browser marketshare away from IE.

        Good luck on what seems like a fun project, though. Some people will certainly find this product useful, but whether it's enough of a customer base to continue development on is a big guess. Risk big, win big, though!

        • Re:Windows only? (Score:3, Insightful)

          by smallpaul ( 65919 )

          Personally, I would not buy the product no matter what platform it runs on because of the (sad) state of SVG support in the browser market, and the foreseen SVG support in the coming years. With IE not being updated for the next 2 years, only Mozilla, Opera, & KHTML variants will be likely to have any decent SVG support anytime soon, and even that is just a possibility, and hardly a foregone conclusion. Your product may be the greatest thing for SVG that has come along (not that that would be saying mu

          • Bah. Adobe knows how to make a plugin work, but just barely. Try scripting against the PDF.OCX sometime. It's unsupported, but it's how Adobe does it -- and even though it is unsupported, since it's a COM object it has a publicly declared interface. Play with it for a few minutes and you'll quickly learn it's very inconsistent and unstable. Play with it on several different platforms, and you'll experience a whole new range of inconsistency.

            PDF is undoubtedly a convenient format, but Adobe's position on t

            • PDF is undoubtedly a convenient format, but Adobe's position on the format is highly restrictive and very unfriendly to developers. PDF has enormous potential which is mostly untapped because of this. Their history with PDF has made me (and many others) regard SVG with a great deal of suspicion. I personally believe they're hoping it'll displace Flash some day, at which time they'll take the same developer-unfriendly approach to SVG that they currently maintain with PDF.

              There is a big difference. Adobe

              • Interesting. Perhaps my suspicion is misplaced then. I was not aware that they didn't own the spec. In that case, I think SVG's major weakness is a lack of promotion and awareness, and this weakness should not be underestimated -- it has buried countless other very good standards.

      • Re:Windows only? (Score:4, Interesting)

        by appleLaserWriter ( 91994 ) on Saturday July 19, 2003 @02:06PM (#6479622)
        Mr Bowman,

        I represent a growing provider of diverse Internet services. We have determined that the Linux platform is by far the most cost effective platform for new projects. Because we have selected Linux as the standard server platform, we find that Apple's Unix-based OS X platform is ideal for desktop use by designers and engineers who produce our new projects. Although we consider tools that require the Windows platform, we are most seriously interested in products that support OS X or Linux. In our experience, many other growing internet ventures hold a similar opinion.

  • Holy legaleze Batman! (Score:5, Insightful)

    by PDHoss ( 141657 ) on Saturday July 19, 2003 @01:15PM (#6479313)
    Can someone summarize if I am going to get 20-to-life and a cellblock husband if I download the spec?

    Jeez, how many paragraphs into the legal requirements do you have to be before you realize that ain't reeeeeal conducive to getting people to beta/bug track/improve your product for free?

    PDHoss
    • Yeah, I know... lawyers. What can you do. I'm not looking for beta testers though--I'm more interested in what you all think from more of a philosophical perspective. Does programming via markup make sense? Might this sort of thing grow into a real, honest-to-God, full-featured programming language one day? Is the fundamental design sound? That sort of thing.

      • Re:Holy legaleze Batman! (Score:2, Funny)

        by Anonymous Coward

        What can you do.

        The GNU revolution is in after mode, how about

        rm -rf /lawyers

      • Re:Holy legaleze Batman! (Score:2, Insightful)

        by Anonymous Coward
        I'm not trolling, I'm serious.

        Gordon Bowman wrote:
        Might this sort of thing grow into a real, honest-to-God, full-featured programming language one day? Is the fundamental design sound? That sort of thing.

        I'm sorry to break this here on slashdot, but if you are so alone at Corel that you don't even have any (qualified) collegues to discuss design matters with, but post them to slashdot of all places to get well thought answers - maybe especially after such legal mumbo-jumbo, you should have a serious tal
    • (Or should that be "A License of which one could be proud")

      Every so often I look at these things closely to see what amusements lie therein. This one has some fun bits. Some of these seem to stem from an attempt to build a license for every possible product and combination of products - thus in this single license you're agreeing to licenses for Clip Art, iGrafx (or IGRAFX - possibly a different product, who knows), Trellix, some SDK and in every country possible. So, here are a couple excerpts from t

  • Future possibilities for improvements (Score:5, Informative)

    by Gord Bowman ( 689736 ) on Saturday July 19, 2003 @01:17PM (#6479323)
    Wow, this actually got posted. Cool. Let me first say that the dSVG 1.1 spec is still evolving. There's lots of room for improvements. For instance, there's an 'if' element, but no 'elseif' or 'else' elements yet. Those are obviously needed. I originally thought that a DTD could not (or should not) define an element as being dependent upon a sibling, but after talking with some XML experts at the SVG Open conference in Vancouver this past week, I see now that I was wrong. Another needed feature is some kind of a fallThrough="true|false" attribute for the 'case' elements within a 'switch' element--mimicking the 'break' statement but in a more XML-ish way.

    One huge area for improvements is in the design of the skins. It seemed like a good idea at the time, but I now see that it has limitations both for performance and for the creation of custom UI controls. More on that in a separate comment...

    The fact that dSVG is implemented with script is, for now, a good thing because it allows us to make changes to the spec without the viewer, since the implementation gets passed along with the content. And for previously written content, the Corel Smart Graphics Studio (CGSG) IDE will automatically convert from the old version of dSVG to the new version (via XSLT).

    I have a big list of ideas for improvements, but it's back at home and I'm still in Vancouver for a few more days attending meeting (so I apologize in advance if I am not always responding in a prompt manner). I'm really interested to see what other developers think of the spec thus far and how it could be improved.

    • Can you please post the spec by itself? (Score:4, Insightful)

      by tmoertel ( 38456 ) on Saturday July 19, 2003 @01:31PM (#6479411) Homepage Journal
      I am interested in reviewing the spec, but it's presently tied to the test-suite software, which is locked away behind a long, complicated, and scary-looking license agreement that I'm not comfortable agreeing to. Could you please provide a link to just the spec?

      Since you have already submitted the spec to the W3C SVG WG, it's already public knowledge, and there's no reason to hide it behind legalese, right? Can't you just provide a link straight to it?

      I'm sure a lot of other people are more interested in the spec than anything else. If you want them (and me) to take a look at dSVG, please make the spec available by itself.

      Thanks!

      • Re:Can you please post the spec by itself? (Score:5, Informative)

        by Gord Bowman ( 689736 ) on Saturday July 19, 2003 @01:45PM (#6479490)
        Hmm. That's a good idea. It's actually my fault, really. They asked me if I could post just the spec and I said that the spec currently linked to the slides in the test suite and that I thought most people would like to actually play around with it. So they said, okay, but we'll need a EULA then. And I said, okay, and then went off to my SVG Open conference. So yes, I'll look into just posting the spec without all that legaleze stuff. It's the weekend, though, so I doubt it would happen until Monday.

        • So yes, I'll look into just posting the spec without all that legaleze stuff.

          Excellent! Thanks for being cool about this.

          It's the weekend, though, so I doubt it would happen until Monday.

          Can you give us anything right now? Monday, I'll be working, but today I can look at your spec. I'm sure a lot of other Slashdot readers are in the same boat. Also, on Monday, your article will be long gone from the Slashdot front page, and so you might want to make better use of this opportunity to introdu

      • Here's a link to just the spec. No agreement needed: http://www.corel.com/content/CSGS/zips/dSVG11Spec. zip [corel.com]

  • As much as this interests me, forget it! (Score:4, Interesting)

    by Jack William Bell ( 84469 ) on Saturday July 19, 2003 @01:23PM (#6479357) Homepage Journal
    There is no way I am going to 'read and understand' all that legal language. I would rather create my own competing specification than do that.

    So, either release it under a license I can understand (one consisting of ten or less paragraphs) or forget it!

  • Useless (Score:1, Insightful)

    by Anonymous Coward
    This sounds like a typical case of cowboy developper meets the garage boys (See Wiki for more details). This new scheme is closed source hence, I categorically refuse to use it for my company. This smells like a lockout. Ontop of that, it feels like only that one developper worked on designing the spec. The last person I want to see design a spec is a developper (even worst if it was ONE developer). They have no clue what the users want or would like to have. Basic marketting non-sense and probably wh

  • Adopting SVG (Score:3, Interesting)

    by HisMother ( 413313 ) on Saturday July 19, 2003 @01:26PM (#6479380)
    SVG is a Good Thing, and it would be fantastic if it had broader browser support. Is anybody sufficiently familiar with the dark corners of the standard to explain why we don't see more implementations? Would it really be so hard for Adobe to update their Linux implementation to work with current browsers? Why isn't Mozilla/SVG farther along?

  • Code examples (Score:2, Informative)

    by AmVidia HQ ( 572086 )
    IDE's to make programming a language easier is always a good thing. Vector graphics client is still dominated by Flash, but demand for more widespread SVG clients will occur when there are apps for it.

    HTML pasted from the Spec, judge for yourself how it looks:

    9.6 Example #1

    dSVG sample behavior: focus - with added attributes focusGroup and focus
    Content of file: dsvg:focus, dsvg:setTransform, dsvg:setAttribute, dsvg:setStyle, (added attributes dsvg:focus, dsvg:focusGroup)
    The dsvg:focusGroup attribute adds

  • adverts? (Score:4, Funny)

    by mz001b ( 122709 ) on Saturday July 19, 2003 @01:33PM (#6479421)
    I think this should have read:

    "Hi, my company just came out with a new product and told me that I get a huge stinkin bonus if I managed to get an advertis^H^H^H^H^H^H^H^Harticle on it posted on /., so please click on this link..."

    • Absolutely. Unfortunately the other efforts which Corel have made at attempting to become lead early adopter of technology eg Linux and Java have ended in what many would term disaster. With that track record I would be dubious about anything Corel promote, esp when the IDE is a grand a go.
    • I know it's not open-source, but we HAVE proposed the spec to the SVG Working Group for consideration. I want it to LEAD to a standard, after lots of feedback and collaborative discussion, not to BE the standard as-is. I'm only one developer--what are the odds that I thought of everything? Zilch.
  • I didn't have any luck with the Corel
    SVG Viewer and Mozilla 1.4 on W2K.
    I suppose a Linux version is totally
    out of the question... :-(
    • Hmm, I know we've had the CSV working with Mozilla on W2K before... maybe not with Mozilla 1.4? I'll look into it. As for a Linux version, NOTHING is ever out of the question. It's all based on demand right now--we have a ton of tasks to do and each one of them has a priority. If a lot of people want CSV on Linux, then that will bump up the priority.
      • I think that a lot of people would like in Mozilla to see SVG directly in XHTML without any plugins. In fact, no need develop anything new, just finish what you have already started with that libart. Nothing will frustrate more than if Mozilla developers will drop very good non-proprietary feature (SVG) unfinished and jump to support a commercial plugin.

        A strong benefit of SVG native support vs a proprietary plugin is an integration of the page (XHTML) scripting (javascript) with SVG. With plugin you've g

  • Direct link to the spec (Score:1, Informative)

    by Anonymous Coward
    dSVG11Spec.zip [corel.com]

    Jeeze Corel, don't be wankers. If you want a *public* review of your specification for a _proposed_standard_, don't make people agree to give away their first-born.
  • Can anyone tell me? I've used svg + javascript + DOM. IT works very well and is supported in adobe's pluggin and is the offical w3c recomendation for making svg dynamic. Why confuse the situation? What need is there for dSVG?

  • -1 (Score:2)

    by zephc ( 225327 )
    -1, screenshots are too small, resubmit

    oh, wait, this isnt K5...
  • having seen how quickly even non-developers can create Web apps, I feel certain that XML-based programming makes sense and is the way of the future

    By that criteria, PPOP (Power-point oriented programming) will be the wave of the future.

  • Waiting for SVG pop-up windows. (Score:3, Insightful)

    by bons ( 119581 ) on Saturday July 19, 2003 @02:45PM (#6479959) Homepage Journal
    So, someone is creating an OO script/language for vector graphics...

    Now that you've approaching Flash 5, can you please explain what you're hoping to accomplish?
    Since their plug-in is commonly installed, their standards and documentation are apparently about as open and propriatory as yours, and since the number of people who can tell the difference between flash and dhtml is minimal, I'm not sure what the actual goal here is.

    According to the normal timetable, Flash 7 should be released before the year is out and that seems to be your primary competitor. Unfortunately it also offers video, sound, raster graphics, and a good lead on a decent OO scripting langage. Oh wait, that's Flash 6.

    Is there something new you're offering (other than a different set of lawyers) that we should be noticing?
    • Is there something new you're offering (other than a different set of lawyers) that we should be noticing?

      Let me see:

      • The ability to navigate using the traditional back/forward buttons (although I believe the lastest versions of Flash support this to some extent).
      • The ability to resize text so it's halfway readable.
      • The ability to cut and paste text.
      • The ability to use my standard ctrl-pageup/pagedown keys to switch between tabs in Mozilla (as well as other browser keyboard accelerators) without them getting intercepted by the Flash plugin.
      • The ability for search engines to index the content I'm presenting.
      There are many reasons why Flash is fundamentally flawed, and SVG is a much better solution in the long run. Only time will tell if the market is able to see that.
      • Yup, and there's plenty more reasons why SVG is often preferred over Flash. It's a standard, for one thing. A lot of people like standards. Our dSVG has been proposed to the SVG Working Group, so we hope that it will lead to a standard also. Standards are good.

        It's also easily data-driven since it's XML. Flash is good for multi-media, but I (personally) doubt it will ever be a major player in the data-driven graphics/apps space. The idea of creating a pure XML solution, from beginning to end, is very appea
      • well:

        * back/forward works.
        * resizing text works, in fact you can easily resize/zoom the entire flash movie. I never have a problem with unreadable flash files, often I have a problem with unreadable html files (with hard-fixed CSS fonts) at 1600x1200, it starts to become an issue. I guess the only "problem" is that Flash usually uses unhinted anti-aliased fonts, but you can use the systems font renderer if you want it. And, as resolutions go up, this downside becomes an advantage.
        * cutting and pasting text
        • * resizing text works, in fact you can easily resize/zoom the entire flash movie. I never have a problem with unreadable flash files,

          It barely works. The word "easy" is not valid here. If a page is made with flash and tiny fonts, I can individually right-click each Flash area to zoom in the size by 2x. The amount of space allocated on the page doesn't change, so now I"m stuck dragging it around with the mouse to see the whole thing. Is there a way to resize a flash within a page, not just zoom in on i
        • back/forward works

          Not on any site I've seen, and not with any version of the Flash plugin I've used (I'm using 6.0 r79, which is the latest released version, according to Macromedia). Care to provide a URL where I can see this is action?

          resizing text works

          Nope. Zooming is not the same as resizing. It is also waaaay to clumsy to be useful on a regular basis. It's far easier to just give up on the site and go somewhere else.

          cutting and pasting text works

          Again, not in any version of Flash I've used.

          • All these things don't come "automatically", you have to choose whether you enable it or not.

            (that in itself might be a major downside, but it's not that it's impossible, it just becomes the responsibility of the designer - blame the people, not the format)

            * back button example/"experiment"
            http://www.robertpenner.com / experiments/backbutton /backbutton.html

            * resizing text
            You can make the swf scale with the browser window (easy, and I don't see why alot of designers choose to use a fixed size for their si
    • According to the normal timetable, Flash 7 should be released before the year is out and that seems to be your primary competitor. Unfortunately it also offers video, sound, raster graphics, and a good lead on a decent OO scripting langage. Oh wait, that's Flash 6.

      Well, there you have one problem with Flash: a new version every year. And that's not a coincidence: it's the way the format can appear to be open yet ends up being proprietary for practical purposes.

      Is there something new you're offering (ot

  • Where does it stop? (Score:3, Insightful)

    by Animats ( 122034 ) on Saturday July 19, 2003 @02:45PM (#6479961) Homepage
    It's tough to do this well. Where do you stop? When you have an animation system? A game engine?

    I'd like to see more open-source tools to create Flash format. Flash is a really good implementation of vector graphics - the engine is small, the files are small, and the system is very powerful. It took Macromedia three rounds to get it right (remember Director?) but finally, they did it.

    Flash format is open, and there are a few non-Macromedia tools for it. But not enough. I once looked into doing a Flash tool for stock charts, so you'd get the raw data from the server and could pan, zoom, and do typical stock-chart operations like moving averages locally. It's possible.

  • .. we are and its fantastic. First of all, all our clients are running either Windows (98 to XP) or Mac OS X .. Adobe's plug-in is working just fine. We made a small modification to the Apache config file and feed our SVG files through the PHP interpreter first -- with PHP code embedded in the SVG file. Much of the data begin display on our clients SVG drawings are dynamic and sourced from a MySQL database. As the database is updated, the SVG drawings and figures change automatically. Saves a ton of w
  • Screen shots screen shots , how'd I know i want it with out screen shots
  • One more tool for the trade.
    Let's go for beer.

  • Example Markup - checkBox and setData (Score:3, Informative)

    by Gord Bowman ( 689736 ) on Saturday July 19, 2003 @04:21PM (#6480579)
    For anyone scared to death by that EULA (I've been assured it's harmless), here is a couple of checkboxes that change the data of a text element. More examples to come.

    Gord

    <svg xmlns:dsvg="http://www.corel.com/schemas/2002/dSVG 11" xmlns:xlink="http://www.w3.org/1999/xlink" height="410px" width="744px" onload="init(evt)" viewBox="0 0 744 410">
    <script type="text/ecmascript" xlink:href="dsvg11/dSVG.js"/>
    <script type="text/ecmascript" xlink:href="dsvg11/baseUI.js"/>
    <script type="text/ecmascript" xlink:href="dsvg11/constraint.js"/>
    <script type="text/ecmascript" xlink:href="dsvg11/button.js"/>
    <script type="text/ecmascript" xlink:href="dsvg11/setData.js"/>

    <dsvg:checkBox toggle="true" xlink:href="dsvg11/skinCheckBox_Default.svg#skinCh eckBox" autoScale="true" disabled="false" selected="false" height="12" width="12" y="70" x="50" label="Check Box 1" id="checkBox1">
    <dsvg:setData value="Sample of setting data." elementID="checkBoxLabel" id="dsvgUniqueID_8"/>
    </dsvg:checkBox>
    <text y="80" x="150" fill="green" id="checkBoxLabel">label</text>
    <dsvg:checkBox toggle="true" xlink:href="dsvg11/skinCheckBox_Default.svg#skinCh eckBox" autoScale="true" disabled="false" selected="true" height="12" width="12" y="120" x="50" label="Check Box 2" id="checkBox2">
    <dsvg:setData value="Sample of setting data." elementID="checkBoxLabel2" id="dsvgUniqueID_9"/>
    </dsvg:checkBox>
    <text y="130" x="150" fill="green" id="checkBoxLabel2">label</text>
    </svg&g t;
  • http://xpserver.mozdev.org/ xpserver is complicated and not finished, although there is a group in India actively working on it.

    From the web site: mod_PX7 then uses XPCOM to load and run the components. The components can be chained using SAX-like events. For example a database component can do a query. The output from the db component is expected to be in XML. This XML can be sent to the browser or fed into another component. For example, an XSLT style sheet. The output from the stylesheet can then go to

  • How is this better than regular SVG scripting? (Score:3, Insightful)

    by kahei ( 466208 ) on Saturday July 19, 2003 @07:15PM (#6481392) Homepage

    In terms of constructs like 'if' and 'elst', I'm not convinced that wrapping the SVG object model in a layer of xml tags will do any more good than wrapping stuff in a layer of xml tags usually does.

    However, it's good to see a widget set being produced for SVG. If a powerful, standard widget set evolves that'll be immeasurably useful in promoting SVG and taking advantage of SVGs natural strengths.

  • Why bother? That arsehole who is CEO of Corel is going to sell the whole kit and kaboodle for about 1/100th its actual value to some private outfit in California, who is going to kill the company because Microsoft wants them gone.

    It is a complete piss-off. Corel is just about to hit turn-around point now, has an infuckingcredible product lineup -- Painter, XMetal, Ventura, iGrafx stuff, Graphigo, Draw -- and looks like its ready to really start kicking ass.

    But no. Kill it instead. Even Cowpland could

  • I for one love the idea of being able to develop SVG applications.

    While it's true that SVG currently need a plug-in, that its installation base is quite small compared to Flash (but most people installing Adobe Acrobat install the SVG plug-in without even noticing), the SVG specification is a W3 Standard, and it's easier to integrate with other Open Source tools on the server side.

    I doubt that dSVG will initially appeal to a large public who won't see the point of it over Flash for multimedia applicatio

    • It must also be recognised that while the technology to build really powerful web application is there in IE, Mozilla, Opera and al, there are very few really interactive applications using those technologies, simply because there is not enough compatibility between the various standard implementations, and to work around those is too costly and difficult to manage well.

      Check out TIBET [technicalpursuit.com] from Technical Pursuit. It's a full browser application environment, built using JavaScript. They decided on JavaScript

  • kevlindev (Score:2, Interesting)

    by AnEmbodiedMind ( 612071 )
    This is similar to KevLinDev's SVG GUI [kevlindev.com] code.

    While the Corel guy is using an XML GUI language, this is the Scripting approach that the he has chosen not to use. With the code on the KevLinDev site you can create various SVG widgets, with a call to a javascript function.

    I think I'd prefer to do it this way, rather then use XML if I was doing it by hand, as it is closer to normal GUI API's then some verbose XML language. I guess the XML approach would probably be great for the back-end standard for various

  • Could be that svg might reap benefits that could really be great for music notation given the right approach. The Recordare musicxml extentions could be used to quickly format music notation through a browser interface using rapid update through svg. Given that then the browser functions could be used along with other parts of the existing interface to speed up the notation gui the possibilities are intriguing. Not that it would replace true music notation software but it could become a very quick way for t

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close