-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Join chunk ordering rules #467
Comments
Can't help but notice the |
Can you help me understand your question a little more? I don't fully grasp it. When you say the original specification, if you meant PNG 1.0, § 4.3. Summary of standard chunks has several "Before PLTE" (cHRM, gAMA, sBIT). So perhaps you meant the original Mozilla spec for APNG? I haven't carefully combed through the libpng patch but I would believe it could be missing something. I wouldn't be surprised if the original Mozilla APNG patch simply left out some of the ordering requirements and the libpng patch was based on it. Then we filled the hole but the libpng patch didn't get updated. |
Yes. Looking at the generated test images from https://philip.html5.org/tests/apng/tests.html linked in the Mozilla specification page out of 60 images there's 3 indexed-color images: 036, 037, 038, they all have the If that rule has been missing from the code and the specification all along there could be a lot of APNG's in the wild created without libpng where |
I see. Man, I keep finding myself wanting to write a crawler to fetch and analyze pngs in the wild. I might be able to have an old Google coworker tell me the results of a test if I write it into Chrome. (We were able to write anonymous test cases and deploy it to say 1% of the population for things like this.) For now, that "could" (break existing APNGs) is difficult to make a decision on. I don't have data on the likelihood of "could". If we add a requirement in this edition and find it to be a problem, we can remove it in a later edition and maintain backwards compatibility with this edition. If we don't add the requirement to this edition, a future edition would be unable to add it without breaking backwards compatibility. So I'm tempted to leave it in this edition. But only because I don't know how powerful "could" is. I'll look into the Chromium and Firefox codebases and see if they enforce a restriction. I assume the patch you are referring to is the libpng APNG patch, right? |
It looks like FireFox does not check that there is a PLTE chunk before the acTL chunk: Nor does Chromium: I reached out to someone at Google about possibly running a test to see how many APNGs in the wild users encounter where the acTL chunk comes before the PLTE chunk. |
That would be very useful, for this and for other issues. |
Yup, the Mozilla APNG spec says:
and PNG 3rd Edition says the same
and (in the table of chunk ordering rules): Chunk name | Multiple allowed | Ordering constraints The intent was to exactly follow the Mozilla spec so the "Before PLTE" is inconsistent with the chunk definition, inadvertent (likely my fault, sorry) and should be corrected. |
The lattice diagrams also don't require |
§ 5.6 Chunk ordering lists out specific chunks and their ordering requirements.
§ 14.3 Ordering of chunks lists out the more general rules.
These two sections should perhaps be merged.
I don't see a benefit to having them separate.
But I do see drawbacks (such as a reader thinking they have absorbed the ordering rules after only seeing half with no indication to them).
I'm adding the "Future edition considerations" Milestone because I don't want to introduce new changes to Third Edition. This ordering split has existed since PNG 1.0 spec.
The text was updated successfully, but these errors were encountered: