pbfhandler.cpp#L23 claims support for any and all GZIP files about qtpbfimageplugin HOT 8 CLOSED

I am that "very helpful person". ;-)

The main offending function is this one:
https://github.com/tumic0/QtPBFImagePlugin/blob/master/src/pbfhandler.cpp#L23
which does not actually look inside the GZIP.

It is important that your plugin does not falsely claim to support files, because Qt will otherwise automatically attempt to use it for files that are not actually supported.

from qtpbfimageplugin.

Well, the canRead() logic could maybe be a little bit improved (the question is at what price), but the problem with the uncertainty will still remain (until one would do a full decompression of the file and full GPB parsing). The core problem is neither GZIP and especially not GPB were designed to be easily recognisable.

But if anyone is trying to open an GZIP/PBF file as an image (why would someone do that?) he will get an error during reading the image which he can get with any other image plugin on any broken image, so he must be prepared to handle such error anyway. The only real problem I can imagine is another conflicting image plugin that also reads GZIP/PBF data. Is there such a plugin?

from qtpbfimageplugin.

Ok, I have missed the SVGZ example from the first comment, so there might be a colliding plugin. But still I would be interested in the real collision as Qt looks first on the file extension.

from qtpbfimageplugin.

Qt's SVG image plugin works exactly the same way as QtPBFImagePlugin does: qsvgiohandler.cpp

So let's do it this way - You report the bug to Qt and if they decide that it is not the way canRead() shall work and the test shall be changed, I will change it like they did.

from qtpbfimageplugin.

The collision happens in the Jami application, when it tries to load an avatar into a QImage. I guess there is no file extension at all there, QImage has to figure out the type from what it guesses.

The fact that both the SVG plugin and this plugin claim the same files indeed makes it clear that both are broken.

The net result is that the entire application crashes due to https://lists.qt-project.org/pipermail/development/2020-April/039228.html (where the consensus among Qt developers appears to be that Jami is at fault for using QImage without a QGuiApplication).

from qtpbfimageplugin.

The fact that both the SVG plugin and this plugin claim the same files indeed makes it clear that both are broken.

It's really not that easy. There are very good reasons why Qt's SVG plugin as well as QtPBFImagePlugin work the way they work. The canRead() function is part of autodetection that has to be fast and may fail (there may be even more plugins for the same data). This is why there are ways to use the exact plugin you want. Also note, that it is not acceptable, that the plugin does a full extract of the data (and there is data where you can't to do it another way) in canRead() to decide. Imagine you have three plugins doing a full extract of a 2GB file just to say "no, it is not my data"...

So as already said, it has to be carefully decided what is the optimal approach. And until Qt makes the decision (changes the SVG plugin detection), I won't change it neither. Reopen if that happens.

from qtpbfimageplugin.

You can do streaming decompression of gzip files, i.e., decompress only the first n bytes, which is exactly what is really needed here.

from qtpbfimageplugin.

I have added this check in a298cfc as it seems not to have a that significant performance drawback (maybe with huge SVG files, but I do not have the resources to test it). But you can still not expect the autodetection to be 100%...

from qtpbfimageplugin.