You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all thanks for a great library, it's one of the best out there.
I'm reporting this issue just for the sake of consistency, because we first encountered this problem when run several tests with imaging and then realized that it comes from standard library. Other people may have a similar issues so I thought it would make sense to report it here as well. So feel free to close it or leave as tracking one.
Here is original issue (unexpected EOF error when reading specific file): golang/go#45902
Note, that a lot of software, most importantly browsers, but also editors and viewers don't treat such files as "corrupted" and decode them normally. This raises a question, which criteria should be when a library decides to skip entire file.
In our project, imaging was near perfect fit and everything was almost ready, but unfortunately we seem to have to fall back to Image Magick bindings because we have are a lot of files like this and it's hard to explain a user that his file is "corrupted" when he can open it in both browser and editor. And despite Image Magick can detect that file is not perfect it still lets decode and manipulate with it.
The text was updated successfully, but these errors were encountered:
Hey!
First of all thanks for a great library, it's one of the best out there.
I'm reporting this issue just for the sake of consistency, because we first encountered this problem when run several tests with
imaging
and then realized that it comes from standard library. Other people may have a similar issues so I thought it would make sense to report it here as well. So feel free to close it or leave as tracking one.Here is original issue (
unexpected EOF
error when reading specific file): golang/go#45902This one is more general: golang/go#10447
Note, that a lot of software, most importantly browsers, but also editors and viewers don't treat such files as "corrupted" and decode them normally. This raises a question, which criteria should be when a library decides to skip entire file.
In our project,
imaging
was near perfect fit and everything was almost ready, but unfortunately we seem to have to fall back to Image Magick bindings because we have are a lot of files like this and it's hard to explain a user that his file is "corrupted" when he can open it in both browser and editor. And despite Image Magick can detect that file is not perfect it still lets decode and manipulate with it.The text was updated successfully, but these errors were encountered: