User:HarJIT/sandbox/Halfwidth-fullwidth typography

A command prompt (cmd.exe) with Korean Localisation showing halfwidth and fullwidth characters

In CJK (Chinese, Japanese and Korean) computing, graphic characters are traditionally classed into fullwidth (in Taiwan and Hong Kong: 全形; in CJK: 全角) and halfwidth (in Taiwan and Hong Kong: 半形; in CJK: 半角) characters. With fixed-width fonts, a halfwidth character occupies half the width of a fullwidth character, hence the name.

Halfwidth and Fullwidth Forms is also the name of a Unicode block U+FF00–FFEF, provided so that older encodings containing both halfwidth and fullwidth characters can have lossless translation to/from Unicode.

Rationale

Further information: Duospaced font

In the days of text mode computing, Western characters were normally laid out in a grid on the screen, often 80 columns by 24 or 25 lines. Each character was displayed as a small dot matrix, often about 8 pixels wide in a monospaced font, and a SBCS (single byte character set) was generally used to encode characters of western languages.

For a number of practical and aesthetic reasons Han characters need to be square, approximately twice as wide as these fixed-width SBCS characters. Accordingly, on fixed-width displays, duospaced fonts (or duospace fonts) were used, in which letters and characters can occupy either a single or double amount of a specified, fixed horizontal space. As these were typically encoded in a DBCS (double byte character set) this also meant that their length on screen in a duospaced font was proportional to their byte length.

Some terminals and editing programs could not deal with double-byte characters starting at odd columns, only even ones (some could not even put double-byte and single-byte characters in the same line). So the DBCS sets generally included Roman characters and digits also, for use alongside the CJK characters in the same line.

On the other hand, early Japanese computing used a single-byte code page called JIS X 0201 for katakana. These would be rendered at the same width as the other single-byte characters, making them half-width kana characters rather than normally proportioned kana. Although the JIS X 0201 standard itself did not specify half-width display for katakana, this became the visually distinguishing feature in Shift JIS between the single-byte JIS X 0201 and double-byte JIS X 0208 katakana. Some IBM code pages used a similar treatment for Korean jamo, based on the N-byte Hangul code and its EBCDIC translation.

Although associated with Asian character sets, the general notion of duospaced fonts is not limited to such characters. Examples of duospaced characters not strictly associated with Asian halfwidth and fullwidth forms include various technical and pictographic symbols as seen in Migu 2M, and the Unicode character Roman Numeral One Hundred Thousand (U+2188) and various other symbols in GNU Unifont.

What a code actually encodes

An individual code in a legacy DBCS, such as Big5, does not always represent a complete semantic unit. Those of logograms are always logograms, but codes for symbols, punctuation or special characters are not always complete graphical characters. What is encoded are particular graphical representations of characters or part of characters that happen to fit in the space taken by two monospaced ASCII characters. This is a property of double-byte character sets as normally used in CJK (Chinese, Japanese, and Korean) computing, and is not a unique problem of Big5.

(The above might need some explanation by putting it in historical perspective, as it is theoretically incorrect: Back when text mode personal computing was still the norm, characters were normally represented as single bytes and each character takes one position on the screen. There was therefore a practical reason to insist that double-byte characters must take up two positions on the screen, namely that off-the-shelf, American-made software would then be usable without modification in a DBCS-based system. If a character can take an arbitrary number of screen positions, software that assumes that one byte of text takes one screen position would produce incorrect output. Of course, if a computer never had to deal with the text screen, the manufacturer would not enforce this artificial restriction; the Apple Macintosh is an example. Nevertheless, the encoding itself must be designed so that it works correctly on text-screen-based systems.)

To illustrate this point, consider the Big5 code 0xa14b (…). To English speakers this looks like an ellipsis and the Unicode standard identifies it as such; however, in Chinese, the ellipsis consists of six dots that fit in the space of two Chinese characters (……), so in fact there is no Big5 code for the Chinese ellipsis, and the Big5 code 0xa14b just represents half of a Chinese ellipsis. It represents only half of an ellipsis because the whole ellipsis should take the space of two Chinese characters, and in many DBCS systems one DBCS character must take exactly the space of one Chinese character.

Characters do not always represent things that can be readily used in plain text files; an example is "citation mark" (﹋, Big5: 0xa1ca), which is, when used, required to be typeset under the title of literary works. Another example is the Suzhou numerals, which is a form of scientific notation that requires the number to be laid out in a 2-D form consisting of at least two rows.