Как я могу настроить шрифты по умолчанию с помощью блоков Unicode или отдельных кодовых точек?
У меня есть следующая неприятная проблема, которую я пытаюсь решить уже несколько недель, но пока безрезультатно.
*ПРЕДУПРЕЖДЕНИЕ. Чрезмерно длинный вопрос - короче: * мне нужен, по сути, общесистемный способ точно определить, какие шрифты будут использоваться для отображения заданной кодовой точки Юникода. В идеале это решение должно быть принято путем обращения к кодовым блокам Юникода, с возможностью дать запасные варианты для отсутствующих кодовых точек и, супер плюс, определить переопределения для отдельных кодовых точек.
Пока я не нашел решения, и многие описания в сети устарели для Ubuntu 10.04.
Полезные ответы включают в себя объяснения или указатели на то, как должен работать текущий рендеринг шрифтов Ubuntu, и что вы можете вообще настроить.
*длинное объяснение: *
Я много работаю с символами Юникода из так называемых "астральных планов", то есть с кодовыми точками за пределами исходных 16 битов Юникода. Сейчас существует много ситуаций - адресная строка браузера, терминал, текстовые редакторы - где шрифты не могут быть настроены так, как вы это делаете, например, в текстовом процессоре или в файле html/css, где вы можете явно определить шрифт для каждого отображаемого символа.
Вместо этого, в каждом таком приложении именно то, что изображение будет отображаться, является результатом установленных в системе шрифтов, настроек всего приложения, возможно конфигурации системы шрифтов, и, похоже, вашей удачи или неудачи.
Для работы с китайскими / японскими / корейскими (cjk) символами я установил Sun-ExtA. Ttf, Sun-ExtB. Ttf и BabelStoneHan. Ttf, наряду с целым рядом других шрифтов, включая стандартное предложение Ubuntu. Кроме того, у меня есть (под Wine) BabelMap и я все редактирую в Komodo Edit 6.1.
Komodo настроен на использование DejaVu Sans Mono, с которым я нахожу достаточно приятным для работы. Посредством общесистемной замены глифов (я полагаю), я получаю много правильных изображений для кодов cjk. Однако я не совсем уверен, что эти изображения действительно происходят от шрифтов, упомянутых выше. Видите ли, блоки cjk содержат более 70000 кодовых точек, некоторые с небольшими различиями, некоторые с незначительными вариантами, а некоторые с прямыми копиями. Это удивительно волосатый предмет. По сути, вы можете успешно работать в этой области только в том случае, если вы абсолютно уверены в том, как должна выглядеть заданная кодовая точка, и наиболее верные из представленных мной изображений содержатся в упомянутых выше шрифтах.
К сожалению, Ubuntu, кажется, испортил довольно много кодов. Взять, к примеру,
u-cjk/5f50 彐
u-cjk-rad1/2f39 ⼹
u-cjk-rad2/2e95 ⺕
Во всех приложениях - включая firefox без надлежащего css и komodo - эти три кодовые точки выглядят абсолютно одинаково на моей машине. Однако, если вы посмотрите на символы в источнике, таком как http://www.longwiki.net/%E5%BD%90 ( 彐, ⼹, ⺕), который, по моему опыту, имеет очень хорошо выбранные GIF-файлы для символов речь идет о тонких различиях между этими тремя кодовыми точками.
Я не очень рад, что Unicode решил определить так много практически идентичных кодовых точек, но тогда было известно, что кодирование cjk является довольно сложной проблемой на протяжении десятилетий. Теперь у меня есть установленные шрифты (здесь это Sun-ExtA. Ttf), которые визуализируют эти три кодовые точки с намеченным внешним видом, но я чувствую, что эти шрифты никогда не получат возможность рендеринга, потому что Ubuntu или кто-то в какой-то момент вмешивается, объявляя, что все эти кодовые точки должны быть сопоставлены с одной. Или, может быть, это какой-то шрифт, который Ubuntu считает правильным шрифтом для этих кодовых точек, который делает путаницу. Позвольте мне показать вам, почему крайне маловероятно, что это правильное и желаемое поведение: из приведенного выше списка вы можете видеть, что кодовые точки находятся в трех разных юникодных блоках, а именно
CJK UNIFIED IDEOGRAPHS
KANGXI RADICALS
CJK RADICALS SUPPLEMENT
Соответственно. Консорциум Unicode разработал довольно странную точку зрения на так называемые "радикалы", что означает, что они рассматривают их как "символы" (для символов разделов в словарях), а не как "символы" (которые вы используете для написания текстов), Я считаю, что это просто чепуха. Эта политика заставляет юникод включать символ типа "лошадь" более одного раза, так как
u-cjk/99ac 馬
u-cjk-rad1/2fba ⾺
Для меня это просто и ясно случай неоправданного дублирования кодов, и согласно заявленной политике юникода эти точки показывают одно и то же, но должны рассматриваться по-разному. Теперь, хотя известны и допущены случаи неумышленного дублирования символов / глифов (когда некоторый комитет утонул во множестве кодовых точек и допустил символ более одного раза - другие кодовые наборы тоже страдают от этой проблемы), это крайне маловероятно в этот случай. Два блока радикалов имеют длину всего несколько сотен кодовых точек, а дополнительный был добавлен только после введения первичного блока радикалов "канси" (даже наименование странное) с единственной целью дифференцировать глифы. Поэтому, учитывая предположение, что маловероятно, что такой дублет был введен по ошибке (любой первокурсник китайского языка мог проверить правильность этих коротких списков - именно с этим вы тратите много времени, изучая китайский язык, разбираясь и помня обо всех этих почти похожих друг на друга), мы должны сделать вывод, что разница во внешнем виде, по крайней мере, между двумя из кодовых точек была полностью предназначена для Unicode, и, следовательно, мой компьютер ошибается, пытаясь убедить меня, что они должны выглядеть одинаково.
Еще один глюк, который я заметил, заключается в том, что некоторые прерывистые кодовые точки определенно отображаются с использованием другого шрифта, чем большинство других; Например, три кодовые точки в первой группе, приведенной ниже, отображаются с помощью шрифта без засечек (возможно, из серии Ume Gothic или Wen Quan Yi), а вторая отображается в стиле песни:
u-cjk/534b 卋
u-cjk/5359 卙
u-cjk/535b 卛
u-cjk/534c 卌
u-cjk/534f 协
u-cjk/535a 博
Такое поведение можно наблюдать как в редактировании gedit, так и в komodo, поэтому я могу быть уверен, что это происходит на уровне операционной системы, а не в приложении.
Заметьте, что рассматриваемые кодовые точки являются непосредственно соседними, поэтому я предполагаю, что шрифт в стиле песни по умолчанию имеет несколько пропущенных кодовых точек, и Ubuntu считает, что шрифт без засечек содержит лучшие альтернативы для этих точек - и получает его неправильно, так как, в конце концов, установленный Sun-ExtA.ttf имеет полное покрытие глифов стиля песни для этого блока юникода (тем не менее, я никогда не видел систему замены глифов, которая действительно работает).
Выше я упомянул BabelMap, довольно полезный инструмент для кодирования символов. Одним из выдающихся аспектов BabelMap является то, что таблица глифов может быть настроена очень управляемым способом, чтобы использовать определенные шрифты для каждого блока Юникода. Я на самом деле хотел бы иметь еще более детальный контроль над несколькими пограничными случаями, но это так же хорошо, как кажется в этом возрасте.