Fix not loading some xmp exif metadata correctly
-
Loading XMP metadata with BUG:520981 - that one is fully done.
Before this commit, Krita would not consider "32 / 10" a valid value for a Rational field in XMP exif metadata. Those files however exist in the wild and the regex to accept the additional spaces isn't much different. This commit changes the regex to accept possible spaces.
-
Saving with invalid values in XMP metadata BUG:520982 - I'm not sure what to do there
So far I made a commit that omits the invalid values, allowing the user to save a .kra file despite not having all correct metadata. However that means it's silently fails to save them, and the user has no idea. In a commit that's not part of this MR I tried to include it in the document warning messages, but then the kra saving would still fail, because it would consider non-empty warning messages list as a fail state.
Ok, Halla said it's fine. I added it to Krita Usage Log, too.
Test Plan
You need to test separately, because both fix the same issue from the user point of view.
- Get the test file: https://bugs.kde.org/attachment.cgi?id=192833
- Before my MR, if you tried to save it as another file, it would fail, complaining about the metadata.
- After the first commit, it won't fail.
- After the second commit but reverting the first one (
git revert --no-commit) it also won't fail.
Formalities Checklist
- I confirmed this builds.
- I confirmed Krita ran and the relevant functions work.
- I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- I made sure my commits build individually and have good descriptions as per KDE guidelines.
- I made sure my code conforms to the standards set in the HACKING file.
- I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
- Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?
Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.