¿Qué componente del sistema es responsable de vincular ligaduras Unicode en una aplicación Java?

Question

Esta es una "meta-pregunta" que encontré al tratar de encontrar una especificación mejor para otra de mis preguntas (Rendering Devanagari ligatures (Unicode) in Java Swing JComponent on Mac OS X).

Lo que aún no entiendo es qué "componente" (a falta de una palabra mejor) de un sistema dado es responsable de mostrar texto Unicode en Java, y más específicamente ligatures.

Por lo que yo entiendo, los siguientes componentes tienen una influencia en el proceso:

1. La codificación de caracteres del sistema (que, por ejemplo, es UTF-8 en Mac OS X 10.6, UTF-16 en Windows 7 (de acuerdo con el comentario de Akira en este superuser.com post)).
2. Java Charset (que de forma predeterminada es MacRoman en Mac OS X 10.6, cp1252 en Windows 7).
3. La fuente que se utiliza para representar el texto, y la información de codificación de ese tipo de letra (como se sugiere por Donal Fellows en my other question:

   "fuentes incluyen información sobre qué codificación que están usando"

.
4. Obviamente si los caracteres que hacen que están presentes en los respectivos puntos de código Unicode.

lo tanto, si una cadena de caracteres Unicode no muestra correctamente (como se ve en mi otra pregunta, s.a.), ¿dónde estaría el problema probablemente? Es decir, ¿qué "componente" (¿qué sería una palabra mejor?) Es responsable de "enlazar" la ligadura, su composición?

Muchas gracias de antemano y háganos saber si necesita más información.

Answer 1

Ese componente del sistema se llama un visualizador de fuentes o de trama fuente. Es responsable de convertir una secuencia de códigos de caracteres en píxeles en función de los glifos definidos en una fuente. Como han indicado otras respuestas, los diversos valores de codificación de caracteres que puede obtener y establecer desde Java son irrelevantes. Cuando la JVM da al procesador de fuentes una secuencia de códigos de caracteres, le dice qué codificación aplica (probablemente UTF16, pero esto es transparente para el programador Java). El renderizador de fuentes usa la codificación de fuentes especificada en el archivo de fuentes para hacer coincidir el correspondiente glifos.

Las versiones actuales de Windows y Mac OS X vienen con excelentes procesadores de fuentes.

El primer punto de confusión es que el JRE viene con su propio procesador de fuentes, como parte de la plataforma Java2D, y esto es lo que usa Swing. Debería haber una opción para controlar si Java usa su propio procesador o el del sistema.

EDIT:McDowell Como se señala en un comentario, en OS X se puede activar el procesador de sistema estableciendo la propiedad de Java apple.awt.graphics.UseQuartz = true.

El segundo punto de confusión es que las ligaduras son opcionales en inglés. Una aplicación de autoedición sustituirá a una ligadura "ffl" (un solo glifo en la fuente) cuando vea una palabra como "shuffle", pero la mayoría de las otras aplicaciones no molestan.En base a lo que has dicho sobre Devanagari (y lo que acabo de leer en Wikipedia), entiendo que las ligaduras no son opcionales en ese idioma.

De forma predeterminada, el renderizador de fuentes Java2D no hace ligaduras. Sin embargo, JavaDoc para java.awt.font.TextAttribute.LIGATURES dice que las ligaduras siempre están habilitadas para escribir sistemas que las requieren. Si esa no es su experiencia, es posible que haya encontrado un error en el renderizador de fuentes Java2D. Mientras tanto, intente utilizar el constructor de fuentes que toma un mapa de atributos de fuente, incluido TextAttribute.LIGATURES.

Answer 2

Si refiere estrictamente a la representación visual, entonces la "codificación" y los temas relacionados ya no son relevantes: la representación va de String a la visualización. El String tiene una codificación definida (e inmutable), que es UTF-16. Así que todas las preguntas como "¿He leído esta secuencia binaria con la codificación correcta" tienen que resolverse primero.

La representación real del texto debe ser realizada por el subsistema de gráficos. Eso sería AWT/Swing para Java o SWT "normal" o cualquier otro sistema alternativo.

El primer paso (que no es estrictamente parte de "representación") es convertir algunos datos binarios a un . Este puede involucrar codificación predeterminada de plataforma iff el código no especifica alguna codificación explícitamente. Este es el paso donde las codificaciones en general entran en juego. Después de eso, estamos en happy-happy-pure-Unicode-land.

Answer 3

Similar a lo que dijo Joachim, ¿cuál es la fuente de los datos? Si está leyendo desde un archivo o secuencia, definitivamente no confíe en la codificación predeterminada del sistema. Debe establecer explícitamente la codificación al leer los datos, p.

BufferedReader br = new BufferedReader(new InputStreamReader(file, "UTF-8")); 

O lo que sea que codifica el torrente está en

Ver:.

http://download.oracle.com/javase/1.4.2/docs/api/java/io/InputStreamReader.html#InputStreamReader(java.io.InputStream,%20java.lang.String)

Answer 4

No soy un experto, pero espero que estos consejos te orientará en la dirección correcta. ..

La codificación de los datos fuente tiene poca relación con la forma en que se procesan las fuentes. Todos los datos de caracteres en Java son UTF-16, por lo que siempre que transcodifique información de origen a caracteres/cadenas, se debe preservar la integridad de los datos.

Sin embargo, nota:

• El sistema AWT puede utilizar el sistema de codificación por defecto para hacer la asignación de fuentes
• Esto es poco probable que solicitar devanagari (no soy consciente de una codificación legado que lo soporta)

AWT maps fonts es a través del fontconfig file. En mi sistema Windows, esto se asigna a la fuente Mangal:

allfonts.devanagari=Mangal 

Sin duda, se está utilizando una fuente diferente en Mac OS.

La traducción de texto nativo se introdujo en algún momento durante la vida útil de Java 6 - No sé si eso tiene alguna relación con el soporte de fuentes o solo afecta la velocidad de renderizado/antialiasing/etc.

• Java 6 Supported Fonts documentación