Thumbnail generation + layout

[Jacob Farber]

Thanks for the feedback Boyan, my comments are inline:

On Wed, Dec 9, 2009 at 8:18 AM, Boyan Sheytanov <
boyan.sheytanov at asteasolutions.com> wrote:

> Hi Jacob,
>
> Just to note that thumbnails for Decapod will not be square-sized, as
> they should represent a spread of pages or a single page. So a default
> size of 256x256 would not look good.


-- This shouldnt be a problem, since the thumbnails dont have to be forced
into a square, rather just the dimensions of the bitmap do - they would be
done in a "best-fit" method stamped on top of any  desired background.



> Auto-scaling also does not seem
> the best option to me. Apart from wasting resources, it doesn't look
> well with the image reorderer that the thumbnail browser in Decapod is
> built upon (when you drag a thumbnail that is auto-scaled, a ghost
> image with the original size is shown).
>
>
-- I might be wrong here, but wouldnt we be dragging the element *holding*
the thumbnail, rather than just the image itself? Otherwise, we would lose
all the UI around the image when dragging...


> On first thought, our best option is to provide image cropping and
> scaling API in Kettle, as it might be needed by Decapod, Fluid Engage
> and other projects. If it is customizable enough and simple to use, I
> don't imagine it would be a burden for institutions (as they need to
> deploy Kettle anyway).
>
>
-- I agree, I think we need a server side solution to help with this, but we
need to make sure an implementor of Kettle doesn't see it as an additional
burden or something to remember to update as things change over time.


Thanks for the awesome feedback,
Jacob


-- 
Jacob Farber
University of Toronto - ATRC
Tel: (416) 946-3002
www.fluidproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20091209/386ead1c/attachment.html>