-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot load an image of mime-type "application/x-msdownload;charset=UTF-8" #5679
Comments
One way to avoid using a fork is to copy the default image loader to your project, change what you need to change, and add it to the |
yeah that is essentially just as good as using a fork url in cargo.toml. Question is how this could be solved more generally without adding like 500 mime-types to this check. one clean way to solve this would actually be to look at the content disposition of the response header, as this one reveals cleanly that it is an image. |
I think the best thing would be to open a PR and add Unfortunately we just did an egui release so itll take a while until the fix is released |
…nd appended encoding info addresses Cannot load an image of mime-type "application/x-msdownload;charset=UTF-8" emilk#5679
created a PR, ready for review. |
I'm currently facing a problem in my program https://github.com/markusdd/EasyEDA_to_KiCAD_Lib_UI where I'm having to interface with a new image API. (using egui 0.30 for this as I cannot migrate to 0.31 yet because of a dependency, but I checked the relevant code, it has not changed)
Most older catalogue entries had URLs directly pointing to JPG files, like this one: https://assets.lcsc.com/images/lcsc/900x900/20230828_Megastar-ZX-PZ2-54-2-5PZZ_C7501276_back.jpg
Analyzing in browser it looks like this:
Now, there is a new API like this: https://jlcpcb.com/api/file/downloadByFileSystemAccessId/8553684168530669568
So the MIME-Type is designated as a download and only the disposition gives away that it is an image. This is common practice for images that are not getting displayed in the browser but directly being downloaded.
The issue is: The image loader currently fails because it does not recognize the MIME-Type and I have found no way through the API to tell it to ignore that.
What I have tried is locally patching the "is_supported_mime" function in src\loaders\image_loader.rs of egui-extras to do this:
So I just 'bluntly' attached my requirement.
And it works perfectly, the images are being displayed again:
But this is not a nice solution and I also cannot deploy my app like this, unless I switch to a fork of egui which I really want to avoid.
Any recommendations how to fix this properly or at least work around it for now?
The text was updated successfully, but these errors were encountered: