# Formulários de meia largura e largura total

Na computação CJK (chinês, japonês e coreano), os caracteres gráficos são tradicionalmente classificados em largura total (em Taiwan e Hong Kong : 形 形 ; em CJK: 全 角 ) e meia largura (em Taiwan e Hong Kong : 半 形 ; em CJK: 半角 ) personagens. Com fontes de largura fixa, um caractere de meia largura ocupa metade da largura de um caractere de largura total, daí o nome.
Os formulários Halfwidth e Fullwidth também são o nome de um bloco Unicode U + FF00 – FFEF, desde que codificações mais antigas que contenham caracteres de meia largura e largura total possam ter conversão sem perdas de / para Unicode.

## Fundamentação

Nos dias de computação em modo texto, os caracteres ocidentais eram normalmente dispostos em uma grade na tela, geralmente 80 colunas por 24 ou 25 linhas. Cada caractere era exibido como uma pequena matriz de pontos, geralmente com cerca de 8 pixels de largura, e um SBCS (conjunto de caracteres de byte único) era geralmente usado para codificar caracteres dos idiomas ocidentais.
Por várias razões práticas e estéticas, os caracteres Han precisam ser quadrados, aproximadamente o dobro da largura desses caracteres SBCS de largura fixa. Como estes eram tipicamente codificados em um DBCS (conjunto de caracteres de byte duplo), isso também significava que sua largura na tela em uma fonte de espaço duplo era proporcional ao comprimento de bytes. Alguns terminais e programas de edição não podiam lidar com caracteres de byte duplo iniciando em colunas ímpares, apenas pares (alguns nem sequer podiam colocar caracteres de byte duplo e byte único na mesma linha). Portanto, os conjuntos DBCS geralmente incluem caracteres e dígitos romanos também, para uso juntamente com os caracteres CJK na mesma linha.
Por outro lado, a computação japonesa antiga usava uma página de código de byte chamada JIS X 0201 para katakana . Eles seriam renderizados na mesma largura que os outros caracteres de byte único, tornando -os caracteres kana de meia largura em vez do kana proporcional normalmente. Embora o próprio padrão JIS X 0201 não tenha especificado a exibição de meia largura para katakana, esse se tornou o recurso visualmente distintivo no Shift JIS entre o katakana JIS X 0201 de um byte e JIS X 0208 de byte duplo. Algumas páginas de código da IBM usaram um tratamento semelhante para o jamo coreano, base no código Hangul de N bytes e sua tradução EBCDIC .

## Em Unicode

Para compatibilidade com conjuntos de caracteres existentes que continham versões de meia e largura total do mesmo caractere, o Unicode alocou um único bloco em U + FF00 – FFEF contendo os caracteres "largura alternativa" necessários. Isso inclui uma versão com largura total de todos os caracteres ASCII e algumas pontuações não ASCII, como o sinal Yen, versões com meia largura de katakana e hangul e versões com meia largura de alguns símbolos naturalmente quadrados, como círculos. Somente caracteres necessários para ida e volta sem perdas a conjuntos de caracteres existentes foram alocados, em vez de (por exemplo) criar uma versão de largura total de todos os caracteres acentuados em latim.
O Unicode atribui a cada ponto de código uma propriedade "Largura do Leste Asiático". Pode ser:
Propriedades de caracteres Unicode com base na largura :
| Abreviação | Nome | Descrição |
| W | Largo | Caráter naturalmente amplo, por exemplo Hiragana . |
| N / D | Limitar | Caráter naturalmente estreito, por exemplo Alfabeto latino básico ISO . |
| F | Largura completa | Variante ampla com normalização de compatibilidade para caracteres naturalmente restritos, por exemplo, script latino de largura total. |
| H | Meia largura | Variante estreita com normalização de compatibilidade com caracteres naturalmente amplos, por exemplo, kana de meia largura . Inclui U + 20A9 ( ₩ ) como uma exceção. |
| UMA | Ambíguo | Caracteres incluídos nos códigos DBCS do Leste Asiático, mas também nos códigos SBCS europeus, por exemplo Alfabeto grego O comportamento duo-espaçado pode, consequentemente, variar. |
| N | Neutro | Caracteres que não aparecem nos códigos DBCS do Leste Asiático, por exemplo Devanagari . |
Os emuladores de terminal podem usar essa propriedade para decidir se um caractere deve consumir uma ou duas "colunas" ao descobrir guias e posição do cursor.

## No OpenType

O OpenType possui as "tags de recurso" fwid, halt, hwid e vhal a serem usadas para fornecer a forma de largura total ou meia largura de um caractere.