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!
Hope it doesn't infringe the EOLAS patent, not eolas also owns the trademark "invented here".
521 Mio US $ huh!
Note more than other embedded content and maybe less, since the Eolas patent is about processes started by embedded content and KSVG runs in-process.
... viruses, MS scripting, etc. etc.
Great patent ... glad someone admits to having invented this stuff
did an emerge of kde-cvs today, its really such a great thing!
there are plenty of usability-enhancements which will get the masses on the desktop onto kde!
thanks and regards to the kde-team,
How did you do this? I'd like to emerge it myself, though it will probably take a couple of days for me on my 500mhz celeron.
Please read the whole manual.
Works well. If it doesn't compile, wait a day and try again. Do each module separately rather than the kde one, otherwise it quits at the first error.
Also see http://forums.gentoo.org/viewtopic.php?t=69335&postdays=0&postorder=asc&...
Thanks Derek, I'll read the manual and give it a shot.
These two scripts help with the whole "wait a day" syndrome. They are released under the GPL, if you edit it, release it.. enjoy!
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!
would it make sense to create fonts in svg format? they'd be smoothly scalable and easy to read on any platform.
I'm really no font expert (as you probably already know because of the question), but I think the current font-situation in linux sucks a little. So, is this a very stupid idea?
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.
Hinting informations in a font is patented by Microsoft.
We have to find another way to render fonts.
Actually, while there is no alternative technology, M$ and Adobe can decide at any moment to forbit any free software to display or print any text...
>> Hinting informations in a font is patented by Apple.
> Hinting informations in a font is patented by Microsoft.
You mean, hinting information in a TrueType font is patented by Apple, don't you?
Yes by Apple, sorry.
But I do not mean "hints in a TrueType font" but "hints in any font format".
Hinting in type1/type3 fonts is not patented. Hinting TT fonts is also not patented, but hinting with bytecoded information in TT fonts is patented by Apple.
AFAIK, the patent is not limited to TT fonts, but any fonts :
US Patent 5159668 :
What is claimed is:
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.
Nope. There is one way to hint fonts that is patented by Apple. Freetype2 uses another way (auto-hinting). Go check their website:
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 :-)
Thanks for the time you spent KSVG ;-)
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?
As I understand this, Cairo combines all of this:
> 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.
> As I understand this, Cairo combines all of this:
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).
I hate to tell you this, but PostScript uses vector model.
I hate to tell you this, but I never claimed something else :)
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.
But, what do you think about spatial uis like the one in GNOME 2.6?
More on that here:
Personally, I don't really liek it, but it seems interesting.
KSVG alsos eems great, especially since now we can have SVG icons and an easy to sue Kpart for it!
I read the preview page and SVG is awesome, I can't believe it has so many uses , even animations! WoW! That is great news!
> But, what do you think about spatial uis like the one in GNOME 2.6?
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)
Not sure which!
So how do you enable it in konqueror?
Settings -> Configure Konqueror -> Open Directories in separate windows
And then right click on a toolbar, Toolbars submenu and uncheck them all.
It's not a single option thing, but it is very quick ( < 1 minute).
Damn, if that's it, thanks but no thanks :)
No, thats not all. Please read the artikel. To disable the toobar and open directories in new windows works in Nautilus too.
its MUCH more involved and much better than that hack, which nautilus has had since 1.0 too. read the article before you spout off please.
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, especially since the Apple itself somewhat abandoned spatial interfaces in OSX.
Question... Neither the article nor the list discussion makes it obvious what we are talking about... Is this, essentially an argument about "Open in a new window"?
If so, I'm a bit underwhelmed. As far as I can see, most users can use either method quite happily, and really don't care very much.
Best usability improvements of the last five years for file management are: image thumbnailing and previews, tabbed file management in Konqy.
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 :)
Windows has not implementet it, please test it on MacOS 9 or older!
It's funny that all these articles/posts all start with something like "Personally I think that OO UIs suck, but as the usability guys say that they are logical and easy to use...".
P.S.: Knowing the 'a new window for each directory' principle from Windows, I agree that it sucks.
because windows, gnome or kde have NEVER had a spatial GUI. dont judge it before you see it, lest you look like a troll.
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.
I defintely wouldn't wat mozilla to have a web browser with a spacial interface, damn taht would be a pain, I think it sucks too, but I guess I need to try a real implementation first.