More Rake Thoughts: generate_derivatives should be sm_title / th_title

[dcnb]

ending the filename with a _th makes customization more difficult

starting with th or sm then having the filename makes more sense and works better.

you are welcome

[evanwill]

🤔

I am not seeing that?

The Rake task takes .pdf, .tif, .jpg, and .png and makes ".jpg" derivatives for them all, so if for some reason you are reasoning with a filename field, you still have to remove the extension and add .jpg which is just as easy as removing the extension and adding _th.jpg, and to do it you don't need to know anything about what came before the filename (i.e. a relative path to some where or url to external file share)-- it would be harder to add sm_ in front (since the filename or image_small might have a file path in front of the filename, so you would need to preserve that somehow without knowing the exact convention) then also still need to remove the extension to switch to .jpg. And in CSV shouldn't be reasoning based on filename (except when setting up your metadata) anyway, since if it has a thumb or small, the info should be in image_thumb and image_small?

[dcnb]

You are, respectfully, totally wrong.

Especially for a file stored in objects. Any customization you are doing from there, any formula, then requires additions to the beginning ("small/") and then end "_sm.jpg" and often that requires, if, for instance, the filename is pic.jpg, a find and replace for the extension to add the "_sm.jpg"

Whereas, if the filename were the same, the formula is easier -- just "/small/sm_"&[filename cell]" -- it's cleaner in a larger folder too.

In sum, I feel totally right.

On Fri, May 28, 2021 at 11:23 AM EvanWill @.***> wrote:

🤔

I am not seeing that?

The Rake task takes .pdf, .tif, .jpg, and .png and makes ".jpg" derivatives for them all, so if for some reason you are reasoning with a filename field, you still have to remove the extension and add .jpg which is just as easy as removing the extension and adding th.jpg, and to do it you don't need to know anything about what came before the filename (i.e. a relative path to some where or url to external file share)-- it would be harder to add sm in front (since the filename or image_small might have a file path in front of the filename, so you would need to preserve that somehow without knowing the exact convention) then also still need to remove the extension to switch to .jpg. And in CSV shouldn't be reasoning based on filename (except when setting up your metadata) anyway, since if it has a thumb or small, the info should be in image_thumb and image_small?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CollectionBuilder/collectionbuilder-csv/issues/11#issuecomment-850591284, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACTM4GJUUG4YZGK5WU2HQLLTP7NRHANCNFSM45VRSCGA .

[maehr]

🤔

I am not seeing that?

The Rake task takes .pdf, .tif, .jpg, and .png and makes ".jpg" derivatives for them all, so if for some reason you are reasoning with a filename field, you still have to remove the extension and add .jpg which is just as easy as removing the extension and adding _th.jpg, and to do it you don't need to know anything about what came before the filename (i.e. a relative path to some where or url to external file share)-- it would be harder to add sm_ in front (since the filename or image_small might have a file path in front of the filename, so you would need to preserve that somehow without knowing the exact convention) then also still need to remove the extension to switch to .jpg. And in CSV shouldn't be reasoning based on filename (except when setting up your metadata) anyway, since if it has a thumb or small, the info should be in image_thumb and image_small?

I agree with you and suggest that you close this issue.

[evanwill]

🤣