Здравствуйте, minorlogic, Вы писали:

M>Совсем простой тестик можно провести , обычный текст с разрешением при котором плохо различим отрендрить в статике и тут же в динамике , просто проанимировать.

M>То есть чтобы текст совершал легкие плавные движения. Текст который движется должен быть намного лучше различим.

Ага, я теперь понял, откуда эти легенды про "многократное" увеличение разрешения. ТоварищЪ c-smile навел меня на эту мысль. Дело в том, что цветовое разрешение связано с пространственным, но до определенного предела. Возьмем черно-белый лазерник. У него точка может либо быть, либо не быть — никаких полутонов. Градации серого обеспечиваются, например, методом упорядоченного возбуждения. Иначе говоря (утрируя!) один серый пиксел — это квадрат 16x16 черных и белых пикселов. Мы увеличиваем цветовое разрешение в 256 раз, во столько же раз уменьшая пространственное. Но есть способ улучшить цветовое разрешение, не ухудшая пространственного. Для этого каждый пиксел должен часто-часто мигать. Его визуальная яркость будет определяться скважностью "мигания" и мы будем воспринимать это как полутон, несмотря на то, что физически пиксел монохромный. Получается так, что имея скважность 0, 0.5 и 1, мы уже имеем три градации яркости, вместо двух. И соотвественно, можем увеличить пространственное разрешение без ухудшения цветового. Но дело-то в том, что на мониторе у нас нет острой необходимости увеличивать цветовое разрешение — оно и так уже достаточно. Или, можно перефразировать, у нас нет ресурса для игры с пространственным разрешением за счет цветового. Вот если бы у нас был монитор 600dpi, но с чисто "бинарными" пикселами — тогда да, управляя скважностью, можно сэмулировать очень тонкие и четкие линии любого цвета, вместо того, чтобы "лепить" их квадратами 16x16 (опять же, утрируя).

В LCD имеет смысл управлять скважностью, но лишь по причине физической невозможности отобразить хотя бы 256 градаций яркости — но это связано опять же, с чисто физикой и жидкими кристаллами.

Здравствуйте, McSeem2, Вы писали:

MS>Преобразование координат — операция тривиальная. Нетривиальным же является использование нецелых пиксельных координат. Я приводил пример, почему это важно:
MS>http://www.rsdn.ru/Forum/Message.aspx?mid=545188&only=1

Автор: McSeem2
Дата: 19.02.04

MS>Но с одной стороны, ты прав. Некие логические единицы не должны зависеть от разрешения устройства. Другое дело — нужны ли реально миллиметры и дюймы? Я считаю, что не нужны. И даже более того — их использование противоречит тому, что мы наблюдаем на мониторах! (догадайтесь с одного раза, почему).
MS>Должны быть некие абстрактные единицы, типа MM_ISOTROPIC или MM_ANISOTROPIC. Все, большего и не требуется. Миллиметры и дюймы на современных мониторах — это вообще нонсенс! Хотя, возможно, это некий задел на будущее. Когда монитор в реальности будет гарантировать NNN DPI, тогда можно будет говорить и о дюймах. А пока что — это лишь некая условность сбивающая с толку.
Я бы сказал так. Если человеческий глаз не будет отличать линию нарисованную одним пикселем, и двумя пикселями, то это начало новой эпохи.

MS>Сейчас даже просто матрица на светодиодах будет стоить очень дорого (особенно синие светодиоды). Это сейчас. 10 лет назад синих светодиодов вообще не существовало (в некоторых лабораториях наверное были). А сколько 10 лет назад стоил гиг оперативной памяти? Это я к тому, что сегодняшняя стоимость не является принципиальным ограничителем.
MS>А вообще-то, надо начинать даже не с этого. RGB — это тоже тормоз. Нужен еще фиолет и малиновый цвет, которые в RGB в принципе не отображаются.
А я бы сказал больше. Даже отослал в философию.здесь

Автор: GlebZ
Дата: 03.10.05

MS>О-хо-хо. Я говорю о неком формате, типа GIF, который бы реально использовался людьми для обмена. Где в Интернете хоть одна страница с EMF? Ладно, фиг с ним, с Интернетом — где хоть одна пиктограмма на десктопе в формате EMF? Реально используется Flash. Ну еще SVG и XAML в стадии эмбрионов. EMF/EMF+ являются чисто внутренними форматами, которые никого не э... затрагивают особо.
MS>Чего я больше всего хочу в векторной 2D графике:
MS>1. Формат данных, отображаемый везде и всюду.
MS>2. Формат данных, легко генерируемый скриптами (как HTML, хоть я и не люблю HTML).
MS>3. Он должен быть и текстовым и бинарным — два представления одного и того же.
MS>4. Легким и быстрым в отображении (мгновенным как GIF, и резким как понос, но ни в коем случае не тормозом, как Adobe Acrobat или GhostScript!)
MS>5. Платформонезависимым.
Подпишусь, два раза. Единственное что, на примере принтеров мы имеем то, что все отображается по разному на разных принтерах. Проблема что принтеры выдерживают точно 300x300 dpi, или 600x600. Так где-то 295 dpi, и уже картинка(страница) перестает вмещаться в лист. Мелочь, но геморой еще тот.
MS>Пока что такого формата нету. Flash рисуется всезде и всюду и очень быстро, но мы зависим от Flash MX при разработке сайта. Программно сгенерировать SWF — это нетривиальная задача. SVG — генерируется элементарно, но почти ничем не отображается (Adobe SVG не в счет — это такая дырища в security, что лучше не ставить).
MS>Я хочу, чтоб было нечто простое, но стандартизованное. Гораздо проще чем SVG и Flash, но гарантированно работающее везде и всюду.
Я думаю, что это все-таки надо требовать от w3c. Возможно мы бы так и умерли без GIF и JPG в виндах(а жили бы на bmp и dip) если бы не интернет. С векторным форматом должно произойти то же самое. Тогда он будет стандартом для всех(и для виндов тоже). А EMF между прочим до сих пор поддерживается Windows. Только, как ты правильно заметил, без всеобщего одобрения — он стандартом, де факто, не стал.

С уважением, Gleb.

Здравствуйте, z00n, Вы писали:

uw>>>PostScript, PDF

MS>>... Но в экранной графике пока что далеко до PostScript.

Z>Postscript на экране был у NEXT в 1987 году. Жалко умер

Z>http://lowendmac.com/orchard/05/0705.html
Z>http://en.wikipedia.org/wiki/Display_PostScript

А современные "яблоки" вроде как на PDF основаны.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

Z>>http://lowendmac.com/orchard/05/0705.html
Z>>http://en.wikipedia.org/wiki/Display_PostScript

ANS>А современные "яблоки" вроде как на PDF основаны.

И на старуху бывает проруха. К сожалению, PDF с точки зрения графических примитивов — еще худший монстр, чем SVG. К тому же, основательно устаревший. Взять хотя бы радиальные градиенты — их спецификацию крайне тяжело имплементировать, а имплементировать эффективно — просто невозможно. В то же время, я ни в одном документе не видел (кроме демо-примеров), чтобы кому-то понабодилось нарисовать эту градиентную "трубу". Вообще говоря, даже центр фокуса является излишеством. А уж чтобы можно было определять этот центр фокуса вне окружности — это вообще перебор. Никому на практике не нужный.

Здравствуйте, McSeem2, Вы писали:

MS>О-хо-хо. Я говорю о неком формате, типа GIF, который бы реально использовался людьми для обмена. Где в Интернете хоть одна страница с EMF? Ладно, фиг с ним, с Интернетом — где хоть одна пиктограмма на десктопе в формате EMF? Реально используется Flash. Ну еще SVG и XAML в стадии эмбрионов. EMF/EMF+ являются чисто внутренними форматами, которые никого не э... затрагивают особо.
MS>Чего я больше всего хочу в векторной 2D графике:
MS>1. Формат данных, отображаемый везде и всюду.
MS>2. Формат данных, легко генерируемый скриптами (как HTML, хоть я и не люблю HTML).
MS>3. Он должен быть и текстовым и бинарным — два представления одного и того же.
MS>4. Легким и быстрым в отображении (мгновенным как GIF, и резким как понос, но ни в коем случае не тормозом, как Adobe Acrobat или GhostScript!)
MS>5. Платформонезависимым.

Для штрихов есть HPGL. Я в свое время (лет 10 назад) использовал его в самых разных целях. Оказалось, что его нормально импортирут многие CAD системы, а генерить его — проще простого. Конечно, сам по себе он совершенно неудовлетворителен. Даже язык управления плоттерами Бердского радиозавода включает более интересные примитивы, такие как вывод текста и рисование дуг эллипсов.

Здравствуйте, Sinclair, Вы писали:

S>Для штрихов есть HPGL. Я в свое время (лет 10 назад) использовал его в самых разных целях. Оказалось, что его нормально импортирут многие CAD системы, а генерить его — проще простого. Конечно, сам по себе он совершенно неудовлетворителен. Даже язык управления плоттерами Бердского радиозавода включает более интересные примитивы, такие как вывод текста и рисование дуг эллипсов.

Есть еще протокол GKS (Graphics Kernel System). Но он еще более еще более устаревший и к тому же, закрытый.
Счастье заключалось бы еще вот в чем:
1. Некая разумная комбинация из SVG и Flash. Чем плох SVG — тем, что анимация в нем делается туго. В простейшем случае надо перерисовать всю сцену. Сцена Flash состоит из нескольких compound shapes (как слои), определенных явным образом с последующим alpha-blend. Таким образом, во Flash нам чаще всего достаточно перерисовать только одну compound shape. В SVG в общем случае, нет явных указаний на то, как нам разбивать рисунок на слои. Предполагается, что это должен оптимизировать user agent. Но задача этой оптимизации является весьма нетривиальной и ничего в общем случае не гарантирует.

2. Независимость от "носителя" — это может быть XML, может быть некий бинарный поток или даже текстовый, но отличный от XML. Вот, например, XML:

<?xml version="1.0" standalone="no"?>
<svg width="12cm" height="5.25cm" viewBox="0 0 1200 400">
  <rect x="1" y="1" width="1198" height="398"
        fill="none" stroke="blue" stroke-width="1" />
  <g stroke-dasharray="30 8 10" stroke-dashoffset="-9">
    <path d="M300,200 h-150 a150,150 0 1,0 150,-150 z"
          fill="red" stroke="blue" stroke-width="5"/>
    <path d="M275,175 v-150 a150,150 0 0,0 -150,150 z"
          fill="yellow" stroke="blue" stroke-width="5" />
    <path d="M600,350 l 50,-25 
             a25,25 -30 0,1 50,-25 l 50,-25 
             a25,50 -30 0,1 50,-25 l 50,-25 
             a25,75 -30 0,1 50,-25 l 50,-25 
             a25,100 -30 0,1 50,-25 l 50,-25"
          fill="none" stroke="red" stroke-width="5"  />
  </g>
</svg>

Вот почти то же самое на неком "другом" носителе:

{svg width=12cm height=5.25cm viewBox="0 0 1200 400"
  {rect x=1 y=1 width=1198 height=398
        fill=none stroke=blue stroke-width=1}
  {g stroke-dasharray="30 8 10" stroke-dashoffset=-9
    {path d="M300,200 h-150 a150,150 0 1,0 150,-150 z"
          fill=red stroke=blue stroke-width=5}
    {path d="M275,175 v-150 a150,150 0 0,0 -150,150 z"
          fill=yellow stroke=blue stroke-width=5}
    {path d="M600,350 l 50,-25 
             a25,25 -30 0,1 50,-25 l 50,-25 
             a25,50 -30 0,1 50,-25 l 50,-25 
             a25,75 -30 0,1 50,-25 l 50,-25 
             a25,100 -30 0,1 50,-25 l 50,-25"
          fill=none stroke=red stroke-width=5 }
  }
}

Это я к тому, что сам формат SVG замечательно ложится на любой носитель, поддерживающий иерархические структуры. Ну, конечно же, основное — это в бинарном виде.

В таком виде формат можно было бы использовать еще и в качестве протокола, например, вместо X11. Или вместо морально устаревшего и толстого PostScript.
А самое главное — тщательно вычистить все противоречия, присущие SVG и упростить имплементацию. SVG сейчас — это очень глючный формат и очень тяжело имплементируемый. И, кстати, большая дыра в защите если его интегрировать в IE. Вот, например — Adobe SVG банально валится на переполнении стэка (паттерн с бесконечной рекурсией):

<?xml version="1.0" standalone="no"?>
<svg width="4cm" height="4cm" viewBox="0 0 400 400">
  <defs>
    <pattern id="CirclePattern" patternUnits="objectBoundingBox"
             x="0" y="0" width="0.5" height="0.5"
             viewBox="0 0 100 100"
             >
      <circle cx="50" cy="50" r="50" stroke-width="5" 
              fill="url(#CirclePattern)" stroke="blue" />
    </pattern> 
  </defs>

  <rect fill="none" stroke="blue" 
        x="1" y="1" width="398" height="398"/>

  <circle fill="url(#CirclePattern)" stroke="black" stroke-width="5"  
           cx="200" cy="200" r="100"/>
</svg>

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, McSeem2, Вы писали:

ЗХ>2 (по существу). Попробуй объяснить мне (не мне — Зверьку, а "мне" — некоторому среднестатистическому пользователю), зачем мне разрешение 6000х9000 (в условиях обычного монитора)?

А я вот сплю и вижу монитор с 600 dpi. Знаешь почему? Текст на таком мониторе будет пропечатан гораздо качественнее. И глазки будут меньше болеть. И читать текст они будут тоже лучше. Медицинский факт -- распечатанный текст читается гораздо лучше, чем на мониторе. Из-за того, что буквы не из пикселов состоят, а из линий.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, minorlogic, Вы писали:

M>>Совсем простой тестик можно провести , обычный текст с разрешением при котором плохо различим отрендрить в статике и тут же в динамике , просто проанимировать.

M>>То есть чтобы текст совершал легкие плавные движения. Текст который движется должен быть намного лучше различим.

MS>Ага, я теперь понял, откуда эти легенды про "многократное" увеличение разрешения. ТоварищЪ c-smile навел меня на эту мысль. Дело в том, что цветовое разрешение связано с пространственным, но до определенного предела. Возьмем черно-белый лазерник. У него точка может либо быть, либо не быть — никаких полутонов. Градации серого обеспечиваются, например, методом упорядоченного возбуждения. Иначе говоря (утрируя!) один серый пиксел — это квадрат 16x16 черных и белых пикселов. Мы увеличиваем цветовое разрешение в 256 раз, во столько же раз уменьшая пространственное. Но есть способ улучшить цветовое разрешение, не ухудшая пространственного. Для этого каждый пиксел должен часто-часто мигать.

DLP?

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

А если серьезно,... полный бред, совмещенный со словесным поносом... плюс ко всему, начиная с Windows 2000 система сидит на шрифтах OpenType...

P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

Здравствуйте, Whistler, Вы писали:

W>А если серьезно,... полный бред, совмещенный со словесным поносом... плюс ко всему, начиная с Windows 2000 система сидит на шрифтах OpenType...

Я ценю Ваше мнение, но все-таки посоветовал бы подучить матчасть. Так называемый "OpenType" — это на практике — тот же TrueType с некими чисто техническими дополнениями и средствами разрешения юридических конфликтов:
http://en.wikipedia.org/wiki/OpenType

History

OpenType was intended by Microsoft to be the successor to the TrueType font format developed by Apple Computer and licensed by Microsoft. Microsoft tried to license Apple's advanced typography technology, "GX Typography," and upon being refused turned to develop its own technology dubbed "TrueType Open" in 1994. Adobe Systems joined Microsoft in 1996, adding support for its PostScript Type 1 fonts, and the name OpenType was then used for the combined technologies.
[edit]

Description

OpenType uses the general structure of a TrueType font, but adds several unique options which enhance the font's typographical abilities. An OpenType font can include either TrueType outlines or PostScript-style outlines (though stored in the CFF/Type 2 format).

OpenType has several distinctive features:

* the font encoding is based on Unicode and can support any language (or multiple languages at once)
* OpenType fonts can have up to 65,536 glyphs
* fonts can have advanced typographic features, which allow proper typographic treatment of complex languages, and advanced typographic effects for simpler languages, such as English.

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

W>P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

Спасибо за совет. Так и сделаю. Вот прямо ЩАС...

Здравствуйте, McSeem2, Вы писали:

W>>P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

MS>Спасибо за совет. Так и сделаю. Вот прямо ЩАС...

Я не хотел показаться грубым...

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

Конечно у TrueType есть свои недостатки, но умоляю, его в 80-х годах разрабатывали, на нем ОС держится с 1990 года (в Windows 3.0 его впервые ввели, если не ошибаюсь)... Да — есть камень в огород Microsoft за то, что они до сих пор не придумали ему более современную альтернативу.

Ей богу, я прочитав твою статью подумал, что в этом кто-то виноват, и ты его хочешь порвать на части.
Я не пропогандист Microsoft, Apple, IBM, Red-Hat и т.д. но такое впечатление, что из-за всех перечисленных тобою песчастий виновата именно Майкрософт. Он не сделали, они не уследили, мочи в сортире их...


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

Здравствуйте, Whistler, Вы писали:
W>А если серьезно,... полный бред, совмещенный со словесным поносом... плюс ко всему, начиная с Windows 2000 система сидит на шрифтах OpenType...
Хуже твоего воспитания только твоя квалификация.

Здравствуйте, McSeem2, Вы писали:

MS>Как для цветового — это понятно. Есть такой способ для GIF (с разными палитрами). А вот как это должно работать для увеличения пространственного разрешения — что-то не соображу. Колись давай.

Да все просто , эбычная математика . Глаз достоточно сложное устройство и старается выудить максимум информации .

А одно и то же изображени с сабпиксельными сдвигами математическими методами превращается в тоже с увеличенным разрешением . То есть набор изображений с сабпиксельным сдвигом дает больше информации чем одно изображение.

Здравствуйте, Whistler, Вы писали:

W>Я не теоретик в области юзер-экспериенса, но знаю что большинству разработчиков эта проблема не мешает
Разработчикам вообще ничего не мешает. Мешает это пользователям, которые получают г. вместо конфетки.
W>,... обычно просто формы (диалоги) делают с плавающими размерами, — Просто размеры (ширину и высоту) всех контролов на форме при инициализации перемножают на коэффициент, который собой представляет собой масштабность шрифта (96 точек на дюйм, 120 точек на дюйм и т.д...).
Я тебе рекомендую перечитать всю тему. Твои представления о смысле и проблемах рендеринга UI, мягко говоря, не соответствуют действительности. Особенно про масштабность шрифта (ты, похоже, вообще не представляешь себе что это такое).

Здравствуйте, Whistler, Вы писали:

W>>>P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

MS>>Спасибо за совет. Так и сделаю. Вот прямо ЩАС...

W>Я не хотел показаться грубым...

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

Я понятно выражаюсь?

Здравствуйте, McSeem2, Вы писали:

MS>
MS>Это они называют Times New Roman?! Да любого типографского дизайнера стошнит от такой пошлятины. Нет в шрифте "Times New Roman" таких зверских засечек. Ну нету! Это выглядит очень вульгарно и пошло. Вот нормальный Times New Roman:
MS>

Максим, а можно следать те же картинки, но с чуть большим размером шрифта? А то я вот, например, кроме некоторой размытости второй картинки разницы как-то не замечаю. Если не трудно, конечно...

(Whistler)

Я извиняюсь еще раз. Перегнул палку, обещаю впредь больше не беспредельничать.

ЗХ>Есть мнение, что попав в новое место, не стоит сразу же демонстрировать понты. Можно оказаться в глупом положении (например, начать учить жизни эксперта в обсуждаемой теме, что и произошло в данном случае).

Ваше мнение ошибочно, я на форуме с 2002 года. И не озадачен целью кидать понты, так как не считаю себя самым умным — иначе меня бы сдесь небыло.

ЗХ>Есть также мнение, что лексические конструкции типа "полный бред, совмещенный со словесным поносом" не способствуют продуктивной дискуссии.
ЗХ>Кроме того, существует мнение, что если нет желания слушать — лучше воздержаться от высказывания собственных мыслей.

ЗХ>Я понятно выражаюсь?

Посностью с вами согласен. Понял вину, прошу восстановить меня из бана.

Здравствуйте, Пацак, Вы писали:

П>Максим, а можно следать те же картинки, но с чуть большим размером шрифта? А то я вот, например, кроме некоторой размытости второй картинки разницы как-то не замечаю. Если не трудно, конечно...

Это элементарно. Берем MS Word и Adobe Acrobat. На самом деле, "мутная строка" — это тот же текст, но с отключенными хинтами. Фишка здесь в том, что он гораздо больше похож на Times New Roman при любых масштабах. Это именно то, что ценят профессиональные дизайнеры и верстальщики (не веб-дизайнеры!). С хинтами меняется само начертание символов в зависимости от размера. Вот фрагмент переписки с c-smile (надеюсь, он не обидится, тем более, что письмо — мое).

С фонтами все очень непросто и скалирование — это лишь малая часть айсберга.
Все дело в волшебных хинтах, будь они неладны.
То есть, неизбежно приходится чем-то жертвовать при отображении. Адоба
жертвует визуальной четкостью, MS-Word жертвует кернингом. Но и те и другие
обеспечивают строгое соответствие экран-принтер. Сейчас проведем визуальный
экспресс-анализ.
http://antigrain.com/stuff/adobe_text_rendering.png
http://antigrain.com/stuff/msword_text_rendering.png

Фрагмент в увеличенном виде:
http://antigrain.com/stuff/adobe_text_zoomed.png
http://antigrain.com/stuff/msword_text_zoomed.png
Нетрудно заметить, что у Адобы одни и те же буквы выглядят по-разному, за
счет субпиксельного позиционирования (i, t, n, s). В ворде же они всегда
одинаковые, но зато "плавают" по горизонтали. За счет этого обеспечивается
лучшая четкость, но кернинг — ни борщь, ни в красну армию. Текст выглядит
четко, но как-то очень неряшливо из за "гуляния" букв. В общем, Adobe
претендует на некий профессионализм, в то время, как MS занимается
профанацией населения. Кстати, профанация практически всегда выгоднее с
точки зрения конечных прибылей.

Далее суть проблемы. На высоком разрешении хинты не нужны вообще и они не
используются. В экранном разрешении — хинты обеспечивают хорошую четкость,
но при прямом рисовании ломают соответствие экран-принтер. Чтобы добиться
приемлемого качества при сохранении хинтов, приходится рисовать по одной
букве, вычисляя ее позицию при отключенных хинтах. Так делает Word (скорее
всего использует какие-то недокументированные функции). Но здесь нас тоже
ждет засада. Даже если мы используем WinAPI GetGlyphOutline, то нам не
так-то просто определить позицию. Там возвращаются gmCellIncX, gmCellIncY,
но они — в целых числах, то есть, в целых пикселах. Этой точности явно
недостаточно, поэтому надо вызывать GetGlyphOutline с GGO_UNHINTED, причем
для шрифта большого размера, скажем, 200 пикселов. Вот тогда можно
более-менее точно вычислить позицию буквы на экране, так, чтобы она
соответствовала позиции на принтере. Ну или делать наоборот — корректировать
позиции на принтере с учетом хинтов на экране — но это будет полный маздай.
То есть, вывод такой. Функции рисования текста WinAPI учитывают и кернинг и
хинты, и текст выглядит прельстиво. Но именно из за этого они совершенно
непригодны для WISIWIG.

Я уже давал ссылку: http://antigrain.com/stuff/RefxAgg.zip
Если менять размер окна, то видно, что строка внизу "прыгает". Она ведет
себя примерно так же, как DrawText:
http://antigrain.com/stuff/andrew_text_zoomed.png
Слово выглядит гораздо более (как это по-русски?) consistent — учитываются и
хинты и кернинг и все очень четко. Но явно видно накопление ошибки даже на
одном слове — сравни с Word или Adobe. Вот из за этой вот "маленькой
разницы" и получается полная ж... с печатью.

Здравствуйте, Пацак, Вы писали:
П>Максим, а можно следать те же картинки, но с чуть большим размером шрифта? А то я вот, например, кроме некоторой размытости второй картинки разницы как-то не замечаю. Если не трудно, конечно...
Я боюсь, что тогда пропадет главная идея. На больших размерах шрифты выглядят более-менее нормально. Вот только радикально отличаются от своей маленькой версии.
Поимимо размытости, в "нормальной" версии можно заметить:
— вертикальные штрихи толще горизонтальных
— у букв w, с справа вверху шарик, а не штрих
— засечки совсем-совсем тонкие.

Здравствуйте, Пацак, Вы писали:

П>Максим, а можно следать те же картинки, но с чуть большим размером шрифта? А то я вот, например, кроме некоторой размытости второй картинки разницы как-то не замечаю. Если не трудно, конечно...

Для пущей убедительности процитирую Стива Джобса (перевод выступления перед выпускниками Cтэнфорда):

Reed College всегда предлагал лучшие уроки по каллиграфии. По всему кампусу каждый постер, каждая метка были написаны каллиграфическим почерком от руки. Так как я отчислился и не брал обычных уроков, я записался на уроки по каллиграфии. Я узнал о serif и sans serif, о разных отступах между комбинациями букв, о том, что делает прекрасную типографику прекрасной. Она была красивой, историчной, мастерски утонченной до такой степени, что наука этого не смогла бы понять.

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

Я бы добавил, что Windows не просто "сдули", но и основательно испортили. Хинты, это конечно же хорошо, но до определенного предела — они не имеют права менять визуальное начертание символов. Хинты Type I — более-менее оптимальны, они не приводят к деградации начертания. Хинты TrueType — это уже перебор. Причины понятны — "деньги здесь и сейчас", но этот подход погружает население в пучину невежества.