> кванторы
Что это?
Опечатка, эвфемизм или слово, мне незнакомое?
> Но говорить о "глобальной" непригодности ttf для полиграфии - некорректно.
Ты сказал «глобальной». Я этого слова не говорил. Я всегда говорю (в разной форме), что если не хочешь иметь проблем, не используй TTF, тем более системных.
Эта формала, во-первых, не противоречит твоим утверждениям, что и TTF-ами, даже системными, можно нормально работать, во-вторых, эта формула эффективна и полезна во многих отношениях, к собственно шрифтам имещих лишь косвенное отношение.
> заметим, что сюда же примыкают и многоязыковые otf - у них такая же юникодная организация
Но у них есть один большой плюс — они описаны кривыми Безье, что снижает вероятность глюков хотя бы в части отрисовки буковок.
И кстати, ни разу не было у меня глюков на выводе с CFF-OTF.
Знаешь такие шрифты:
AdobeMingStd-Light-Acro.otf
KozGoPro-Medium-Acro.otf
KozMinPro-Regular-Acro.otf
KozMinStd-Regular.otf
Это китайские и японские адобовские CFF-OTF-ы. Unicode в полный рост. Многоязычность рядом с этим, по-моему, детский лепет — столько там внутри глиф (иероглифов).
Так вот, и работается ими, и в PS (EPS, PDF) выводится, и RIP-уется без даже намёка на глюки. Вот только софтом не всяким… Я, например, работал и выводил адобовским.
А вот
MSGOTHIC.TTC
MSMINCHO.TTC
SIMHEI.TTF
их MS-овские аналоги в TrueType-OTF. Они тоже, в общем-то, работоспособны, но ведут себя несколько капризнее. Случайно ли, имеет ли это отношение к TTF, или дело в разаботчике — не знаю, но факт остаётся фактом. (Строго говоря, они не MS-овские, но MS-ом распространяются.)
Что это?
Опечатка, эвфемизм или слово, мне незнакомое?
> Но говорить о "глобальной" непригодности ttf для полиграфии - некорректно.
Ты сказал «глобальной». Я этого слова не говорил. Я всегда говорю (в разной форме), что если не хочешь иметь проблем, не используй TTF, тем более системных.
Эта формала, во-первых, не противоречит твоим утверждениям, что и TTF-ами, даже системными, можно нормально работать, во-вторых, эта формула эффективна и полезна во многих отношениях, к собственно шрифтам имещих лишь косвенное отношение.
> заметим, что сюда же примыкают и многоязыковые otf - у них такая же юникодная организация
Но у них есть один большой плюс — они описаны кривыми Безье, что снижает вероятность глюков хотя бы в части отрисовки буковок.
И кстати, ни разу не было у меня глюков на выводе с CFF-OTF.
Знаешь такие шрифты:
AdobeMingStd-Light-Acro.otf
KozGoPro-Medium-Acro.otf
KozMinPro-Regular-Acro.otf
KozMinStd-Regular.otf
Это китайские и японские адобовские CFF-OTF-ы. Unicode в полный рост. Многоязычность рядом с этим, по-моему, детский лепет — столько там внутри глиф (иероглифов).
Так вот, и работается ими, и в PS (EPS, PDF) выводится, и RIP-уется без даже намёка на глюки. Вот только софтом не всяким… Я, например, работал и выводил адобовским.
А вот
MSGOTHIC.TTC
MSMINCHO.TTC
SIMHEI.TTF
их MS-овские аналоги в TrueType-OTF. Они тоже, в общем-то, работоспособны, но ведут себя несколько капризнее. Случайно ли, имеет ли это отношение к TTF, или дело в разаботчике — не знаю, но факт остаётся фактом. (Строго говоря, они не MS-овские, но MS-ом распространяются.)
интересные ссылки
>>> который, как утверждается оказался новостью для специалистов Adobe
мать-перемать, вот они самородки доморощенные с новостями для адоба и для всего мира. Поправили байтик, и у них в ворде-2000 в 98м винде стали русские буковки видны. От оно счастье какое! А то что кернинга при этом в кварке и пейдже не стало, так это они не заметили -- а начхать. И во всех новых шрифтах в инфе 204, а все ради домохозяек и секретарш с бэ-ушными пентиум-1. И я как идиот почти два дня трахался. Как я зол. Alex Stepanov по сравнению с ними просто отдыхает..
>>> который, как утверждается оказался новостью для специалистов Adobe
мать-перемать, вот они самородки доморощенные с новостями для адоба и для всего мира. Поправили байтик, и у них в ворде-2000 в 98м винде стали русские буковки видны. От оно счастье какое! А то что кернинга при этом в кварке и пейдже не стало, так это они не заметили -- а начхать. И во всех новых шрифтах в инфе 204, а все ради домохозяек и секретарш с бэ-ушными пентиум-1. И я как идиот почти два дня трахался. Как я зол. Alex Stepanov по сравнению с ними просто отдыхает..
Ещё ссылка:
http://www.orthonord.orthodoxy.ru/fonts/winfonts.htm
В общем-то, то же самое, что и по уже приведённым.
======================================
У меня вот вопрос возник.
В самодельном CFF-OTF, деланном FL4.6, не рабают НИКАКИЕ кернинговые пары НИГДЕ. А в Type1, сгенерированным из того же самого FL-проекта, всё работает и для руссского, и для английского (в InDCS, в AICS).
Где ковырять?
http://www.orthonord.orthodoxy.ru/fonts/winfonts.htm
В общем-то, то же самое, что и по уже приведённым.
======================================
У меня вот вопрос возник.
В самодельном CFF-OTF, деланном FL4.6, не рабают НИКАКИЕ кернинговые пары НИГДЕ. А в Type1, сгенерированным из того же самого FL-проекта, всё работает и для руссского, и для английского (в InDCS, в AICS).
Где ковырять?
>И во всех новых шрифтах в инфе 204
У меня после всех этих экспериментов с 204 и новыми версиями старых шрифтов кварк вообще перестал видеть Прагматику. Это, так, частности. Но вывод печальный - подобные эксперименты могут отразиться в самых неожиданных местах. В этой стране порядка нет нигде.
Кстати, этот Дмитрий Юнов, очевидно, не сам придумал эти волшебные слова, где-то нашел.
У него есть и еще кое-что:
Цитата:
PSS. Также согласно пониманию Adobe для Cyrillic and CE INF файлов шрифтов значения должны быть:
По моим данным, это ни на что не влияет, кроме старого Adobe Type Foundary, но рекомендуется этому следовать. Для других языков эти сеттинги не приведены к стандарту.
для MS ANSI 1251 Cyrillic
<...>
CharacterSet (cyrillicreg.cs)
Encoding (cyrillic.enc)
<...>
для MS 1250 CE (Eastern Europe)
<...>
CharacterSet (ce.cs)
Encoding (ce.enc)
(Конец цитаты)
Так вот, в имеющемся у меня шрифте PragmaticaE (т. е. для СЕ) написано так:
CharacterSet (charset.ps)
Encoding (ascencoding.ps)
А для кириллической ПрагматикиС наборы вообще произвольные от
CharacterSet (cyrillicreg.cs)
Encoding (cyrillic.enc)
до
CharacterSet (custom)
Encoding (SpecificEncoding),
причем волшебные строки гуляют от просто
WindowsCharSet 204
до полноценных
WindowsCharSet 204
WindowsFirstChar 32
WindowsLastChar 255
Это совершенно родные лицензионные шрифты от Паратайпа выпуска примерно 1999 г.
У меня после всех этих экспериментов с 204 и новыми версиями старых шрифтов кварк вообще перестал видеть Прагматику. Это, так, частности. Но вывод печальный - подобные эксперименты могут отразиться в самых неожиданных местах. В этой стране порядка нет нигде.
Кстати, этот Дмитрий Юнов, очевидно, не сам придумал эти волшебные слова, где-то нашел.
У него есть и еще кое-что:
Цитата:
PSS. Также согласно пониманию Adobe для Cyrillic and CE INF файлов шрифтов значения должны быть:
По моим данным, это ни на что не влияет, кроме старого Adobe Type Foundary, но рекомендуется этому следовать. Для других языков эти сеттинги не приведены к стандарту.
для MS ANSI 1251 Cyrillic
<...>
CharacterSet (cyrillicreg.cs)
Encoding (cyrillic.enc)
<...>
для MS 1250 CE (Eastern Europe)
<...>
CharacterSet (ce.cs)
Encoding (ce.enc)
(Конец цитаты)
Так вот, в имеющемся у меня шрифте PragmaticaE (т. е. для СЕ) написано так:
CharacterSet (charset.ps)
Encoding (ascencoding.ps)
А для кириллической ПрагматикиС наборы вообще произвольные от
CharacterSet (cyrillicreg.cs)
Encoding (cyrillic.enc)
до
CharacterSet (custom)
Encoding (SpecificEncoding),
причем волшебные строки гуляют от просто
WindowsCharSet 204
до полноценных
WindowsCharSet 204
WindowsFirstChar 32
WindowsLastChar 255
Это совершенно родные лицензионные шрифты от Паратайпа выпуска примерно 1999 г.
> Как я зол.
Из прочитанного по сылкам, я заключил, что в общем-то так оно и должно работать. Хорошо это или плохо, радостно или грустно, но так оно всё устроено. То есть, не глюки это и не баги, а нормальная штатная работа всех звеньев цепи.
Долго раскачивались разработчики разного софта, в том числе и сами разработчики спецификаций, принятых аж 1998 году.
Но раскачались, и кто-то стал подтягиваться (FL, InD, AI, PhS и т.д.), а кто-то застрял на уровне технологий начала-средины 1990-х (PM, Кварк и т.д.).
PM-у это простительно — он давно уж в стороне от адобовского мэйнстрима, но Кварк-то! Фирма одной софтины, и, казалось бы… — а что в итоге?
==============================
Но давайте о кернинге в CFF-OTF поговорим — гораздо злободневнее это, чем кернинг в PM & Co.
(А то, может, открыть новую тему этим вопросом, а то эта уж очень долго загружается уже?)
Из прочитанного по сылкам, я заключил, что в общем-то так оно и должно работать. Хорошо это или плохо, радостно или грустно, но так оно всё устроено. То есть, не глюки это и не баги, а нормальная штатная работа всех звеньев цепи.
Долго раскачивались разработчики разного софта, в том числе и сами разработчики спецификаций, принятых аж 1998 году.
Но раскачались, и кто-то стал подтягиваться (FL, InD, AI, PhS и т.д.), а кто-то застрял на уровне технологий начала-средины 1990-х (PM, Кварк и т.д.).
PM-у это простительно — он давно уж в стороне от адобовского мэйнстрима, но Кварк-то! Фирма одной софтины, и, казалось бы… — а что в итоге?
==============================
Но давайте о кернинге в CFF-OTF поговорим — гораздо злободневнее это, чем кернинг в PM & Co.
(А то, может, открыть новую тему этим вопросом, а то эта уж очень долго загружается уже?)
>Из прочитанного по сылкам, я заключил, что в общем-то так оно и должно работать. Хорошо это или плохо, радостно или грустно, но так оно всё устроено. То есть, не глюки это и не баги, а нормальная штатная работа всех звеньев цепи.
В статье по твоей ссылке есть такая фраза:
Среди предлагаемых FontLab’ом таблиц в точности соответствует Adobe Standard Cyrillic Font Specification таблица с именем «Adobe Cyrillic», однако она не полностью соответствует спецификации CP1251: в ней не учтено появление в кодовой позиции 0x88 (136) символа Euro (подробнее об этом см. здесь). Кроме того, дублируется имя «hyphen» в позициях 0x2D (45) и 0xAD (173), но поскольку шрифт не может иметь дублирующиеся имена символов (в отличие от их индексов Unicode), то второе имя будет потеряно. Поэтому предлагается использовать другую кодовую таблицу с именем «CodePage 1251 Cyrillic», которую можно загрузить отсюда. Она должна быть скопирована в каталог, в котором FontLab хранит файлы с расширением .enc (для FontLab’а 3.1х это каталог \Encoding). В списке таблиц она появится при следующем вызове FontLab’а.
Это так (я имею ввиду несоответствие спецификаций)?
И еще. Я заглянул в инф-файл одного из кириллических Т1-шрифтов от Адобе. Как и ожидалось, ничего про 204 там нет. Т. е. по Адобе все это фигня.
В статье по твоей ссылке есть такая фраза:
Среди предлагаемых FontLab’ом таблиц в точности соответствует Adobe Standard Cyrillic Font Specification таблица с именем «Adobe Cyrillic», однако она не полностью соответствует спецификации CP1251: в ней не учтено появление в кодовой позиции 0x88 (136) символа Euro (подробнее об этом см. здесь). Кроме того, дублируется имя «hyphen» в позициях 0x2D (45) и 0xAD (173), но поскольку шрифт не может иметь дублирующиеся имена символов (в отличие от их индексов Unicode), то второе имя будет потеряно. Поэтому предлагается использовать другую кодовую таблицу с именем «CodePage 1251 Cyrillic», которую можно загрузить отсюда. Она должна быть скопирована в каталог, в котором FontLab хранит файлы с расширением .enc (для FontLab’а 3.1х это каталог \Encoding). В списке таблиц она появится при следующем вызове FontLab’а.
Это так (я имею ввиду несоответствие спецификаций)?
И еще. Я заглянул в инф-файл одного из кириллических Т1-шрифтов от Адобе. Как и ожидалось, ничего про 204 там нет. Т. е. по Адобе все это фигня.
Кварк 5 работает с такими шрифтами уже корректней, чем Кварк 4. Подробности в анонсированном обзоре.
Потом, насколько я знаю, Адобе утаивает ряд спецификация (так же как и Microsoft утаивает про TrueType). И естественно в первую очередь Адобе заинтересованно именно в глючности Кварка.
Я не оправдываю Кварк (хотя и люблю его больше, чем все Адобе вместе взятое). Просто констатирую очевидные вещи.
AE wrote:
> Кстати, этот Дмитрий Юнов, очевидно, не сам придумал эти
> волшебные слова,
> где-то нашел.
Откуда такая уверенность, можно спросить?
Потом, насколько я знаю, Адобе утаивает ряд спецификация (так же как и Microsoft утаивает про TrueType). И естественно в первую очередь Адобе заинтересованно именно в глючности Кварка.
Я не оправдываю Кварк (хотя и люблю его больше, чем все Адобе вместе взятое). Просто констатирую очевидные вещи.
AE wrote:
> Кстати, этот Дмитрий Юнов, очевидно, не сам придумал эти
> волшебные слова,
> где-то нашел.
Откуда такая уверенность, можно спросить?
> вывод печальный - подобные эксперименты могут отразиться в самых неожиданных местах
ну у Шляпы условный рефлекс, пнуть кварк, это я оставляю без внимания. Но то что он, ради этого, заявляет, что прописанные в инф "под давлением общественности пользователей ворда" (кстати родину фонтлаба все знают? неудивительно если они вняли гласу "общественности"), это якобы так и должно быть, это слишком
> Я заглянул в инф-файл одного из кириллических Т1-шрифтов от Адобе. Как и ожидалось, ничего про 204 там нет. Т. е. по Адобе все это фигня
то что я и хотел спросить еще вчера (сам не нашел т1 из адобовского фолио). Вот и ответ.
А новые т1 от например Паратайпа идут с 204, но смотрим в фонтлабе, у них у всех креатор PYRS, он же Pyrus. Вот все и объясняется
----------------------
> Но давайте о кернинге в CFF-OTF
проверил, действительно так. Сам же FL при повторном открытии otf не видит кернинг. Но однако, кварк видит кернинг, правда только в некир. части. Значит в шрифте он записан. Но некорректно не только с точки зрения адоба, но и самого родителя шрифта. Где-то я слышал, что FL пока еще толком не работает с otf
ну у Шляпы условный рефлекс, пнуть кварк, это я оставляю без внимания. Но то что он, ради этого, заявляет, что прописанные в инф "под давлением общественности пользователей ворда" (кстати родину фонтлаба все знают? неудивительно если они вняли гласу "общественности"), это якобы так и должно быть, это слишком
> Я заглянул в инф-файл одного из кириллических Т1-шрифтов от Адобе. Как и ожидалось, ничего про 204 там нет. Т. е. по Адобе все это фигня
то что я и хотел спросить еще вчера (сам не нашел т1 из адобовского фолио). Вот и ответ.
А новые т1 от например Паратайпа идут с 204, но смотрим в фонтлабе, у них у всех креатор PYRS, он же Pyrus. Вот все и объясняется
----------------------
> Но давайте о кернинге в CFF-OTF
проверил, действительно так. Сам же FL при повторном открытии otf не видит кернинг. Но однако, кварк
видит кернинг, правда только в некир. части. Значит в шрифте он записан. Но некорректно не только с точки зрения адоба, но и самого родителя шрифта. Где-то я слышал, что FL пока еще толком не работает с otf> Это так (я имею ввиду несоответствие спецификаций)?
В FL4.6 я нашёл два вхождения «hithen» только в Windows ANSI (WINANSI.ENC). Не знаю, это его имели в виду?
В Adobe Cyrillic (Mac) (ADOBECYR.ENC) вхождение «hithen» одно.
Другие файлы *.ENC, если я правильно понимаю, к кириллице вообще даже близко отношения не имеют.
Если посмотреть в FL4.6, то имя «Euro» стоит на своём месте, и hiphen не дублируется.
А глядеть, как оно было в 3-м FL нет ни возможности (поскольку не установлен), ни желания.
> предлагается использовать другую кодовую таблицу с именем «CodePage 1251 Cyrillic»,
В Codepage содержатся юникодные индексы, а не имена глиф. Имена присваиваются из Adobe Gliph List или из Standrd Table (где они хранятся — х.з.). Честно говря, разницы между ними я так и не разглядел. Пользуюсь Adobe Gliph List.
> И естественно в первую очередь Адобе заинтересованно именно в глючности Кварка.
И PageMaker-а, да? Он ведь ведёт себя с этими шрифтами точно так же.
Давай теперь глюки всех програм всех разработчиков будем валить на MS и Adobe.
Я могу понять, почему у Adobe PM оказался в таком запущенном состоянии — он у них не один такой красивый, и замена ему давно готовилась (а не с того ли самого момента, как спецификации 1998 года были приняты?).
Но у Кварка-то, как у конторы, всего один продукт (так?), что ж они его так ?… Во всём утаённые спецификации виноваты?
В FL4.6 я нашёл два вхождения «hithen» только в Windows ANSI (WINANSI.ENC). Не знаю, это его имели в виду?
В Adobe Cyrillic (Mac) (ADOBECYR.ENC) вхождение «hithen» одно.
Другие файлы *.ENC, если я правильно понимаю, к кириллице вообще даже близко отношения не имеют.
Если посмотреть в FL4.6, то имя «Euro» стоит на своём месте, и hiphen не дублируется.
А глядеть, как оно было в 3-м FL нет ни возможности (поскольку не установлен), ни желания.
> предлагается использовать другую кодовую таблицу с именем «CodePage 1251 Cyrillic»,
В Codepage содержатся юникодные индексы, а не имена глиф. Имена присваиваются из Adobe Gliph List или из Standrd Table (где они хранятся — х.з.). Честно говря, разницы между ними я так и не разглядел. Пользуюсь Adobe Gliph List.
> И естественно в первую очередь Адобе заинтересованно именно в глючности Кварка.
И PageMaker-а, да? Он ведь ведёт себя с этими шрифтами точно так же.
Давай теперь глюки всех програм всех разработчиков будем валить на MS и Adobe.
Я могу понять, почему у Adobe PM оказался в таком запущенном состоянии — он у них не один такой красивый, и замена ему давно готовилась (а не с того ли самого момента, как спецификации 1998 года были приняты?).
Но у Кварка-то, как у конторы, всего один продукт (так?), что ж они его так ?… Во всём утаённые спецификации виноваты?
> прописанные в инф "под давлением общественности пользователей ворда" (кстати родину фонтлаба все знают? неудивительно если они вняли гласу "общественности"), это якобы так и должно быть, это слишком
А я однозначно написал, что свои выводы я сделал НА ОСНОВАНИИ ПРОЧИТАННОГО. Ты какие выводы делаешь на сновании прочитанного там? Или только такие, что я всегда не прав, потому, что Кварк не люблю? (Возможно, я его и полюбил бы в ЕГО время, но сейчас время уже не его. Уходит его время в Истрию, вслед за PM-ом. Заметь, я «Историю» с большой буквы написал написал — уважаю и чту. Он славно потрудился, но пора на пенсию.)
======== Здесь о Кварке больше не встреваю. Надолело ===========
========================================================
> Но некорректно не только с точки зрения адоба, но и самого родителя шрифта. Где-то я слышал, что FL пока еще толком не работает с otf
А я слышал тут за углом от Arkady (по дуругому поводу, правда), что в OTF многие вещи прописываются вручную в OTF Futures. Эти-то вещи CS-ы нормально из шрифтов читают, если они в шрифте всё правильно сделано и ничего не забыто.
Вот я и подумал, что может быть, и кернинг в OTF туда же прописывается (я даже в этом почти уверен), и ещё я подумал, что может быть кто-нибудь информацией на этот счёт владеет и поделится.
P.S.
Документацию почитать, что ли…
А я однозначно написал, что свои выводы я сделал НА ОСНОВАНИИ ПРОЧИТАННОГО. Ты какие выводы делаешь на сновании прочитанного там? Или только такие, что я всегда не прав, потому, что Кварк не люблю? (Возможно, я его и полюбил бы в ЕГО время, но сейчас время уже не его. Уходит его время в Истрию, вслед за PM-ом. Заметь, я «Историю» с большой буквы написал написал — уважаю и чту. Он славно потрудился, но пора на пенсию.)
======== Здесь о Кварке больше не встреваю. Надолело ===========
========================================================
> Но некорректно не только с точки зрения адоба, но и самого родителя шрифта. Где-то я слышал, что FL пока еще толком не работает с otf
А я слышал тут за углом от Arkady (по дуругому поводу, правда), что в OTF многие вещи прописываются вручную в OTF Futures. Эти-то вещи CS-ы нормально из шрифтов читают, если они в шрифте всё правильно сделано и ничего не забыто.
Вот я и подумал, что может быть, и кернинг в OTF туда же прописывается (я даже в этом почти уверен), и ещё я подумал, что может быть кто-нибудь информацией на этот счёт владеет и поделится.
P.S.
Документацию почитать, что ли…
> Ты какие выводы делаешь на сновании прочитанного там?
из имеющего отношение к теме: шрифтовые стандарты не есть некий дарованный абсолют, а довольно запутанный, местами противоречивый процесс, еще не завершенный, к тому же вынужденный поддерживать обратную совместимость, хотя бы некоторое время. Охотно верю байке о "новости для специалистов адоба", наверное байт 055h был заложен в формат pfm (которого теперь фиг найдешь) очень давно, проектировщики для чего-то его планировали, потом вместе с генеральной линией партии (и новым поколением адобовцев) появились другие приоритеты, другие механизмы поддержки не-латинских языков и символов. И вместе с тем, как определили наши кулибины, АТМ для 95-98, или скорее MSOffice, взаимодействуя с GDI (или с чем там, не знаю) учитывает этот байт. И я предполагаю, что включение 204 в inf -- подарок авторов фонтлаба соотечественникам, вышедший боком. Потому как оказалось, что для старика кварка критерием что кернить, что нет, является этот самый байт. Тоже видать разработчики заложили при царе горохе. Не планировали наверное кернить не-латинские шрифты ( они вообще это обещали? не думаю)
...А недокументированные возможности -- это реальная сила в руках публикующего "открытые" стандарты, кстати
_________
> в OTF многие вещи прописываются вручную в OTF Futures
тут не только мои познания, но и энергия в чем-либо покопаться заканчивается. Ждем Arkady
________
>> И естественно в первую очередь Адобе заинтересованно именно в глючности Кварка.
>И PageMaker-а, да?
ну а почему же нет? Если б пейдж хорошо работал, кто бы покупал ИД? они вообще всемирный заговор готовят
> Здесь о Кварке больше не встреваю. Надолело
Надоело или наболело?
Но все равно большое спасибо
из имеющего отношение к теме: шрифтовые стандарты не есть некий дарованный абсолют, а довольно запутанный, местами противоречивый процесс, еще не завершенный, к тому же вынужденный поддерживать обратную совместимость, хотя бы некоторое время. Охотно верю байке о "новости для специалистов адоба", наверное байт 055h был заложен в формат pfm (которого теперь фиг найдешь) очень давно, проектировщики для чего-то его планировали, потом вместе с генеральной линией партии (и новым поколением адобовцев) появились другие приоритеты, другие механизмы поддержки не-латинских языков и символов. И вместе с тем, как определили наши кулибины, АТМ для 95-98, или скорее MSOffice, взаимодействуя с GDI (или с чем там, не знаю) учитывает этот байт. И я предполагаю, что включение 204 в inf -- подарок авторов фонтлаба соотечественникам, вышедший боком. Потому как оказалось, что для старика кварка критерием что кернить, что нет, является этот самый байт. Тоже видать разработчики заложили при царе горохе. Не планировали наверное кернить не-латинские шрифты ( они вообще это обещали? не думаю)
...А недокументированные возможности -- это реальная сила в руках публикующего "открытые" стандарты, кстати
_________
> в OTF многие вещи прописываются вручную в OTF Futures
тут не только мои познания, но и энергия в чем-либо покопаться заканчивается. Ждем Arkady
________
>> И естественно в первую очередь Адобе заинтересованно именно в глючности Кварка.
>И PageMaker-а, да?
ну а почему же нет? Если б пейдж хорошо работал, кто бы покупал ИД? они вообще всемирный заговор готовят> Здесь о Кварке больше не встреваю. Надолело
Надоело или наболело?
Но все равно большое спасибо
Shlyapa wrote:
> 1. Они юникодные, в отличие от подавляющего большинства
> ходящих по рукам TTF-ов.
а в чем собствинна разница между уникодным и неуникодным ttf?
в том, что в юникодных ttf русская "А" имеет индекс 0x410, а в неуникодных 0xc0?
> Если эти TTF-ы большинство софта ещё
> может нормально записать в PS (EPS, PDF), то с Unicode
> справляется далеко не всякий софт.
это проблемы софта. со шрифтами все ок.
> И AI 10 тому пример,
у ai cs с этим все в порядке.
> 3. Системные шрифты — TTF-ы, то есть кривыми описаны… как их
> там…, в общем, не Безье, не PostScript.
а вы знаете - почему так получилось и откуда вообще взялись ttf?
> 4. Системные шрифты Win9x и Win2000/XP (а NT4 уже плохо
> помню) — это далеко не одно и то же,
это почти одно и тоже. т.е. онимеют разные версии, но являются эволюцией одного и того же.
> платформы на платформу. Разве не видел ты, zg, как
> превращается в крякозбрики текст, красиво выглядивший на
> одном компе, при открытии на другом.
нет.
> Если бы не эти пункты (и еще какие-нибудь мелочи, которые я
> сейчас упустил), то разве я возражал бы против системных
> шрифтов? И не я один, подчёркиваю.
вы путаете причину и следствие. шрифты прямые. крив софт.
> 1. Они юникодные, в отличие от подавляющего большинства
> ходящих по рукам TTF-ов.
а в чем собствинна разница между уникодным и неуникодным ttf?
в том, что в юникодных ttf русская "А" имеет индекс 0x410, а в неуникодных 0xc0?
> Если эти TTF-ы большинство софта ещё
> может нормально записать в PS (EPS, PDF), то с Unicode
> справляется далеко не всякий софт.
это проблемы софта. со шрифтами все ок.
> И AI 10 тому пример,
у ai cs с этим все в порядке.
> 3. Системные шрифты — TTF-ы, то есть кривыми описаны… как их
> там…, в общем, не Безье, не PostScript.
а вы знаете - почему так получилось и откуда вообще взялись ttf?
> 4. Системные шрифты Win9x и Win2000/XP (а NT4 уже плохо
> помню) — это далеко не одно и то же,
это почти одно и тоже. т.е. онимеют разные версии, но являются эволюцией одного и того же.
> платформы на платформу. Разве не видел ты, zg, как
> превращается в крякозбрики текст, красиво выглядивший на
> одном компе, при открытии на другом.
нет.
> Если бы не эти пункты (и еще какие-нибудь мелочи, которые я
> сейчас упустил), то разве я возражал бы против системных
> шрифтов? И не я один, подчёркиваю.
вы путаете причину и следствие. шрифты прямые. крив софт.
> а в чем собствинна разница между уникодным и неуникодным ttf?
В том, что ты сам же и цитируешь буквально следом.
> это проблемы софта. со шрифтами все ок.
Но пользуемся-то мы не шрифтами как таковыми, а через софт. Задача ведь в том, чтобы качественный результат получить, а ИСПОЛЬЗОВАНИЕ системных шрифтов резко снижает шансы на успех.
> это почти одно и тоже.
Однако, «совсем» или «почти», а не одно и то же — факт.
> вы путаете причину и следствие. шрифты прямые. крив софт.
Не путаю. И не говорю так, как ты пытаешься мне приписать.
Повторяю ещё раз свою формулировку: не пользуйтесь системными шрифтами.
Где здесь характеристика шрифтов или софта? Здесь только реально работающий практический рецепт, следование которому существенно снижает количество проблем на выводе. НЕ ПОЛЬЗУЙТЕСЬ!
В том, что ты сам же и цитируешь буквально следом.
> это проблемы софта. со шрифтами все ок.
Но пользуемся-то мы не шрифтами как таковыми, а через софт. Задача ведь в том, чтобы качественный результат получить, а ИСПОЛЬЗОВАНИЕ системных шрифтов резко снижает шансы на успех.
> это почти одно и тоже.
Однако, «совсем» или «почти», а не одно и то же — факт.
> вы путаете причину и следствие. шрифты прямые. крив софт.
Не путаю. И не говорю так, как ты пытаешься мне приписать.
Повторяю ещё раз свою формулировку: не пользуйтесь системными шрифтами.
Где здесь характеристика шрифтов или софта? Здесь только реально работающий практический рецепт, следование которому существенно снижает количество проблем на выводе. НЕ ПОЛЬЗУЙТЕСЬ!
Для начала, несколько цитат из http://www.osp.ru/publish/2002/02/038_print.htm
==============
при покупках шрифтов в новых форматах нужно выбирать между пониманием MS, Adobe и Apple таких технологий и знать, в каких приложениях они могут использоваться. Реально выбор ограничен технологией OpenType, для чего разработчикам программного обеспечения необходимо лицензировать у MS и Adobe (бесплатно) специальную библиотеку — OTLS (OpenType Layout Services engine) — для работы с расширенными возможностями шрифтов. Неприятно, что шрифты OpenType делятся на два семейства: формат MS TrueType с таблицами OpenType (*.ttf) и формат Adobe PostScript CFF с таблицами OpenType (*.otf).
===========
Даже кернинг-информация в шрифтах OpenType доступна только через такую библиотеку. Программы верстки, игнорирующие OTLS, при использовании шрифтов OpenType не могут получить доступ к лигатурам, капители, специальным знакам, вариантам начертания символов, расширенной метрике шрифтов, включая кернинг групп символов и контекстуальный кернинг. Как пример новейшей программы, не использующей OTLS со всеми вытекающими последствиями, приведем QuarkXPress 5.
Это главное ограничение в применении шрифтов OpenType на платформах Mac OS 9/X, Windows 98/2000/XP, где кернинг для обычных (classic) приложений из первой группы (см. выше) ограничен первыми 256 символами или просто латинской частью алфавита.
Но есть и приятные исключения. К ним относятся все современные версии приложений Adobe — Acrobat 5, PhotoShop 6 (и будущий 7), Adobe Illustrator 10, InDesign версий 1.52 и 2. За счет использования OTLS-библиотеки они одинаково полноценно работают со шрифтами OpenType на Mac OS 9/X, Windows XP/ME/2000, минуя операционную систему и ATM.
===============
(Не в тому, но всё-таки)
Использование в InDesign 2.0 CE ядра Unicode и расширенная поддержка европейских языков и европейского региона бывшего СССР ставит его вне конкуренции в сравнении с QuarkXPress и даже с QuarkXPress Passport (специальной версией Quark с поддержкой множества западноевропейских языков в одном документе).
Отсутствие поддержки Unicode в приложениях первого поколения, к которым относится QuarkXPress, делает весьма проблемной для них поддержку XML — важного стандарта структурирования и представления документов. InDesign 2.0 блестяще справляется с этой задачей.
===============
(Всё, что сказано об адобовском софте, справедливо и в отношении CS-версий. Просто статья написана в позапрошлом году. Прим. моё — Sh.)
===============
Но вернёмся к практическому кернингу в OTF.
О том, как это делается, написано в Рукововодстве по FontLab 4.6 (возможно, и более раннего) начиная со стр. 428.
О том, как конвертирвать OTF-кеннинг в обычный, написано на стр. 660.
Сам этого всего ещё толком не читал, но сижу читаю.
==============
при покупках шрифтов в новых форматах нужно выбирать между пониманием MS, Adobe и Apple таких технологий и знать, в каких приложениях они могут использоваться. Реально выбор ограничен технологией OpenType, для чего разработчикам программного обеспечения необходимо лицензировать у MS и Adobe (бесплатно) специальную библиотеку — OTLS (OpenType Layout Services engine) — для работы с расширенными возможностями шрифтов. Неприятно, что шрифты OpenType делятся на два семейства: формат MS TrueType с таблицами OpenType (*.ttf) и формат Adobe PostScript CFF с таблицами OpenType (*.otf).
===========
Даже кернинг-информация в шрифтах OpenType доступна только через такую библиотеку. Программы верстки, игнорирующие OTLS, при использовании шрифтов OpenType не могут получить доступ к лигатурам, капители, специальным знакам, вариантам начертания символов, расширенной метрике шрифтов, включая кернинг групп символов и контекстуальный кернинг. Как пример новейшей программы, не использующей OTLS со всеми вытекающими последствиями, приведем QuarkXPress 5.
Это главное ограничение в применении шрифтов OpenType на платформах Mac OS 9/X, Windows 98/2000/XP, где кернинг для обычных (classic) приложений из первой группы (см. выше) ограничен первыми 256 символами или просто латинской частью алфавита.
Но есть и приятные исключения. К ним относятся все современные версии приложений Adobe — Acrobat 5, PhotoShop 6 (и будущий 7), Adobe Illustrator 10, InDesign версий 1.52 и 2. За счет использования OTLS-библиотеки они одинаково полноценно работают со шрифтами OpenType на Mac OS 9/X, Windows XP/ME/2000, минуя операционную систему и ATM.
===============
(Не в тому, но всё-таки)
Использование в InDesign 2.0 CE ядра Unicode и расширенная поддержка европейских языков и европейского региона бывшего СССР ставит его вне конкуренции в сравнении с QuarkXPress и даже с QuarkXPress Passport (специальной версией Quark с поддержкой множества западноевропейских языков в одном документе).
Отсутствие поддержки Unicode в приложениях первого поколения, к которым относится QuarkXPress, делает весьма проблемной для них поддержку XML — важного стандарта структурирования и представления документов. InDesign 2.0 блестяще справляется с этой задачей.
===============
(Всё, что сказано об адобовском софте, справедливо и в отношении CS-версий. Просто статья написана в позапрошлом году. Прим. моё — Sh.)
===============
Но вернёмся к практическому кернингу в OTF.
О том, как это делается, написано в Рукововодстве по FontLab 4.6 (возможно, и более раннего) начиная со стр. 428.
О том, как конвертирвать OTF-кеннинг в обычный, написано на стр. 660.
Сам этого всего ещё толком не читал, но сижу читаю.
Kassian wrote:
> > Кстати, этот Дмитрий Юнов, очевидно, не сам придумал эти
> > волшебные слова,
> > где-то нашел.
> Откуда такая уверенность, можно спросить?
ну я тут воспользовался личным знакомством ;-))).
вот его ответ:
Привет, Вадим.
В 1998 я исследовал Арабские Тип 1 и АТМ (1994 года) от Адобе, нашел там эту
фишку.
Спросил корневых людей в Монотайпе и Адобе что это и как с другими кодовыми
страницами. Они сказали, что это НЕ используют, и не знают, откуда это
пошло.
Я полез выяснять, кто собственник формата PFM. Оказалось Aldus.
Начал искать описание. В MS SDK/DDK от 1994-95 года нашел кусок документации
на PFM c (c) Aldus. Там была ссылка на то что байт резервирован для
совместимости с локализованными версиями ПейджМакера 3 и 4 и их (Альдуса)
собственным пост скрипт драйвером.
Поэкспериментировал с разными кодовыми страницами и АТМ. Работает. С
GDI.exe. Работает. Написал Микрософтовцам. Один из их старых идеологов нац.
Поддержки вспомнил, что во времена Win 3.0 3.1 (1990-1992) этот хак
(поддержка) был добавлен в код GDI.exe.
Написал несколько фагов, Андрей Лютов по моему алгоритму сделал мне утилиту
и я все отослал в Adobe, Bitsream, Agfa, Monotype, MS. И выложил на Веб.
Все.
Можешь использовать данную информацию свободно.
> > Кстати, этот Дмитрий Юнов, очевидно, не сам придумал эти
> > волшебные слова,
> > где-то нашел.
> Откуда такая уверенность, можно спросить?
ну я тут воспользовался личным знакомством ;-))).
вот его ответ:
Привет, Вадим.
В 1998 я исследовал Арабские Тип 1 и АТМ (1994 года) от Адобе, нашел там эту
фишку.
Спросил корневых людей в Монотайпе и Адобе что это и как с другими кодовыми
страницами. Они сказали, что это НЕ используют, и не знают, откуда это
пошло.
Я полез выяснять, кто собственник формата PFM. Оказалось Aldus.
Начал искать описание. В MS SDK/DDK от 1994-95 года нашел кусок документации
на PFM c (c) Aldus. Там была ссылка на то что байт резервирован для
совместимости с локализованными версиями ПейджМакера 3 и 4 и их (Альдуса)
собственным пост скрипт драйвером.
Поэкспериментировал с разными кодовыми страницами и АТМ. Работает. С
GDI.exe. Работает. Написал Микрософтовцам. Один из их старых идеологов нац.
Поддержки вспомнил, что во времена Win 3.0 3.1 (1990-1992) этот хак
(поддержка) был добавлен в код GDI.exe.
Написал несколько фагов, Андрей Лютов по моему алгоритму сделал мне утилиту
и я все отослал в Adobe, Bitsream, Agfa, Monotype, MS. И выложил на Веб.
Все.
Можешь использовать данную информацию свободно.
> несколько цитат из http://www.osp.ru/publish/2002/02/038_print.htm
статья весьма тенденциозная. Автор сыплет именами собственными, упоминает якобы "легендарный" софт... "Обширная группа" приложений у него с двумя лидерами, но и состоит из двух членов...
> Но есть и приятные исключения. ...PhotoShop 6 (и будущий 7),
хм-м, у меня в седьмом шопе русский текст не кернится ни с Minion Pro, ни с NewtonC, ни с TNR... 7-й шоп конечно история, но все равно, чё он врёт-то?
> минуя операционную систему и ATM
во, это я и говорил всегда
________________________
> Но вернёмся к практическому кернингу в OTF
отпиши пожалуйста здесь если будут результаты
____________________________
> Они сказали, что это НЕ используют, и не знают, откуда это
пошло
ну прямо как я и предположил. Что же он, такой умный, не заметил потери кернинга? Может это неспроста? Да еще, деловой такой, "утилиту" предлагает встречным и поперечным... эх
статья весьма тенденциозная. Автор сыплет именами собственными, упоминает якобы "легендарный" софт... "Обширная группа" приложений у него с двумя лидерами, но и состоит из двух членов...
> Но есть и приятные исключения. ...PhotoShop 6 (и будущий 7),
хм-м, у меня в седьмом шопе русский текст не кернится ни с Minion Pro, ни с NewtonC, ни с TNR... 7-й шоп конечно история, но все равно, чё он врёт-то?
> минуя операционную систему и ATM
во, это я и говорил всегда
________________________
> Но вернёмся к практическому кернингу в OTF
отпиши пожалуйста здесь если будут результаты
____________________________
> Они сказали, что это НЕ используют, и не знают, откуда это
пошло
ну прямо как я и предположил. Что же он, такой умный, не заметил потери кернинга? Может это неспроста?
Да еще, деловой такой, "утилиту" предлагает встречным и поперечным... эх