Attachment width and height
Chris
some confirmation on the latest status of storing the attachment
width/height in the database.
My understanding from reading past posts is that the best option for
storing width/height information in the database is to use Kennon
Ballou's fork:
http://github.com/kennon/paperclip
First Question:
Is this still the recommended way?
Looking through Kennon's code it appears that only the original sizes
are stored in the database and that the different styles are
re-calculated based on the original dimensions on demand.
Second Question:
Is my understanding of the calculation of the dimensions for the
various styles correct?
With my initial overview of the code I can't really tell if a system
call is being made to calculate these dimensions on the fly or not, or
if it is simply re-calculating the math based on the dimensions
specified for the styles in the model and the original dimensions. It
appears to me that a system call is NOT occurring to determine the
width/height of the various styles.
Third Question:
Am I correct in assuming that a system call is NOT being used to
determine the dimensions of the generated styles?
Ideally I'd like to have all the dimensions stored in the database and
only calculated once on creation (or update of the file). Does anyone
have any better suggestions on how to do this?
Thanks,
-Chris
Kennon Ballou
time to merge it, and have kind of been waiting until the trunk
stabilizes with support for rails3 (which appears to only be available
as a branch in someone else's fork).
> First Question:
> Is this still the recommended way?
Looking back at my own fork, you can probably get the same functionality
by rolling a processor to do it instead of building it into paperclip
directly, so if someone has already done this I'd probably recommend
that way myself. That being said, I'm using my fork in several
production sites and haven't had any issues.
> Looking through Kennon's code it appears that only the original sizes
> are stored in the database and that the different styles are
> re-calculated based on the original dimensions on demand.
I believe that is correct; this fit my use case and so I hadn't taken it
further. Also, I think that if you override the :original style with new
sizes, I'm not sure what exactly it stores.
> Second Question:
> Is my understanding of the calculation of the dimensions for the
> various styles correct?
>
> With my initial overview of the code I can't really tell if a system
> call is being made to calculate these dimensions on the fly or not, or
> if it is simply re-calculating the math based on the dimensions
> specified for the styles in the model and the original dimensions. It
> appears to me that a system call is NOT occurring to determine the
> width/height of the various styles.
IIRC, I'm just using the built in Geometry, which I thought was using
the information from the original `identify` call
> Third Question:
> Am I correct in assuming that a system call is NOT being used to
> determine the dimensions of the generated styles?
My fork definitely does not calculate the actual dimensions of generated
styles.
> Ideally I'd like to have all the dimensions stored in the database and
> only calculated once on creation (or update of the file). Does anyone
> have any better suggestions on how to do this?
Again, I'd recommend using a custom processor to do this, as then you
could put all of the functionality in there and not clutter up paperclip
itself.
If you make a processor to do this, please let me know and I could merge
it into my fork and replace the existing functionality. Although best
case scenario, you convince Jonathan to put it into the paperclip
master. I still don't know why we can't get some sort of functionality
like this into master, since it's such a common need and so many people
have asked for it :-)
| Kennon Ballou
| Angry Turnip, Inc.
Chris wrote:
> I know this has been kicked around a bit in the past, but I'd like
> some confirmation on the latest status of storing the attachment
> width/height in the database.
>
> My understanding from reading past posts is that the best option for
> storing width/height information in the database is to use Kennon
> Ballou's fork:
> http://github.com/kennon/paperclip
>
>
>
>
>
>
> Thanks,
> -Chris
>
Chris
Thanks for the information. I'll look at the processor route.
Thanks again,
-Chris
Chris
http://gist.github.com/343678
I have created a thumbnail processor that extends the existing
thumbnail processor to save the image dimensions.
WORDS OF CAUTION:
1) I'm fairly new to Ruby and Paperclip, so this may not be the best
way to solve the issue.
2) This isn't purely a thumbnail processor. It also includes a small
monkey patch for Paperclip so that you can call @object.image.width
and have it return the width. (Same for the height) The good news is
that you aren't directly modifying the Paperclip files, so upgrading
isn't a problem.
3) The style dimensions are stored JSON encoded in the database
(that's how we can store the width/height for an arbitrary number of
styles in a single column) so you need to make sure your system can
handle the JSON.parse() command. I'm not sure which gem I have that
allows it (I have both json and json_pure installed). You also need
to make sure your database column is large enough to handle the data.
4) I don't strictly store the width/height. I store the output of the
Geometry.from_file command. Which means that the hash includes
'width', 'height', and 'modifier'. I have no clue what the modifier
is for, but figured it's better to keep it than toss it in case it is
important for someone. This also means that the float value returned
from Geometry.from_file is stored rather than an integer value. I
chose to keep the full data in the database and return the integer
value when calling the 'width' method.
5) The monkey patch causes the width/height method to be available to
ANY attachment on your site, even if the model doesn't have a
#{name}_dimensions column. I'm counting on you not to do something
stupid like calling 'width' on something that wasn't actually run
through this processor.
6) I have no clue what it does if you pass it a PDF.
7) THIS IS THE BIG ONE: There is a bug in the Style class in the core
Paperclip code. If you use the described (in the gist) method for
passing the :format parameter for the style you will not get the
proper image url returned. If you have more than a singe image
displayed on a page, the first image will work properly, all the rest
will not (just for displaying). The bug is on line #19 of
paperclip/lib/paperclip/style.rb in the 'initialize' method. The
original code looks like this:
@format = definition.delete(:format)
It needs to be changed to this:
@format = definition[:format]
So, a lot of caveats but it works for me with the latest
thoughtbot/paperclip code (at least with the fix described in #7
applied to Paperclip).
-Chris
On Tue, Mar 23, 2010 at 11:49 PM, Kennon Ballou <ken...@angryturnip.com> wrote: