R help - Jul 2021 - Plotting the ASCII character set.

I have (used to have?) a function plot_ascii() which would display the
ascii character set in a graphical display.  It simply used text() to
place the symbols on a 16 x 16 grid.  The labels used by text() were
taken from a character vector that I called "all.ascii".  According to
my notes, the entries of this vector were obtained from a posting to
R-help made by the redoubtable Martin Maechler back in 2002.

This function *used* to work!  Now it doesn't.  When I invoke
plot.ascii() I get an error:
> Error in text.default(tmp, labels = all.ascii) : 
>   invalid string in PangoCairo_Text
To give a simple example, just looking at *one* of the characters,
which comes from the string "\260" in my data file:

    a <- "\260"
    plot(0,0,type="n",xlim=c(0,1),ylim=c(0,1),ann=FALSE,axes=FALSE)
    text(0.5,0.5,labels=a)

Same error.  If I type the name a I get "\xb0", which I don't
understand.  Can't get my head around character encoding.

If I do

    plot(0,0,type="n",xlim=c(0,1),ylim=c(0,1),ann=FALSE)
    text(0.5,0.5,labels="\ub0")

then I get the degree symbol plotted; I guess that b0 is the hex
encoding of the degree symbol; apparently 260 is the octal encoding of
this symbol.

Can anyone suggest how I might get my plot_ascii() function working
again?  Basically, it seems to me, the question is:  how do I persuade
R to read in "\260" as "\ub0" rather than "\xb0"?

I hope for enlightenment! :-)

cheers,

Rolf Turner

P.S. My sessionInfo() may be relevant:

R version 4.1.0 (2021-05-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.2 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
LAPACK: /usr/lib/x86_64-linux-gnu/atlas/liblapack.so.3.10.3

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_NZ.UTF-8        LC_COLLATE=en_GB.UTF-8    
 [5] LC_MONETARY=en_NZ.UTF-8    LC_MESSAGES=en_GB.UTF-8   
 [7] LC_PAPER=en_NZ.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] brev_0.0-5

loaded via a namespace (and not attached):
 [1] magrittr_1.5      usethis_2.0.1     devtools_2.4.2    pkgload_1.2.1    
 [5] R6_2.4.1          rlang_0.4.11      mixreg_1.0-1      fastmap_1.0.1    
 [9] tools_4.1.0       pkgbuild_1.2.0    sessioninfo_1.1.1 cli_2.5.0        
[13] withr_2.4.2       ellipsis_0.3.2    remotes_2.4.0     rprojroot_1.3-2  
[17] lifecycle_1.0.0   crayon_1.3.4      processx_3.5.2    purrr_0.3.4      
[21] callr_3.7.0       fs_1.5.0          ps_1.6.0          testthat_3.0.3   
[25] memoise_2.0.0     glue_1.4.0        cachem_1.0.5      compiler_4.1.0   
[29] desc_1.3.0        backports_1.1.6   prettyunits_1.1.1


-- 
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

Hello Rolf Turner,

On Sat, 3 Jul 2021 14:02:59 +1200
Rolf Turner <r.turner at auckland.ac.nz> wrote:
> Can anyone suggest how I might get my plot_ascii() function working
> again?  Basically, it seems to me, the question is:  how do I persuade
> R to read in "\260" as "\ub0" rather than
"\xb0"?
Part of the problem is that the "\xb0" byte is not in ASCII, which
covers only the lower half of possible 8-bit bytes. I guess that the
strings containing bytes with highest bit set used to be interpreted as
Latin-1 on your machine, but now get interpreted as UTF-8, which
changes their meaning (in UTF-8, the highest bit being set indicates
that there will be more bytes to follow, making the string invalid if
there is none).

The good news is, since it's Latin-1, which is natively supported by R,
there are even multiple options:

1. Mark the string as Latin-1 by setting Encoding(a) <- 'latin1' and
let R do the re-encoding if and when Pango asks it for a UTF-8-encoded
string.

2. Decode Latin-1 into the locale encoding by using iconv(a, 'latin1',
'') (or set the third parameter to 'UTF-8', which would give
almost the
same result on a machine with a UTF-8 locale). The result is, again, a
string where Encoding(a) matches the truth. Explicitly setting UTF-8
may be preferable on Windows machines running pre-UCRT builds of R
where the locale encoding may not contain all Latin-1 characters, but
that's not a problem for you, as far as I know.

For any encoding other than Latin-1 or UTF-8, option (2) is still valid.

I have verified that your example works on my GNU/Linux system with a
UTF-8 locale if I use either option.

-- 
Best regards,
Ivan