Talk:Graphic character

Status of space
"The space is considered to be both a graphic character and a control character in ISO 646; this is probably due to it having a visible form on computer terminals but a control function (of moving the print head) on teletypes. "

I can see what this is saying. In some respects the space would be considered a graphic character:
 * it has a visual representation
 * as such, where code 32 appears in the buffer of a text-mode VDU whose character set is ASCII or any superset thereof, one can be sure what to expect to see in that character cell
 * fonts are likely to contain a glyph for it, even if that glyph has the appearance of a blank space (though this may depend on the platform); in any case, the character would have a width
 * programming languages, database systems, etc. invariably allow it to be included within a string (if they support strings at all)

In other respects it is special:
 * it is sometimes represented by a "control code" such as SP, in line with the control codes for ASCII characters 0-31 and 127.
 * in the syntax of many text-based data formats and programming languages, it is a whitespace character just like CR, LF and HT
 * in most modern programs that support multi-line display and/or editing of text (word processors, web browsers, text editors, email clients, etc.), it is treated specially in order to achieve word-wrapping and (in some cases) justification
 * a daisywheel probably wouldn't include a petal for space; rather, the printer would be likely to just advance the print head when it receives a space character (this is perhaps the basis of the statement about teletypes).

Ironically, there are standard C functions  and , which consider the space to be neither a control character nor a graphic character, which is the opposite of this statement.

I suppose the only real conclusion of this is that the status of the space depends on your point of view. Still, we ought to find a link for the ISO standard on this. Moreover, the use of "probably" implies that the reason given is speculation, rather than research, so I'm not sure that tagging it with or is right.

What do people think we should do with the statement? — Smjg (talk) 02:06, 4 May 2013 (UTC)


 * Description of these two funcs (taken from isalpha(3) manpage on GNU/Linux) may suggest:
 * checks for any printable character except space.
 *  
 * checks for a control character.
 * And on the same system, space matches  but not   (nor  ).
 * Maybe the quoted sentence should be rather „… neither …“, and claim „graphic character, also known as printing character“ should be improved?
 * —Mykhal (talk) 06:59, 7 June 2024 (UTC)
 * Maybe the quoted sentence should be rather „… neither …“, and claim „graphic character, also known as printing character“ should be improved?
 * —Mykhal (talk) 06:59, 7 June 2024 (UTC)


 * I'd almost forgotten I'd posted that! I don't see   on either the man page or my original message – have you made a transcription error?
 * I see the wording has been changed a bit, but I'm still not sure that it makes sense. "It can have a visible form, and also a control function (moving the print head)."  This seems to be saying that moving the print head is something it does in addition to having a visible form.  Which is nonsense: all ASCII graphic characters normally advance the cursor/carriage/print head/whatever when rendered.  I suppose the way in which it is different is that in some situations (such as teletypes) it may be effectively a control character, its operation being "advance the print head without printing a character".  In this respect, it's also the same as the space bar on typewriters.
 * Incidentally, some systems have character codes for 'left', 'right', 'up' and 'down'. On these, 'right' is effectively 'space' considered as a control character.  When sent to a line printer, these would have the same effect on the output.  But on a VDU, 'right' would simply advance the cursor whereas 'space' would replace the character at the current position with a space as well.
 * But the problem is that the quoted sentence is stating what ISO 646 says. To change it would be to misrepresent the standard.  Still, I'm sure there's a better way to write what the sentence that follows is trying to say. — Smjg (talk) 10:30, 7 June 2024 (UTC)