> SRFI 14, which is already part of R7RS-large, already provides the
> charset constants charset:graphic and charset:printable in the same
> senses, so I wouldn't want to contradict those.  There are problems with
> SRFI 14 which may require its replacement  — I hope not  — but I don't
> foresee this changing, as it is aligned with ISO C, ISO C++, and Posix.

For even more fun, Python's `string.printable` considers *all* ASCII
whitespace to be printable: "This includes the characters space, tab,
linefeed, return, formfeed, and vertical tab."

>     Common Lisp also uses the term "graphic character" in the way that you
>     and BSD use "printable character":
>
> And unfortunately so does Unicode.  @#$*.    Neither standard uses the
> term "printable character", so they basically don't make the distinction
> at all.

The ASCII standard (http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf)
also says of space: "This character is interpreted both as a graphic
char- acter and as a control character." The term printable and printing
(character) do not appear in the document at all. This would favor the
term "graphic character".

Also I had no idea anybody interprets space as a control character. BSD
iscntrl() does not. Great. I guess this is the popular interpretation.

> I still think Posix/C/C++ wins.

Hmm. Maybe that and SRFI 14 would set the strongest precedent for
"printing". All of the standards documents would favor "graphic" which
is also a better word in lay terms but it would be a gratuitous
difference from SRFI 14.