KDE To Adopt SVG: Take A Glance

Karma Sucks writes "According to the KSVG website, KDE 3.2 will be adopting SVG in a very real way. A special preview of KSVG is available, showing everything from font rendering to a snowfall simulation using ECMAScript and DOM. KSVG is fully integrated into the KDE framework and can be used as a KPart -- e.g., by applications such as Atlantik."

Comments

Thats not good enough! We need an SVG interface!

[Adolph_Hitler]

The KDE team needs to do more than just adapt SVG as a plugin, they need to render the whole interface via SVG. Maybe cairographics could be used as the backend, and KDE's UI, Icons, Widgets etc could be completely resolution indepedent and rendered via SVG.

And Mozilla?

[PipianJ]

So Konqueror will have decent SVG support now.

When are we going to get decent working SVG support for Mozilla (and Phoenix) in X then? Last I checked, we're still stuck with libart (which can't be officially included in Mozilla thanks to the lack of a tri-license) and the infamous Bug 111152 was still open...

Why is SVG important to the desktop?

[stienman]

I suspect a number of people are wondering why SVG is important to the desktop. There is one major reason to have SVG as part of the normal program rendering. Several smaller reasons, too.

Objects can be clearly rendered in SVG regardless of the output device resolution.

We are seeing small 15" laptop screens with resolutions of 1920x1200. Soon we will have desktop monitors with higher and higher resolutions. This is because the profit margin in low resolution LCD monitors is quickly becoming very thin. Manufacturers are going to try and differentiate their products by touting the clarity and color rendition of better, higher resolution screens.

So the operating system designer doesn't have to

1. Create an icon for each resolution
2. Use icon scaling
3. And make many sections of code that will make sure the important things are on screen and usable.

Many applications could and should run well on a PDA (4", 200x320) a cell phone(1.2" 90x90) and a scientific visualization workstation (120", 6400x4000) without device specific code or modes.

The smaller reasons include much less data - if a graphics card rendered SVG, then the connection between the computer and the card could be slow and very long distance. Hard drives space isn't an issue, except in power-conscious embedded areas where smaller graphics files could make a difference.

Lastly, rendering speed improvements could be realized. Aside from dedicated HW doing the rendering, if the OS did it in a trusted manner then it could be faster than many libraries and/or programmer hacks. Programs could as a result be smaller, since they don't have to maintain as much graphics, layout, and UI information.

In short, there are many good reasons to include SVG in the lower system level - mostly looking toward the future of hardware, but when it's here, won't it be nice to be ready?

-Adam

Re:Wicked cool!

[Adolph_Hitler]

2) SVG should not be used for the entire UI, that's overkill, but for many areas it makes life a lot easier. For instance, icons in SVG make them infinitely scalable, so that people can resize their screens or their icons to whatever they find comfortable with no loss of quality. (Think handicapped.) Also, no more need for Small and Large versions of icons. Just have one icon, and the system scales it to whatever size is needed. Yeah just like having more than 64 megs of ram is overkill, I mean who could ever use more than 64 megs of ram? Just like the 3dfx Voodoo 3 was overkill, I mean who would ever need a new video card after this? I mean the 1ghz pentium, its definately overkill, who would ever need more than 400mhz Pentium 2? I think what Linux needs is overkill if its to compete with the other OS's which are more modern. OSX and Longhorn will be overkill, but people want overkill and if you are to compete with overkill then you must overkill the overkillers. Personally I want an SVG interface, I like the idea of not having to set my resolution, I like the idea of having perfect quality text, I like the eye candy of OSX, and if i have the video card to do this with absolutely no hit to speed, why shouldnt it be done? If I dont like it I'll turn it off and I'll still have a faster system which uses less ram than a pixel based GUI. Please go into details on why SVG for the entire interface would be bad. Just because you won't use it is not a good enough reason, you need facts not opinion.

Why XML?? Just why?

[ebyrob]

Can somebody tell me why SVG would be implemented using XML? I mean .png, .gif, and .jpg don't use verbose ascii storage formats do they?

What ever happened to compact binary image formats?

Re:Why XML?? Just why?

[sorotokin]

The main reason it is XML is so it integrates well with other W3C standards: SMIL, XHTML, XSLT, XSL:FO and CSS. Actually SVG itself relies a lot on these formats. For instance, styling is done with CSS, SVG can easily be generated with XSLT, a lot of SVG text layout attributes came from FO and SVG animation is basically an integration with the SMIL animation module. SVG is not supposed to do everything by itself, and, for instance in Adobe SVG Viewer v6 preview you can embed a pieces of XHTML in SVG and SVG in XHTML.

And verbose it is not. Actually after gzip compression (support for gzip is mandated by the spec) it is one of the most compact graphics format.

Re:SVG != resolution-independent icons

[crisco]

Your first two paragraphs remind me of why font hinting is required. Fonts are resolution independant graphics, yet they require help with rendering at low resolutions to maintain readability.

Does SVG have any simple means to create a 'hinting' system?