Благодарю всех за ответы и участие в обсуждении.
Уважаемый
Макар.Н.Насчет произвола. Конечно, в плане унификации иероглифики без произвола не обойтись. Но для нас (тех, кто не вырабатывает стандарты), рано или поздно, придется подстроиться хотя бы частично под эти самые стандарты (их вырабатывают те, кто «рулят»). Касательно 伙(huo3) U+4F19 в Юникоде это как раз ключ (КанСи - №9) (человек). В NanJi Star это просто ляпсус. Это свидетельствует о том, что, скорее всего, в основе сортировок у них была не Юникодовская кодировка, а стандартные GB2312 и Big5. Вот уже иллюстрация удобства стандартизации – готовая сортировка по ключам и строкам. Хотя я сам лично все 20902 иероглифа CJK Unifed Ideographs проверял в плане принадлежности к ключам и числу строк – есть неоднозначности в плане принадлежности к ключам (пример – 龝) и строкам с точностью до ±2 строк в зависимости от начертания в шрифте (Сун, Хей, Мин, Японск, Кор и т.п.) – произвол однако. В настоящее время наиболее четкая концепция стандартизации наблюдается у стандарта Юникод. Ведь мало выбрать во всяких древних словарях и закодировать по порядку кучу редчайших знаков, но они еще и выработали XYZ CJK концепцию подстановок и эквивалентности знаков. Именно отсюда идут так называемые Z-варианты – исторически разное написание одного и того же знака.
По поводу экономности ввода. Я исследовал в плане информационной емкости на разных выборках текстов кит. оригинала и русс. перевода. Так вот, получается, что один ханьцзы соответствует в среднем примерно нашим 4–4,5 буквам. Т.е. 4 нажатия клавиш ввода однобайтовых символов как раз и являются тем чисто информационным пределом. В ЦанЦзе, кстати, максимум распределения длины записей кодировки также соответствует четырем нажатиям на один иероглиф. В УБи, также пиарят ввод в 4 нажатия. Boshiamy, Array30, DaYi – тоже длина кодировки не более 4 символов.
А по третьему вопросу экономность сама говорит за себя - 2 клика на 90 % иероглифов
Ну, если указывать декомпозицию, то это 3 клика. И опять если 2 клика из списка (таблицы) 100-200 знаков, то это победа только для «мышиных» систем ввода, а не клавиатурных. Декомпозиция, согласен, это уже излишество в Вашем варианте системы ввода – тогда чаще 2, реже три клика без декомпозиции. Мне очень понравилось, что проблему неоднозначности декомпозиции Вы решаете просто и изящно при помощи одного модификатора. Только бы не возникло ситуаций, где надо снять неоднозначность 2-3 модификаторами подряд, но я уже вижу, это действительно будут редкие случаи. По принципу сокращения длинной цепочки кодировки «первый, второй, последний» - это та же самая ЦанЦзе, только не с алфавитом из 25 знаков, а существенно большим – более 200. У Вашего подхода действительно есть серьезные перспективы. Только может в плане сортировки таблицы «ваших» ключевых знаков нужно что-то поменять. Подойдут классическая сортировка по числу черт, сортировка по «многонаселенности» ключа (рекордсмен тут ключ «вода» - нереально много знаков, более 1000). Сортировка по частоте использования для ключевых знаков, даже не могу сказать – подходит ли она? Также стоит в таблице унифицировать варианты ключей.
что бы ни глаголили стандарты, "нож сбоку" и "нож сверху" графически совершенно разные элементы, и вижу я их по-разному.
Вот тут то и нужна оптимизация. Действительно, если в Вашей системе начать объединять варианты ключей, то попрет неоднозначность декомпозиции, которую модификатором уже не выправишь. Но излишняя подробность в описании графических вариантов одного и того же «малозаселенного» ключа тоже нагружает мозг. Я кстати благодаря Wenlin4 и Вашей структурной иероглифике начинаю понимать глубокую связь между графическими вариантами, которые ранее вообще не мог связать между собой, считая их какими-то вымершими ключами. А это улучшает мнемонику запоминания иероглифа.
Вообще, проблема в том, чтобы система ввода с одной стороны не была излишне подробной – возрастает длина строки ввода (число нажатий на один знак), но с другой стороны излишнее упрощение системы приведет к неоднозначности списка выбора, состоящего в отдельных ситуациях из 10-20 знаков, что терпимо, но не совсем желательно. Именно ЦанЦзе имеет оптимальную неоднозначность списка выбора максимум в 3-4 иероглифа и то – очень редко.
С моим подходом (см. мои посты в теме выше) у меня получается с использованием элементов ЦанЦзе длина строки ввода не более 5 символов (ключ(1-2 символа), декомпозиция(1 символ-разделитель), неключевая часть (1-2 символа)). Но однозначно закодировать стандартный радикал двумя символами из алфавита ЦанЦзе не получается. Иногда неоднозначность доходит до трех. Я думаю, может подключить иную систему морфологического ввода, хотя и там не гарантируется однозначность кодирования именно радикалов. Поэтому пока я частично признаю фиаско клавиатурных методов по части реализации систем ввода на основе ключевых знаков. Тут, наверное, придется обходиться только мышкой.