KSVG has recently been moved to the kdegraphics module, meaning that KSVG will now be part of the KDE 3.2 release. KSVG aims to be a full flavored implementation of the W3C SVG standard. Some of you will think of icons when we speak of SVG but SVG is much more: It is a web technology with full ECMAScript/DOM support. With the number of SVG powered sites growing steadily, Konqueror will soon be able to display these sites with a high-quality and open-source viewer. KSVG is fully integrated into the KDE framework and can be used in your applications as a KPart, enabling you to add support for vector graphics quite easily. Have a look at this special preview of KSVG and prepare yourself for the power of vectors in KDE 3.2!

I just emerged a fresh copy of KDE CVS. It rocks! The default Konq menu is down to 14 entries, and contains "Copy Text" :) Konq is also really fast, though the speed seems to be fluctuating a bit with CVS releases. Kontact looks a bit nicer too. KDE 3.2 is going to rock!

I've always thought that a font format allowing advanced vector capabilities like color and shading would be nice. Especially something where you can define generic and relative colors and alter according to a base setting.

Not really. Fonts need extensive hinting information that isn't present in SVG. It won't be practical to put pure vector fonts in anything until we get at least 300 dpi screens, if ever. Although, the font situation in Linux is quite good. Between Qt 3.x and Fontconfig, installing fonts is reduced to just copy some fonts to /usr/share/fonts or $HOME/.fonts. Font rendering is also really high-quality, as long as you've got some good Postscript or well-hinted TrueType fonts.

1. A method for manipulating the outline of a symbol image at a plurality of output sizes for improving the display of a digital typeface on raster output device having an output resolution and having an array of pixels, comprising the steps of:

storing in a first memory means a plurality of control points corresponding to an outline of said symbol image, at least one of said control points having predetermined information specifying different positions of said at least one of said control points for at least two of said plurality of output sizes;

selecting at least one of said control points of said outline which requires manipulation;

selecting a first size from said plurality of output sizes to display said outline at said first size on said raster output device;

calculating a distance and direction for repositioning said selected control point at said first size and said output resolution;

manipulating said outline by using the distance and direction calculated for said selected control point to reposition said selected control point;

and storing the results of said outline manipulation in a second memory means.

I don't see how. Hinting was in Postscript Type1 fonts long before Apple and Microsoft came up with TrueType. Between the PSHinter and the Autohinter in Freetype 2.1.5, I have no need for the patented TT hinter anymore :)

It would only seem to make sense when either the text is pretty big and/or the text needs much decoration, like a gradient or a filter effect like dropshadow. OTOH the svg fonts specification is still a work in progress AFAIK, so who knows :)
BTW the infrastructure is there in ksvg to implement svg fonts, its just waiting for someone to implement it :-)
Cheers,

I've heard of various rendering subsystems on different platforms using particular 'languages', like Display Postscript on some old UNIXes and Display PDF on MacOS X. Would such a thing be possible with SVG?

Some standardised, ultra-high-quality renderer that can easily be redirected to printing would be brilliant. It could be used by word-processors, DTP packages, vector graphics packages etc for proper WYSIWY-really-G, not the rough approximation that often seems to be the case on Unix software.

Is KSVG up to the task? The output screenshots remind me of Artworks on the Acorn - in other words, lovely. :-)

xsvg.org is working on something like this. I can't judge whether it is a good idea to move SVG rendering on the server. The advantage would be that the X11 server could render directly without any client communication, the disadvantage would be that the X11 server may need to expose the SVG tree to the client and manipulations of that tree would be slower and possibly more complicated.

> I've heard of various rendering subsystems on different platforms using
> particular 'languages', like Display Postscript on some old UNIXes and
> Display PDF on MacOS X. Would such a thing be possible with SVG?

> Some standardised, ultra-high-quality renderer that can easily be redirected
> to printing would be brilliant. It could be used by word-processors, DTP
> packages, vector graphics packages etc for proper WYSIWY-really-G, not the
> rough approximation that often seems to be the case on Unix software.

If you are talking about Qt, then you are correct, it doesn't work. The reason is that it is designed wrong -- backwards. What you are always going to have (if correctly designed) is that WYS is a lower resolution approximation of WYG on the printer.

There is NO solution to this problem except a 1200 DPI display.

If you want a better approximation of WYG, you need to turn font hinting OFF which makes the display look worse.

No, Cairo is a renderer that offers drawing commands. It works on a lower layer and does not store a vector model (that's why you can use it for both PDF and SVG - their rendering models are quite similar).

Yes, Postscript uses a vector model. BUT, once you have drawn something, you cannot change it. For example

100 100 moveto 200 200 lineto stroke

will draw a line. You cannot give this line a name and change its coordinates later, as with SVG objects. Once the stoke command is given, the line if final. If, on the other hand, you just give the PS interpreter

100 100 moveto 200 200 lineto

then nothing at all will be drawn, and a newpath command will cause the PS interpreter to forget it entirely.

That is what is meant when the previous poster said that the vector model is not stored. (It isn't: only the display bitmap is stored, unless you have a DSC PS file and a device that handles the DSC stuff, but that isn't strictly part of the PS interpreter, and is certainly nothing to do with the PS display model.)

Thank you for explaining what I and/or the previous poster didn't understand.

However, what you say doesn't quite make sense to me.

I think that what you are doing is confusing the lack of a WYSIWYG PostScript editor program with the language used in a PostScript file. If such a program existed, it would clearly have some of the same capabilities as Sketch or Sodipodi, and it would output a PostScript file, not a bit map.

OTOH (IIUC), SVG stores more information than just the strokes and fills -- it stores information that several of these primative objects go together to make a more complex object, this is an advantage of SVG over PostScript for this use. IIUC, this is what is meant by the vector model. PostScript would need to use comments to do this and this would not be very elegant.

However, Cairo *does* appears to be an attempt to integrate PS, PDF, and screen rendering. I see nothing specific about a native file format for it. But I would assume that it will be XML with embedded SVG. In that case, it would be able to export to PS and PDF but not use them as input, or if useable as input then an export and reinport would result in the loss of information.

>>Cairo *does* appears to be an attempt to integrate PS, PDF, and screen rendering. I see nothing specific about a native file format for it. But I would assume that it will be XML with embedded SVG. In that case, it would be able to export to PS and PDF but not use them as input, or if useable as input then an export and reinport would result in the loss of information.<<

Cairo is just a renderer that happens to have a X11 extension and is integrated in the X11 server. You call a few C methods, and it will paint something. Usually it will paint on the screen, but with the right driver it may print to PS or PDF stream.

It can not load or save data, and it does not know anything about XML. It does not know anything about PS or PDF either.

PDF rendering model refers to the type of commands that it processes. There are different ways to describe vector graphics, and Cairo happens to go the Adobe way.

It's been in there in Konqueror since KDE 2.0, just not by default (and will never be.. usability of spatial interfaces is better than browser interfaces, but usability of spatial interfaces for people who are used to browser interfaces (99% of computer users), is not good)

So, basically, do you want to make your interface easy for new computer users or classic MacOS or BeOS users (GNOME), or for existing Windows/MacOSX/KDE/GNOME users (KDE)

Eh. I'm not impressed. Its the GNOME bowing down to the Apple guys again... There is a good post on the gnomedesktop thread about this article. He points out that these days computers have become so pervasive that people have adopted to navigation methods that are most efficient on a computer, rather than what maps well to the real world. Thus, the spatial metaphor is less important today.

Yes, the short story is that every directory/folder is opened in a new window, and that these windows represent the folder. In other words, they do not have navigation buttons(forward/back) or a location bar, because the directory of the window is fixed.

To be honest, from having used this method of file management under countless older operating systems, then Windows 95, every time I installed win 98 I would just take five minutes to tweak it to do the same thing. Tweaking KDE to do the same is indeed trivial. Just get it to open new windows and remove the toolbars.

Then one day I got tired of doing the changes when I reinstalled each machine at work and left it. Since then, I've been fine with things in a browsing method.

Really, it makes no difference in the way I work, and my range of users, from people who know almost nothing about computers to the web/e-mail/wordprocessing users to the presentation/photoshop/dreamweaver lot have all been fine. As far as I can see, the users really don't care; in fact, they don't even seem to have noticed.

The only issues I have with browser navigation, is that Windows makes it very hard to open a folder in a new window when you need to, so that you can copy using DnD. Konqy doesn't have that problem, and the tabbed FM is great :)

Not true; The classic MacOS finder was quite spatial. It went well with Apple's "pretend your computer is a desk" mantra.

The OSX finder is not so-spatial for very good reasons.

1. People are used to non-spatial interfaces. Because of hrrm... Microsoft, NeXT, etc...

2. Spatial interfaces tend to clog the whole screen full of windows. This was why, for example, why Netscape didn't originally open up a new window for every page opened and why it had back/forward navigation buttons. Microsoft and others found that this approach worked equally well for local files.

As others have pointed, out, it's already possible to have a psuedo-spatial Konqueror. Just turn all of your toolbars off and set things to open in new windows.