Add examples of reading the generated QR codes

[jeroen]

The latest version of opencv can detect and decode QR codes: https://docs.ropensci.org/opencv/reference/qrcode.html

We could use this for unit tests or user examples of reading the generated QR back into R.

[ThierryO]

That would certainly be an option. I've noticed that opencv suggests qrcode. Don't we risk to get a circular dependency when qrcode suggests on opencv?

[jeroen]

That only is a problem for hard dependencies, like "Imports". But "Suggests" is a soft dependency, so either package can be loaded without the other, so there is no problem.

[ThierryO]

I wrote a little test function. It works with ascii but fails with special characters.

  test_read_qr <- function(input) {
    requireNamespace("opencv")
    test_file <- tempfile("qrcode", fileext = ".png")
    png(test_file)
    plot(qr_code(input))
    dev.off()
    opencv::ocv_read(test_file) |>
      opencv::ocv_qr_detect() |>
      expect_equal(input)
    rm(test_file)
  }
test_read_qr("\u00E6")
x <- "fa\xE7ile"
Encoding(x) <- "latin1"
test_read_qr(x)

Error: opencv::ocv_qr_detect(opencv::ocv_read(test_file)) (`actual`) not equal to `input` (`expected`).

`actual`:   "\xe6"
`expected`: "æ"   
In addition: Warning messages:
1: In grepl("\n", x) : unable to translate '<e6>' to a wide string
2: In grepl("\n", x) : input string 1 is invalid

Error: opencv::ocv_qr_detect(opencv::ocv_read(test_file)) (`actual`) not equal to `input` (`expected`).

`actual`:   "fa\xe7ile"
`expected`: "façile"   
In addition: Warning messages:
1: In grepl("\n", x) : unable to translate 'fa<e7>ile' to a wide string
2: In grepl("\n", x) : input string 1 is invalid

[ThierryO]

Below are the problematic qr codes. They give the correct output on my phone.

façile

æ

[jeroen]

Good catch.

I see that you explicitly convert all input to latin in https://github.com/ThierryO/qrcode/blob/60b002480f137c305a9cd93b9acad16c3628f471/R/qr_encode.R#L61C1-L66

However latin1 is a legacy encoding that only works for european text and does not support Chineese, emojis, etc.

Most widely used qr encoders/decoders assume text is UTF-8 encoded from what I read from here.

I think the best solution is to update qrcode to always call enc2uf8 on the input text and not convert to latin1, such that the qr always contains the text in the standard utf-8 format.

[ThierryO]

Handling UTF-8 as UTF-8 is not as simple as just using enc2utf8. I'm on a tight schedule due to a CRAN error. I'll use opencv only to test ASCII text.