Summary: | Issue loading version 2.8 file in 2.9 due to .TIF layers inside of .KRA file | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | William Thorup <7achoneus> |
Component: | File formats | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | halla |
Priority: | NOR | ||
Version First Reported In: | 2.9 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/calligra/c1f1a85c7ff6bb0108b162043db33d35f1c0c95d | Version Fixed In: | |
Sentry Crash Report: |
Description
William Thorup
2015-03-16 15:44:58 UTC
Hi William, Thanks for your report. Could you share the actual .kra file with us? If it's confidential, feel free to mail it directly to me. File sent. Thank you Boudewijn! Hi William, A krita .kra file is a plain old zip file, so I unzipped it and took a look. There are two issues with the file you sent me: the internal path to the layer data starts with a /, which means the zip code is getting confused and thinks that the layer data is outside the zip file, because this means an absolute path. The second problem is the the long path to the layer data, which has spaces inside. I'm not sure why that's a problem, and I'll look into it, but I'll mail you a fixed file so you can at least access your data. If you have more files like this, you can fix them by: * make a temporary directory * enter the temporary directory * unzip the .kra file * make a directory called 'image' * move the layer and annotation folders at the end of the long path to 'image' * open the xml files and replace the long path with image * zip the result up again. Krita using .zip compression to create it's files is an interesting fact. I wonder if this might have something to do with with the bug I recently filed for the Ark file compression utility used in Kubuntu. Here https://bugs.kde.org/show_bug.cgi?id=344923 Recently Ark has been creating bad .zip files for me. But this doesn't make too much sense that these Krita files work just fine with Krita 2.8.6. Unless Krita uses a bugged version of Ark internally to create the .kra files? Sounds like a long shot though. Thank you for looking into this Boudewijn. Also, thank you for the information on changing the files so they work with the latest version of Krita. I have had to backtrack to 2.8 in order to do my work until now. But with the process to manually fix the files, I can enjoy all the new features 2.9 has to offer :) It's actually possible, ark and krita use the same library for reading and writing zip files, and there's been a bit of development in those libraries recently. On the other hand: if 2.8 works for you and if you haven't had to change your version of the kde libraries, then the bug really must be in Krita. So that's what I will assume for now -- and I'll try to find a fix asap. Oh dear, now I know what's up. It isn't the spaces, it isn't the leading /, it's the part of the folder tree that was just a number. Prior to 2.9, the calligra libraries had a bug where there's be a string 'part' prepended to any folder that started with a number. So... We'd store this in maindoc.xml: name="media/lachoneus/Wills External Hardrive/Thor_Media/2014/Company Work/Art/Project Ark/Issue 1/Pages/single_page_template.tif" And then we'd use this path in the zip file: name="media/lachoneus/Wills External Hardrive/Thor_Media/part2014/Company Work/Art/Project Ark/Issue 1/Pages/single_page_template.tif" Let's see what I can do to patch this up... Git commit c1f1a85c7ff6bb0108b162043db33d35f1c0c95d by Boudewijn Rempt. Committed on 20/03/2015 at 09:45. Pushed by rempt into branch 'calligra/2.9'. Related: bug 2, bug 9 If a part of a path started with a number, KoStore pre 2.9 would prepend 'part'. We don't do that anymore, but there are files out there with that weirdness, so check whether the path can be opened, and if it can't, fix it up. M +26 -1 krita/ui/kra/kis_kra_load_visitor.cpp http://commits.kde.org/calligra/c1f1a85c7ff6bb0108b162043db33d35f1c0c95d |