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 Thomas,

Thomas Zander wrote:
> On Wednesday 01 August 2007 10:49:31 Michael Brauer wrote:
>> Well, this probably can be said in better words. I'm very open for
>> suggestions.
> 
> I'm wondering why there was a requirement for 24-bit and alpha and 
> non-interlace.
> My guess would be that this is the most common png format (there are a LOT 
> of subformats) and everyone will be able to read those.

The thumbnail specification for ODF used the freedesktop.org 
specification as a guide. It freedesktop.org specification says:

"The image format for thumbnails is the PNG format, regardless in which 
format the original file was saved. To be more specific it must be a 
8bit, non-interlaced PNG image with full alpha transparency (means 255 
possible alpha values). However, every program should use the best 
possible quality when creating the thumbnail. The exact meaning of this 
is left to the specific program but it should consider applying 
antialising."

I guess the requirements in the ODF spec come from there, except that 
the 8 bit color depth has been increased to 24 bit, because 8 bit are 
not really a lot.

But even in freedesktop.org spec, the requirements seem to be only 
minimum requirements, because the specification says: "every program 
should use the best possible quality".

> I especially recall windows not being very good at supporting PNGs.

I'm not aware of any limitations regarding the support of PNG sub 
formats, but I'm not an expert in this area. However, I am not aware 
that such limitations, if they exist at all, were the reasons for the 
current text in the specification.

> 
> Has this situation changed that its ok to release these requirements?
> 
>> In addition, the thumbnail image size has an
>> impact on the document size. The larger the image gets, the larger the
>> documents get. That may not be an issue for desktop systems, but may be
>> for small devices storing many small documents. So, taking it all
>> together, the "optimal" thumbnail image size depends on many factors,
>> and it seems to be reasonable to me to allow implementors/users to
>> choose an image size that is appropriate for their use case and
>> platform, rather than to require a certain one in the specification.
>> The same applies to other PNG parameters that we have in the
>> specification
> 
> A 256x256 image is some 7.5Kb. A 128x128 is barely 3kb.  So, I'm not 
> convinced.

Convinced of what?

I think we are in agreement that it is not sufficient any longer to 
allow only 128x128 bit images, but that larger images have to be 
supported, and I'm actually not proposing to store smaller images than 
128x128. As for the image size, the only open question is whether there 
should be a 128x128 minimum size. I have no objections to that, but I 
think we don't need that if we say already that images should look well 
if displayed with a 256x256 resolution.


> 
> I still think we need a minimum of 128x128, and I'd like some more info on 
> the other specs as well before we just throw them away.

See above. I have no objections to adding a minimum size, but I don't 
think we need them if we add the note that I have proposed in my 
previous mail. I have further no objections to extend this note with the 
other requirements we had if this is considered to be reasonable. 
However, I actually believe that it is the better option to provide them 
as non-normative guidelines, than as normative text. Because the latter 
may mean that users of a platform for which these requirements are not 
optimal may have disadvantages.

BTW: We recommend to use PNG for images within the document, too. We 
don't have any limitations where as well.

Best regards

Michael


-- 
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]