<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Wednesday 27 May 2009, Martin Renold wrote: > hello, > > Here are my notes and the proposal. > I will add this to the specification if noone objects. > > Notes: > > This is what other file formats do: > - OpenOffice: includes Thumbnails/thumbnail.png, 256x256, alpha > - Krita: includes preview.png, 256x256 > - XCF: GIMP adds an 128x128 preview to ~/.thumbnails/normal/ > Nautilus and Konqueror use them but can't generate them. > Renaming or moving those files removes the preview, see: > http://jens.triq.net/thumbnail-spec/thumbsave.html > > The maximum size that any program shows without "really" opening the > image is 256x256 (when hovering over PNG in konqueror). Usually, > thumbnails and previews are limited to 128x128 at maximum zoom. > > Proposal: > > I suggest we go the Krita way and add a file called "preview.png", with a > maximum size of 256x256. The preview must not be referenced in stack.xml. > The preview is highly reccommended, but not mandatory. This is in order to > simplify the minimal OpenRaster export implementation. I would suggest the ODF (or as you named it OpenOffice) way, and use Thumbnails/thumbnail.png. That way application that allready support ODF thumbnail just have to add openraster as a mimetype, and it will works automagically. I suspect the krita way is inherited from the old koffice file format, lets go forward and uniformize with existing ISO standard :) > Programs that save OpenRaster files should add a scaled version of the > preview to ~/.thumbnails/normal as specified by the "Thumbnail Managing > Standard" (max. 128x128, see link above). Other programs are encouraged to > update this when required (eg. file rename). My personnal opinion is that it's not up to programs (other than file management), to manage ~/.thumbnail and that the way the gimp did it is just a work around and should not be generalized. A bit off topic... Looking at [1], I think the data directory should be only a recommendation, since anyway all files are saved in stack.xml with a relative path from stack.xml. [1] http://create.freedesktop.org/wiki/OpenRaster/File_Layout_Specification -- Cyrille Berger</body></html>