Text chunk processing should be in terms of the Encoding Standard

[annevk]

There's a couple of issues with the text here as far as I can tell:

• It's not clear how invalid UTF-8 byte sequences are handled.
• It's not clear if Latin1 means what it maps to in browsers (windows-1252) or isomorphic decode (https://infra.spec.whatwg.org/#isomorphic-decode).

I'm not sure it needs to say anything about encoders having data in other encodings. As there are no fields to store other encodings, it seems self-evident they have to convert.

[svgeesus]

Hi @annevk sounds good, do you have examples of other specs that correctly describe handling of invalid UTF-8 byte sequences by referencing Encoding?

Browsers tend not to display the text chunks inside images, so it is hard to test how they handle bad Latn-1 in practice.

[annevk]

See https://encoding.spec.whatwg.org/#specification-hooks for the possible UTF-8 paths. I suspect you want "UTF-8 decode".

If this is true Latin1 you want https://infra.spec.whatwg.org/#isomorphic-decode. Otherwise you want https://encoding.spec.whatwg.org/#decode with the windows-1252 encoding. I guess we could see what various operating systems do and go with that?

[svgeesus]

Looks like we will need some WPT tests with iTXt containing a UTF-8 BOM, to check it gets discarded rather then presented as literal characters or replacement characters.

[svgeesus]

TweakPNG can be used to view, and edit, the content of iTXt so should be good for making test files too.

[ProgramMax]

Yeah, TweakPNG is nice. I used it for the tRNS WPT test.

Do browsers not ignore iTXt? Is there a way for the browser to access it? (So it can be used in a WPT?)

[svgeesus]

It is possible to get at any part of a PNG file from JavaScript, though it does require writing one's own parser. As an example, PNG file chunk inspector

[annevk]

(I'm pretty sure browsers don't have an API to get at image data currently, though there have been proposals in the past.)

[ProgramMax]

I might be able to compile libpng to wasm, giving us a parser. But this seems pretty extreme for a WPT. And it wouldn't really be testing the browser's iTXt handling, anyway.

[annevk]

How are we writing tests at the moment?

I think ideally tests are in some kind of format that many different kind of implementations can consume. And then implementations that end up ignoring iTXt chunks simply don't run those tests (or only run them to ensure they do the correct thing decoding-wise).

[ProgramMax]

Currently, the tests let the browser raster the image and then query pixels to confirm they are the expected color:
https://wpt.fyi/results/png?label=master&label=experimental&aligned&view=subtest&q=png

The problem I mean is I bet most (all?) browsers see a iTXt chunk and skip past it. I don't think they parse the contents at all.
If I write a parser, I'm not testing the browser. And if my parser then handles the iTXt chunk correctly, all I've done is confirm my own parser behaves correctly. It wouldn't test any sort of conformance.

[annevk]

Right, so

1. iTXt probably needs to be optional in terms of that it is okay to skip past it. That also means that if you do process it you probably don't want to bail out on the entire image if there's an error (i.e., don't use a fatal text decoder).
2. Some aspects of this can be tested across all implementations.
3. Some tests won't be useful for all implementations.

I don't think we want to drop the feature so that's the best we can do here.

[ProgramMax]

Oh, I think I follow now.
We can create an image with a deliberately broken iTXt chunk and make sure the tests still display an image.

[svgeesus]

@annevk wrote:

iTXt probably needs to be optional in terms of that it is okay to skip past it.

PNG already has this: critical chunks are "absolutely required in order to successfully decode a PNG image" while ancillary chunks "may be ignored by a decoder." iTXt is ancillary.

That also means that if you do process it you probably don't want to bail out on the entire image if there's an error (i.e., don't use a fatal text decoder).

Covered under PNG decoders and viewers ... Error handling, specifically:

Recover from an error, if possible; otherwise fail gracefully. Errors that have little or no effect on the processing of the image may be ignored,

and

This is a specific kind of criticality and one that is not necessarily relevant to every conceivable decoder. For example, a program whose sole purpose is to extract text annotations (for example, copyright information) does not require a viewable image. Another decoder might consider the tRNS and gAMA chunks essential to its proper execution.

or, in this specific case, a program whose sole purpose is to extract text annotations should decode UTF-8 correctly (insert link to Encoding Standard).

@ProgramMax wrote:

We can create an image with a deliberately broken iTXt chunk and make sure the tests still display an image.

Yes.