Структура, декомпозиция и унификация современного китайского иероглифа или сложный путь CJK стандартизации Unicode

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

Здравствуйте уважаемые читатели Магазеты. Если предыдущая моя статья была посвящена исключительно вопросам фонетики диалектов, то в этой работе можно увидеть полную противоположность, поскольку будут рассмотрены аспекты китайской иероглифики в рамках стандарта Unicode (Юникод). В настоящее время перед разработчиками стандарта Unicode встаёт интересная дилемма: с одной стороны  дополнительные плоскости стандарта пока ещё дают огромный запас возможных кодировочных мест для китайских иероглифических знаков, а с другой стороны, может быть пора уже перестать экстенсивно наращивать численность CJK иероглифов и пойти несколько иным путём…

Вступление

В 2011 году исполнилось 20 лет существования стандарта Unicode. Тогда не нужно было быть семи пядей во лбу, чтобы понять — конфликты однобайтовых кодировок и особенно китайская иероглифическая письменность сильнее всего подхлестнули развитие единого мирового стандарта символов с двухбайтовой кодировкой. А давайте-ка вспомним 1998–2000 годы. Это было золотое время начала массового вхождения стандарта Unicode в нашу компьютерную повседневность. И тогда ещё часто можно было ощущать на себе подобные неприятные конфликты кодовых страниц при открытии разных документов в Word, Visio и др. А в Adobe Photoshop только путём умелых махинаций в системном реестре с хитрой подменой кодировок CP1251->CP1252 можно было вставить фразу на кириллице. А что сейчас? А сейчас пользователю гарантируется, что никаких потерь информации от сбоя кодировок хотя бы у юникодовской (UTF-8) интернет-странички не произойдет, ни на кириллице, ни на арабице, и любой китайский иероглиф гарантированно воспроизведётся при открытии (разумеется, только при наличии установленного азиатского шрифта в системе).

CJK Unicode

Теперь непосредственно про основную тему статьи — CJK-направление в Unicode. Изначально число китайских иероглифов в блоке CJK Unifed Ideographs — основном костяке в стандарте Unicode — было равно 20 902, многим это уже тогда казалось запредельным числом. Этот набор полностью охватывал многие стандартные восточноазиатские кодировки GuoBiao, Big5, KSC, JIS. Казалось, что всё так и будет, все были довольны, но неоднократно заявлял о себе Гонконг с его прогремевшей в «интернетах» проблемой иероглифа (+U282E2) «лифт» и недостатка др. знаков. Ещё вспомнили, что оказывается и во Вьетнаме в своё время чересчур увлеклись конструированием значков Тыы Ном, коих теперь насчитывают тысячами, хотя вьетнамские иероглифы сейчас представляют чисто исторический интерес для специалистов. В общем, неизбежно встал вопрос о расширениях. Посмотрим на хронологию стремительного увеличения популяции ханьцзы в стандарте Unicode за счёт расширений.

———————————————-

CJK   Unicode 1.0 (1993) – 20902 字

CJK-ExtA  Unicode 3.0 (1999) – 6582字

CJK-ExtB  Unicode 3.1 (2001) – 42711字

CJK-ExtC  Unicode 5.2 (2008) – 4149字

CJK-ExtD  Unicode 6.0 (2010) – 222字

CJK-ExtE  – planned >16000字, но после2007 г. ~ 10 000字

————————————————-

Итого ~ 85 000字 (держитесь китаисты, возможно, это ещё не предел!)

Не пора ли остановиться, и от экстенсивного пути развития стандарта перейти к интенсивному?

Язык описания структуры иероглифической декомпозиции (IDEOGRAPHIC DECOMPOSITION SEQUENCE).

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

1) Wenlin CDL (Character Description Language)

2) Ideographic Decomposition Sequence,

остановимся на втором – Ideographic Decomposition Sequence. Именно он неявно был постулирован в самом стандарте Unicode путем введения блока под символы декомпозиции (Ideographic Description Characters) ещё в1999 г. Что представляет собой строка о декомпозиции знака? Это просто описание составляющих частей иероглифа и описание применённого типа  декомпозиции:

Это может быть развернутая полная запись (представлена выше на рисунке), либо бинарная запись из двух операндов. Т. е. таким простым образом можно удобно записывать структуру иероглифа для методов ввода, для обучения и запоминания, а также для решения многих других задач. Вот стандартизованные символы для обозначения декомпозиции (вверху латинская мнемоника, внизу номер символа в стандарте Unicode).

Большинство операций декомпозиции – операторы бинарного типа. Это значит, что нужны два операнда и один символ для представления информации о структуре иероглифического знака (декомпозиции). Тринарными являются только операции с мнемоническими кодами LCR и UCD. Преобладающая бинарность операций продиктована самим фундаментальным способом образования иероглифа, чаще всего сводящимся к простой формуле:

«иероглиф»=«ключевая часть»+«фонетик или семантик, не ключевая часть».

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

Примеры бинарных операций:

 

Примеры операций декомпозиции типа OV(OVERLAID):

Сама запись декомпозиции для каждого ханьцзы будет ещё и полезна для дальнейшего развития самой CJK стандартизации в Unicode. К примеру, знак, для которого попросту не получилось декомпозиции – тогда мы имеем тот самый истинный радикал, несоставной иероглиф, который послужит кирпичиком для более сложных составных ханьцзы. Именно из таких есть смысл формировать новые таблицы базовых радикалов и это будут не классические 214 ключей Кан Си, а что-то иное. Либо имеется иероглиф, для которого так и не было найдено второй декомпозиционной половинки в современных CJK Extensions, тогда эта половинка, по идее, должна будет быть обязательно включена как самостоятельный знак в стандарт Unicode в последующих расширениях. И вот здесь может начаться конфликт мнений. Ведь, по сути, базовой предпосылкой для вставки иероглифа в расширения Unicode является его наличие в каком-нибудь признанном древнем или не очень древнем иероглифическом словаре. Но когда мы начинаем вставлять просто сегментированные, «вырванные» из знаков графемы, ревнители «расовой чистоты» словарного происхождения иероглифов для Unicode могут встать в позу: – «Не позволим, дескать, засорять мировой стандарт безродными значками, взятыми из ниоткуда!». Похоже, что именно в такой противоречивой ситуации  находятся сегодня разработчики стандарта.

Сразу очевидно, что большинство типов декомпозиции в первом приближении, в принципе, не требуют дополнительной координатной информации для взаимосопряжения соединяемых элементов, расположенных в квадратном окне результирующего иероглифа. В конце концов, хотя бы сам ключевой знак уже может подсказать оптимальные размеры, в которые необходимо вписать второй подчинённый знак.  А вот у типа декомпозиции (+U2FFB) – OVERLAID  для точного воспроизведения иероглифа зачастую жёстко необходима дополнительная информация по координатам сопряжения и трансформации двух объединяемых знаков. Поэтому сам описываемый в этой статье принцип записи декомпозиции или композиции, будет уже неприменим без координатной информации, в частности, для динамической генерации иероглифов типа OVERLAID (+U2FFB) .

Да и для остальных типов декомпозиции в рамках динамической генерации новых иероглифов стоит отметить один маленький «недостаток». Некоторые не ключевые элементы, особенно располагающиеся слева от ключа (это ситуация, когда ключ стоит справа в композиции типа LEFT TO RIGHT), при вставке в новый знак могут немного видоизмениться. Например 改=己[LR]攵. Т.е. тогда в предполагаемой шрифтовой технологии необходимо будет закладывать ещё и варианты трансформации (подстановки) формы знака в зависимости от типа декомпозиции и места расположения иероглифа внутри квадратной иероглифической области.

Потенциал шрифтовых технологий для динамической генерации иероглифов.

Конец 90-х годов прошлого века это ещё и время начала победного шествия для расширения стандарта TTF – технологии Open Type. Эта технология сейчас обеспечивает поддержку всех систем сложных языковых письменностей: и письма справа налево, и разных форм букв в зависимости от положения в слове (арабский), динамического образования лигатур (деванагари, бенгали…) и многого другого. Только в шрифтах с поддержкой технологии Open Type лигатуры и разные формы одной буквы должны быть так или иначе заранее прорисованы в наборе символов, и могут быть с индексом или даже без индекса Unicode. Но для описываемой в этой статье динамической генерации иероглифов, скрытых или запасных символов «заготавливать» не надо. Достаточно будет только базового иероглифического набора, лишь бы он максимально охватывал все потенциально возможные варианты генерируемых составных иероглифов. Я не специалист, но возможно, что при некоторой доработке, технология Open Type всё-таки может быть пригодна и для динамической генерации иероглифов по записанной непосредственно в тексте строке композиции (декомпозиции). Т.е. мне видится это так: при так называемом польском формате записи [OPERATION, OPERAND1, OPERAND2] и при обнаружении, например, в потоке символов знакомого нам знака U+2FF0, после него сразу же должна следовать выборка ещё двух иероглифических знаков (поскольку это бинарный оператор), причём первый знак располагается масштабированием справа, второй – слева, например ([LR]氵光)=>洸. Оптимальную ширину пропорции деления на две половинки в декомпозиции U+2FF0 (IDEOGRAPHIC DECOMPOSITION LEFT TO RIGHT) можно сделать заранее переменной, исходя из используемого ключевого знака, и это может быть заложено в выбранном шрифте в виде некоторой информации о базовых правилах композиции знака с различными ключевыми элементами. Скорее всего, качество графики таких иероглифов, даже при учёте переменной ширины пропорции разделения, будет всё равно не совсем гармоничным и идеальным, зато формально всё это будет работать. А теперь можно предельно упрощённо подсчитать, сколько из базового набора, содержащего, например 50 000 знаков, можно будет получить новых знаков, хотя бы при однократной бинарной генерации по простейшему принципу композиции «ключ» + «знак». Это будет астрономическое число и равно оно 214*50000=10 700 000 знаков. А уж сколько вариантов можно получить при сложных типах композиции в несколько действий, даже страшно считать! Т.е. это может фактически остановить неудержимое и экстенсивное наращивание новых CJK расширений стандарта Unicode. И знаменитый мегаиероглиф с нестандартным для путунхуа звучанием [biang] наконец-то можно будет записать в тексте вот так (c учётом расширенных нововведений, о них см. ниже по тексту):

А сколько же ещё по всему Китаю разнообразных ресторанов и закусочных, в которых каждый хозяин, просто из кожи вон лезет, чтобы придумать свой оригинальный иероглиф в названии заведения, так что же, их также надо вносить в стандарт – вот тогда точно Unicode может просто лопнуть.

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

[NEW_HZCHAR]=[HZCHAR1]+<DECOMPOS>+[HZCHAR2]

теоретически способна удовлетворительно работать для всех типов декомпозиции, кроме OVERLAID (U+2FFB).  Внешне это будет выглядеть уже как некий гибрид, с одной стороны это развитая шрифтовая технология, с другой – практически вполне самостоятельный редактор метода ввода (IME).

Весьма отдалённым примером экономичности при реализации подобного подхода служит многим известный шрифт MS Song. Его размер всего лишь 2,5 МБт,  а он содержит все 20 902 иероглифа из основного CJK блока Unicode. Другие аналоги этого шрифта имеют размер файла TTF около 15–20 МБт. А весь секрет в том, что при формировании иероглифических символов в MS Song в рамках классического формата TTF просто использованы перекрёстные ссылки на другие заранее уже сформированные символы, и также задаётся пространственное смещение для сопряжения нескольких частей вновь образуемого иероглифа. Размер ссылки на глиф и информация о пространственном положении и масштабировании этого «ссылочного» глифа всегда занимают на порядок меньше места, чем полная прорисовка этого же знака в иероглифе заново по всем точкам символьного контура. А в большой массе иероглифов от раза к разу тысячекратно повторяющихся элементов более чем предостаточно. Т. е. выгодно иметь только базовый набор и некие простые правила формирования новых сочетаний из этого базового набора – это занимает меньше места. Именно в чём-то аналогичный путь дальнейшего развития стандарта в области кодирования CJK-иероглифов необходимо выбирать дальше для развития стандарта Unicode.

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

Неполнота представления знаков

Казалось бы, теперь всё выглядит довольно понятно и безоблачно – бери и кодируй таким образом декомпозицию для всех CJK иероглифов из расширений Юникода, но есть одна серьёзная проблема – это неполнота представления составных частей иероглифов для небольшой части используемых знаков в составе CJK-расширений стандарта Unicode. Т. е. с помощью бинарного способа пока ещё не для всех ханьцзы в настоящее время имеется возможность полного представления типа A = B + C. Но это относится именно к бинарной форме представления операции композиции. Если невозможно представить запись декомпозиции иероглифа в виде одной операции, просто из-за отсутствия одной из составных частей знака в стандарте Unicode, то вполне возможна полная запись этого знака путём двух-трёх операций декомпозиции, для которых наличие менее сложных составных частей будет всегда более вероятным. Но удобство бинарного представления (одна операция и два операнда) записи декомпозиции китайского иероглифа наиболее удачно можно использовать для хранения в иероглифических базах, поскольку так всегда можно выделить ключевую и не ключевую часть знака, а это удобно для группирования и сортировок родственных знаков. Но даже если вдруг идея развития динамической генерации иероглифов потерпит техническое фиаско, то ещё остаются структурные методы ввода, и такое представление структуры знака будет очень удобно для быстрой генерации строк в соответствии с взаимоувязанной по не ключевым знакам системой кодирования различных методов.

Неявные ключевые знаки

Многие китаисты наверняка замечали некую скрытую систематичность среди небольшого числа редких иероглифов. Это я о том, что существует гораздо большее количество знаков, которые можно было бы также считать ключевыми. Эти ключевые значки не вошли в 214 классических радикалов словаря Кан Си, но по типу образования от них новых знаков вполне могут претендовать на звание ключа. Введение или просто принятие во внимание “выделенности” знаков подобного типа может существенно обогатить принципы декомпозиции, и в то же время, поможет способствовать расширению формата декомпозиционной записи для охвата большего количества знаков, графические части которых пока еще не включены в стандарт. Вот некоторые из этих «непризнанных» ключевых знаков с отображением схемы образования нового знака от них.

Расширенная модификация декомпозиции.

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

  Принцип интуитивно понятен, и что самое главное, этот принцип однозначен, кроме последних двух вариантов, для решения проблемы которых потребовались дополнительные нововведения.

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

 

Большинство из представленных выше рекомендуемых унарных типов декомпозиции также имеют альтернативную «стандартную» форму записи. Хотя, особое внимание следует обратить на унарную операцию с мнемоникой Т (Triplet, предлагаемый код U+2FFE). Это именно та уникальная и обойдённая вниманием стандартизаторов  операция композиции, с применением которой верхняя часть сформированного знака должна немного ужиматься по горизонтали, а не быть оставлена «размазанной» по всей ширине после композиции. Поэтому о «стандартных» аналогах декомпозиции с сочетанием двух обычных U+2FF1 и U+2FF0 конкретно для этой операции «утроения» нужно говорить весьма взвешенно.

Об упрощениях 1977 г.

Обязательно здесь я хотел бы упомянуть о второй реформе упрощения иероглифов, проведённой в КНР в1977 г., но отменённой немного позднее. Это были иероглифы, ещё более упрощённые в плане рукописного начертания. А как, например, сегодня поступать с такими знаками, забыть про них навсегда или всё-таки увековечить в стандарте для истории, ведь это тоже был кропотливый труд большого коллектива китайских специалистов в области иероглифики и языка. Но тогда речь пойдет о тысячах ханьцзы и их производных, доводящих дополнительное количество, возможно, до 5 000 знаков. В источнике [Суханов В.Ф., Упрощённые начертания и разнописи китайских иероглифов, 1980] приведены также многие варианты упрощений, принятых в1977 г., и я не могу сказать, что они совсем уж неудачны. В них действительно много здравых зёрен.

В конце концов, чтобы отмести все споры на эту тему, важнейшим количественным показателем эффективности упрощений 1956 и 1977 гг. будет простой подсчёт суммарного числа черт, к примеру, для 3000 наиболее часто употребимых знаков, и сопоставление этого количества как между собой, так и с аналогичными показателями рукописного ввода (число черт) для традиционных знаков. Однако здесь надо будет чётко различать сами упрощённые формы, разнописи и каллиграфически несовместимые с типографическими, формы откровенной скорописи для китайских иероглифов. И чтобы провести такую работу, конечно же, предварительно необходимо принятие решения о современной подготовке к стандартизации упрощений от 1977 г. и внесении их в стандарт Unicode. Возможен также несколько другой путь, основанный на динамической генерации иероглифов из строки декомпозиции. Если внести в стандарт только наиболее значимые графемы от упрощений 1977 г., то с динамической генерацией становится возможным гораздо меньшим количеством иероглифов покрыть все эти новые знаки. Ведь даже с исторических позиций, присутствие упрощённых знаков от 1977 г. в стандартных наборах сейчас, в принципе,  необходимо, поскольку кто-то же из специалистов подобной тематикой всё равно занимается в Китае или за его пределами.

Упорядочивание вариантов

Приведённая выше информация касалась только структуры китайского иероглифа. Но есть ещё одно направление в стандартизации – унификация. Многие понимают, что современное чудовищное количество ханьцзы в Unicode отчасти порождено ещё и многочисленными вариантными формами различных иероглифов. Так вот, унификация копотливо разбирает эти генетические связи между иероглифами и выявляет наиболее значимого из них, так сказать – родоначальника. Какая же может быть связь между унификацией вариантов и динамической генерацией иероглифов?  А очень даже непосредственная. Это позволит выбирать только базовые формы иероглифов и путем неких дополнительных преобразований динамически получать желаемый упрощённый (первое, второе упрощения), традиционный или другой тип варианта от одного базового иероглифа. И опять же, если с динамической генерацией знаков ничего не выйдет, то, в любом случае, тогда просто остаётся информация о генетической связи между основными иероглифами и их вариантными формами. Наиболее наглядной, в вопросе визуализации, для этих задач является трёхмерная XYZ концепция отображения вариантов китайских иероглифов.

XYZ концепция

Подобная концепция, прежде всего, привлекает своей наглядностью визуализации связей между основным и вариантными иероглифами. По оси Х от основного иероглифа откладываются семантические варианты, т. е. смысл иероглифа почти один, но эти иероглифы принципиально различные и не могут считаться объединенными по смысловому признаку, что-то вроде наших синонимов. По оси Y откладываются официально упрощенные формы основного иероглифа, причем традиционная, упрощенная и основная формы являются абсолютно разными иероглифами. Здесь можно условиться, что по любой оси сортировка нескольких иероглифов выполняется по количеству черт, положительное направление оси соответствует уменьшению количества черт в знаке. Поэтому на оси Y могут быть и традиционная форма одного иероглифа и упрощённая, они будут расположены с разных сторон от основного знака. И наконец, Z – это ось наименьших, так называемых вариантных различий, когда иероглиф не являясь упрощённым, всё-таки немного отличается от основного, а смысл имеет, разумеется, абсолютно такой же. Пример эффектного XYZ отображения вариантов для иероглифа 齊 (для китайского иероглифического ареала).

Неплохо было бы подобную концепцию сделать четырёхмерной.  Просто добавить новую ось L (Locale), поскольку в разных регионах заимствование, упрощение иероглифических знаков и распространение их вариантов шло различными путями, т. е. L  принимает перечислимые значения, как минимум, по основным региональным ареалам L=漢,日,韓,越. Ниже приведён пример таких XYZ трёхмерных гиперсрезов с четырёхмерной XYZL-структуры для иероглифа 龍.

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

Всё выше написанное не стоит считать навязыванием своего мнения разработчикам мирового стандарта Unicode. Это были всего лишь размышления вслух и анализ пройденного пути, а это бывает действительно часто полезно в тупиковых ситуациях или на распутье. И напоследок, я хотел бы сказать следующее. В настоящее время уже можно констатировать, что этап накопления основного массива данных в иероглифических расширениях стандарта Unicode подходит к концу. Теперь настаёт пора общего анализа, унификации и систематизации всей имеющейся в Unicode иероглифической информации, но эта работа растянется ещё не на одно десятилетие. Экстенсивное развитие стандарта Unicode плавно завершается, и теперь все наши взоры обращены в сторону проекта Unihan, одно название которого вселяет надежду, что во всей этой почти 100 000-ой куче всевозможных китайских значков рано или поздно будет наведён более строгий порядок…

Благодарю за внимание, и надеюсь, что было хоть немного интересно.

WERTA, 25/07/2012

Фото аватара

Автор: WERTA

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

44 комментария

  1. Yesss!!!!!!!

    Я, наконец-то написал скрипт для генерации иероглифов по их описаниям!

    На выходе получается картинка в формате SVG, которую можно отобразить в любом масштабе в современном браузере или конвертировать в PNG.

    Требует Ruby 1.9.

    Пока что реализованы только операторы ⿰ и ⿱, а иероглифы получаются не очень красивые.

    Репозиторий доступен по ссылке: https://bitbucket.org/mnyonpa/zaozi/

    1. К сожалению не знаком с Ruby. А технически что нужно установить, чтобы иметь возможность просто и “вживую” увидеть ваши наработки. Меня очень заинтересовало это, скорее всего, у меня в голове появятся новые мысли, например, в плане метрик для масштабирования символов перед композицией.

          1. Совсем адские пока нельзя — требуется, чтобы все компоненты были в Unicode. Т.е. biang пока не поддерживается :) Но ограниченно адские уже можно.

        1. Отлично!!! Этот день должен войти в историю. Наконец-то мы смогли увидеть давно обещанную еще в 2001 г. композицию иероглифического знака. Я, к сожалению, так и не разобрался с установкой Ruby. Зато очень приятно сразу в онлайн составлять знаки и получать результат. Это нужно обязательно оформить в виде сетевого ресурса, скриптов т.п. Возможно, это нужно также оформить отдельной статьей в «Ма». Я увидел сегодняшнюю «мощную» смысловую иероглифическую композицию от нашего Главреда, и в голове все встало на места. Я понял, чего нам не хватает:

          1) Те сложные (расширенные) варианты декомпозиции, которые я описал выше, они требуют уже заполненной базы по композиции для всех знаков. Поэтому нужно остановиться на классической Юникодовской декомпозиции – для нее не нужна информация о композиции используемых знаков.
          2) Нам не хватает метрик. Метрик должно быть два типа: масштабирования и смещения.
          3) Вручную, прямо в программном коде, придется заполнять метрики только для ключиков и некоторых их вариантах. Для остальных 99,9 % это будут вполне стандартные отношения 50% на 50% (хотя бы для типов LR, UD). Напомню, что в Юникод-блоке любого ключа варианты ключиков всегда идут сразу же за первым основным ключом блока. Редко бывает, что упрощенный вариант ключа и вся его «свита» идут в конце блока. Т.е. нам нужно только заполнить метрику для всяких там: «вода с двумя точками», трава, всякие тонкие «крышечки». Т.е. например если «вода с двумя точками»=20 % ширины, то для остального знака автоматически = 80 %.
          4) Помимо метрики ширины, можно добавить еще и метрику смещения в каких-то условных единицах, чтобы сильно не сжимать и не уродовать знак. Т.е. тонкую «крышечку» или «травку» можно просто сместить вверх, без сжатия по вертикали.
          5) Остальным сложным знакам смело можно по умолчанию задавать 50 % размера для равных по иерархии декомпозиций (трудноопределимые ключи, составные знаки из двух сложных неключевых знаков по типу LR, UD). Также смело можно задавать 33 % для любого знака в троичных композициях по типу LCR, UCD.
          6) Для дальнейших экспериментов предлагаю сменить фонт. Есть хороший микрософтовский от Win7 – Microsoft YaHei. Он тоненький и скругленный. И кажется у него есть CJK Extension A.

          P.S. Даже не предполагал, что обычная моя статья возродит к жизни такой гениальный прорыв в области иероглифостроения. Так держать!!!…

          1. Пост в Магазете появится в ближайшее время.

            Что касается метрик, можете посмотреть, что у меня пока файл с метриками представляет: https://bitbucket.org/mnyonpa/zaozi/src/02eb97c41b1a3423f7b9b33a04df059e15901578/scales.json?at=default

            Вкратце, каждый IDS содержит метрики [x, y, hscale, vscale] для всех трёх компонентов, универсальные (*) и для конкретных. Плюс метрики для двух компонентов сразу (Т.е., чтобы правильно отображать иероглифы, начинающиеся с ⿵门, первый компонент имеет правило для самого 门, второй имеет правило 门*, задействующееся, если первый компонент это 门). Это всё несколько запутано, и к тому же третий компонент где он есть, не при делах, но пока так.

            x и y выражаются в em, hscale и vscale относительной величиной — это позволяет менять размер знака, что уже реализовано. Значения очень странные, потому что кажется, x и y зависят от масштабирования, но я пока в эту логику SVG въезжать не стал.

            Я себе сделал апп для визуального редактирования метрик, но пока только как proof-of-concept. Если я его во что-то законченное оформлю, то смогу скорее всего тоже загрузить на GAE.

            Я Ваши предложения по метрикам в ближайшее время посмотрю и добавлю/поправлю.

            Что касается шрифта, то отображение зависит от браузера и установленных в системе шрифтов, поэтому я специально не стал задавать какой-то определённый шрифт, хотя добавить не проблема.

        2. У меня есть несколько комментариев и вопросов.
          1) Я подзабыл шрифтографию. Размер буквы «М» (em) – он железно сохраняется хотя бы во всех азиатских шрифтах или есть отклонения.
          2) Про фонты и имел в виду следующее. Просто все масштабирования негативно сказываются на толщине черт, особенно вертикальных. Поэтому нужно, чтобы черты были одинаковой толщины (а это только стиль ХэйТи и ему подобные) и чтобы толщина черт была по возможности тонкой. Т.е. для экспериментов не нужно использовать Сун или Мин стили.
          3) Нужно четко различать главные ключи и их рабочие варианты.
          Например «ВОДА»
          Главный –水, он используется в композиции LR довольно редко, в основном UD (снизу)
          Рабочий – 氵, именно он порождает то подавляющее большинство ханьцзы (LR) в самом густонаселенном ключе «ВОДА».
          Т.е. запись 水[LR]气=汽 оторвана от графической семантики знака и представляет собой больше логическое описание структуры иероглифа и его компонент.
          Верной для графической композиции будет, конечно же, запись 氵[LR]气=汽
          Есть например серьезная проблема с некоторыми типами ключей. Например все знают, что ключ 方 часто содержит дополнительный довесочек 人 (斺,於) или (施,斾) – для них такой вариант крышечки я так и не нашел, хотя догадываюсь, что это тоже «человек» –人. Т.е сначала для этого ключа пользователь сам сформировать глиф с довесочком, а затем добавить слева ключ方. Здесь была бы очень удобна моя расширенная трактовка декомпозиции 㫆=㫃⿸小, но для такого подхода нужна полная информация о декомпозиции используемых знаков, что сейчас технически невыполнимо (просто многих компонентов нет в Юникоде).

          1. Скоро будет можно, добавив к адресу ?fontfamily=[название шрифта], задавать шрифт. Сейчас уже работает, но чуточку глючно.

        3. Посмотрел эту страничку: http://svghanzi.appspot.com/
          Просто потрясающе! Я бы прорекомендовал следующее:
          1) По умолчанию при заходе на страницу сделать сразу какой-нибудь заведомо несуществующий в Юникоде фееричный пример композиции суммарно черт эдак на 50, а фонт в примере задать размерами 256 пт или 400 пт, чтоб получаемый ханьцзы был в полэкрана. Это кстати немного сгладит искажения толщин вертикальных линий, что даст возможность использовать по умолчнаю классический Мин-стиль.
          2) Но для этого получаемый глиф желательно разместить в просмотре на той же самой странице в какой-нибудь рамочке по центру, чтобы не было перехода на след. страницу после композиции.
          3) В описании мнемоник для типов декомпозциии не хватает в начале перечисления тэгов LR и UD.
          4) Я видел, что не хватает некоторых рисунков на странице. Я вообще могу взять на себя графику и оформление дизайна html-страницы (опыт имею).
          5) Как я и писал в статье, композицию типа OVERRIDE кроме как центральным наложением не реализуешь без доп. информации по координаным сдвигам (пример на странице – zhong). Видимо тут придется для пользователя описать ограничения на использование конкретно этого типа композиции.
          6) Можно ли предусмотреть экспорт в растровые форматы кроме SVG?, а то SVG не во всех просмотрщиках (кроме интернет-браузеров) “виден”.

          Пока идеи закончились. Буду весьма рад помочь.

          1. Опечатки поправлю.

            Что картинки с главной страницы уехали — это глюк, поправлю тоже в ближайшем будущем.

            Что касается главной страницы, мне хотелось бы намеренно оставить её в таком виде, без стилей вообще, с инструкцией по пользованию сервисом, и всё. Это наиболее отвечает и самому характеру сервиса, который выдаёт SVG-файлы, и всё.

            中 и 來 как раз на удивление правдоподобно выглядят со стандартной настройкой метрик, а вообще, может быть, стоит сделать визуальный редактор метрик доступным всем (или зарегистрированным) пользователям, чтобы если кого-то не устраивает результат, он мог бы зайти и отредактировать метрики так, чтобы было красиво, а потом они бы отсылались на одобрение для возможного включения их в общий файл метрик. Но это нужно будет прикручивать порядочно функционала к движку сайта, и хотя это технически очень просто и может быть сделано за день, придётся подождать, пока на меня снова найдёт вдохновение. А пока просто баги основные исправлю, и всё.

            Что касается растровых форматов, если вам известна какая-нибудь Python-библиотека, которая бы хорошо конвертировала текстовые блоки SVG в скажем PNG, скажите, и я добавлю её поддержку. У меня на компьютере стоит svg2png, но она их игнорирует, и не на пайтоне к тому же. По-моему, гики решат проблему конвертации самостоятельно с помощью какой-нибудь хитрой рутины, а чайники — с помощью функции QQ «сделать скриншот», так что особой необходимости в этом нет.

            Есть у меня, правда, другой скрипт, который достаёт иероглифы из SVG-шрифта в виде кривых, если его прикрутить, тогда результирующие SVG-файлы будут хорошо конвертироваться в PNG. Это как-нибудь потом можно сделать, но ограничит возможный выбор шрифтов парой бесплатных шрифтов Arphic.

  2. Вам также спасибо за внимание к теме. Я думаю, что моя CJKV-база (формат MS Acess), которую я, как монстра д-ра Франкенштейна, собираю по частям вот уже 12 лет (честно говорю Спасибо различным авторам всевозможных таблиц), наведёт ещё больше интересных мыслей. Я недавно добавил новую таблицу (CJK DECOMPOSITION 2013), где объединил всё для масимаьно быстрого забивания декомпозиции. Я также расширил эту работу на CJK ExtB. Т.е. теперь для около 70000 иероглифов Юникода можно будет “забить” декомпозицию. Эта база начиналась всего лишь как некое собрание словарей и таблиц для методов ввода.
    (макросы для ввода азиатских знаков прямо в Word без каких-либо системных клавиатурных раскладок):
    http://baron-werta666.narod.ru/CJKV_VBA/CJKV_VBA_IME_for_MS_Word_v3_0.html

    Но впоследствии, благодаря системе CangJie я смог включиться и в работу по декомпозиции знаков. Короче, вот ссылка на эту базу (распространение свободное):
    http://rusfolder.ru/35064165
    Таблиц много, но конкретно по тематике статьи нужна будет только таблица CJK DECOMPOSITION 2013.
    Самые главные поля для заполнения:
    RAD – первый знак(чаще всего это радикал)
    COMP- тип композиции (пока только в классическои и стандартном понимании по Юникоду)
    – тип композиции (пока только в классическои и стандартном понимании по Юникоду)
    NRAD – второй знак в декомпозиции
    RPOS – очень важное поле, принимает значения: первый (FIRST), последний (LAST), размножение ключа MUL (2,3,4) и ключ в явном виде не присуствует после декомпозиции знака на две составляющие (N/D).
    В основном, пока заполнены (12 тыс) только CJK UNIFED IDEOGRAPSH, однако я подключил и ExtA и ExtB, поскольку недавно смог найти всю заполненную таблицу CangJie для ExtB (42 тыс. знаков)

    Может, кому-то эти идеи будути полезны…

    1. К сожалению, я так и бросил все попытки открыть Вашу базу, т.к. оказалось, что бесплатных программ, позволяющих открыть файл MS Access на маке, кажется, нет. Однако, оказалось, что данные декомпозиции есть в форматах CSV и SQL в пакете cjklib. Если интересно, можете взглянуть: https://github.com/cburgmer/cjklib/blob/master/cjklib/data/characterdecomposition.csv

  3. Спасибо Вам ещё раз огромное за статью, она по-прежнему продолжает наводить меня на интересные мысли!

  4. LaTeХ знаю, но по наслышке. Им формулы ученые выводят в своих научных статьях. OpenType – знаю, его я в далекой молодости в 2000 г. осваивал. Unicode – брал, ХеTeХ – не брал, но вы меня уже заинтриговали. Пошел копаться в Гугль.

    1. Т.е. можно брать просто текстовые боксы с ключами, масштабировать и сдвигать их нужным образом при помощи например пакета pstricks, и на выходе будут красивые иероглифы любым шрифтом. Правда, не знаю, насколько трудно программировать под TeX.

      И задача, которая стоит — определить для каждого ключа нужные пропорции в зависимости от нахождения его в той или иной части. Но мне кажется, это решаемо.

    1. Не вполне понимаю, что такое ХеТеХ.

      Я забил уже почти 12 тыс. нижних или правых “хвостиков” от ханьцзы в основном наборе 20902, дальше процесс сущесвтенно замедлился, посколкьу при выделении фильтром в группе одного фонетика остаются все меньше и меньше знаков. От себя могу подготовить такую базу в MS Acess следующей структуры.

      1) UNI_ID – Юникодовский номер иероглифа
      2) RAD – номер радикала (001-214 по Юникоде) или просто иероглиф-ключ
      3) HZ – …собственно ОН самый
      4) CJ – строка ЦангЦзе
      5) CJ_LENGTH – длина строки ЦангЦзе
      6) RAD_POS – номер позиции радикала (1 первый, 2-последний,3 – кратный 4 – не опр.)
      7) FIRST – первый знак в декомпозиции
      8) DECOMP_TYPE – знак типа декомпозиции (по Юникоде)
      9) LAST – второй знак в декомпозиции
      10) STROKES – полное число строк
      11) ADD_STROKES – число строк в добавленном знаке
      12) MULTIPL – число кратности копирования иероглифа в кратных знаках (品 и т.д.)
      13) UNICODE_DIAP – диапазон Юникода (CJK Unif, ExtA, ExtB, ExtC…)

      Знаки будут либо 20902 знака от CJK Unif, либо CJK Unif + ExtA
      Многое уже будет введено мною (например 12000/20902), но все равно база будет иметь незавершенный вид, однако это позволит забивать композицию нескольким пользователям. Например взяли и распределили между собой ключи и начали забивать декомпозицию для оставшихся незаполненных позиций. Прототип такой базу уже давно есть у меня, но он устарел. Я его хочу привести именно к указанному выше формату, который жестко продиктован правилами, изложенными в этой статье.

      А что такое ХеТеХ?

  5. [QUOTE]Для геометрического взаиморасположения есть ещё вот такое: kanji.sljfaq.org/four.html[/QUOTE]
    Это метод 4 угла – самый популярный из структурных методов ввода для кандзи.

  6. [QUOTE]Надо выбрать Multi-Radical Search.[/QUOTE]
    К сожалению это не совсем декомпозиция. Это просто поиск иероглифа по множеству радикалов, которые входят в его состав. Например: 櫻=(木,貝,女) – последовательность в множестве слагающих радикалов вообще может быть произвольная.
    Это не совсем декомпозиция. Декомпозиция – это именно сохранение информации о геометрическом взаиморасположении знаков в иероглифе с сохранением строгой последовательности начертания. А такой метод поиска довольно популярен именно в японских IME при различных kanji-словарях.

  7. Отличная, интересная статья. Такие посты хочется видеть чаще в Ма, а то туристы все заполонили своими бездарными хвалебными воплями о Китае.

    1. > Всё выше написанное не стоит считать навязыванием своего мнения разработчикам мирового стандарта Unicode.

      Кстати, вот это в корне неверный подход :)
      Я считаю, наоборот, нужно изложить всё в виде proposal и послать в консорциум по Юникод.

      1. [QUOTE]Я считаю, наоборот, нужно изложить всё в виде proposal и послать в консорциум по Юникод.[/QUOTE]
        Не вопрос, только примут ли замечания… Да и куда им на какой ящик пропосалсы отправлять надо?

  8. Спасибо за столь подробные комментарии! Всё стало более ясно. Суть в общем такая, что чтобы всё было систематизировано и в одном месте месте – такого нет, а есть раскиданные по разным местам разнородные фрагменты сделанные разными людьми и чтобы это собрать во едино нужно кучу времени потратить.
    Кроме Вэньлиня, также видел, что кое-какая декомпозиция (но вроде бы не полная а по ключам + нек. граф. элементам) используется для поиска иероглифов в японской базе EDICT на сайте типа этого: http://jisho.org/, она общедоступна для скачивания на сайте университета Монаш, но там совсем мало знаков и ориентация на японский язык. Насчет Цанцзе – видел раньше саму базу, но мне она показалась не совсем тем, что нужно конкретно для поиска – она скорее ориентированная на особенности собственно этого набора.

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

    ЗЫ: А как с вами можно связаться?

    1. [QUOTE]по разным местам разнородные фрагменты сделанные разными людьми и чтобы это собрать во едино нужно кучу времени потратить.[/QUOTE]
      Пожалуй вы правы, все только начинается. ранее это было теория, а теперь все взялись за практическую реализацию.

      [QUOTE]Насчет Цанцзе — видел раньше саму базу, но мне она показалась не совсем тем, что нужно конкретно для поиска — она скорее ориентированная на особенности собственно этого набора.[/QUOTE]
      Как раз нет. Цанцзе очень удобен в плане ввода декомпозиции. В Акцессе выделяете хвостик кодировочной строки например из трех символов, этот хвостих например соотетствует некому фонетику (который справа или внизу) и включаете фильтр. Таблица отфильтруется и останутся фактически только знаки с этим фонетиком, плюс случайно попавшие в такую фильтрацию другие знаки без интересуемого фонетика и они будут в меньшинстве. Именно так я забил около 10 000 пар знаков декомпозиции и ключа для наиболее легких и очевидных типов декомпозиции в основной набор 20902 знаков.

      [QOUTE]Вообще декомпозиция нужна очень многим для организации полноценного поиска иероглифов по графическим элементам (не обязательно ключам) и для меня очень странно, что её до сих пор нет нигде[/QOUTE]
      Собственно это и побудило поднять здесь такую проблему, нужно всем, пообещали, а ничего такого нет до сих пор в течение 10 лет.

      [QOUTE]ЗЫ: А как с вами можно связаться?[/QOUTE]
      [email protected]

  9. >Ideographic Decomposition Sequence,

    Имеется ли где-либо в свободном доступе база данной декомпозиции для каждого иероглифа вошедшего в стандарт Unicode? Работаю с базой Unihan уже давно и даже когда-то слепил на его базе что-то типа словаря с кучей поисковых индексов по разным чтениям, ключам и т.д. для своих нужд, но такого поля с декомпозицией (полной или же частичной) среди общедоступных данных я не нашел, только лишь соответствующий “ключ” к которому “приписан” данный иероглиф. Нечто похожее видел только в базе Вэньлиня, но как это оттуда взять непонятно, да и это как вы правильно отметили не совсем то.

    1. Реально инормацию по декомпозиции я честно “заимствовал” из источников
      1) Gazebo IME
      2) CJKLib – свободный проект (ссылку не привжу, в поисковике наберете)

      И сам я в своей базе данных, используя код ЦанЦзе в прошлом году забил декомпозицию (только тип декомпозиции) для 27 тыс знаков (основной набор + ExtA) и около 10 000 сочетаний из CJK Unifed Ideographs. Эт очень кропотливая работа. Сейчас пока не имею времени, чтобы объединить всю эту информацию. По крайней мере хочу сделать декомпозицию для (основной набор + ExtA).
      В Unihan декомпозиции я не встречал (по крайней мере в прошлом году). Из Веньлиня ее никак не взять (не могу найте где она), тем более, что у них принципы декомпозиции очень примитвны и несовместимы с принципами декомпозиции, разработанной Unicode.

    1. morphium_hidrochloricum, спасибо что проявили интерес к статье. Насчет нужного вам иероглифа…. Ну это, наверное, в Микрософт надо обращаться и желательно с гневными требованиями, я как понимаю у них тема с динамической генерацией нестандартизованных глифов похоже технически подзаглохла, а так все красиво и ясно начиналось… Ну лично для вас я просмотрю Unicode CJK- расширения, может и есть такой. Я вообще хотел бы у всех спросить, может быть кто-то хоть бы краем уха или глаза видел реальные примеры динамической генерации иероглифов. Я только статьи встречал, но там они такие корявые в примерах получались, и это были не True Type шрифты, а что-то типа самодельных векторных технологий. Лично я давно не наблюдал свидетельств существования таких технологий, тем более у TrueType. Как раз вот эта разница между “мечтой” и полным отсуствием ее реализаций в реальности в течение вот уже длительного времени, побудили меня поднять такую проблему в этой статье.

      1. Поиск иероглифа в мировом стандарте UNICODE
        ====================================
        Ideographic description = 王[LR]座
        Radical=王
        Total Strokes=14
        Additional Strokes=10
        CJ code = MGIOG
        Search
        ————————————————————–
        CJK Unifed Ideographs ………….100% NOT FOUND
        CJK Unifed Ideographs ExtA….100% NOT FOUND
        CJK Unifed Ideographs ExtB….100% NOT FOUND
        CJK Unifed Ideographs ExtC….100% NOT FOUND
        CJK Unifed Ideographs ExtD….100% NOT FOUND
        ————————————————————–
        Запрашиваемый Вами иероглиф отсутствует в
        Мировом стандарте.
        ————————————————————–
        …Это нестандартный иероглиф…
        …Это нестандартный иероглиф…
        …Это нестандартный иероглиф…
        …Это нестандартный иероглиф…
        (…Внимание…шшш…Группа зачистки, обнаружено отклонение от мирового стандарта…шшш…Принято…шшш…Вылетаем на место…). :)
        ====================================
        А если без шуток, то ваш пример показателен. Я действительно сейчас просмотрел все расширения. Его нет. Надо найти проект планируемого расширения Е, может в нем есть. А составляющие компоненты знака есть. И символ декомпозиции есть. Но ни в одном шрифтовом движке этого пока еще не внедрили. Вот так, обидно да…

  10. Уф… Всё исправил. Прошу простить меня, надеюсь я успел всё исправить вовремя. Технический сбой и обрыв текста пройзошёл как раз из-за того злосчастного гонконгского иероглифа “лифт” (даже боюсь теперь его здесь приводить). Он из расширения CJK Unicode Ext-B, а движок html-страниц, похоже, на нём регулярно спотыкается (как и на остальных из новой плоскости Юникода). Кстати, и знаки иероглифической декомпозиции тоже не воспринялись движком (на это раз повезло, обрыва текста не было). Я их заменял вот так например [LR], удобно и понятно.

    1. Я прошу прощения, что добавил иероглиф «лифт», мне показалось, что так нагляднее, но я не заметил никаких проблем от его добавления, ибо как эта статья, так и статья http://en.wikipedia.org/wiki/Written_Cantonese, из которой я его взял, отображаются у меня на компьютере полностью и без проблем, и движок html-страниц ни на нём, ни на других кантонских иероглифах не спотыкается.

      1. Я поясню. В момент отправки записи на утверждение произошел обрыв текста. Он происходил ВСЕГДА и после сохранения или отправки на утверждениев этом месте, пока я не убрал этот иероглиф из текста(он из расширенной плоскости Юникода). Т.е. это действительно системная, а не случайная вещь, и похоже присущая именно этому движку (я просто сейчас боюсь ставить такой эксперимент снова). И кстати, значки декомпозиции (2FF1-…) из обычной плоскости Юникода также (но без обрыва текста) превратились в точку. Это что-то в дивжке.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *