Собственно говоря, крупных проколов найдено два: неудачный выбор аббревиатуры кодировки (UCS) и неудачное решение с монолитностью оу.
Месяца через три после объявления о кодировке было обнаружено, что “UCS” имеет довольно распространенного тезку: Unified Character Set — базовое понятие из области Юникода. Фактически, это синоним Юникода. Позже мне на это начали указывать пользователи. Кроме того, в C++ Builder и Delphi имеются типы данных UCS2Char, UCS4Char, UCS2String, UCS4String... Короче, это не просто совпадение, а совпадение с распространенным сокращением. Обидно также, что его могло бы не быть, не сократи мы нашу аббревиатуру ради благозвучности. Unified Church Slavonic ENCODING, UCSE — таков был полный вариант названия, но мне не понравилось окончание на «Е» (вспомнилась «ПАСЕ"), и было оставлено только три буквы, тем более что проговаривались они гораздо проще.
Этот прокол — более тонкий, и в качестве частичного оправдания могу предъявить то обстоятельство, что проектировщики кириллической части Юникода также его допустили. Он имеется почти во всех известных мне «частных» церковно-славянских КШС и шрифтах. Короче, наступает на эти грабли подавляющее большинство. Моя собственная инерция была столь велика, что наткнулся я на этот прокол лишь совсем недавно, когда начал делать поддержку произвольной разрядки для UCS, и уже написал три четверти необходимого кода.
В чем заключается проблема? В UCS8 диграф «оу» во всех регистрах и лигатурах выполнен в виде единых, монолитных символов, занимающих по одному знакоместу. Между тем, это вполне очевидное решение является неправильным по целому ряду причин. Можно долго спорить, являются ли компоненты «о» и «у» из «оу» в ново-ЦС самостоятельными графемами, или же они настолько же неделимы, как, скажем, компоненты бывшей некогда двумя символами буквы «ы». При проектировании КШС семантика графических знаков не играет никакой роли и игнорируется, если она входит в противоречие с правилами отображения и форматирования символов в тексте выбранной письменности.
Попытаюсь объяснить это понятнее. Для наглядности я буду сравнивать «оу» с традиционно монолитным и сегодня, и в ново-ЦС символом «ы». Есть три существенных момента:
С точки зрения любой системы отображения и форматирования текстов «о» и «у» в «оу» ведут себя как отдельные символы. Любой из первых двух пунктов даже сам по себе будет являться веской причиной реализовывать компоненты отдельными символами.
В данном случае я не имею в виду более высокий уровень работы с текстами – ввод и редактирование. Здесь, возможно, для удобства пользователя придется связать эти компоненты, сделать поведение и реакцию системы на изнутри разъединенные компоненты такой, как если бы они составляли единый символ. Однако это вовсе не обязывает в шрифтах делать «оу» монолитными.
Далее, вопросы кернинга также не препятствуют разъединению диграфа «оу». Поскольку надстрочники в «оу» никогда не ставятся над «о», разрывающий кернинг-пару накладной надстрочник никогда не встретится между «о» и «у».
Новая кодировка не так уж сильно будет отличаться от старой: изменения коснутся лишь слов, начинающихся на «оу», в которых будет отсутствовать начальное «о». Поскольку на практике нелегко будет сразу разобраться, в какой кодировке набран текст: в новой или в старой, — лучше будет совместить обе предлагаемых реформы: замену аббревиатуры UCS и расчленение диграфа «оу». Замечу, что и после реформ старые тексты при установленных старых (ныне еще не старых, UCS) шрифтах останутся читаемыми.
Вне зависимости от того, будут ли приняты эти предложения или нет, все выявленные проколы однозначно необходимо учесть при разработке новых кодировок, — начиная с иного наименования и заканчивая, возможно, предложением корректирующего дополнения в Юникод по поводу «оу».