From kde-core-devel  Mon Feb 11 13:35:42 2002
From: David Faure <david () mandrakesoft ! com>
Date: Mon, 11 Feb 2002 13:35:42 +0000
To: kde-core-devel
Subject: Re: Thumbnail Standard, XCF reader
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101343453130819

On Monday 11 February 2002 14:18, Malte Starostik wrote:
> Good day,
> 
> I've ported KIO::PreviewJob to comply with the Thumbnail Managing Standard
> (http://triq.net/~pearl/thumb-spec.php).
> It doesn't change any i18n strings nor the outer appearance of previews except
> that the sizes are adjusted to be nicely scalable from 128x128, which is but
> a few pixels difference.
> As it adds to the interoperability with "foreign" applications, I'd really
> like to commit this for 3.0, but not without an okay.

This sounds great to me. Interoperability is a move in the right direction ;)
If this doesn't bring in too many bugs, I think it's a "must have".

> Either case, it requires a small Qt patch that reads PNG text chunks also for
> non-progressive loading (sent to qt-bugs@, answer pending).
Ouch. How important is that ? I mean, PNG's text chunks can be useful
for the metainfo stuff, but for image previews ?

> Second, this is a new feature, so I guess it has to wait for 3.1, but I'll
> dare asking anyway ;-)
> My harddisk contains a small kimageio plugin to read XCF files, at least RGB
> and RGBA ones (via libxcf,
> http://www.informatik.uni-oldenburg.de/~pearl/gnome/libxcf.html). Transparent
> backgrounds don't work, still it provides basic XCF-thumbnail capability ;-)

Hehe, tackat asked you too ? ;)

For info, I wrapped up a very basic one, based on xcftopnm and pnmtopng...

--- imagecreator.cpp    2001/10/01 20:47:41     1.8
+++ imagecreator.cpp    2002/02/11 13:32:40
@@ -25,6 +25,10 @@
 #include <qimage.h>

 #include <kimageio.h>
+#include <ktempfile.h>
+#include <kstandarddirs.h>
+#include <kprocess.h>
+#include <kdebug.h>

 #include "imagecreator.h"

@@ -39,8 +43,26 @@ extern "C"

 bool ImageCreator::create(const QString &path, int, int, QImage &img)
 {
+    QString pathOk( path );
+    if ( path.endsWith(".xcf" ) ) // TODO more complete check of whether QImage supports it
+    {
+        // We need those two
+        if ( KStandardDirs::findExe( "xcftopnm" ).isEmpty() )
+            kdError() << "xcftopnm not available!" << endl;
+        else if ( KStandardDirs::findExe( "pnmtopng" ).isEmpty() )
+            kdError() << "pnmtopng not available!" << endl;
+        else {
+            KTempFile tmpFilePNM;
+            tmpFilePNM.setAutoDelete(true);
+            KTempFile tmpFilePNG; // can't delete that one !
+            KShellProcess proc1;
+            proc1 << QString("xcftopnm %1 > %2 && pnmtopng %2 > %3").arg(path).arg(tmpFilePNM.name()).arg(tmpFilePNG.name());
+            if ( proc1.start( KProcess::DontCare ) )
+                pathOk = tmpFilePNG.name();
+        }
+    }
     // create image preview
-    return img.load( path );
+    return img.load( pathOk );
 }

Well it's usually better to use a lib than an external program, I guess,
(being more efficient)... although... this is a bit more flexible, not requiring
anything at compilation time. It's quite slow though, is that the same
with using the lib directly ? I attributed it to the XCF format...

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david, http://www.konqueror.org
KDE 3.0: Konquering the Desktops