Le lundi, 30 mars 2020, 21.08:18 h CEST Russ Allbery a écrit :
> Didier 'OdyX' Raboud <odyx@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.
It's a modifiable binary artifact, in that you can read it's content, and
create a different version of itself from the same content, or an alteration
of it. With (but even without) the image in their center, it takes quite some
trial-and-error to get the _exact_same_ image. It's easy to get a functionally
identical QR code; it's quite harder to get the exact same. It _can_ be a bi-
directional lossless conversion; I'd argue that without upstream's build-
parameters, it's not.
Anyway, I am not really arguing that QR codes (even these) are not
redistributable in Debian source or binary packages (I'm leaving this to the
FTP masters). I am saying that with the tooling we have (qrencode is one of
plenty), it is really easy to produce functionally-equivalent QR codes. And
that I think that the cost of doing so (at build time) is really small with
regards to the benefit we get in term of transparency (the URL from the QR
code becomes searchable, the build process is clarified).
Regards,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.