Incopy CS/CS2 и пропажа буквы ч

Всё, что будет описано ниже, относиться к шрифтам OpenType с расширением .otf и одной кодовой страницей. Тестирование проводилось в InCopy CS и CS2.

Случилось так, что переданный заказчику шрифт, категорически отказывался работать в InCopy CS, а если точнее, работал до тех пор пока не встречалась строчная «ч». Как только клиент пытался набрать строчную «ч» в режиме Layout, вместо «ч» печатался знак деления - divide.

В Story можно было спокойно набрать строчную «ч».

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

Ранее я с такой ситуацией я не сталкивался ввиду того, что мало кто работает в InCopy, а уж заказывает шрифты и подавно. Получив необходимую информацию, создал виртуальную машину с WinXP, именно она была у заказчика, скачал с сайта Adobe демку InCopy CS2 и приступил к тестированию.

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

Удаляю знак divide из новой версии шрифта, тестирую – баг отсутствует. Ура победа! Однако, это полумера, а это мне не интересно...

Открываю работающий шрифт от Adobe (взял standard, так как он более всех ближе по составу знаков к двум предыдущим шрифтам), начинаю сравнивать: в родном шрифте Adobe, знаков немного больше.

«Хватаясь за соломинку», создаю в неработающем шрифте эти знакоместа. Начинаю тестировать – не работает, значит состав знаков тут не при чём. Единственное место где можно поискать разгадку, это значения таблиц cmap, но FLS мне в этом не помощник, так как не показывает значения cmap, значит для этого понадобиться более тонкий инструмент – TTX.

TTX способен декомпилировать шрифт и представить его содержимое в виде xml кода.

Декомпилирую шрифт и начинаю изучать значения cmap, на первый взгляд всё как и в моём шрифте. Нет – в cmap 6, значение Encoding ID = 7(!), а у моего ID = 0.

Снова открываю мой шрифт в FontLab-е, иду в FontInfo > Additional [cmap] tables, генерирую значения автоматически, нажав на кристалл.

Меняю значение EID с 0 на 7, и сразу понимаю почему именно 7 - на против значения 7, стоит Russian. Тестирую шрифт – баг исчез!

Отлично, победа!

На всякий случай, декомпилирую шрифт с приставкой PRO – нет, значение EID у него равно «0», значит проблема только у одно страничных шрифтов. Хм, а в спецификации об этом ничего нет!

Через пару месяцев проблема вернулась – заказчик захотел добавит в шрифт знаки расширенной латиницы. Проводя аналогию со шрифтами с приставкой Pro (многостраничными), я не стал использовать этот хак, и как выяснилось зря. Во время тестирования в InCopy, проблема с «ч» появилась снова, пришлось опять применять этот хак.

Как удалось выяснить из экспериментов, баг появляется в том случае, если в шрифте одновременно не присутствуют четыре кодовые страницы: cp1250, cp1251, cp1252 и cp1253, для всех остальных случаев хак не нужен.

В завершении, хотелось бы отметить, что в версии CS3 и выше, этот баг уже отсутствует.
Приятной работы!

• fontlab5
• статьи о шрифтах