Re: Meeting minutes - Aug 8th, 2022

I agree.
Although, I don't know how to make them part of the standard, per se. I
think the sample images could be provided alongside the standard as a
helpful tool but not part of the standard itself.

In that regard, PngSuite <http://www.schaik.com/pngsuite/> [1] already does
a great job while not being part of the standard. Maybe we can add a
mention to it somewhere if we aren't already.

[1] http://www.schaik.com/pngsuite/

On Mon, Aug 8, 2022 at 12:00 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> I have to agree on the error handling text vs. sample files.
>
>
>
> One thing that I am pushing in the JPEG committees is that any “reference
> software” **MUST** include a test suite containing both valid and invalid
> files.  I think we should consider the same here – and it fits nicely into
> the “testability” requirements of W3C.
>
>
>
> Leonard
>
>
>
> *From: *Chris Blume (ProgramMax) <programmax@gmail.com>
> *Date: *Monday, August 8, 2022 at 11:56 AM
> *To: *public-png@w3.org <public-png@w3.org>
> *Subject: *Meeting minutes - Aug 8th, 2022
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
>
> Attached is a PDF of the meeting minutes from Aug 8th, 2022.
>
> Executive summary:
>
>    - PNG encoders and decoders are already strongly motivated to behave
>    well (displaying what they can, for example). Any error handling wording we
>    add to the spec to encourage this would not provide additional motivation.
>    Instead, if we want to encourage good error handling behavior we should
>    provide sample images to validate error cases.
>    - We should be firm on PNG encoders to not write out-of-bounds palette
>    indices. For decoders, we can provide a note which mentions that different
>    decoders behave differently and there are images in the wild which abuse
>    this.
>    - Further research is needed to make a decision about the unused
>    trailing bytes in a compression stream.
>    - The PNG spec wording should change away from claiming unused high
>    bits of bKGD and tRNS values "are zero". The wording should instead be
>    along the lines of "should be zero". Additionally, the spec should mention
>    that these bits are ignored. This change clarifies that this is not an
>    error condition.
>    - There are several issues with the definitions section. At the
>    moment, it seems like trimming the definition section will act as a common
>    solution to these issues.
>
> The next meeting will be Aug 22nd, 2022 from 11am-noon Eastern US time.
>
> A future email will list topics for that meeting.
>