Какой системный компонент отвечает за связывание лигатур Unicode в приложении Java? - PullRequest
Новая
       24

Какой системный компонент отвечает за связывание лигатур Unicode в приложении Java?

6 голосов
/ 17 мая 2011

Это «мета-вопрос», с которым я столкнулся, пытаясь найти лучшую спецификацию для другого из моих вопросов ( Рендеринг ливанаций Деванагари (Unicode) в Java Swing JComponent на Mac OS X ).

Что я пока не совсем понимаю, так это то, какой «компонент» (если не сказать лучшего слова) данной системы отвечает за отображение текста Unicode в Java, а более конкретно ligatures .

Насколько я понимаю, на процесс влияют следующие компоненты:

  1. Системная кодировка символов (например, UTF-8 в Mac OS X 10.6, UTF-16 в Windows 7 (согласно комментарию Акиры к этому сообщению superuser.com )).
  2. Java Charset (по умолчанию это MacRoman в Mac OS X 10.6, cp1252 в Windows 7).
  3. шрифт, используемый для визуализации текста, и информация о кодировке этого шрифта (как предложено Donal Fellows на мой другой вопрос :

    «шрифты содержат информацию о том, какую кодировку они используют».

  4. Очевидно, присутствуют ли отображаемые символы в соответствующих кодовых точках Юникода.

Итак, если строка символов Unicode не отображает правильно (как видно из моего другого вопроса, с.а.), где проблема, скорее всего, будет? То есть, какой «компонент» (какое слово лучше?) Отвечает за «связывание» лигатуры, ее состава?

Заранее большое спасибо и, пожалуйста, дайте мне знать, если вам понадобится дополнительная информация.

Ответы [ 4 ]

4 голосов
/ 17 мая 2011

Этот системный компонент называется средством визуализации шрифтов или растеризатором шрифтов.Он отвечает за преобразование последовательности кодов символов в пиксели на основе глифов, определенных в шрифте.Как уже говорилось в других ответах, различные значения кодировки символов, которые вы можете получить и установить из Java, не имеют значения.Когда JVM дает средству визуализации шрифта последовательность кодов символов, оно сообщает ему, какая кодировка применяется (возможно, UTF16, но это прозрачно для программиста Java.) Средство визуализации шрифтов использует кодировку шрифта, указанную в файле шрифта, для сопоставления соответствующей кодировки.глифы.

Текущие версии Windows и Mac OS X поставляются с отличными средствами визуализации шрифтов.

Первая путаница заключается в том, что JRE поставляется со своим собственным средством визуализации шрифтов, как часть платформы Java2D, и это то, что использует Swing.Должна быть возможность контролировать, использует ли Java собственный рендерер или системный.

РЕДАКТИРОВАТЬ: Как указано McDowell в комментарии к OS XВы можете включить системный рендерер, установив свойство Java apple.awt.graphics.UseQuartz = true.

Вторая путаница заключается в том, что лигатуры на английском языке являются необязательными.Настольное издательское приложение заменит лигатуру "ffl" (один глиф в шрифте), когда оно увидит слово типа "shuffle", но большинство других приложений не беспокоятся.Исходя из того, что вы сказали о Деванагари (и о том, что я только что прочитал в Википедии), я понял, что лигатуры на этом языке не являются обязательными.

По умолчанию средство визуализации шрифтов Java2D не выполняет лигатуры.Однако в JavaDoc для java.awt.font.TextAttribute.LIGATURES говорится, что лигатуры всегда включены для написания систем, которые в них нуждаются.Если это не ваш опыт, возможно, вы обнаружили ошибку в средстве визуализации шрифтов Java2D.Тем временем попробуйте использовать конструктор Font, который берет карту атрибутов шрифта, включая TextAttribute.LIGATURES.

3 голосов
/ 17 мая 2011

Я не эксперт, но, надеюсь, эти советы укажут вам правильное направление ...

Кодирование исходных данных мало влияет на то, как отображаются шрифты.Все символьные данные в Java - это UTF-16, поэтому до тех пор, пока вы правильно транскодируете информацию из источника в символы / строки, целостность данных должна сохраняться.

Однако, обратите внимание:

  • Система AWT может использовать системную кодировку по умолчанию для сопоставления шрифтов
  • Это вряд ли применимо к Devanagari (я не знаю о существующей кодировке, которая его поддерживает)

Шрифты для карт AWT - через файл fontconfig .В моей системе Windows это соответствует шрифту Mangal: 

allfonts.devanagari=Mangal

Нет сомнений в том, что в Mac OS используется другой шрифт.

В некоторых случаях во времяВремя жизни Java 6 - я не знаю, имеет ли это какое-либо отношение к поддержке шрифтов или просто влияет на скорость рендеринга / сглаживания / и т.д.

2 голосов
/ 17 мая 2011

Если вы ссылаетесь строго на визуальный рендеринг, то «кодирование» и связанные с ним темы больше не актуальны: рендеринг переходит с String на визуальный показ. String имеет определенную (и неизменяемую) кодировку, которая является UTF-16. Таким образом, все вопросы типа «прочитал ли я этот двоичный поток с правильной кодировкой» должны быть решены сначала .

Фактическая отрисовка текста должна выполняться графической подсистемой. Это будет AWT / Swing для «нормальной» Java или SWT или любой другой альтернативной системы.

Первый шаг (который не является строго частью «рендеринга») заключается в преобразовании некоторых двоичных данных в String. может включать кодировку по умолчанию для платформы если код явно не указывает какую-либо кодировку. Это шаг, когда кодировки в целом вступают в игру. После этого мы находимся в счастливой, счастливой, чистой стране Юникод.

1 голос
/ 17 мая 2011

Подобно тому, что сказал Иоахим, каков источник данных?Если вы читаете из файла или потока, я бы определенно не доверял кодировке системы по умолчанию.Вы должны явно установить кодировку при чтении данных, например, 

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

или в любой другой кодировке, в которой находится ваш поток.

...