Декомпозиция китайского иероглифа: структура баз данных и способы генерации знаков

В этой статье хотелось бы подытожить многое, что касается структурной декомпозиции китайского иероглифа.

Небольшой экскурс. Идея, задуманная автором этих строк в далёком 2001 г., наконец-то была реализована относительно недавно – в мае 2013. Всё началось, как говорится, «на собственных началах» с простого кодирования по методу Cang Jie в пределах основного иероглифического диапазона CJK Unifed Ideographs (4E00–9FA5). Помимо уже занесённых данных по кодированию методом Cang Jie, это было заполнение информации для остатков тех иероглифов, которые вообще не попали ни в Big5, ни в GB2312 наборы, и поэтому не были затронуты существовавшими в те годы вариантами всевозможных Cang Jie IME, распространявшихся свободно. Это было что-то около 5 тыс. не закодированных знаков из 21 тыс. Другими словами, тогда в свободном доступе попросту не было ещё полностью заполненных таблиц с кодирующей строкой Cang Jie для всех 20902 знаков. И вот, после завершения сего эпичного труда (разумеется, с многочисленными ошибками кодирования по Cang Jie), я сразу же начал понимать, что на основании выборки, (например – фильтрации в таблице MS Access) для части из начальных, либо части из конечных символов строки кодирования Cang Jie, для подавляющего большинства составных знаков становится довольно легко выделять неключевые (фонетические) части, что даёт выход на сравнительно быстрое заполнение таблицы структурной декомпозиции по принципу жёсткого бинарного разбиения ключ (определитель) – фонетик.

Вот пример фильтрации по трём символам правой части строки кодирования CangJie:

葷=廿月十十

褌=中月十十

諢=卜口月十十

賱=月金月十十

輝=火山月十十

運=卜月十十

鍕=金月十十

韗=木手月十十

餫=人戈月十十

鯶=弓火月十十

После такой фильтрации и выборки можно быстро занести в столбец для неключевой части иероглиф 軍, а ключевая часть в большинстве случаев заранее известна, хотя тут нужен контроль для знаков с трудно определимым ключом. Для случаев, когда ключ стоит в конце знака, такая выборка работает хуже. Это потому что по правилам метода первый элемент (который стоит в начале) двусоставного иероглифа всегда кодируется только графемами CangJie в числе не более двух; выборка левой части знака всего по двум символам кодирования будет давать уже существенно неоднозначные результаты. Ниже по тексту будет показано, что подавляющая доля китайских иероглифов содержит ключевую часть знака в начале композиции.

Вообще, тот «бессмысленный» труд всё же не прошел даром. В голове остались хотя бы результаты углубленного изучения правил метода Cang Jie – это уже было пользой. Вскоре собственноручно заполненная таблица со всеми 20902 знаками стала, разумеется, не нужна, поскольку буквально через некоторое время появились в свободном доступе более правильные таблицы с кодированием строкой Cang Jie, но главная идея об ускоренном способе заполнения таблиц структурной декомпозиции была накрепко ухвачена…

Прошло некоторое время. За десять лет очень многое изменилось как в самом стандарте Unicode, так и во всём, что с ним связано; появилось много CJK-расширений. Стали свободно доступны шрифты, поддерживающие и ExtA, и ExtB. В свободном доступе появились таблицы с различными версиями Cang Jie, полностью покрывающими диапазон даже для CJK ExtB (43 тыс. знаков). И тут стало понятно – можно начинать действовать…

Для работы с декомпозицией китайского иероглифа, прежде всего, необходимо было сделать выбор – какую использовать версию системы CangJie: 3 или 5? Знакомство с версией CJ v.5 не внушило оптимизма, поэтому я остановил свой выбор на старой доброй версии 3, которая была более логичной (…личное мнение). Версию кодирования CJ в единственной полностью заполненной таблице для ExtB, которую удалось найти в Сети, я так и не смог определить. Далее, в 2012 г. я реализовал на VBA-макросах в MS Word ввод по системе CangJie: отдельно для всего диапазона CJK Unifed+CJK ExtA и отдельно для всего диапазона CJK ExtB. Разумеется, что для изучения и быстрого заполнения структурной информации у расширенных знаков, фонетические методы ввода становятся менее востребованными, поскольку вообще-то из ExtB очень немногие иероглифы имеют чтения на Pinyin. После всех усовершенствований, с довольно неплохими знаниями системы Cang Jie, автору этих строк стали подвластны для ввода около 70 тыс. знаков. Вообще, за все эти годы я так и не смог понять: то ли собираемая мною база всевозможных фонетических и структурных таблиц «тянула» за собой дальнейшую разработку простеньких IME на VBA-макросах, то ли – наоборот, макросы помогли быстро заполнить базу… трудно ответить. Тогда в 2012 г. я не особо задавался подобным вопросом, ибо наконец-то пришла пора начинать скоростное занесение информации по структурной декомпозиции для огромного числа ханьцзы…

Предлагаемый мною основной принцип разбиения в рамках принятой концепции декомпозиции – это исторически обусловленная двухкомпонентность (бинарность) операций построения китайского иероглифического знака. Т.е. новый знак должен формироваться всегда из двух элементов. Это чуть-чуть противоречит стандартной концепции CJK-декомпозиции от Unicode, где из двенадцати бинарных были предусмотрены также две тринарные операции: LCR (U+2FF2) и UCD (U+2FF3). Скорее всего, их появление обусловлено банальной нехваткой графических компонентов в стандарте Unicode. Однако эти две операции также можно альтернативно использовать и в рамках бинарного подхода в описании языка декомпозиции китайского иероглифического знака; об этом я писал в одной из предыдущих статей на «Ма».

Второй базовый момент – это чёткое разделение двух составляющих иероглифа: на ключевую часть и на неключевую часть. Конечно, такой подход продиктован самим способом построения китайских иероглифов, 90% которых эволюционно сформировано по фоноидеографическому принципу, а не по идеографическому (как думают многие начинающие…). Это дополнительно позволит, например, по неключевой части сопоставлять фонетическую семантику группы знаков с различными иероглифическими ключами, но с одинаковой неключевой (фонетической) частью. Таким образом, первый компонент в таблице базы данных должен быть всегда закреплен за ключевой частью, а второй – за неключевой (фонетик). Для знаков с явным и легко определяемым ключом подобный подход даже позволит выполнять анализ фонетики (например – реконструкции утраченных чтений). Однако в случае знаков с трудно определимым ключом совсем не гарантируется, что неключевая часть будет строго соответствовать фонетическому аспекту знака. Хотя опыт личного анализа большого массива знаков из диапазонов CJK Unifed Ideographs + ExtA подтверждает эмпирический принцип, согласно которому фонетик, дающий чтение иероглифу, практически никогда не бывает его ключевым знаком. Но это всё равно несущественно, поскольку доля иероглифических знаков с графически трудно определимым или неявным ключом в наборе CJK Unifed Ideographs (20902 знака) составляет около 5%. Также необходимо отметить, что элемент ключевой части знака необязательно должен принадлежать к набору из 214 радикалов словаря Кан Си; в качестве ключа составные части иероглифа могут быть представлены дополнительными вариантами ключевых знаков, иногда даже не входящими в стандартный список из 214, а также более сложными иероглифами, запрятавшими в глубине своей композиции классифицирующий Kang Xi-ключик.

Примеры:

水: 洲=氵[LR]州 (zhōu), использован обычный ключ «вода».

雨: 霴=雲[LR]隶 (dài), как ключ используется не радикал 雨, а 雲 (облако).

Третий момент (пожалуй, самый главный в этой статье) – учёт порядка положения ключа в двухкомпонентной композиции. Для того, чтобы окончательно «примирить» два подхода: и логический – жёстко фиксированное бинарное описание «ключ-фонетик», и графический – сохранение правильной графической последовательности компонент, нужна была ещё одна дополнительная частичка информации. Это может быть даже булёв тип данных, поскольку в последовательном порядке композиции с учетом строго заданной бинарности любой операции, вообще могут существовать только два варианта: ключевая часть в начале, либо ключевая часть в конце построения знака. Варианты «ключ в середине» с помощью предлагаемой мною удачной интерпретации стандартизованных в Unicode команд декомпозиции: LEFT_CENTER_RIGHT и UP_CENTER_DOWN, всё равно могут быть сведены к бинарной форме представления операндов. В общем, необходимо указание дополнительной информации о положении ключа графической композиции, например ORDER=1 – ключ или ключевая часть находится в первом элементе, ORDER=2 – ключ или ключевая часть – во втором элементе. Знаки, у которых в начале идёт ключевой элемент, для набора CJK Unifed Ideographs составляют подавляющее большинство – 79 %. Особым случаем являются продублированные двух-, трёх- и иногда даже четырёхкратно иероглифы. Для некоторых из них в явном виде выделить ключ становится затруднительно (учетверённые по углам квадрата знаки), поскольку в подобных ситуациях все элементы композиции одинаково повторены и входят в знак равноправно. Доля знаков с кратно повторенными элементами для набора CJK Unifed Ideographs составляет не более 0,6 %. Поэтому в базах данных стóит дополнительно выделять особую категорию подобных знаков, состоящих из повторяющихся элементов.

Расширенный принцип записи декомпозиции:

廴: 廵=廴,[SLD] ,巛, ключ в начале

力: 劷=力, [LR] ,羊, ключ в конце

殳: 毉=殹, [UD] ,巫, ключ в начале

門: 閷=閃, [LR] ,杀, ключ в конце

虫: 蟲=虫×3, повторение знака.

Известно, что проблемой для декомпозиционного описания всех стандартизованных знаков является отсутствие графических компонентов для малой части представленных в Unicode иероглифов, задействованных как в основном наборе CJK Unifed Ideographs, так и в расширениях CJK ExtA и CJK ExtB. Поэтому необходимо предусмотреть возможность указания дополнительного шага декомпозиции для отсутствующих составных частей как по первой и по второй компонентам знака.

Примеры:

女: 嬎=女[LR]N, дополнительно (免[SLD]生), ключ в начале;

心:愛=N[UD]N, дополнительно (心[UD]夂), (爫[UD]冖), ключ в начале;

水: 漢=氵[LR]N, дополнительно – нет компонент (о ужас!), ключ в начале.

Да-да, для правой неключевой части самого-самого, что ни на есть, китайского иероглифа 漢 [hàn], в стандарте Unicode отсутствуют как сама графема, так и два отдельных компонента, позволяющих в рамках дополнительного шага двусоставной композиции описать структуру этого знака. Неключевую часть иероглифа 漢 удаётся описать только лишь тремя компонентами сразу (U+2FF2 廿 中 夫), но в рамках принимаемого бинарного подхода это становится невозможно.

Без дополнительного указания декомпозиции отсутствующих составных частей, доля знаков с неполным описанием компонентов (по причине графической неполноты стандарта Unicode) составит около 2%. Эта величина уже даётся с учётом обязательного привлечения широкого спектра знаков из наборов ExtA и ExtB для описания составных компонентов. Дополнительный учёт расширенных наборов ExtС и ExtD уже практически не изменит подобного соотношения, поскольку в этих небольших по численности наборах отсутствуют редкие базовые знаки (зачастую это бывают именно части составных иероглифов, не вошедшие в древние словари), а доминируют, в основном, упрощенные варианты обычных двусоставных иероглифов, не включенных в более ранние наборы знаков CJK Unicode. Я также не поленился и «пробил» информацию по запланированным расширениям E и F – практически то же самое. Хотя весьма приятно было увидеть там многие составные части от проекта вторичных упрощений, разрабатывавшегося в 1977 г. (в расширении F).

Ссылки на проекты новых Unicode CJK-расширений:

Extension E: http://www.unicode.org/L2/L2013/13151-n4459.pdf

Extension F: http://www.unicode.org/L2/L2012/12333-cjk-f.pdf

На сегодняшний момент в открытом доступе известны три примера баз данных, в которых с разной степенью подробности, для различного числа знаков и в различном формате представлена информация по декомпозиционной структуре китайского иероглифического знака. Вот краткий обзор:

Вариант 1 – Jade Gazebo IME (…почила, R.I.P.)

База данных для нового и местами весьма оригинального метода ввода Jade Gazebo IME. Ядро системы ввода представляет собой обычный текстовый файл (ime.dat) с открытой текстовой информацией по иероглифической декомпозиции. Недостатки: несмотря на присутствие исчерпывающих данных о двух компонентах с соблюдением графического порядка начертания знака, наблюдается отсутствие информации о типе декомпозиции (LEFT_RIGHT, UP_DOWN,…), хотя для обычного IME структурного типа ввода это и не особо нужно. И второй недостаток – описание в базе данных не охватывает даже весь основной набор знаков из CJK Unifed Ideographs, а привязано к множеству знаков, в основном, из национальных стандартов базовых символьных наборов государств Восточной Азии (BIG5, GB2312…). Неполнота графического описания компонент знаков и придуманные разработчиком собственные немыслимые радикалы вынудили его реализовать в программе еще и шрифтовые суррогаты, которые в используемом специальном ttf-шрифте почему-то размещены не как положено в Unicode PUA, а в областях: Hiragana, Bopomofo и также в других близко расположенных к этому участку диапазонах стандарта Unicode. Личное мнение по этой базе данных – сугубо отрицательное (как впрочем и по этому IME-методу ввода).

Вариант 2 – Wenlin 4

Очень хорошее и удобное программное приложение для работы с огромным числом китайских иероглифов. В плане справочной работы с иероглифическими знаками достоинства у этого программного продукта определённо есть. Прежде всего, необходимо отметить поистине огромное число иероглифов, заметно перекрывающее имеющийся на сегодня суммарный массив китайских иероглифических знаков во всех расширениях Unicode, причём с указанием состава декомпозиции практически у любого знака. Информация по базе данных иероглифической декомпозиции в этом приложении защищена и скрыта от анализа, что логично, поскольку это коммерческий проект. Сведения по структуре китайского знака доступны только из самого приложения. В плане описания декомпозиции знаков, у программы Wenlin 4 всё же есть недостатки. Во-первых, это очень примитивное описание типов декомпозиции собственной «домашней» разработки (CDL), и оно совсем не такое, как принятое в стандарте Unicode – CJK Ideographic Description. С одной стороны, там есть удобные типы (например, утроение знака), которых нет в Unicode, но с другой – абсолютно отсутствуют многие такие важные варианты декомпозиции, как: SURROUNDING LEFT TOP, SURROUNDING LEFT DOWN и другие подобные им типы из стандарта Unicode. Во-вторых, хоть Wenlin и использует широко даже CJK Unicode ExtB, но иногда невозможно понять логику разработчиков, когда уже имеющийся компонент в CJK Unicode ExtB они заменяют полностью аналогичным знаком, но только из Unicode PUA своих собственных шрифтов. Но несмотря на мелкие недостатки, мнение о программе осталось весьма положительное. По крайней мере, можно было всегда «консультироваться» с этим справочником по поводу альтернатив декомпозиции для сложно или неоднозначно разбиваемых знаков. А ещё несколько пугает подход разработчиков Wenlin по декомпозиции не вполне графически однозначных компонентов. Они иногда путают генетические связи базовых составных компонент между собой: 夂<=>攵, 夭<=>天 и постоянно не желают различать – 肉<=>月(луна). Также не всегда понятны альтернативные варианты их разбиения при весьма неоднозначной декомпозиции:

水:渕=>浂[LR]刂вместо очевидного 氵[LR] (关[LR]刂)

木: 樃=>桹[LR]月 вместо очевидного 樃=>木[LR]朗,

но это, видимо, обусловлено просто графической неполнотой компонентов знаков в стандарте Unicode. Однако графическая неполнота не дает повода для нарушения логической принадлежности знака к ключу, каким бы заманчивым не был альтернативный вариант декомпозиции с иными составляющими компонентами и с отнесением уже к другому ключевому знаку. Кстати, разработчики из Wenlin уже написали «под себя» proposals к дополнению знаков из диапазона CJK Ideographic Description. Кому интересно, вот ссылка: http://www.unicode.org/L2/L2002/02221-cdp-idc.pdf

Вариант 3 – Project CJKDecomp by Gavin Grover

Открытый проект. Первоначально развивался под названием CJKLib. Включает в себя не только описание декомпозиции, но и ведение баз данных по фонетической и другой информации, касающейся свойств китайских иероглифов. Со временем часть проекта, а скорее, часть его авторов, начали специализироваться только на иероглифической декомпозиции, и они вышли на совершенно немыслимый уровень.

Тут приходится констатировать – это самая мощная на сегодняшний день база по декомпозиции, свободно доступная в Сети. Полностью заполнена структура не только для основного набора CJK Unicode, но и для расширений А, В, С, D. База имеет целый список своих индивидуальных особенностей. Они заслуживают подробного описания. Первое – это очень мощный, не побоюсь этого слова, язык описания вариантов декомпозиции, коих я насчитал около 60. Сравните с 12-ю стандартизованными вариантами из Unicode и с ещё меньшим числом вариантов из «языка» CDL от Wenlin. Здесь, в CJKDecomp есть и зеркальные дублирующие знак повороты, и приклеивание сопрягаемых черт, а также совсем уж диковинные варианты, которые словами даже трудно описать. Вторая особенность – полная замена компонентов, графически отсутствующих в стандарте Unicode, всевозможными подставными суррогатами, которых насчитывается аж 10 тыс. Но есть и минусы. Это постоянное использование в основных знаках и в суррогатах довольно новых символов из диапазона CJK Ideographic Strokes (базовые черты иероглифов – 36 черт), которые пока ещё далеко не всеми шрифтами поддерживаются. Кстати, многие иероглифические черты также давно уже представлены знаками из начала основного диапазона CJK Unicode и первых сотен знаков из ExtB. Да и само массовое использование 36 базовых черт наводит на грустные мысли о «разложении на атомы», а это уже совсем другое направление изучения структуры иероглифа, более ориентированное на графику и OCR, чем на композицию знака. Опять серьёзный минус этого проекта – нет информации о положении ключа, соблюдён только графический порядок компонентов при декомпозиции.

Что же мы хотели бы получить, в конечном итоге, от готовой и собранной базы по декомпозиции и структуре китайского иероглифа. Тут нужна жестко заданная директива. Всего просматриваются два принципиально различающихся направления:

1)  Описание логической структуры иероглифического знака.

Это направление полезно, прежде всего, для изучения иероглифического знака, в целях простоты его запоминания. Новичок в изучении иероглифов часто старается запомнить сложный знак целиком без попыток его сегментации, и, начиная с определенного уровня сложности, это приводит к провалам в памяти, забываниям с последующими психологическими травмами и т. д. Заучивание классической таблицы из 214 радикалов и их вариантов параллельно с пониманием всего лишь 12 основных типов декомпозиции – вот самый простой способ мнемоники запоминания знаков. Другое применение логического подхода – разработка таблиц новых систем IME структурного типа для ввода китайских иероглифов. И как было уже упомянуто выше по тексту, ещё одно полезное свойство применения такого подхода – фонетический анализ по неключевым компонентам.

2)  Описание графической структуры иероглифического знака.

Однако чисто логический подход всё же неприменим для графической генерации новых иероглифов, отсутствующих в мировых стандартах. Нет, запись логической структуры знака, с учетом положения ключа, конечно, обеспечит сравнительно легкую генерацию для около 90% знаков, но не более того.

Вот наглядный пример, и выглядит такие попытки генерации знаков в различных статьях на уровне — пока «неочень»:

HanGlyph. A Chinese Character Description Language.

Candy L. K. Yiu, Wai Wong, Chinese character synthesis using METAPOST

Wai Wong, Candy L.K. Yiu, Kelvin C.F. Ng, Typesetting Rare Chinese Characters in LATEX

Xue Yongzeng and Gu Yingying, A Survey on Digital Description of Chinese Character Glyph

LianWen JIN, XiaoNa ZU, Synthesis of Chinese Character Using Affine Transformation

Daniel G. Peebles, SCML: AStructural Representation for Chinese Characters

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

На этапах заполнения базы структурной декомпозиции приходилось серьёзно «воевать» с проблемой графической неполноты составных компонентов в Unicode. Уже примерно на 80 % заполнения от 21 тыс. иероглифов основного набора, стало ясно, что без дополнительных нововведений, частично устраняющих неполноту графического описания не обойтись. Поэтому в рамках бинарного подхода в таблице декомпозиции были сформированы еще два поля: поле декомпозиции ключевого компонента (в случае его отсутствия в стандарте Unicode) и аналогично поле для неключевого компонента (фонетик). Это принесло ощутимые плоды. Вот статистика неполноты описания по заполненным 20902 знакам основного CJK-набора Unicode:

3,26 % – в Unicode (+ExtA,+ExtB) отсутствует компонент неключевой части знака

0,51 % – в Unicode (+ExtA,+ExtB) отсутствует компонент ключевой части знака

0, 015 % – в Unicode (+ExtA,+ExtB) отсутствуют оба компонента знака

0,052 % – в Unicode (+ExtA,+ExtB) отсутствуют оба компонента знака и их невозможно описать даже в рамках дополнительного шага вспомогательной декомпозиции.

Общая черта организации всех рассмотренных выше вариантов баз – отсутствие информации о положении ключа в знаке. Моё небольшое новшество касательно порядка ключа (ORDER=1,2), позволит использовать базу структурной декомпозиции для решения задач принципиально разных и описанных выше подходов: прежде всего логического, фонетического и частично графического направлений.

Таблица предложенной автором CJK-декомпозиции (основной диапазон CJK Unifed Ideographs).

Какие же способы генерации и ввода нестандартных иероглифов технически могут быть реализованы:

Ввод иероглифов по принципу композиции.

Это самый простой случай, где работает подобные идеи. На входе – знак композиции и два компонента из набора стандартных знаков, на выходе – новый, но тоже стандартный знак. Таблица композиции даст окончательный ответ: можно или нельзя составить такой знак и ввести его в текст. Это существенно узкий подход, ограниченный только существующими в стандарте знаками. Ничего принципиально нового тут получиться не может. Только сам процесс ввода делается более естественным и наглядным. Именно этот простой вариант я сумел реализовать в форме макросов для VBA. (читайте сразу п. 1.3 Модуль CJK-декомпозиции)

CJK VBA generation

Open Type реализация.

Вообще, красивая идея динамической композиционной генерации не стандартизованных иероглифов, начавшись в конце 90-х годов, так и осталась в положении: «а воз и ныне там», (по крайней мере, применительно к платформе MS Windows). Тогда серьёзные надежды возлагались на шрифты Open Type. Действительно, в технологии Open Type возможна обычная подстановка одного знака вместо нескольких введённых знаков. Это и может быть использовано для ввода не стандартизованных иероглифов. Но при этом нестандартные иероглифы всё равно должны быть заранее прорисованы в шрифте и с помощью таблицы подстановки они должны быть связаны со стандартными знаками, через которые осуществляется ввод. Т. е. это будет выглядеть как шрифт с очень большим числом символов, многие из которых попросту не имеют собственного номера для позиции в таблице стандарта Unicode. Но такой подход всё равно ограничен. Т. е. можно создать шрифт, в который включены, например, вместе с ExtA и ExtB все 72 тыс. иероглифов и заранее проработать таблицу подстановки ещё для 50 тыс. нестандартных символов, также прорисовав их и вставив в такой шрифт. Но это всё равно будет набор иероглифов с ограниченным числом знаков, т. е. – 122 тыс. иероглифов. Яркий пример такой реализации – свободно распространяемый OTF-шрифт с возможностью ввода знаменитого мегаиероглифа [biang]. Для этого в шрифте имеется один единственный не индексированный в Unicode иероглиф (сам [biang), также есть c два десятка знаков: 5 для IDS декомпозиции плюс 9 стандартных иероглифов-компонентов. Печально, что идея применения Open Type для генерации иероглифов бесславно закончилась всего лишь таким примитивным примером.

Ссылка на шрифт Biang.

А возможен ли вообще неограниченный подход в генерации любых знаков? Ответ – да, по крайней мере, реализованный на отдельных приложениях или скриптах, использующих обычные системные шрифты. Рассмотрим такие варианты:

Векторная реализация.

Всё предельно просто. Берём компоненты из шрифта, указываем тип композиции, затем крутим, вертим, смещаем, и на выходе получаем составной знак по 11 из 12 существующих в Unicode типов построения китайского иероглифа. Возможна и многошаговая генерация знака. Верхний предел числа знаков – бесконечность. Приятно отметить, что ощутимый шаг в направлении динамической генерации нестандартных иероглифов (в SVG-формате) был сделан одним из членов авторского коллектива «Ма» в феврале 2013 г.

Очевидно, что очень и очень много составных иероглифов могут быть созданы из символов, уже имеющихся в азиатских шрифтах. Но основной недостаток векторного направления – это серьёзная чувствительность к отсутствующим графическим компонентам некоторых ключей, в качестве которых выступают составные и сложные знаки (например, верхняя часть ключа «птица», которая без нижнего элемента «огонь4» часто используются в других знаках, но в Unicode она не представлена).

Растровая реализация.

Тут имеются самые широкие возможности. Много аналогий с векторным подходом, но имеются свои выгоды. Генерация нового символа ведётся на растре с хорошим разрешением и также с использованием системных ttf-шрифтов. Но в отличие от векторного, в растровом подходе у любого знака, который планируется использовать в качестве ключа, можно обычным залитым прямоугольником, т.е. проще говоря – «закрывашкой», легко формировать готовый ключевой знак. В векторном походе такого не получится (там сложнее реализовать «закрывашку»). Автор эти строк немного поэкспериментировал в этой области, но потом позорно забросил смелый эксперимент из-за недостатка свободного времени.

Hanzi generator

Вот как это задумывалось…

Metrics generator

Задание метрик для составляющих знаков.

Metrics generator1

Использование «закрывашек» для генерации нового ключевого компонента.

Но повторюсь, это очень перспективное направление генерации практически неограниченного числа знаков по 11 из 12 стандартных типов декомпозиции. Как и в векторной реализации, для растрового подхода аналогично необходимо предварительное задание метрик (сдвиги, масштабирования) совмещения для всех вариантов используемых ключей, т. е. как они должны сочетаться с неключевыми компонентами для достижения гармоничного и правильного облика результирующего знака.

В качестве небольшого анонса. Автор этих строк в настоящее время интенсивно прорабатывает вопросы заполнения всей информации о декомпозиции для самого мощного расширения Unicode ExtB (42 тыс. знаков), используя труды от Gavin Grover. Так вот, анализируя предложенные им типы расширенной декомпозиции китайского иероглифа, мне удалось систематизировать это, строго следуя существующей стандартной концепции Unicode IDS, поэтому в следующей статье я обязательно поделюсь с читателями результатами. А там уж и до proposals for Unicode дело как-нибудь дойдёт…

comments powered by HyperComments

Orphus: Нашли опечатку? Нажмите Ctrl+Enter

Автор: WERTA

Фанат грамоты на кiтайскiхъ знакахъ. Родился в 1977 г. Проживаю в РФ. Интерес к китайскому я зыку и культуре внезапно проснулся в 1997 г. Особенно интересует меня все, что касается: международных стандартов CJKV унификации, кодировок, методов ввода, схем романизации и общей фонологии основных кит. диалектных групп. За границей не был, КНР не посещал. Опыта языкового общения с носителями китайского языка не имею. Перевел в 2011 г. c традиционного китайского на русский язык компьютерную игру 殖民計劃 — Colonial Project (DOS, RTS, 1996, T-Time Corp.).

Papa HuHu
2014-09-01 20:15:26
Все-таки мне лично видится самым перспективным вариантом именно SVG-генерация. Это ведь решит вопрос вывода у пользователя, в независимости от того, какие шрифты у него стоят, не так ли? Да и при векторной генерации, проще создать программу, при которой пишущий редкий знак человек, может более гибко задать эстетические параметры компоновки иероглифа. Не будем забывать, что в целом необходимость в написании таких иероглифов дико-крайне-чрезвычайно мала. Поэтому, я осознаю, что создание базы данных графической компоновки иероглифов это дело благое, но в целом не уверен, что в свете развития технологий, такое уж и нужное.
Papa HuHu
2014-09-01 20:20:26
За ссылку по упрощенным иероглифам для Unicode - спасибо :) очень интересная это тема :)
Papa HuHu
2014-09-04 20:31:29
Ну да, такова цель - чтобы можно быть иметь в шрифте все знаки, которые только могут встретится при оцифровке. А что, Уникод же почти резиновый :) ему-то что. Просто не все шрифты пока еще включают все его символы. Но опять же, пусть их там даже 1.000.000 будет - с теми компьютерными мощностями, что есть сейчас, что такое иметь шрифт с миллионом символов на своем планшете или телефоне - так, плевое дело.
WERTA
2014-09-04 18:39:10
«Насколько я понимаю, расширение Уникода это все-таки для лучшей оцифровки книг.» - Я так и не понял основной политики Юникода в этом вопросе. Вроде так: «Есть древний словарь, есть в нем знаки – давайте стандартизируем все эти знаки…». Давно уже с этим расширением ExtB работаю в плане описания символов, и прихожу к такому вот унылому выводу: очень многие из этих расширенных знаков (вьетнамские они или нет, не важно) так или иначе они являются уже похожими на какой-нибудь очень распространенный стандартный иероглиф с большИм количеством черт. И все это в нескольких вариантах: то с новой чертой, то с чертами элемента немного по-другому ориентированными и т.д. Одна только «черепаха» [龜] (кл.№213) сколько имеет графических вариантов в основной плоскости Юникода. Как будто кто-то невнимательно по памяти чертил сложные знаки из Поднебесной, ну и ошибся немного с составными элементами. Вот такое сложилось видение.
Infusiastic
2014-09-03 12:42:48
<p>«Чувствительна к отсутствующим графическим компонентам некоторых ключей» лишь моя сырая и недоработанная реализация.</p> <p>«Закрывашку» можно сделать с лёгкостью и в векторном, и в растровом варианте, проблема в том, что для каждого шрифта в обоих случаях необходимо описывать свои размеры закрывашки.</p> <p>Разумная альтернатива — ограничиться одним шрифтом, что я собирался сделать во второй версии своего сервиса. Это к тому гарантирует результат вне зависимости от того, какие шрифты стоят на компьютере у пользователя.</p> <p>Использование растра не имеет никаких преимуществ вообще (растризовать изначально векторные TTF это вообще странная идея), а недостатки (зазубрины на иероглифах большого размера) хорошо видны даже на скриншотах в этой статье.</p>
Papa HuHu
2014-09-04 18:27:15
Насколько я понимаю, расширение Уникода это все-таки для лучшей оцифровки книг. А про стандарты, там же вопрос вовсе не в планке, как ограничителе. Это просто наследие той поры, когда надо было регулировать шрифты и еще не было Уникода. То есть, стандарты имеют смысл что "должно быть не меньше вот этих 2Х.ХХХ иероглифов", а не в смысле "не должно быть больше, чем установлено стандартом". Ну, про вопросы официальных документов и ввода фамилий и топонимов - это другой вопрос. Тут это просто вопрос бюрократического документооборота. Как у нас нельзя же в кириллические поля для паспорта, скажем, вводить латинские буквы. А может я бы хотел себе имя в паспорте типа Иwaн? :)
WERTA
2014-09-04 18:22:49
В 2001 году очень смелые были декларации. Но они декларациями и остались. Как мне видится это будет набор из 1) Основных знаков (CJK, ExtA, ExtB… в зависимости от задач шрифта) 2) Недостающих компонент (они не индексируются Юникодом в стандарте OpenType) 3) Таблицы количества черт в стандартизованных знаках (это нужно, чтобы знать как больше или меньше отодвигать (сжимать) ключевой знак, например, влево) 4) Таблицы вариантов трансформаций символов (мы же хотим. чтобы все выглядело красиво) Вот такое видение. Это большая работа, поэтому они так и не сделали ее. Я немного изучал OpenType самостоятельно и скажу, что на тот момент он не потянул бы это. Про сегодняшнюю версию стандарта - не скажу, хотя с тех пор он мало изменился.
WERTA
2014-09-04 18:15:51
«Не будем забывать, что в целом необходимость в написании таких иероглифов дико-крайне-чрезвычайно мала.» - да, тут не поспоришь. Действительно, я слышал, что подобная проблема нестандартизованных знаков оч.редко «вылазит» только в Гонконге и не далее. В остальных же национальных стандартах для наборов символов всё уже давно продумано и жестко зафиксировано (интересно, если опустить планку стандартов, с какой скоростью нестандартные иероги начнут размножаться?) Ещё я слышал, что добавляют в стандартные наборы сейчас новые знаки, в основном связанные с историческими топонимами и редкими фамилиями. Так что описанные мною попытки создания технологий построения любых иероглифов – это скорее чисто спортивный интерес отодвинуть границы возможного к бесконечности. …но лучше за границы возможного – не выходить.
WERTA
2014-09-04 18:07:06
Да, полностью согласен насчет одного шрифта. Я также рассматривал метрики композиции только для строго определенного шрифта. Насчет некой ущербности растров - согласен, даже если говорить об иероглифе на растре, например, 1024х1024 пикселя. Шрифтово-векторные технологии заведомо будут выгоднее в плане реализации. Но и SVG рисунок и другой рисунок в растровом формате среди иероглифов останутся лишь внедренными объектами, а так хочется какую-нибудь продвинутую версию OpenType технологии, которая с легкостью делала бы композицию любого знака (из введенных символов декомпозиции) в тексте, скажем, MS Word’a. Но эта тема оказалась сложна и неподъемна, поэтому и канула в безвестности…
Infusiastic
2014-09-04 18:08:17
<p>Да, конечно, в сторону OpenType работать было бы наверное очень перспективно, но как я понимаю, это очень сложно должно быть.</p>