Illustrator, Шрифты и Fontlab

Shlyapa wrote:
> Ага, не за горами круглая дата — начало наведения порядка
> MS-ом, первым шагом к которому было введение ещё одной
> Codepage для кириллицы.
какие codepage? причем тут они? есть unicode.

> выходом Win95
а причем тут эта ос для домохозяек? вроде форум серьезный.

> А потом не заставил себя ждать и MSO «юникодный».
а сним какие проблемы?

> И шрифты системные, RIP-ами неперевариваемые…
вот давайте приведем риальный пример. файлик, желательно оригинал, который который на рипе не рипуется.

> > …драйвер (тот который atmfd.dll) для тупе 1 и otf шрифтов
> видит кернинг только для первых 256 символов…
> Можно подробнее? Или ссылки?
---
ATM (and also the Windows CFF handler from Adobe) decompiles GPOS kerning
into flat pairs for non-OT savvy apps. Because the potential number of
decompiled kerning pairs in a large multilingual font is huge, ATM subsets
the kerning for Windows CP 1252 only, which is why you are not getting any
kerning for Cyrillic OTF fonts.

You should see all the kerning working correctly in an OT-savvy app like
InDesign, which directly accesses the GPOS kerning.
---
и вообще - это в рассылке сотню раз обсуждалось - и даже ты там в обсуждениях засветился.

 

> вот давайте приведем риальный пример. файлик, желательно оригинал, который который на рипе не рипуется.
> и вообще - это в рассылке сотню раз обсуждалось - и даже ты там в обсуждениях засветился.

Вот именно туда я и засылал скриншот с RIP-а с классическим примером обработки Aril-а.
Если лень в архиверыться, могу с лёгкостью воспроизвести, поскольку не зря я пример классическим назвал — он 100% воспроизводим в воспоизводимых условиях (определение научности методоа помнишь, пусть не дословно?).

 

> Какая к черту реальная юникодность? Илл 10.0.3 (не СЕ), шрифт адобовский OTF, в списке пишет, например, Minion Pro - Cyr, в наборе кириллицы нет.

Однако, не это ли я имел в виду, говоря «…Adobe с её технологией (пусть пока ещё и не небезупречной)…», ИМЕЯ В ВИДУ , что «в не-CЕ версиях адобовского софта работа с кириллицей даже не декларируется».

И потом, что теперь о 10-м говорить? Дело прошлое. CS актуален, а у него с этим делом уже ГОРАЗДО лучше.
FH ведь вы тут самый свежий шрифтами мучаете, отчего ж не 10-й?

Об этом уж было много-много раньше — by default обсуждаются и сравниваются самые свежие версии (релизы) софта.

 

В 10-м Фрихе юникоде не работал вовсе, его и мучать не нужно было. А все остальное у него работало нормально. МХ - первый юникодный Фрих, оттого и проблемы. А когда юникоде появился в Илле?

 

ой - я не помню. а из какой программы вывод был?

 

опа. это в каком месте в mx есть уникод? поподробней можно?

 

Я понимаю юникодность как возможность работать с кириллицей в юникодных шрифтах без дополнительных телодвижений (наверно, есть и другие определения). С этой точки зрения МХ нормально работает с кириллицей системными юникодными шрифтами и адобовскими OTF. Но юникодность у него, как бы сказать, необычная, сильно зависит от ОС (судя по всему), а потому кириллицу в юникодных шрифтах он видит, а вот расширенную латиницу не видит. Ну и всякие заморочки с Тайп1-шрифтами. Над этим и бьемся.

 

уникодность - это нормальная работа с любым глифом из уникодного шрифта.

и кстати в aics с этим все в порядке.

 

> А когда юникоде появился в Илле?

Вроде, ещё в 9-м, но «раскачался» по-хорошему только к CS-у.

==================

>> А потом не заставил себя ждать и MSO «юникодный».
> а сним какие проблемы?

Ну как же?! Не помнишь?
То был звёздный час TTFCONV.EXE.
Его испражнения по сей день разребаются, никак не разгребутся (у большинства).

==================

> ой - я не помню. а из какой программы вывод был?

Не суть важно.
Ключевыми параметрами там являются PPD и RIP (версия RIP-а).
Некоторые PPD менее «устойчивы», другие более.
И чем старее RIP, тем проблем больше, но чтобы лицезреть классический пример глючного вывода TTF-а, RIP нужен не такой уж и старый — арлекиновский 2000 года. На более старых вообще кранты, однако, это я уж только по памяти. Старее Express RIP 5.3 у меня RIP-ов на компе нет, но и на нём глюки воспроизводятся просто замечательно.

К тому же, во множестве TTF-ов стоит запрет на внедрение. Это мы тут собрались, отчаянные font-ковыряльщики, но в подавляющем-то большинстве случаев люди шрифты не ковыряют, и потому с такими шрифтами вывод вообще не возможен.

 

>Вроде, ещё в 9-м, но «раскачался» по-хорошему только к CS-у.

Ну вот, у Фриха есть еще две версии в запасе

 

Я не спорю. Это у МХ так, первый шажок (вопрос куда).

 

> Ну вот, у Фриха есть еще две версии в запасе

Нет у него никакого запаса. Закон Мура помнишь? В данном случае он вполне применим, я думаю.
(Как у отечественной Hard & Soft индустрии был запас… Тю-тю, где она, индустрия-то?)

 

Shlyapa wrote:

> >> А потом не заставил себя ждать и MSO «юникодный».
кстати - к чему здесь кавычки?
> > а сним какие проблемы?
> Ну как же?! Не помнишь?
> То был звёздный час TTFCONV.EXE.
и что??? если шрифтолабатель с кривыми руками не туда запихнул русские буквы, то виновата ms?

> > ой - я не помню. а из какой программы вывод был?
> Не суть важно.
ну почему же? или у нас весь софт абсолютно прямой?

и я не понял. ты как-то съехал с системных ттф, на ттф в целом.

 

Поживем - увидим. Последние года 3 фрих хоронят, а он как огурчик (не сглазить бы).

 

> ну почему же? или у нас весь софт абсолютно прямой?

Да потому же! Не имело никакого значения (большого значения) из чего PS делать, но огромно е значение — какие шрифты использовались. Если там был Arial — глюк проявлялся сразу.

> и я не понял. ты как-то съехал с системных ттф, на ттф в целом.

Вполне логично. Но если хочешь, можем притормозить пока только она системных. (Правда, мне придётся специально всякие опыты с ними ставить, чтобы память освежить — уж очень давно я их в своей работе не использую, если на выходе PS/EPS/PDF.)

 

Shlyapa wrote:
> Если там был Arial — глюк проявлялся сразу.
а если arial заменить на какой либо другой ttf - глюк исчезнет?

> Вполне логично.
не вижу логики. я сам могу согласится, что _любой_ ttf может проглючить на определенной связке софт+рип. но ты везде кричишь о глобальной глючности именно системных ттф-ов. у меня это вызывает некоторое недоумение.

 

zg wrote:
> не вижу логики. я сам могу согласится, что _любой_ ttf может
> проглючить на определенной связке софт+рип. но ты везде
> кричишь о глобальной глючности именно системных ттф-ов. у
> меня это вызывает некоторое недоумение.

Подписываюсь под каждым словом. Никаких особенностей у системных шрифтов, отличающихся от спецификации TrueType мне не известно.
Таким образом системные шрифты - это тот же TrueType.
Не хочу ввязываться в спор с упертым человеком, но скажу, что мне доводилось делать постскрипты (в т.ч. из Ворда) с использованием больших (многораскладочных) ttf, сдавать их на фотовывод и получать нормальные пленки.

Дело не в шрифтах, а в руках.

 

> но ты везде кричишь о глобальной глючности именно системных ттф-ов. у меня это вызывает некоторое недоумение.

Это у меня вызывает недоумение, что ты недоумеваешь?

Можно подумать, я один «кричу». Весь форум исписан. Сейчас ты скажешь, что тут через один мой ответ. Хорошо, сходи на любой другой русскоязычный сайт (форум) по ДПП, и прочитай там всё то же самое о системных шрифтах, что пишу я (да не так уж и многоя об этом пишу, не преувеличивай).

Глючны не сами системные шрифты, а то, как они вписываются в рабочий процесс, построенный на разном софте.
Ну, и плюс некоторые свойства самих системных шрифтов, конечно же.

1. Они юникодные, в отличие от подавляющего большинства ходящих по рукам TTF-ов. Если эти TTF-ы большинство софта ещё может нормально записать в PS (EPS, PDF), то с Unicode справляется далеко не всякий софт. И AI 10 тому пример, раз уж мы в AI-шной ветке (оговорка означает, что и многих других программах можно сказать то же самое).

2. Если софту, таки, удаётся записать Unicode в PS, он там, как правило, в т.н. CID-е. (Често говоря, теорией этого дела я владею слабо, потому обо всём здесь в сугубо практическом свете.)
Эти вот CID-ы далеко не каждым RIP-ом принимаются.
И Distiller далеко не всякий PS с этим делом внутри перегоняет в PDF. И PDFWriter тоже. А сечас и нет никакой разницы Distiller и PDFWriter — в Acrobat 6 они одном флаконе.

3. Системные шрифты — TTF-ы, то есть кривыми описаны… как их там…, в общем, не Безье, не PostScript.
Именно отсюда проистекает легко воспроизводимый глюк, о котором я говорил выше — некоторые буквы (на вскидку, что помню — «э» и «Э» в Arial-е) отрисовываются RIP-ом не то, что неправильно или некрасиво, а просто чудовищно.

4. Системные шрифты Win9x и Win2000/XP (а NT4 уже плохо помню) — это далеко не одно и то же, однако имеют практически одни и теже имена, что худо для переноса с компа на комп, с платформы на платформу. Разве не видел ты, zg, как превращается в крякозбрики текст, красиво выглядивший на одном компе, при открытии на другом.
Даже если такой файл упаковывают и передают вместе со шрифтами, много от этого проку? Кто из присутствующих заменял свои системные шрифты на принесённые вместе с нетленкой из-под другой Винды?

Если бы не эти пункты (и еще какие-нибудь мелочи, которые я сейчас упустил), то разве я возражал бы против системных шрифтов? И не я один, подчёркиваю.

> Подписываюсь под каждым словом. Никаких особенностей у системных шрифтов, отличающихся от спецификации TrueType мне не известно.

Не спеши подписываться.
Чуть ни в каждом из вышеизложенных пунков (через один, по крайней мере) находит отражение отличие системных шрифтов от обычных, широкораспространённых TTF-ов. Много вы знаете TTF-ов, таких же навороченных несистемных? Чтобы и Unicode, и множество языков внутри, и OTF-фичи (которые в системных шрифтах КАК БУДТО бы есть)? Я, например, ни одного такого не знаю.

> Дело не в шрифтах, а в руках.

Где-то подобное я уже слышал…
Не всё в руках, многое объективно и руками непреодолимо.
Вот поставлю я тебе жёсткое условие: использовать только некиий конкретный PPD, только некий конкретный RIP и только указанной версии. И всё, опустишь ты свои золотые руки — PS с системным TTF-ом внутри невыводим.
В других услових выводим, но глючен.
И я сам готов привести примеры условий, когда выводим без глюков.

И Type1 разные бывают, и тоже глючат порой. Но соотношение в десятки, если не сотни раз в пользу Type1, в десятки раз в пользу обычных TTF-ов, против системных. Это из практики, и не только моей, а не из каких-то и чьих-то пристрастий.

> что мне доводилось делать постскрипты (в т.ч. из Ворда) с использованием больших (многораскладочных) ttf, сдавать их на фотовывод и получать нормальные пленки.

И мне доводилось. И тоже нормально. И из Корела выводы безглючные мне делать доводилось. Но как-то не воодушевляет сей факт на то, чтобы делать это каждый день.
Каждый день другими шрифтами в другом софте как-то ловчее. НЕ У МЕНЯ ОДНОГО.

 

Shlyapa wrote:
> Каждый день другими шрифтами в другом софте как-то ловчее. НЕ
> У МЕНЯ ОДНОГО.

С этим никто не будет спорить, но только ты кванторы в своих высказываниях все время меняешь.

С ttf бывает больше проблем. С многоязыковыми ttf проблем еще больше (заметим, что сюда же примыкают и многоязыковые otf - у них такая же юникодная организация).

Но говорить о "глобальной" непригодности ttf для полиграфии - некорректно.

 

я все о злополучной WindowsCharSet в inf... ну прямо тайна скрытая мраком

T1_SPEC.PDF
5013.Cyrillic_Font_Spec.pdf
5004.AFM_Spec.pdf
5178.PFM.pdf

-- нет такой буквы в этих словах. Адоб пишет, что это то же, что байт 055h в файле pfm. И далее, что этот формат (pfm) поддерживается микрософтом, пожалуйста к нему. На микрософте нету. В гугле среди прочего только слова о том что "и я не нашел на микрософте" или мертвые ссылки.

единственное что я нашел на адобе, это что арабский виндоуз 3,11 считывает этот байт чтобы понять, надо ли поместить шрифт среди поддерживающих арабский язык

некий любитель на хоумпаге, посвященной символу евро в шрифтах (мда, солидный ресурс)

homepages.fbmev.de/bm134751/inf_fmt_en.html

пишет, что

-----------------------------
WindowsCharSet <number>
needed for non latin-1 fonts; this value gives the character set for the font, possible values are:

value character set
0 code page 1252 (Western Europe)
2 Symbol character set
161 code page 1253 (Greek)
162 code page 1254 (Turkish)
177 code page 1255 (Hebrew)
178 code page 1256 (Arabic)
186 code page 1257 (Baltic)
204 code page 1251 (Cyrillic)
222 code page 874 (Thai)
238 code page 1250 (Central Europe)
---------------------------------

И всё!

Что такое LOGFONT.lfCharSet я представляю, но это же совсем из другой оперы, работа со шрифтами в GDI, афаик, и как это связано с поддержкой кернинга в шрифте тем или иным софтом -- не понимаю