Didier 'OdyX' Raboud <o...@debian.org> writes: > Yet one is a string, and the other one an image. If you edit the string > before turning it into a QR code, you get a valid QR code (maybe > encoding a broken, or misleading URL, but still valid QR code). If you > edit the QR code directly, you _can_ get a valid QR code, but chances > are that you are not getting what you want. We have a direct "string > representation" → "binary artifact", quite like in compilation.
Putting aside the issue of the embedded graphic, which is a separate matter, this doesn't sound right to me. Surely the QR code is an encoding of a string? If one can do a round-trip conversion into your preferred format without loss, I'm having a hard time seeing how this is not a preferred form of modification. In other words, to me this feels like claiming that ISO 8859-1 text files are not in the preferred form of modification because they're not Unicode. You can convert them to Unicode trivially and without information loss, so this doesn't feel like a distinction we should be drawing. > That said. We don't _have_ to ship these in source or binary packages, > and therefore getaway without re-building these. But if we are to ship > them, building them at build-time from their source strings is a really > modest price to pay; for the sake of "actually building binary artifacts > from source". If you apply this same rule to character sets or encodings (test files in base64, for instance), I think it looks obviously silly, and I'm not sure why this case would be any different. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
