Bug 189338

Version:           KDE4 trunk r951942, qt-copy trunk r942603 (using Devel)
Installed from:    Compiled sources

I tried to find why Gwenview fails to display my TGA files (some metainfo error) for me, while other KDE apps (and thumbnail creator) don't. So it turns out that depending on how Qt's QImage plugins are accessed, QImageReader will either determine probable format by the file extension and try that first, or ask the plugin to parse the data.

tga.cpp/TGAPlugin::capabilities(..) claims to handle the filetype-predetermined TGA's fine without even looking at the data, and does handle them pretty well, but Gwenview accesses QImageReader with just the image data which then requires TGAHandler::canRead to parse the data for possible format match.

According to Qt4 docs:
TGAHandler::canRead looks to have some problems for parsing TGA header data:
 it uses QIODevice::readLine which unintentionally stops reading after any coincidental newline characters (saw this in one of my TGA's)
 it creates variable QString(QByteArray) which unintentionally stops copying data after any coincidental null characters (very common)
 i can't figure out what exactly the QRegExp header parser is doing, after i looked up a TGA specification doc online..

The QRegExp in the patch I have here is not any in depth look into TGA header format, particularly the last character which I only assume is what is meant by 'pixel format' in the tga.cpp file top commentary as to what tga.cpp is supposed to support. I just know TGAHandler::canRead looks fairly broken as it is now, and I think this is a fairly reasonable fix for times when TGAHandler::canRead is actually used by KDE apps (but with QRegExp caveat above!).