OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC,

here a some comments from my colleague Hubert Figuiere who knows more about this then me:



Best regards,

~Florian


>>> Michael Brauer - Sun Germany - ham02 - Hamburg 

On Tuesday 31 July 2007 20:36:19 Florian Reuter wrote:
> here a some comments from my colleague Hubert Figuiere who knows more
> about this then me:
>
> 

Thomas Zander wrote:
> On Tuesday 31 July 2007 20:36:19 Florian Reuter wrote:
>> here a some comments from my colleague Hubert Figuiere who knows more
>> about this then me:
>>
>> 

On Tuesday 31 July 2007 20:55:42 Bruce D'Arcus wrote:
> Thomas -- you might read the document that Florian linked to before
> jumping on him.

I took his email to reply to, I could have taken any email.  My point was 
that there is a proposal where the only reason I have seen so far is that 
some (unnamed) operating system might not work with it.
I was requesting more info.

> It recommends using 128x128 or 256x256. Are you saying 
> we can't allow 256x256?

In vain of the classic mistake of "640kb should be enough for everyone" I 
have no problems with changing the spec to requiring a minimum of 128x128 
so an implementation can write a 256x256 image or even bigger.

I think the rest of the original text still makes sense, and I'd like to 
see the concrete problems faced on which the proposal was based.
-- 
Thomas Zander

Hi,

first of all, thank you very much for all the feedback to the proposal. 
I'm answering to this particular mail, because I think the suggestion 
from Florian/Hubert Figuiere provided a very good basis for refining my 
proposal. However, this mail should be seen as a reply to the other 
mails regarding this topic as well.

Actually, I think I should have provided some more rationales for the 
proposal: The reason for proposing to change the specification at all 
was that it turned out that some operating systems allow to display 
thumbnails in boxes that are larger than 128x128 pixels. As 
Florian/Hubert Figuiere correctly mention, the thumbnail specification 
at freedesktop.org allows 128x128 and 256x256 pixels. Microsoft Windows 
Vista also allows thumbnail boxes up to 256x256 (at least that is what I 
have been told). And 128x128 pixel thumbnail upscaled to 256x256 simply 
look bad. Therefore, the rational behind the proposal actually was to 
support larger thumbnail images than 128x128 pixels. The idea never was 
to support smaller ones.

I thirst thought about adding 256x256 pixels as an option, but decided 
against that. The reason is that the two examples provided above are 
just two examples. Other operating systems may use other thumbnail 
sizes, and who knows what sizes will be used in future OS versions, 
let's say in a year or two? 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.

However, I also agree that with the text I have proposed, any guidance 
what an appropriate image size may be is lost, and that this may be an 
issue. To resolve this issue, I like Hubert Figuiere's idea to say in 
which resolution thumbnail images are typically displayed, rather than 
recommending any image sizes. I therefore suggest to add a the following 
(non-normative) note to the (normative) text I have proposed:

"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."

Well, this probably can be said in better words. I'm very open for 
suggestions.

A normative minimum size seems not to be required in that case, because 
the note makes already clear that a 33x32 pixel image will not be the 
best choice.

Some more comments are inline.


Florian Reuter wrote:
> Dear TC,
> 
> here a some comments from my colleague Hubert Figuiere who knows more about this then me:
> 
> 
> 
> Best regards,
> 
> ~Florian

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

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.
I especially recall windows not being very good at supporting PNGs.

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.

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.
-- 
Thomas Zander

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