Repository navigation
Conversation
Since #82 the transform has written `format:/scratch/output-0`, and ImageMagick reads a prefix it has no coder for as part of the filename, so a JPEG uploaded as .jfif, .jif or .jfi failed as unreadable. The ImageMagick toolchain stages a sibling named with the format's extension again and adopts it into place, as before #82, so an unknown format keeps the source's, as it does under stock Rails. The vips toolchain keeps #82's direct write. Fixes #84.
Member
|
Going to decline to merge in favor of hotcell#103 which modifies the format on the client side. I think that's cleaner and also improves the VIPS side of the house. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #84
Why
Rails names a web image's variant format after the upload's extension when Marcel maps that extension to the blob's content type. So an app using the ImageMagick transformer gets format
jfiffor a JPEG uploaded asphoto.jfif. The same goes for.jifand.jfi, in any letter case.Since #82, the transform saves straight to the output's scratch path, which has no extension, so image_processing names the output format with a prefix:
jfif:/…/output-0. ImageMagick has no coder calledJFIF. It reads the whole string as a filename, fails to open it, and the operation answersunreadable, a permanent failure, for a perfectly good JPEG. Stock Rails doesn't hit this, because it lets image_processing name a tempfile with the extension.What changes
Output#path(extension:)) and adopts it into place, as it did before Require image_processing 2.2.0 and drop the transform rename #82. ImageMagick picks the coder from an extension it knows, and keeps the source's format for one it doesn't. That's the same thing stock Rails gets.Transforming#performnames the save path through a newencoded_pathhook: the default is the scratch path, andTransformers::Image::Magickoverrides it.Output#pathdoc and comment now mention this second use of the extension sibling, and there's a changelog entry underActiveStorage::HotCell::Server/ Fixed.An explicit
svgzvariant, which failed the same way, now behaves as it does under stock Rails too.Tests
magick_transform_image_test.rbgets #84's reproduction forjfif,jifandjfi: a JPEG transformed to each format comes back as a resized JPEG.unable to open image 'jfif:…'.bundle exec rakepasses locally: every suite includingtest:activestorage, plus rubocop.rake docs:checkis clean.