The Wayback Machine - https://web.archive.org/web/20200525104820/https://github.com/coobird/thumbnailator/issues/78
Skip to content

/ thumbnailator

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

Jump to bottom

Adding a suffix to the thumbnail filename gives inconsistent file filename #78

Open
GoogleCodeExporter opened this issue Jul 25, 2015 · 2 comments
Open

Adding a suffix to the thumbnail filename gives inconsistent file filename #78

GoogleCodeExporter opened this issue Jul 25, 2015 · 2 comments
Labels
Priority-Medium Type-Defect auto-migrated

Comments

@GoogleCodeExporter
Copy link

@GoogleCodeExporter GoogleCodeExporter commented Jul 25, 2015 

The filename of thumbnails appears inconsistent if your input and output file 
types are different.

Thumbnails.of(testFile)
.size(100, 100)
.outputFormat("jpg")
.toFiles(Rename.SUFFIX_HYPHEN_THUMBNAIL);

i.e. If you create a jpeg thumbnail for a file with a .png extension then the 
resulting filename .png.jpg but if you create a jpeg thumbnail from a .jpg file 
the extension stays the same.

mypicture-suffix.png -> mypicture-suffix.png.jpg
mypicture-suffix.jpg -> mypicture-suffix.jpg

This can be done by modifying the Rename.appendSuffix() method to not append 
the file extension back onto the filename and leave that to the 
FileImageSink.write() method which handles appending it if the extensions are 
different.

Original issue reported on code.google.com by ja...@somethingwild.co.nz on 15 Jun 2015 at 5:54
@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Jul 25, 2015 

Thank you for taking the time to point out this issue.

I am aware of this behavior, and it is the original intended behavior. 
(Although it is not clearly documented.)

That said, I have noticed that this behavior is a little bit surprising for 
some people. (See Issue 66)

One of the advantages of keeping the old extension is that it will keep a 
record of what the original format of the image was.

I'm up to hearing more opinions about what the most appropriate behavior should 
be for cases where the image formats change between the input and output.

(Also, I may end up merging this issue with Issue 66, as it is very similar.)

Original comment by coobird...@gmail.com on 16 Jun 2015 at 4:23

  • Changed state: Accepted
@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Jul 25, 2015 

My recommendation would be for consistency
e.g.
always replace the extension (mypicture.png -> mypicture-thumbnail.jpg)
always add an extension (mypicture.jpg -> mypicture.jpg-thumbnail.jpg)

Thinking about the problem in two ways gives slightly different requirements.
- I'm creating thumbnails and still using the original image
- I'm creating a scaled down version of the original image to use instead

In my use-case I'm doing the first (thumbnails) and decided in the end to keep 
the source file type as the thumbnail file type as images with transparency 
when converting to jpeg were being created with a black background colour.

Could I suggest adding some new static constants to the Rename class with some 
more doc as probably be the best solution (and maintain compatibility) as they 
are nice to have to get things going quickly.

Original comment by ja...@somethingwild.co.nz on 16 Jun 2015 at 8:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority-Medium Type-Defect auto-migrated
1 participant
@GoogleCodeExporter
You can’t perform that action at this time.