OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Proposal for modification of preview image description


Hi,

thank you very much to all who provided comments to the topic. However, 
I have to admit that I have some difficulties to figure out what they 
mean for my proposal.

The current proposal is to state the following:

"Thumbnails *shall* be saved in the PNG format.

Note: Current desktops display thumbnail images within squares of up to
256 pixel width and height. While this specification does not define
upper or lower limits for thumbnail image sizes, implementations should
only use image sizes that are displayed with a reasonable quality if
scaled to fit into 256x256 pixel square."

So, is it suggested to add some wording for
- a 128x128 bit minimum size, and/or
- 24 bit per pixel, and/or
- alpha transparency?

And is it suggested to add them as normative requirements, or only as 
informal guidelines (i.e. a note)?.

My opinion is that the minimum size and alpha transparency are 
indirectly covered by my proposal, because it states that one "should
only use image sizes that are displayed with a reasonable quality if
scaled to fit into 256x256 pixel square."

That means that is clear that image sizes smaller than 128x128 won't be 
a good choice, and that one for thumbnails that are not squares either 
has to provide images that are not squares, or has to add transparent bits.

The 24 bit color item may be added.

I personally have a preference for stating these things in a 
non-normative way in the future. Simple reason is that the "optimal" 
image size and parameters depend on the platform, and may change in the 
future. I further believe that implementors have an interest in storing 
high quality thumbnail images anyway, and regardless whether we specify 
minimum requirements.

I therefore propose to extend the note above as follows:

Note: Current desktops display thumbnail images within squares of up to
256 pixel width and height, and 24 bit per pixel. While this 
specification does not define upper or lower limits for thumbnail image 
sizes, implementations should only use image sizes that are displayed 
with a reasonable quality if scaled to fit into 256x256 pixel square."

However, while I have a preference for that solution, I have no 
objections to adding one or more of the requirements to the normative 
text, if there is majority for this in the TC, and/or if no objections 
are raised to this approach. It therefore would be good if those who 
believe we should add normative minimum requirements could indicate 
that, and those who have objections for adding them, too, so that I get 
some guidance how to adapt the proposal, if required.

Thank you and best regards

Michael




Florian Reuter wrote:
> Dear TC
> 
> I have some additional comments from our desktop team (Federico Mena Quintero <federico@novell.com>):
> 
> <snip>
> My comments from the desktop side of things:
> 
> * 128x128 or larger is fine; we'll scale the available thumbnails to
> whatever the file manager displays, anyway.  Note that if all your
> documents look similar (letterhead, or LaTeX-like articles) thumbnails
> are just eye candy and they are not really useful, because you cannot
> tell one document apart from another by looking at a thumbnail :)
> 
> * 24 bits per pixel is fine (8-bits-per-channel RGB).  Other bit depths
> are pointless, but we deal with them just fine (we simply ask libpng to
> "give me 24 bpp RGB").
> 
> * Alpha is pointless (all documents have a background color for the page
> --- last time I checked OOo didn't support transparent paper), though
> we'll deal with it just fine (we'll just composite against a suitable
> background like white).
> 
> * PNG is nice and easy, though we can deal with JPEG as well just fine.
> We simply ask a helper program to extract the thumbnail data from the
> ODF file, and then convert it to a format we like.
> </snip>
> 
> ~Florian
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]