Re: OpenOffice
Victor B. Wagner wrote:
On Sun, 24 Feb 2002, Aleksey Novodvorsky wrote:
В том то и дело, что приведенная Вами конструкция используется
повсеместно. И для меня не очевидно, что
(некоторый кусок текста) glyphshow
развернется в конструкцию длиннее
Для меня очевидно, что имя глифа для кириллицы занимает в файле
примерно в 10 раз больше места, чем один символ.
Неочевидно :-)
То есть, если у Вас один вектор кодировки, соответствующий реальной
восьмибитной кодировке -- да.
Но обычный случай -- несколько векторов, в которых глифы идут в порядке
появления, а тогда в (....) попадет не символ, а его номер.
Конечно, остается еще "afii" , но это уже не на порядок больше. Если же
учесть необходимость хранить сами векторы с именами глифов, то на
небольшом тексте получаем выигрыш для glyphshow.
И неочевидно
как это сократить.
А начавши рассматривать PS-программы от gs я наткнулся там на вот
такой комментарий:
% We have to define BuildChar rather than BuildGlyph:
% there is no PDF equivalent of glyphshow, and we need
% the character code to access the Widths.
Может для печати из Мозиллы это и некритично, а вот для
генерации PS вообще пригодность для дистилляции критична крайне.
Надо смотреть. Часть фразы полсе запятой выглядит крайне сомнительно,
похоже что это именно то, о чем мы говорили здесь в связи с парсером.
Для access to the Widths совершенно не обязателен character code.
Возможно, что имеющиеся проблемы с генерацией pdf связаны с этим
заблуждением.
исключительно примитивен и легко читаем. Скорее всего, это увеличивает
время интрепретации, но в реальной жизни я этого не наблюдал.
Кстати, я тут подумал, что интересным подходом к генерации PS
является тот, что применен в html2ps. Этот скрипт не читает afm-ок
вообще. Тем не менее параграфы выравниваются, переносы делаются
и буковки друг на друга не наползают.
Сейчас нет под рукой. Вообще говоря, отдельный afm нужен только в том
случае, если в системе нет pfb(a). Да и вывод глифов одной "фразы" (то
есть фрагмента, выводимого относительно некоей точки) всегда будет
выглядеть корректно, без наползания (но, возможно, с выходом за границу
листа).
Размер файла в реальной жизни иногда тоже бывает значим.
Размер можно сильно уменьшить, если посдставлять имена глифов при
генерации ps, а не в самой ps-программе.
То есть с точностью до наоборот? Из общих соображений чем больше
работы мы делаем до генерации PS, и чем меньше - внутри PS-интерпретатора,
тем больше файл.
Большой файл -- да. Маленький -- нет, так как в ps надо включать векторы
или таблицу glyphs<->unicode.
Вообще, а не возродить ли список cyrfonts? Похоже пошла вторая волна
идеологически правильной кириллизации. Первая была - создание
хоть каких-нибудь свобоных кириллических шрифтов. Теперь такие
шрифты есть - и URW, и sharatype, и cm-super. Дело за малым - научить
все заслуживающие внимания программы корректно с ними работать.
Мысль хорошая, но прорыв здесь будет если и только если удастся те же
свободные URW с кириллицей поселить в mainstream. В Rawhide они уже
есть. Что же касается gs-fonts, то Raph тормозит процесс без объяснения
причин. Даже Столлмен не может его продавить.
Rgrds, AEN
Reply to: