Re: [EXTERNAL] [PNG] Upcoming meeting topics (Fourth Edition)

We can discuss it.
But since this is last minute, let's keep tomorrow's meeting cancelled and
add it to next meeting.

Could you write out a brief thing for the changes? Could be a GitHub issue
or several. Or it could just be an email spelling it out.

Thanks!

On Sun, Apr 27, 2025, 8:58 AM Cosmin Truta <ctruta@gmail.com> wrote:

> On Sun, Apr 27, 2025 at 3:24 PM Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
> > Cosmin, I can somewhat understand your position in the context of
> browsers, where users are simply consuming content authored by others….but
> in the case of authoring tools (e.g., Photoshop), then the considerations
> are quite different and may even be business/competitive decisions.
>
> Acknowledged -- hence my use of words "non-normative Recommendations for
> Decoders". And also (perhaps even more importantly) -- *if* we can reach
> consensus.
>
> > So without really understanding what direction(s) you might be trying to
> head towards – it’s difficult to offer more constructive feedback at this
> time.
>
> I will bring forth specific information, but for now, I just wanted to ask
> if this can be added to our WG agenda for things to do in PNG v4.
>
> For a sneak preview, I have no intention at all to suggest how to
> interpolate or extrapolate pixel data that's been missing from the IDAT. I
> was rather thinking about what to do if a PNG file ends abruptly after IDAT
> but before reaching IEND. Or if a PNG file has garbage after IDAT before
> reaching IEND. Or if a palette-encoded PNG file has PLTE and tRNS swapped.
> All of these peculiar instances of brokenness (and a few more) have, at
> least in my mind, one resolution that is rather obvious; but, please, do
> let me know if I'm mistaken :-)
>
> One last important clarification that I want to make is that I have no
> plans to allow garbage data in a PNG datastream, either in the spec or in
> the libpng implementation. From libpng's point of view, this is an
> implementation detail. libpng has two kinds of errors: plain errors (or
> just "errors", which are hard errors that trigger a hard stop), and benign
> errors (which are still errors, but of a recoverable kind). So a PNG
> decoder, be it libpng-based or not, can tell the application "FYI, this is
> a broken PNG, but here's the data that I've been able to retrieve so far,
> in case you're interested".
>
> Sincerely,
> Cosmin
>