View Single Post
Old 05-31-2022, 05:04 AM   #4
xyclonei
Zealot
xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.xyclonei put the bomp in the bomp-a-bomp-a-bomp.
 
xyclonei's Avatar
 
Posts: 118
Karma: 67444
Join Date: Dec 2018
Device: Kobo Clara HD
Quote:
Originally Posted by JSWolf View Post
But how does the website code know to pick up the converted images given that they will now have a different file extension?
This is my assumption on how it works.

If you have a look at .kobo/articles directory, you can see that the images are stored as a UID filename with no extension. The article file (index.html) makes a call to the filename only. If it's JPG encoded, it displays, else it fails.

What this script does is to make an in-place replacement of the PNG file with a JPG one. Since the filename remains, the call to the image should still be valid and will display correctly.

What I want to check though is whether this can be used as a catch-all for any image type.
xyclonei is offline   Reply With Quote