w3c / png

Maintenance of the PNG specification
https://w3c.github.io/png/
Other
44 stars 11 forks source link

Lack of public APNG chunks #448

Closed jbowler closed 2 months ago

jbowler commented 4 months ago

The reasons for not defining public versions of the APNG chunks are entirely fallacious. Public chunks do not invalidate the corresponding previously used private chunks; the very heart of the PNG chunk approval process depends on this.

The v3 specification needs to make the definitions of APNG chunks be public chunks and remove the false reasoning.

svgeesus commented 4 months ago

So, you are suggesting that the spec can ignore 17 years of deployed content and just require content authors and tooling to start over because checks notes the failed ad-hoc approval process which produced this mess is more important than interoperability and web compatibility.

jbowler commented 4 months ago

So, you are suggesting that the spec can ignore 17 years of deployed content and just require content authors and tooling to start over because checks notes the failed ad-hoc approval process which produced this mess is more important than interoperability and web compatibility.

No. I'm saying you don't understand private vs public chunk handling IRL and that you are reaching completely erroneous conclusions as a result. No one will change to the public chunks until a sufficiently large set of decoders and APNG editors have provided support. It will take several years not because it is hard but because a lot of software development environments follow a practice of not doing anything until they have to.

It really is trivial to support both public and private APNG chunks of the same "base" name because all it requires is a simple bitwise operation on a single bit of the name; in this case , written in C, "name &~ 0x200000".

svgeesus commented 4 months ago

No one will change to the public chunks until a sufficiently large set of decoders and APNG editors have provided support.

No content creation tools will add such support because there is literally zero motivation for them to do so (export as a file that works, or one that doesn't?)

I agree that if we were to add a duplicate set of public chunks, decoders could trivially support both the private and public forms. But given zero content, their motivation to do so would be fairly low.

ProgramMax commented 3 months ago

@jbowler please be more respectful. "fallacious" and "you don't understand private vs public chunk handling" are pushing it.

Let's walk through the scenario where we make APNG chunks public.

First, web browsers already (prior to Third Edition) supported APNG's private chunks. They can handle both private and public chunks. As you pointed out, that is easy. But they'll never drop the private chunks since they want to preserve web history.

Content creation tools also already support APNG's private chunks. We could ask them to start using public chunks instead. That is a lot of work for us to identify, contact, and keep tabs on all of them. Plus we would need their users to update. I would guess if we're lucky we can get the bulk of it in half a year. But there will always be a long tail that will never drop the private chunks.

My point here is we cannot get away from the private chunks. That isn't an option. So the usual Public vs. Private intentions are out the window.

And what is all of this effort for? The usual Public vs. Private is gone so it's just to honor the idea of Public vs. Private at this point, right? Another way to honor it would be to have a callout saying why this situation was handled uniquely.

Did I miss something? Do you feel there would be an actual benefit? If so, please elaborate.