| Summary: | KRA and ORA plugins are not recognised by QImageReader | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kimageformats | Reporter: | Andrius <andriusmao> |
| Component: | general | Assignee: | Alex Merry <alex.merry> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | aacid, deri, ebm2003rkm, halla, kdelibs-bugs, mircomir, nate, tysontanx |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Microsoft Windows | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=435402 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Andrius
2016-05-13 02:11:42 UTC
*** Bug 423637 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kimageformats/-/merge_requests/17 I don't see how merge request 17 is going to fix this. That MR is about fixing loading of files themselves, this bug is about QImageReader doesn't even knowing it can open those kind of files. Andrius maybe you didn't get those plugins compiled? *** Bug 435402 has been marked as a duplicate of this bug. *** It fixes the canRead method, not the reading of the files itself. Thanks for mentioning that. I need to improve on it, though, I'll try to do that tomorrow, since that "magic" string can be in a wider range of locations. It may be that the reason the position changes is because quazip is using deflate on the mimetype file rather than just storing it uncompressed. This does not make much sense because the compressed size (24 bytes) is longer than the uncompressed size (19 bytes), using zip64 the difference is greater. Is there a way to tell quazip to store the file "mimetype" (rather than deflate) or to not deflate files which grow larger when compressed. I would be surprised if it was that, since the mimetype is readable in the binary, so it's not compressed. I think I've got it, at least for the position of the string. The kzip store called m_pZip->setExtraField(KZip::NoExtraField); And for quazip that's apparently dd->archive->setDataDescriptorWritingEnabled(false); I'll still have rework this patch, though, since that's needed for 64 bits zipped kra files If you do a "zipinfo -v" on the .kra file produced by quazip you get:-
=========================================================================
Archive: ../Wales.kra
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 38332741 (000000000248E945h)
Actual end-cent-dir record offset: 38332719 (000000000248E92Fh)
Expected end-cent-dir record offset: 38332719 (000000000248E92Fh)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 43 entries.
The central directory is 3049 (0000000000000BE9h) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 38329670 (000000000248DD46h).
Central directory entry #1:
---------------------------
mimetype
offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: yes
file last modified on (DOS date/time): 2020 Jul 8 16:13:24
32-bit CRC value (hex): a703f0a1
compressed size: 24 bytes
uncompressed size: 19 bytes
length of filename: 8 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100444 octal): -r--r--r--
MS-DOS file attributes (00 hex): none
There is no file comment.
Central directory entry #2:
---------------------------
There are an extra 16 bytes preceding this file.
maindoc.xml
offset of local header from start of archive: 78
(000000000000004Eh) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: yes
file last modified on (DOS date/time): 2020 Jul 8 16:13:24
32-bit CRC value (hex): afbe52a3
compressed size: 1266 bytes
uncompressed size: 5070 bytes
length of filename: 11 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: text
Unix file attributes (100444 octal): -r--r--r--
MS-DOS file attributes (00 hex): none
There is no file comment.
Central directory entry #3:
---------------------------
There are an extra 16 bytes preceding this file.
=========================================================================
You can see that the first file (mimetype) is shown as deflated and the
compressed size is larger than the original. It also shows there is no
extra field, although there appears to be a 16 byte gap between each file.
This is the equivalent zipinfo for a .kra file which was produced by kzip.
=========================================================================
Archive: ../WalledGarden.kra
There is no zipfile comment.
Zip archive file size: 27595676 (0000000001A5139Ch)
Actual end-cent-dir record offset: 27595654 (0000000001A51386h)
Expected end-cent-dir record offset: 27595654 (0000000001A51386h)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 54 entries.
The central directory is 4228 (0000000000001084h) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 27591426 (0000000001A50302h).
Central directory entry #1:
---------------------------
mimetype
offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: Unix
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2020 Jul 4 00:06:16
32-bit CRC value (hex): a703f0a1
compressed size: 19 bytes
uncompressed size: 19 bytes
length of filename: 8 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
There is no file comment.
Central directory entry #2:
---------------------------
maindoc.xml
offset of local header from start of archive: 57
(0000000000000039h) bytes
file system or operating system of origin: Unix
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2020 Jul 4 00:06:16
32-bit CRC value (hex): bfca0969
compressed size: 1417 bytes
uncompressed size: 5876 bytes
length of filename: 11 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
There is no file comment.
Central directory entry #3:
---------------------------
documentinfo.xml
=========================================================================
*** Bug 438807 has been marked as a duplicate of this bug. *** On KDE 5 (Debian) I saved a .KRA from Krita 5.2.3. Dolphin shows the preview and Gwenview opens it without problems. Please attach a .kra showing the problem (if it still exists). 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! |