Why a png, why not a thumbnail, why a control.
- From: Michael Meeks <michael ximian com>
- To: Jens Finke <jens triq net>
- Cc: Chris Phelps <chicane reninet com>, <gnome-devel-list gnome org>, <gnome-devel-list gnome org>, <gnome-2-0-list gnome org>, <gnome-components-list gnome org>
- Subject: Why a png, why not a thumbnail, why a control.
- Date: Tue, 11 Dec 2001 02:01:29 -0500 (EST)
Hi Jens,
Firstly libthumb fills a different niche than a preview. I am
fairly convinced that you're not going to get a sensible amount of preview
information into a 64x64 pixmap - and if you interpolate it up you'll just
get rubbish. My feeling is that a relatively large (but compressed) png
would be ideal. Many document views have a very regular - compressible
layout and thus it seems reasonable to pick a largish sort of size;
perhaps 320x200 or somesuch - interpolated to a sensible size on display.
Of course - a thumbnailing library could operate on a compound
doc. file to further shrink the thumbnail to 64x64 if that is what was
required. Personaly I would do this sparingly - a preview of a word
document is going to look just like any other word document at that sort
of size - better to have a pretty TigerT icon [1].
So - yes libthumb is useful, but I feel not for previews.
On Mon, 10 Dec 2001, Jens Finke wrote:
> Well, your point is to use a BonoboControl for displaying all this.
> Let's assume you have a dir with 30 different files in it. I don't
> believe it's very efficient to start multiple controls to create a
> preview for all the different file types.
Quite - and that's why the control use is only suggested for a
single pane to the left of a file selector window. I think we're talking
at cross purposes here. No-one would suggest using BonoboControl as a
generic thumbnailing abstraction - for a start it wouldn't anti-alias
nicely, it'd kill the XServer etc. etc.
> My idea is to define a standard way of storing such previews on the
> filesystem level.
Indeed - best inside some sort of standard compound doc. format -
which apparently, is going to be pkzip [ according to rumours ]. Of course
- libthumb will have a different standard for caching thumbnails - since
it's operating on an entirely different set of constraints and performance
requirements.
Regards,
Michael.
[1] - if you were feeling particularly cunning - you could write some sort
of edge detection / count code and get some metric of whether there was in
fact useful / visible data in the file. Or whether to have a stock icon
type [ inside libthumb ]
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]