Есть постскриптовый шрифт. Как можно узнать ширину любого символа из его таблицы.  :-O Как значения увеличиваются. То есть при 6 пт ширина буковки "А" 1.126 мм. Сколько будет при 10 пт  :-?

Это сообщение было отредактировано:  Kassian, 12 Окт, 2004 г. - 23:03

Открываешь AFM-файл, -- первая и третья цифры твои. От третьей отнимается первая.

Например:
C 65 ; WX 722 ; N A ; B 0 0 722 708 ;

В данном случае, ширина буквы "А" -- 722 юнита.

или:

C 68 ; WX 759 ; N D ; B 79 0 718 708

718-79=639
Ширина буквы "D" -- 639 юнитов

Как увеличивается ширина, никогда не задумывался. Сейчас,в отличие от "железного" набора, все вроде бы делается простым умножением. Похоже, что при 10 пт твоя "А" будет иметь ширину 1,876 мм.
А зачем оно тебе?

Пишу прогу для кварка. Чтоб автоматизировать расстановку прайсовых строк.
Для этого необходимо узнать ширину и высоту шрифта при разных кеглях?
Можно было бы ручками выяснить сколько? Однако при этом убъется уйма времени. Надо ли...
У меня есть pfb и pfm файл. И узнать так просто не удалось.
первый - написал дап и далее ничего не понятно. Писаный бай ФонтЛаб
второй файлик еще более непонятный. Писаный бай ТайпМаркет. ;-)

PFM тебе тут не поможет.
В PFB не помню, есть ли метрики в зашифрованной части...
В AFM они все в открытом виде. Вот и думай.

Вспомнилось, -- вроде бы была утилита, которая расшифровывает PFB. Пошукай через Гугль или Яндекс.

А, что за шрифт?

Это сообщение было отредактировано:  Denis, 12 Окт, 2004 г. - 20:25

Есть они в PFB. Есть, например, такая програмуля Noah, которая позволяет их смотреть.
Кстати програмуля FontLab тоже их смотрит ;-)


Не, ширина - это значение WX.
А четыре числа после B - это какая-то заумная вешь, недоступная мозгу гуманитария. И вообще опциональная.
Кстати вообще все индивидуальные метрики в AFM файле опциональны. Они дублируют информацию из PFB.

aPANa
На сайте адобе.ком лежит pdf'ник Adobe Type 1 Font Format (T1_spec.pdf). По идее, в нем должно быть написано, как в PFB это кодируется.

ЗЫ.
  К сожалению, первое предупреждение за неинформативное название темы (исправил).

Нет-нет... я имел в виду вот эти цифры "79 0 718 708"

Первая -- величина левого полуапроша (от нулевой отметки до начала символа)
Вторая -- нижнее значение от нулевой отметки до начала символа
Третья -- от нулевой отметки до правого края символа
четвертая -- высота символа от нулевой отметки

Например:

"C 71 ; WX 778 ; N G ; B 47 -18 690 726 ; "

1. От нуля до левой границы символа G -- 47 юнитов
2. Свисание за нуль -- 18 юнитов
3. От нуля до правой границы символа -- 690 юнитов
4. Высота символа от _нуля_ -- 708 юнитов

Итого: высота символа -- 726, ширина -- 643

Есть сомнения?  ;-)

nik7777
Это да. Но тем не менее ширина кегельной площадки эксплицитно указывается в поле WX. Зачем тогда высчитывать по полю B ?
Кроме того, у пустого символа (Space) в поле B вообще будут одни нули.

Это да, но я так понял, что нужен точный размер каждого символа.
А так конечно можно по WX'у...

Получить ширину/высоту символа или текста не займет уйму времени. Смотря конечно на чем программировать, но вообще есть такие вещие как TextWidth
и TextHeight + параметры фонта (size,name). Либо считайте пропорции для символов (массив для каждого символа (ширина/высота), каждого использованного фонта).

Действительно, на адобе есть дока о том. как создаются пфм файлы. Раздел Extended text metrics  действительно совпадает с адобовским оригиналом. Далее все становится прикольнее. То есть Extent Table для кириллических шрифтов полностью разнится. Что я имею ввиду. Проги типа пфм2афм отображают неправильно ширины символов (с английскими шрифтами все ок!). То есть загружая прогу (например Кварк), она отображает совсем другие результаты.
Оказалось, что эти гады поменяли старший и младший байт ширинах. Почему-то они отличаются от спецификации адоба. Теперь прикол с керндатой. Наверняка адобовская спецификация опять таки была послана подальше и все символы опять-таки пришлось угадывать. А вот угадал их или проверить нельзя. Есть ли кириллическая спецификация, которая написана для всех однозначно. А не так каждый... захотел.
Расстояния считаются на самом деле тривильно. Действительно поле WX. Но оно не всегда правильно. Для уточнения заведена керндата. Если пара символов есть в керндате, то ширину можно уточнить. И тогда ширина строки будет точной (так утверждается). Если считать по полю WX, то небольшое отличие есть (например, с тем же Кварком).
Увеличение ширины за счет увеличения фонта является величиной пропоциорнальной и найти ее не составляет проблем. То есть простая пропорция позволяет получить точный результат.
Может есть какая-нибудь общая спецификация, которую все поддерживают. :-?

aPANa
М-да, с такими серьезными вопросами лучше обращаться к Henyk. Или прямо к YarYar (автор FontLab'а). Или у Фигурнову.


У Инди тоже отклонения будут? Подозреваю, что нет. Думаю, это локальная проблема Кварка.

2 aPANa

Здесь путаница. Ширина символа — это расстояние, на которое смещается текущая позиция на листе бумаги после вывода символа. Она задаётся в поле WX. То есть, при выводе символа смещение текущей позиции на листе бумаги будет равно WX * font size.

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

Хорошо, Виктор. Согласен, я не правильно выразился.  :roll: Я буду говорить о кварке (ИНДИ, пижама и т.д. могут считать по-другому).
_______________________       
Ширина символа — это расстояние, на которое смещается текущая позиция на листе бумаги после вывода символа. Она задаётся в поле WX.
_______________________
Хорошо. Да будет так. Возьмем некоторую строку из 10 символов. Чтобы просто складывалось из 5 символов "А" и 5 символов "Б". Кернинг отключаем. Получаем некоторое значение, например, 8004 юнитов. Переводим в пункты. Ставим эту строку в Кварк. Ставим ширину, соот. 8004 юнита. Замечательно в бокс это значение вошло.  :-P Мы долго радуемся.
Смотрим внимательно. Однако бокс можно было задать меньше. Вычисляем ширину минимального бокса, в который можно вписать наше слово.
Берем другой набор символов. Эффект повторяется. Как все таки правильно он считает.
Еще один занимательный вопрос. Дабы усложнить ситуацию. Ставим Track amount +5. Долго пришлось выяснять, что значит +5. Выяснилось, это значение +5 эм. И расстояние 1 эм, если верить народу, равно ширине двух нулей в данном шрифте деленное на 200. Хорошо посчитали - поставили. Замечательно в бокс попадает, но опять-таки с некоторой  небольшой разницей. Теперь меняем условия. Ставим отрицательное значение Track Amount, например -5. считаем он выдает ширину, которая в бокс просто не вписывается. То есть, для отрицательного значений он считает как-то по-другому.
Может ли мне кто-нибудь помчь в решении этой проблемы.