Eu tenho o seguinte problema irritante que venho tentando resolver há semanas, sem sucesso até agora.
* ATENÇÃO questão excessivamente longa - em suma: * o que eu preciso, em essência, é uma maneira de definir exatamente quais fontes serão usadas para exibir um determinado ponto de código unicode. Idealmente, essa decisão seria feita referindo-se a blocos de código unicode, com uma maneira de fornecer fallbacks para pontos de código ausentes e, super-plus, para definir substituições para pontos de códigos únicos.
Eu não encontrei nenhuma solução até agora, e muitas descrições na net parecem estar desatualizadas para o Ubuntu 10.04.
Respostas úteis incluem explicações ou ponteiros sobre como a renderização atual da fonte do ubuntu deve funcionar e o que você pode configurar.
* longa explicação: *
Eu trabalho muito com caracteres unicode dos chamados 'planos astrais', isto é, com pontos de código além dos 16 bits originais do unicode. Agora existem muitas situações --- barra de endereço do navegador, terminal, editores de texto --- onde fontes não podem ser configuradas da maneira que você faria, digamos, em um processador de texto ou um arquivo html / css, onde você pode definir explicitamente o fonte para cada caractere a ser exibido.
Em vez disso, em cada aplicação, precisamente qual imagem aparecerá é um resultado das fontes instaladas no sistema, configurações de todo o aplicativo, possivelmente configuração do sistema de fontes e, ao que parece, sua boa ou má sorte.
Para o propósito de trabalhar com caracteres chineses / japoneses / coreanos (cjk), instalei o Sun-ExtA. Ttf, Sun-ExtB. Ttf e BabelStoneHan. Ttf, juntamente com um grande número de outras fontes, incluindo a oferta padrão do Ubuntu. Além disso, eu tenho (sob vinho) BabelMap e faço toda a minha edição em Komodo Edit 6.1 .
O Komodo está configurado para usar o DejaVu Sans Mono, que eu acho bastante agradável para trabalhar. Por meio da substituição de glifo em todo o sistema (acredito), estou obtendo muitas imagens corretas para pontos de código cjk. No entanto, não tenho certeza se essas imagens realmente se originam das fontes mencionadas acima. Você vê, os blocos cjk contêm bem mais de 70000 pontos de código, alguns com diferenças sutis, alguns com variantes desprezíveis, e alguns sendo cópias definitivas. É um assunto surpreendentemente peludo. Basicamente, você só pode trabalhar com sucesso neste campo se puder ter absoluta certeza de como um determinado ponto de código deve se parecer, e as renderizações mais fiéis que encontrei estão contidas nas fontes mencionadas acima.
Infelizmente, o Ubuntu parece atrapalhar alguns pontos de código. Tome, por exemplo,
u-cjk/5f50 彐
u-cjk-rad1/2f39 ⼹
u-cjk-rad2/2e95 ⺕
Em todos os aplicativos - incluindo o firefox sem o css adequado e komodo - esses três pontos de código parecem exatamente idênticos em minha máquina. No entanto, se você procurar os personagens em uma fonte como link ( 彐 , ⼹ , < href="http://www.longwiki.net/%E2%BA%95"> ⺕ ), que, na minha experiência, tem gifs muito bem selecionados para os personagens em questão, existem diferenças sutis entre esses três pontos de código.
Eu não estou tão feliz que o unicode tenha escolhido definir tantos pontos de código virtualmente idênticos, mas a codificação cjk tem sido conhecida por ser um problema bastante difícil por décadas. Agora eu tenho fontes (aqui é Sun-ExtA. Ttf) instaladas que renderizam esses três pontos de código com os visuais pretendidos, mas meu sentimento é que essas fontes nunca têm a chance de renderizar porque o Ubuntu ou quem quer que seja em algum ponto intervém, declarando que esses pontos de código devem ser combinados com um único. Ou talvez seja alguma fonte que o Ubuntu considere a fonte correta para esses pontos de código que fazem a fusão. Deixe-me mostrar por que é altamente improvável que esse seja o comportamento correto e desejado: na lista acima, você pode ver que os codepoints residem em três blocos unicode diferentes, a saber
CJK UNIFIED IDEOGRAPHS
KANGXI RADICALS
CJK RADICALS SUPPLEMENT
Respectivamente. O consórcio unicode desenvolveu um ponto de vista bastante estranho sobre os chamados "radicais", o que significa que eles os tratam como "símbolos" (para símbolos de seções em dicionários), não como "caracteres" (que você usa para escrever textos), que eu acredito que é bobagem simples. Essa política leva o unicode a incluir um caractere como "cavalo" mais de uma vez, como
u-cjk/99ac 馬
u-cjk-rad1/2fba ⾺
O que para mim é simples e simples um caso de duplicação codepoint injustificada, e é uma política declarada de unicode que esses pontos mostram o mesmo, mas devem ser tratados de forma diferente. Agora, enquanto há casos conhecidos e admitidos de duplicação inadvertida de caractere / glifo (onde alguns comitês se afogaram nas miríades de pontos de código e admitiram um caractere mais de uma vez --- outros conjuntos de códigos sofrem com esse problema, também), isso é altamente improvável este caso.Os dois blocos de radicais têm apenas algumas centenas de pontos de código, e o suplementar foi adicionado somente após a introdução do bloco de radicais 'kangxi' primário (até mesmo a nomeação é maluca), para o único propósito de diferenciar os glifos . Portanto, dado o pressuposto de que é altamente improvável que esse gibão tenha sido introduzido por erro (qualquer aluno de chinês do primeiro ano poderia verificar essas listas curtas por correção - é com isso que você gasta muito tempo ao aprender chinês, resolvendo e lembrando-se de todos aqueles quase-olhar), devemos concluir que uma diferença na aparência pelo menos entre dois dos pontos de código foi totalmente intencionada pelo unicode e, portanto, meu computador está errado ao tentar me convencer de que eles devem ser iguais. / p>
Outro problema que notei é que alguns pontos de código intermitentes são definitivamente exibidos usando outra fonte que a maioria dos outros; Por exemplo, os três pontos de código no primeiro grupo abaixo são renderizados por uma fonte sans-serif (possivelmente da série Ume Gothic ou Wen Quan Yi), enquanto a segunda é renderizada em estilo de música:
u-cjk/534b 卋
u-cjk/5359 卙
u-cjk/535b 卛
u-cjk/534c 卌
u-cjk/534f 协
u-cjk/535a 博
Esse comportamento pode ser observado tanto no gedit quanto no komodo edit, então posso ter certeza que acontece no nível do SO, não dentro do aplicativo.
Observe que os pontos de código em questão são imediatamente vizinhos, então meu palpite é que a fonte de estilo de música padrão tem alguns pontos de código ausentes e o ubuntu acredita que uma fonte sans-serif contém as melhores alternativas para esses pontos --- e erra, já que, afinal de contas, o Sun-ExtA.ttf instalado tem uma cobertura completa de glifos no estilo de música para este bloco de unicode (eu disse, nunca vi um sistema de substituição de glifo que realmente funciona). / p>
Acima, eu mencionei o BabelMap, que é uma ferramenta bastante útil para fazer o trabalho de codificação de caracteres. Um dos aspectos pendentes do BabelMap é que a tabela de glifos pode ser configurada de uma maneira muito fácil de usar fontes específicas para cada bloco unicode. Eu realmente gostaria de ter um controle ainda mais refinado para alguns casos de fronteira, mas isso é tão bom quanto parece nessa idade.