Clairty around intended reading of "character" in section 4.2 and elsewhere (v1.6)

[aragilar]

The width attribute is meant to indicate the number of characters to be used for display of the quantity. This has special significance when used with character data, see below.

seems to imply "character" is the number of graphemes in a string (especially since this is in a section discussing display not storage), whereas later

When used with datatype="char" arrays the width attribute is interpreted as an upper bound for the array length in characters, i.e. Unicode code points.

implies "character" is code points.

In the case of multi-dimensional char arrays the value refers to the number of characters in each string element.

could mean in bytes, code points or graphemes (I think the implied reading is code points, but I'm not sure).

I think maybe the best thing to do is find every instance of character and replace it with the appropriate unicode term (see https://stackoverflow.com/questions/27331819/whats-the-difference-between-a-character-a-code-point-a-glyph-and-a-grapheme). I can try to find some time to make a PR with the suggested changes?

[mbtaylor]

@aragilar thanks for this critical reading. I had in mind code points in all three of these usages, but I wrote it before I read the utf8everywhere reference [which points out the slippery nature of terms like "character" in a Unicode context] that you pointed to in a post elsewhere.

The reason that I mentioned display in the first of those quotes was for continuity between uses of the width attribute, which in general concerns display/formatting requirements in a not-necessarily-Unicode context.

So I would suggest to leave the first of those quotes the same, since it's discussing the motivation of the width attribute in general terms; it's only character data for which non-ASCII-like considerations will arise. In the other two cases, which are where the application to datatype="char" is discussed, it should just say code points rather than characters.

Would an edit like that address your concerns about section 4.2?

[mbtaylor]

@aragilar I've had a go at tightening up this language - could you take a look at #90? If you're still not happy by all means make edits or write a PR yourself.