Интервью с разработчиком FreeType

Интересные цитаты:

I never quite understood the people who say that you should not worry about optimizing your code until very late in the project. My experience is that this attitude leads developers to choose very sophisticated and generic designs that are extremely difficult to retrofit into something efficient later, because so many layers in the code depend on them. I'm not advocating micro-optimization, simply the fact that you should be able to profile and adjust your designs incrementally during development. (сразу вспоминаю OO)

There is no clear answer as to what is best. Personally, I can't stand native TrueType hinted fonts anymore, they look too distorted to me, even if their contrast is better. My favorite Linux distribution is Ubuntu at the moment, and the first thing I do after installing it is to wipe the version of FreeType provided with it to get rid of the bytecode interpreter :o) (а я смотреть на шрифты без bytecode interpreter просто не могу - странный выбор)

Also, I still don't understand why Debian and Ubuntu keep distributing patent-infringing code in FreeType, while they keep MP3 and DVD playback out of their normal installs. I'm not even sure it's DFSG compliant... (а в fedora всё отключено - приходится freetype пересобирать)

Его накурили, по ходу дела. BCI в убунте отключен.

Я думаю, ему видней. :)

Дайте краткий перевод плиз

А, точно -- там LCD color filtering отключен [1]. Значит накурили меня :)

[1] http://permalink.gmane.org/gmane.comp.fonts.freetype.user/1912

> If you absolutely need the bytecode interpreter, you can be patient and wait for October 9, 2009, when the patents expire.

А я думал, это навсегда. :)

объясните анонимусу все-таки, что такое байткод интерпретатор, есть ли он в убунтах, и хорошо это или нет?

>Also, I still don't understand why Debian and Ubuntu keep distributing patent-infringing code in FreeType, while they keep MP3 and DVD playback out of their normal installs.

алсо, я тоже. кто-нибудь может объяснить?

> BCI в убунте отключен.

Вызывающе неверная информация.

В Дебиане и Убунте BCI включён. Чтобы понять, как плохо без него, зайдите в настройки шрифтов и поставьте уровень хинтинга в "Нет".

Ви таки думаете, что я не пробовал? :)

> Вызывающе неверная информация.

> В Дебиане и Убунте BCI включён. Чтобы понять, как плохо без него, зайдите в настройки шрифтов и поставьте уровень хинтинга в "Нет".

Понятия не имею, включен BCI в убунте или нет. Но у Вас определенно проблемы с логикой (а также с воспитанием), поскольку BCI != hinting. В интервью как раз очень много говорится о том, как люди работают над улучшением алгоритмов хинтинга без использования патентованного байткода, а также по субъективному мнению David Turner'а их алгоритмы выдают лучшие результаты, чем байткод, поэтому он и отключает поддержку байткода где только можно :)

/me врубил patented BCI и patented subpixel rendering в Fedora 7 ...

$ cat /usr/src/redhat/SPECS/freetype.spec |head -n11
# Disable patented bytecode interpreter and patented subpixel rendering.
# Setting to 0 enables them.
%define without_bytecode_interpreter    0
%define without_subpixel_rendering      0

%{!?with_xfree86:%define with_xfree86 1}

Summary: A free and portable font rendering engine
Name: freetype
Version: 2.3.4
Release: 2%{?dist}


Шрифты стали более чёткими на LCD.
Liberation Sans 9, 96dpi, Smoothing: Subpixel [RGB order], Hinting: Medium.

>В Дебиане и Убунте BCI включён. Чтобы понять, как плохо без него, зайдите в настройки шрифтов и поставьте уровень хинтинга в "Нет".

Раньше выкачивал freetype, раскомментировал нужные строки пересобирал, затем отключал antialiasing - качество шрифтов, за исключением некоторых артефактов, как в альтернативной ОС.

Сейчас просто подключаю репозиторий http://www.telemail.fi/mlind/ubuntu и опять же отключаю antialiasing - эффект тот же, но без лишнего гимора.

>В Дебиане и Убунте BCI включён. Чтобы понять, как плохо без него, зайдите в настройки шрифтов и поставьте уровень хинтинга в "Нет".

Там включен автохинтинг. Байткод включается патчем. Чтобы это понять достаточно сравнить шрифты до и после патча ;)

Гы-гы-гы, а сервер там на Fedora :P

>Раньше выкачивал freetype, раскомментировал нужные строки пересобирал, затем отключал antialiasing - качество шрифтов, за исключением некоторых артефактов, как в альтернативной ОС.


врубил BCI раскомментировав строчку... попробовал вырубить через gnome-font-properties smoothing - становились шрифты корявыми...
что не так?

Нафига менять freetype если шрифты корявые? yum install freefont terminus-font-x11 terminus-font-console попробовать...

Liberation Sans корявые?!??

> Чтобы это понять достаточно сравнить шрифты до и после патча ;)

Пробовал - результат абсолютно одинаковый. Потому что Freetype там _уже пропатченный_. А вот если сделать dpkg-reconfigure fontconfig и сменить native на autohinter, сразу становится понятно, в чём разница.

> Liberation Sans корявые?!??

Да. Они без полных инструкций.

>по субъективному мнению David Turner'а их алгоритмы выдают лучшие результаты, чем байткод

Это потому, что их (freetype) BCI работает хуже, чем, к примеру у M$: без сглаживания в некоторых местах (tahoma,'w',11ppm) умудряется даже некоторые точки местами поменять и соответственно там, где действительно качественно инструктированные шрифты выглядят идеально (в отфтопике) - freetype умудряется их покарёжить, что и даёт право создателям freetype говорить вышесказанное

>Это потому, что их (freetype) BCI работает хуже, чем, к примеру у M$: без сглаживания в некоторых местах (tahoma,'w',11ppm) умудряется даже некоторые точки местами поменять и соответственно там, где действительно качественно инструктированные шрифты выглядят идеально (в отфтопике) - freetype умудряется их покарёжить, что и даёт право создателям freetype говорить вышесказанное

Не могли-бы вы привести один скриншот хорошего качества, где можно посмотреть пример "идеально" выглядящего шрифта из офтопика (желательно чтобы был виден интерфейс и текст в самом приложении) , и так-же для сравнения кокой-нибудь из тех, "ужасных" шрифтов изуродованных Дэвидом Тёрнером. Спасибо.

напиши в tahoma-8 (при 96dpi это 11ppm) без сглаживания строку 'vw8' (подсказка: все символы должны быть симметричными по оси y)

>напиши в tahoma-8 (при 96dpi это 11ppm) без сглаживания строку 'vw8' (подсказка: все символы должны быть симметричными по оси y)

Как-же я ей напишу, если у меня ее нет? Стал-бы разве просить скриншот выложить?

>the original four Times New Roman font files available in Windows had been developed by a team of 12 people working at Monotype for a year.

Такими темпами хинтинга в Dejavu мы нескоро дождёмся... А надо ли? ;)

>Такими темпами хинтинга в Dejavu мы нескоро дождёмся... А надо ли? ;)

Навряд ли стоит ждать - быстрее появятся дисплеи с матрицей ~300dpi и проблема перестанет быть, тем более, что такие матрицы уже работают в телефонах : http://www.engadget.com/2007/02/12/toshibas-g900-and-e01-with-windows-mobile-6/ Осталось увидеть их в настольном исполнении.

Я боюсь цена у такой матрицы будет невероятная.

>Я боюсь цена у такой матрицы будет невероятная.

Вполне возможно первое время она и будет несколько кусаться, но если наладят массовый выпуск, и подключится несколько крупных производителей то цена быстро придет в норму - так ведь всегда бывает. Я очень надеюсь, что не будет повторения истории, как с 200dpi моделью от Viewsonic. В любом случае увеличение dpi до значения 300 и выше - есть единственный способ довести качество изображения на дисплее до комфортного уровня, а все эти сглаживания, хинтинг и т.д. есть временные уловки из серии - "На безрыбье.."

>/me врубил patented BCI и patented subpixel rendering в Fedora 7 ...

Пожалуй этого маловато будет... Ниже приведен примерный перечень
действий который я проделываю над freetype2, а еще обязательно
необходимо патчить libxft, ну и cairo если используете.

--- include/freetype/config/ftoption.h.old	2006-05-12 02:05:49.000000000 +0800
+++ include/freetype/config/ftoption.h	2006-10-02 01:22:50.000000000 +0800
@@ -436,7 +436,7 @@
   /*   Do not #undef this macro here, since the build system might         */
   /*   define it for certain configurations only.                          */
   /*                                                                       */
-/* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER */
+#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER
 
 
   /*************************************************************************/
@@ -448,7 +448,7 @@
   /* FT_PARAM_TAG_UNPATENTED_HINTING; or when the debug hook               */
   /* FT_DEBUG_HOOK_UNPATENTED_HINTING is globally activated.               */
   /*                                                                       */
-#define TT_CONFIG_OPTION_UNPATENTED_HINTING
+#undef TT_CONFIG_OPTION_UNPATENTED_HINTING
 
 
   /*************************************************************************/
@@ -480,7 +480,7 @@
   /*   http://partners.adobe.com/asn/developer/opentype/glyf.html          */
   /*   http://fonts.apple.com/TTRefMan/RM06/Chap6glyf.html                 */
   /*                                                                       */
-#undef TT_CONFIG_OPTION_COMPONENT_OFFSET_SCALED
+#define TT_CONFIG_OPTION_COMPONENT_OFFSET_SCALED
 
 
   /*************************************************************************/

--- freetype-2.2.1/modules.cfg.orig	2006-07-07 21:01:09.000000000 -0400
+++ freetype-2.2.1/modules.cfg	2006-07-07 21:01:54.000000000 -0400
@@ -110,7 +110,7 @@
 AUX_MODULES += cache
 
 # TrueType GX/AAT table validation.  Needs ftgxval.c below.
-# AUX_MODULES += gxvalid
+AUX_MODULES += gxvalid
 
 # Support for streams compressed with gzip (files with suffix .gz).
 #
@@ -124,7 +124,7 @@
 
 # OpenType table validation.  Needs ftotval.c below.
 #
-# AUX_MODULES += otvalid
+AUX_MODULES += otvalid
 
 # Auxiliary PostScript driver component to share common code.
 #

--- freetype-2.2.1/src/psaux/psobjs.c~	2006-04-26 16:38:17.000000000 +0200
+++ freetype-2.2.1/src/psaux/psobjs.c	2006-09-10 15:01:13.000000000 +0200
@@ -165,6 +165,11 @@
       return PSaux_Err_Invalid_Argument;
     }
 
+    if ( length < 0 ) {
+      FT_ERROR(( "ps_table_add: invalid length\n" ));
+      return PSaux_Err_Invalid_Argument;
+    }
+
     /* grow the base block if needed */
     if ( table->cursor + length > table->capacity )
     {

diff -rup freetype-2.2.1.orig/src/autofit/aflatin.c freetype-2.2.1/src/autofit/aflatin.c
--- freetype-2.2.1.orig/src/autofit/aflatin.c	2006-08-22 22:30:15.396263448 +0800
+++ freetype-2.2.1/src/autofit/aflatin.c	2006-08-22 22:32:01.469137920 +0800
@@ -1344,14 +1344,14 @@
      *  We snap the width of vertical stems for the monochrome and
      *  horizontal LCD rendering targets only.
      */
-    if ( mode == FT_RENDER_MODE_MONO || mode == FT_RENDER_MODE_LCD )
+    if ( mode == FT_RENDER_MODE_MONO )
       other_flags |= AF_LATIN_HINTS_HORZ_SNAP;
 
     /*
      *  We snap the width of horizontal stems for the monochrome and
      *  vertical LCD rendering targets only.
      */
-    if ( mode == FT_RENDER_MODE_MONO || mode == FT_RENDER_MODE_LCD_V )
+    if ( mode == FT_RENDER_MODE_MONO )
       other_flags |= AF_LATIN_HINTS_VERT_SNAP;
 
     /*

--- freetype-2.3.0/include/freetype/config/ftoption.h.spf	2007-01-18 14:27:34.000000000 -0500
+++ freetype-2.3.0/include/freetype/config/ftoption.h	2007-01-18 14:27:48.000000000 -0500
@@ -92,7 +92,7 @@
   /* This is done to allow FreeType clients to run unmodified, forcing     */
   /* them to display normal gray-level anti-aliased glyphs.                */
   /*                                                                       */
-/* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
+#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
 
 
   /*************************************************************************/
===================================================================
RCS file: /var/lib/cvs/sources/freetype/freetype2/src/base/ftbitmap.c,v
retrieving revision 1.17
retrieving revision 1.18

diff -u -r1.17 -r1.18
--- freetype/freetype2/src/base/ftbitmap.c	2007/03/29 11:56:21	1.17
+++ freetype/freetype2/src/base/ftbitmap.c	2007/04/06 08:19:04	1.18
@@ -149,15 +149,15 @@
       if ( bit_last < bit_width )
       {
         FT_Byte*  line  = bitmap->buffer + ( bit_last >> 3 );
+        FT_Byte*  end   = bitmap->buffer + pitch;
         FT_Int    shift = bit_last & 7;
         FT_UInt   mask  = 0xFF00U >> shift;
         FT_Int    count = height;
 
 
-        for ( ; count > 0; count--, line += pitch )
+        for ( ; count > 0; count--, line += pitch, end += pitch )
         {
           FT_Byte*  write = line;
-          FT_Byte*  end   = line + pitch;
 
 
           if ( shift > 0 )

--- src/truetype/ttgload.c
+++ src/truetype/ttgload.c
@@ -271,7 +271,11 @@
 
     n_points = 0;
     if ( n_contours > 0 )
+    {
       n_points = cont[-1] + 1;
+      if ( n_points < 0 )
+        goto Invalid_Outline;
+    }
 
     /* note that we will add four phantom points later */
     error = FT_GLYPHLOADER_CHECK_POINTS( gloader, n_points + 4, 0 );
@@ -682,7 +686,7 @@
     FT_GlyphLoader  gloader = loader->gloader;
     FT_Error        error   = TT_Err_Ok;
     FT_Outline*     outline;
-    FT_UInt         n_points;
+    FT_Int          n_points;
 
 
     outline  = &gloader->current.outline;
@@ -709,7 +713,7 @@
       /* Deltas apply to the unscaled data. */
       FT_Vector*  deltas;
       FT_Memory   memory = loader->face->memory;
-      FT_UInt     i;
+      FT_Int      i;
 
 
       error = TT_Vary_Get_Glyph_Deltas( (TT_Face)(loader->face),

>Also, I still don't understand why Debian and Ubuntu keep distributing patent-infringing code in FreeType, while they keep MP3 and DVD playback out of their normal installs.

Потому-что за пределами пиндосстана все же есть жизнь. :D

>My experience is that this attitude leads developers to choose very sophisticated and generic designs that are extremely difficult to retrofit into something efficient later, because so many layers in the code depend on them.

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

http://www.scantips.com/no72dpi.html

http://img231.imageshack.us/img231/3538/82340817er9.png

>October 9, 2009

вот он, вендекапец и конец света ;-)

> Я боюсь цена у такой матрицы будет невероятная.

Dell Inspiron 9400 с матрицей 1920x1200/17" стоит сильно меньше двух тысяч, при неплохой остальной начинке. Эффективное разрешение получается 128dpi. Вот прям щас в него смотрю. У всяких мелких устройств (12"/1280x800) - тоже около того.

Так что около-200dpi-ные железки будут уже скоро, хочется надеяться. В виде 14" Full HD ноутов, и будут они дорогие, но не заоблачно.

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

Сглаживание, хинтинг - это интеллектуальные способы решения проблемы, а предлагаемые тобой (и не только) железячные - "в лоб". Ты хоть представляешь себе, какая должна быть пропускная посособность канала видеокарта-монитор для передачи 300dpi-изображения диагональю, к примеру, 17"? В квадрат возводить умеешь? Думаешь обновлением монитора всё и закончится? Или мозги человеку даны для каких-то других целей?

> Ты хоть представляешь себе, какая должна быть пропускная посособность канала видеокарта-монитор для передачи 300dpi-изображения диагональю, к примеру, 17"?

Ну, ээ.

17" - это ~15"x10", т.е. 4500x3000 точек, т.е. 13,5Mx24 бит на кадр, т.е. 324*60 мегабит/сек, т.е. 200 гигабит в секунду ;)

Вполне себе, в общем, достижимая скорость, особенно если видеокарту в монитор встроить.

>Сглаживание, хинтинг - это интеллектуальные способы решения проблемы, а предлагаемые тобой (и не только) железячные - "в лоб". Ты хоть представляешь себе, какая должна быть пропускная посособность канала видеокарта-монитор для передачи 300dpi-изображения диагональю, к примеру, 17"? В квадрат возводить умеешь? Думаешь обновлением монитора всё и закончится? Или мозги человеку даны для каких-то других целей?

Как гласит древняя суфийская мудрость - "Сколько обезьяна не хитрит, а жопа все равно голая". Все эти так называемые вами "интеллектуальные" способы все равно остаются уловками, и не важно где их сработали - в майкрософт ли, либо в эппл или freetype, да и результаты они дают мягко говоря довольно посредственные. А железячный способ остается единственно-возможным решением (как всегда). А, что касается пропускной способности - так я даже и углубляться в рассчеты особо не стану - возьмем к примеру Sony Vaio UX, который имеет приблизительно желаемый dpi при диагонали 4,5", и все это счастье великолепно работает на задрипанном встроенном 945GM. Востребованные вами 17" больше по-площади приблизительно в девять раз, следовательно потребуют увеличинной девятикратно пропускной способности. Такой возможностью обладают современные ширпотребные GeForce 79**, а серия 8*** превосходит ее наверное двукратно - и это уже сегодня, а пока такие матрицы станут массовыми - мощность видеокарт приумножится еще больше.

>http://www.scantips.com/no72dpi.html

Не совсем понимаю, как это может помочь нарисовать символ, ну скажем 3х3мм требующий для нормального построения 1256 точек, на матрице, имеющей в лучшем случае физически 128 точек (на 9 квадратных мм)?

>А железячный способ _остается_ единственно-возможным решением (как всегда).

покажи мне _существующее сейчас_ решение по адекватной цене (варианты из "светлого будущего" не предлагать)

>что касается пропускной способности - так я даже и углубляться в рассчеты особо не стану

>Такой возможностью обладают современные ширпотребные GeForce 79**, а серия 8*** превосходит ее наверное двукратно - и это уже сегодня, а пока такие матрицы станут массовыми - мощность видеокарт приумножится еще больше.

8800GTS: 2048*1536*85hz*24bit = ~ 6.4Гбита, HDMI к примеру - 10,8Гбит. Выше написано было, что для 17"*300dpi потребуется 200Гбит: не кажется ли маразматичным поднимать аппаратные требования на порядок _только_ ради "тру"-отображения шрифтов? Никто не спорит, что это именно "тру", но для реализации таких мониторов/интерфейсов могут потребоваться годы + куда более изощрённые технологии и они с большой долей вероятности тоже будут запатентованы (как и большинство новационных аппаратных решений)

Начнём с того, что я не совсем понимаю, при чём тут вообще dpi и почему весь лор о них томно вздыхает, разговаривая о мониторах. Насколько я понимаю, речь нужно вести о разрешении. То-есть, 21'' монитор с разрешением, скажем, 3000х2000 сглаживания бы уже и не требовал, ибо "ступеньки" при таких мелких пикселах были бы уже не видны? Это вопрос к людям, понимающим что-то в этой теме.

>ачнём с того, что я не совсем понимаю, при чём тут вообще dpi и почему весь лор о них томно вздыхает, разговаривая о мониторах. Насколько я понимаю, речь нужно вести о разрешении. То-есть, 21'' монитор с разрешением, скажем, 3000х2000 сглаживания бы уже и не требовал, ибо "ступеньки" при таких мелких пикселах были бы уже не видны? Это вопрос к людям, понимающим что-то в этой теме

Ну, как причём dpi? Важен именно dpi, и ничего больше - не имеет значения какого размера экран, имеет значение его разрешающая способность которая на современных мониторах явно не достаточна. А "просто о разрешении" говорить нет смысла - берем два монитора с одинаковым разрешением 1024х768, один с диагональю 5", другой с 50" На каком из них изображение будет лучше? (при условии наблюдения с одинакового разумного расстояния). Поэтому говорить необходимо именно о разрешающей способности т.е. dpi. Возьмем для примера один символ размером 8pt (~3mm) под который на 20" с ~100 dpi матрице будет выделена область размером 12х12=144 точек. Попробуйте таким небольшим количеством пикселей передать наклонные линии и окружности без искажений. И возьмем матрицу 300dpi, на которой под тот-же символ уже будет отведено 1296 точек - вполне хватит, чтобы передать все закругления и наклоны без искажений и ступенек.

Вы текст по ссылке вообще читали? Там долго и с примерами объясняют, почему dpi на мониторе нет и быть не может. Детализация на мониторе передаётся пикселами.

А все патчи увидеть можно? А то я находил, но только старые и изменений было много. Не рискнул руками доводить...

>800GTS: 2048*1536*85hz*24bit = ~ 6.4Гбита, HDMI к примеру - 10,8Гбит. Выше написано было, что для 17"*300dpi потребуется 200Гбит...

Ну, не 200Gbit а : (4500 х 3000 * 24 * 60) / 1024^3 = 18Gbit/sec. А реальный поток будет меньше намного. Интерфейс HDMI обеспечивает 10,2Gbit/sec 48bit. А пропускная способность видеопамяти Geforce 79** - 50Gbit, а у 8*** - 100Gbit. И все это доступно уже сегодня.

>Не кажется ли маразматичным поднимать аппаратные требования на порядок _только_ ради "тру"-отображения шрифтов?

Нет, не кажется. Во-первых ничего сверх-естественного делать не приходится - практически все необходимое уже существует. А во-вторых - "тру-отображение-шрифтов" - является первостепенной задачей, т.к. прочтение и написание различных текстов - является основным занятием любого пользователя. И я думаю, что оправданным будут любые затраты, которые позволят довести качество отображения шрифтов хотя-бы до пресловутого порога в 300 dpi. Никому-же не кажется маразматичным, что компания майкрософт подняла аппаратные требования на порядок ради свистелок, и не дав практически ничего нового и полезного. А тут такое дело, как шрифты... Наконец-то можно будет использовать serif по-назначению.

>Вы текст по ссылке вообще читали? Там долго и с примерами объясняют, почему dpi на мониторе нет и быть не может. Детализация на мониторе передаётся пикселами.

Ну, мало-ли что-где написано... Многие любят заниматься словоблудием, но сути дела это совершенно не меняет. Хотите называйте : dot, drop, point, pixel, зерно - как угодно, в любом случае речь идет о наименьшей единице из которой составлено изображение. И смысл очень простой - чем из большего количества этих самых единиц составлено изображение - тем оно четче, плавнее и детализированнее выглядит, а на чем оно там - на бумаге, фотопленке, ткани или мониторе - без разницы. А еще если этих атомов будет недостаточно, как в случае с мониторами - мы получим ужасные шрифты с "лесенкой", костыли в виде суб-пикселей, хинтингов и прочих, в принципе никому не нужных патентованных ухищрений.

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

Я использую Arch, и патчи беру отсюда : http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/freetype2/?cvsroot=Current&a...

и еще вот этот : http://aur.archlinux.org/packages/freetype2-cleartype/freetype2-cleartype/fre...

Для libxft : http://aur.archlinux.org/packages/libxft-cleartype/libxft-cleartype/libXft-2....

Для cairo-1.4.8 (для 1.4.10 не пошло, пока еще не разобрался) : http://aur.archlinux.org/packages/cairo-cleartype/cairo-cleartype/cairo-1.2.4...

>Во-первых ничего сверх-естественного делать не приходится - практически все необходимое уже существует...

...но ничего не делается, а ведь всё так просто

>И я думаю, что оправданным будут любые затраты, которые позволят довести качество отображения шрифтов хотя-бы до пресловутого порога в 300 dpi.

любые - это очень громко сказано, где и когда это можно будет купить за разумные деньги?

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

кажется, очень многим

>костыли в виде суб-пикселей, хинтингов и прочих, в принципе никому не нужных патентованных ухищрений.

будь уверен: в том чудо-мониторе их будет на порядок больше

Даже знакомые виндозники соглашаются, что оффтопик рендерит шрифты зело-галимо по сравнению с линуксом (то есть, с freetype с авто-хинтингом).

Твоим друзьям, наверное, стоит очки купить.

Автохинтинг — это же полная жопа. Зря что ли рзработчики нормальных шрифтов хинты создают?