|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Monday, 24 September 2001||Author: The Staff of Linux.com|
|Published to: enhance_articles_multimedia/Multimedia News||Page: 1/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.
|Introduction||Page 1 of 3 >>|
InterviewLauris Kaplinski lives in Tartu, Estonia with his family. He studied molecular biology and philosophy, and started a small family computer shop in 1994, when he first came across Linux. Lauris says his first computer was a Commodore 128 in the late 1980s, and the first coding projects he was involved in was in Z80 assembler. He currently works for Ximian.
Lauris is the author of a recent and popular drawing application called Sodipodi It has drawn the attention of many graphics artists and web developers around the world due to the fact that it is a true SVG editor and vector-based drawing application. It is the first of its kind available for GNOME. Linux.com spoke to Lauris about Sodipodi and his views on the SVG standard.
Linux.com: Please give us a brief history of Sodipodi. Who are all the developers involved in Sodipodi?
Lauris Kaplinski: I was deeply impressed by CorelDraw 3 back in 1993 and have used it since occasionally to do simple graphics, like business cards, book stickers and so on. For some reason I have always felt myself better with vector than raster graphics - so although impressed by The GIMP later, it found it to be of little use.
Sodipodi started with gnome-canvas, originally created by Federico Mena and Raph Levien. I was not the only one, seeing it as good starting point for starting something comparable to Corel at last. But canvas lacked bezier path object class, so I started developing one - little parts of my work found place in the gnome-print preview widget. About that time I was introduced to project Gill (Gnome Illustrator) of Raph Levien. It was an ambitious project, trying to implement a SVG editor entirely on top of DOM tree and callback events. Unfortunately there was not even nearly usable DOM library available for Gnome, so Gill development was very slow - plus it was unclear, how good user experience one could achieve on top of the slow and complex DOM.
I started playing with Gill code. Initial Sodipodi was born, as heavy sub classing of canvas objects (Gill used mainly stock canvas items), while still relying on DOM. Later I rewrote the object system several times, but there is still some original code present in SVG parsing. Initial Sodipodi was a standard single-window, toolbar, and menubar Gnome application. Current GUI is mostly the work of Frank Felfe. Me and Frank are the only active developers at moment. My brother Lemmit works on external projects, like writing webpages and collecting clipart for Sodipodi.
Sodipodi has chosen W3C SVG as its native file format, while targeting to be a generic drawing application, while most other programs have developed their own file formats. What good and bad sides do using published standards for file formats such as SVG have?
Lauris Kaplinski: Well, it was not Sodipodi's decision - I shamelessly borrowed it from Gill. The good thing about using a published standard is that I do not have to spend time creating an imaging model. I just have to implement it. No extra headache keeping file format upwards/downwards compatible. Using SVG natively may give Sodipodi slight advantage in web development, as it will preserve 99.9% of hand-written structure.
The bad part is that SVG is created for display. Editing requires all kinds of fancy tweaks, that often need to keep serious meta-information in addition to SVG. For example, referenced objects (like gradients) can be everywhere in a document, not only in some standard place.
The SVG standard is quite complex, so supporting most of it is hard. Editing adds extra burden here, as we do not like unsupported features to be silently overwritten. SVG document format natively links external objects, like texts and images. While saving these into a single file is possible, it renders (in case of images) it unreadable.
|Introduction||Page 1 of 3 >>|