Как я могу настроить шрифты по умолчанию с помощью блоков 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, и, следовательно, мой компьютер ошибается, пытаясь убедить меня, что они должны выглядеть одинаково. [ 1125]

Другой сбой, который я заметил, заключается в том, что некоторые прерывистые кодовые точки определенно отображаются с использованием другого шрифта, чем большинство других; Например, три кодовые точки в первой группе, приведенной ниже, визуализируются шрифтом без засечек (возможно, из серии Ume Gothic или Wen Quan Yi), а вторая - в стиле песни:

u-cjk/534b    卋
u-cjk/5359    卙
u-cjk/535b    卛

u-cjk/534c    卌
u-cjk/534f    协
u-cjk/535a    博

[1127 ] Такое поведение можно наблюдать как в редактировании gedit, так и в komodo, поэтому я могу быть уверен, что это происходит x на уровне операционной системы, а не внутри приложения.

Заметьте, что рассматриваемые кодовые точки являются непосредственно соседними, поэтому я предполагаю, что шрифт в стиле песни по умолчанию имеет несколько пропущенных кодовых точек, и Ubuntu считает, что шрифт без засечек содержит лучшие альтернативы для этих точек. --- и ошибается, так как, в конце концов, установленный Sun-ExtA.ttf имеет полное покрытие глифов стиля песни для этого блока юникода (тем не менее, я никогда не видел систему подстановки глифов, которая действительно работает ). [+1128]

Выше я упомянул BabelMap, довольно полезный инструмент для кодирования символов. Одним из выдающихся аспектов BabelMap является то, что таблица глифов может быть настроена очень управляемым способом, чтобы использовать определенные шрифты для каждого блока Юникода. Я на самом деле хотел бы иметь еще более детальный контроль над несколькими пограничными случаями, но это так же хорошо, как кажется в этом возрасте. [Тысяча сто двадцать девять]