Originally Published: Monday, 24 September 2001 Author: The Staff of Linux.com
Published to: enhance_articles_multimedia/Multimedia News Page: 2/3 - [Printable]

Linux.com Interviews Lauris Kaplinski

On September 5th 2001, the World Wide Web Consortium released the Scalable Vector Graphics 1.0 Specification as a recommendation. With the SVG standard gaining popularity and acceptance, Linux.com spoke to Lauris Kaplinski, a GNOME developer and the author of Sodipodi - a vector-based SVG drawing application, about a few technical insights into the standard, Sodipodi and GNOME in general.

  << Page 2 of 3  >>

Linux.com: How do you compare the SVG standard to Macromedia's Flash? What do you think are the advantages and disadvantages?

Lauris Kaplinski: I know too little about Flash, to do a fair comparison. Recently there has been lot of talking about SVG as W3C's answer to the growing popularity of Flash - this is partially true - but there are important differences too, so they can as well be considered complementary, not competing, technologies.

Flash has probably always been a multimedia-oriented web presentation language. SVG was originally created as standard for vector images solely. Still, being XML based, and W3C backed, SVG seamlessly fits into larger framework of web technologies, thus immediately gaining advantage of other projects (ECMAScript, DOM, CSS, etc.). Although SVG embeds SMIL animation features, I think its primary uses for coming years will be static - like with HTML, where you can do animations with JavaScript, but the vast majority of the web is static. SVG will be the markup language for graphs, logos, titles and other design elements, replacing bitmaps as primary design blocks of future web pages. Being XML based and relatively easily editable by hand are certainly major success points for such uses. Flash probably will survive in the multimedia world as language for full-featured multimedia presentations. In that area readability and editability are much less important, than well-supported authoring tools. Also, Flash is more compact and thus better suited for the animation world.

Linux.com: What do you feel about Sodipodi at this point? Is it at a stage where it is useful yet? What is in store for everybody in the future?

Lauris Kaplinski: It is useful for simple tasks, like layout birthday invitations or business cards. To certain extent also to generate web graphics - either raw images to be retouched in GIMP - or vice versa - adding text and vectorial elements to bitmaps.

I am relying on user feedback for improvements, as I do very little graphic work myself. Currently I am writing support for gradients. If completed, the same code can be extended to support patterns. Then there will come some line drawing improvements. And after that I am planning to split the whole thing into viewer and editor parts, thus making it more suitable as bonobo image component.

Linux.com: Sodipodi uses many advanced features of GNOME. How do you describe GNOME as an application framework? What do you feel is required (from the point of a software application developer)?

Lauris Kaplinski: I like Gtk+, although it is overbloated sometimes - but its dynamic object system is really cool (mandatory disclaimer - if used correctly). My feelings with Gnome libraries are more mixed - the bloat/usefulness ratio is slightly worse there. But Gnome is a great framework to get your work started - there is a nice set of basic building blocks - although these are usually not extensible enough for serious application development. You can later replace these one-by-one as needed.

Bonobo is a great framework, although it had a serious problem of being in constant change for a long time (like most of Gnome, actually). This makes keeping applications in sync with libraries major extra work, and also causes lot of installation problems for users later. The biggest problem with Gnome is major lack of coordination between different subsystems. It would be a great development platform with only 10% of current features, if only those 10% would be implemented consistently between different libraries. But well - this is not only Gnome's problem.

  << Page 2 of 3  >>