Version: (using KDE Devel) Installed from: Compiled sources Please support SVG static images in kimagio, so that every KDE application can use SVG content transparently. Currently I have available two versions of source to support this. One version uses KSVG, the other librsvg. The second solution is faster, but has some external dependencies (libcroco, glib2, libart_lgpl)
Can you please attach both versions so this can be looked at again after 3.3?
Created attachment 6602 [details] work for KSVG based plugin Included in the actual ImageIO code, the .desktop file and a helper class This doesn't compile, because there is missing a patch to KSVG (rendering to a RGBA QImage) Unfortunately I have never managed to actually make the code run as a KImageIO module
Created attachment 6603 [details] work on a librsvg bases QImageIO module contains code to use librsvg and some Makefile about how to include and link the needed references. This needed probably work (pkgconf and such) The main.cpp contains a sample about how to register the handler with QImageIO
Well, using glib2 is not the direction that KDE wants to go. (It is bad enough that Arts needs glib.) As for the KSVG solution, it looks fine. (Can the copyright "KPainter developers" be precised somehow, as such general team names are not allowed anymore for new files in KDE, since earlier this year. Have a nice day!
> Well, using glib2 is not the direction that KDE wants to go. (It is bad > enough that Arts needs glib.) At least currently this is a political remark which leads to suboptimal performance. From what I understood KSVG(1) ist currently in maintenance mode only. KSVG2 is not quite ready to replace it. KSVG is slower (because it is less well suited for static rendering only - it provides a canvas type interface and a DOM implementation, too) Perhaps make it a compile time dependency - compile --with-glibs --with-librsvg? > As for the KSVG solution, it looks fine. (Can the copyright "KPainter > developers" be precised somehow, as such general team names are not allowed > anymore for new files in KDE, since earlier this year. The author is "Dirk Schoenberger et al", I suppose. Unfortunately I currently don't have a SPAM-safe email address.
This would make KDE have 4 separate SVG loaders, though. (Qt's, kiconloader's, KSVG, and now this)
On Monday 02 August 2004 20:43, Dirk Schoenberger wrote: (...) > ------- Additional Comments From dirk.schoenberger freenet de 2004-08-02 > 20:43 ------- > > > Well, using glib2 is not the direction that KDE wants to go. (It is bad > > enough that Arts needs glib.) > > At least currently this is a political remark which leads to suboptimal It is not only political, it is also technical. If I remember well, when I looked at this for KOffice, librsvg needs some higher GNOME libraries (a quick test with "nm" tells me for example Pango). It is not like lixml or libxslt a library that is quite independant. > performance. From what I understood KSVG(1) ist currently in maintenance > mode only. KSVG2 is not quite ready to replace it. > KSVG is slower (because it is less well suited for static rendering only - > it provides a canvas type interface and a DOM implementation, too) Perhaps > make it a compile time dependency - compile --with-glibs --with-librsvg? > > > As for the KSVG solution, it looks fine. (Can the copyright "KPainter > > developers" be precised somehow, as such general team names are not > > allowed anymore for new files in KDE, since earlier this year. > > The author is "Dirk Schoenberger et al", I suppose. > Unfortunately I currently don't have a SPAM-safe email address. Perhaps a http://www.kdemail.net address (redirection only)? (Spam through @kde.org is very uncommon, so I suppose through @kdemail.net it should be the same.) Have a nice day!
> If I remember well, when I looked at this for KOffice, librsvg needs some > higher GNOME libraries (a quick test with "nm" tells me for example Pango). > It is not like lixml or libxslt a library that is quite independant. Ok you are right. Pango is not really a Gnome lib, but Gtk+ is near enough, I suppose. A compile time option would still be nice. > Perhaps a http://www.kdemail.net address (redirection only)? I will check this out. > This would make KDE have 4 separate SVG loaders, though. (Qt's, > kiconloader's, KSVG, and now this) Qt don't offer really SVG support. From what I understood, it supports it in the form of a metafile / QPicture. This is limited to the functionality of QPainter. From what I understood, SVG support for Qt4 (the Arthur rendering engine) is planned, but not for the first Qt 4 releases. kiconloader - this SVG is even more limited than KSVG (feature wise) KSVG - unfortunately this uses a) a DOM approach and b) some KTrader calls. This makes it less than optimal for static on-off renderings like for images or icons. There seem to be some more attempts for SVG rendering. In SVG plugin is some loader code which don't seem to be used, but was used for my KSVG plugin. There exist a KFile SVG plugin with thumbnail creation. I am not quite sure which code is used there.
On Monday 02 August 2004 22:22, Dirk Schoenberger wrote: (...) > ------- Additional Comments From dirk.schoenberger freenet de 2004-08-02 > 22:22 ------- > > > If I remember well, when I looked at this for KOffice, librsvg needs some > > higher GNOME libraries (a quick test with "nm" tells me for example > > Pango). It is not like lixml or libxslt a library that is quite > > independant. > > Ok you are right. Pango is not really a Gnome lib, but Gtk+ is near enough, Gtk+ then. (But the sources are on gnome.org.) > I suppose. A compile time option would still be nice. > (...) > > > This would make KDE have 4 separate SVG loaders, though. (Qt's, > > kiconloader's, KSVG, and now this) > > Qt don't offer really SVG support. From what I understood, it supports it > in the form of a metafile / QPicture. This is limited to the functionality > of QPainter. I am not sure where QPainter would be a limit to create an image on screen. (A QImage does not let you have floating-point points either.) But in Qt3, the SVG loader in QPicture is limited. > From what I understood, SVG support for Qt4 (the Arthur > rendering engine) is planned, but not for the first Qt 4 releases. In the description of Arthur, SVG is going to be supported: http://www.trolltech.com/products/qt/whatsnew.html (It is Cairo and PDF that are supposed not to be in Qt 4.0.) > kiconloader - this SVG is even more limited than KSVG (feature wise) As far as I know, kiconloader is provisory, until a better solution is found. > KSVG - > unfortunately this uses a) a DOM approach and b) some KTrader calls. This > makes it less than optimal for static on-off renderings like for images or > icons. There seem to be some more attempts for SVG rendering. In SVG plugin > is some loader code which don't seem to be used, but was used for my KSVG > plugin. > There exist a KFile SVG plugin with thumbnail creation. I am not > quite sure which code is used there. That is again QPicture. Have a nice day!
> > Qt don't offer really SVG support. From what I understood, it supports it > > in the form of a metafile / QPicture. This is limited to the functionality > > of QPainter. > But in Qt3, the SVG loader in QPicture is limited. I think the QPainter rendering model is rather limited and not quite compatible to the rendering model needed for SVG. Basically QPainter exposes the following API features - immediate mode rendering - polygons or direct graphical primitives like arcs only - integer coordinates - explicit affine transformations - image rendering doesn't really support affine transformations - no antialiased rendering - no alpha channel (semi transparent areas) In contrast, the Postscript family of rendering models, i.e Postscript, PDF, SVG, supports the following features - semi-immediate mode rendering - vector paths with sub paths and segments which may be e.g. bezier curves. This allows to implement all other primitives like arcs. Semi immediate mode: in a first step the path is composed, in a second step the path is rendered. - floating point coordinates - device independence - implicit affine transformations - the graphics state manages the current settings, including the current path - image rendering with affine transformations, images can be rotated, cscaled, skewed freely, you may specify which algorithms should be used for interpolating the pixels to render. There is no longer a 1:1 relationship pixel in image -> pixel on screen / printer - antialiased rendering possible - alpha channel is possible It is possible to implement a Postscript / PDF level API using QPainter calls, but I am not quite sure if the effort is worth it (for a possible implementation check out my KPainter project in kdenonbeta), but even there anti-aliasing and transparency are not really possible. Qt4 (Arthur) introduces part of the needed changes, but I think it doesn't go far enough. > I am not sure where QPainter would be a limit to create an image on screen. > (A QImage does not let you have floating-point points either.) After you have rendered a SVG image to an image buffer, it is indeed no longer a problem to render it. My idea for SVG support would be that QPainter supports the needed rendering primitives natively. > > From what I understood, SVG support for Qt4 (the Arthur > > rendering engine) is planned, but not for the first Qt 4 releases. > In the description of Arthur, SVG is going to be supported: > http://www.trolltech.com/products/qt/whatsnew.html > (It is Cairo and PDF that are supposed not to be in Qt 4.0.) This is for rendering, i.e. there will exist a SVG paint device. SVG import / reading is a whole other area alltogether...
proposal for a compromise: if we don't use librsvg, perhaps we could use an external cairo dependency. Part of cairo is a static SVG renderer with the same public API as librsg. It should only be dependent on gdk-pixbuf (and cairo). KSVG (2) will hoefully have a cairo backend.
This seems completely overtaken by more recent developments. Anyone familiar enough with this to say its effectively done?
I tested a simple QImage/QImageReader based program: - Qt does load .svg into the image, possibly in "design size" - transparency is handled, the image is returned in ARGB32 premultiplied format - .svgz is NOT handled, albeit the SVG loader knows to decompress gzip This is a filename extension problem, as renaming that file to .svg, but still leaving it compressed, works fine. Bug reported to Trolltech, closing this one.
Since the old bug never made it into the database, I refiled it. http://bugreports.qt.nokia.com/browse/QTBUG-8227