Почему в Linux отстойные шрифты | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translated in draft, editing and proof-reading required.
If you do not want to register an account, you can sign in with OpenID.
Why Linux fonts suck | ||
The easily fixable stuff | — :-) — NeoNN — :) — leprechaunzz | |
Availability of fonts. Install at least msttcorefonts so that most web fonts of interest are available. | Доступность шрифтов. Установите хотя бы msttfcorefonts, и большинство интересующих web-шрифтов станут доступны. | |
Decent hinting. It looks like interpreting the bytecode hinting is no way to get correct results with the freetype grayscale or LCD hinting process. This is because of the Freetype implementation differs from Microsoft's implementation. | Неплохая подрисовка (хинтинг). Похоже, выполнение байткода подрисовки не дает правильных результатов во freetype с оттенками серого или подрисовки для ЖК. Это происходит потому, что реализация Freetype отличается от реализации Microsoft. | |
An example: The vanishing diagonal stem in z using small sizes of Times New Roman is a giveaway for using the bytecode. You need to use autohinting to avoid this type of artifacts, because the official bytecode for these fonts adjusts this stem to a line with no width and therefore no area. The monochrome rendering in both implementations interpretes this as a diagonal line, but the grayscale rendering calculates area and determines it has none: therefore it does not draw it. | Например: исчезающая диагональная черта в символе z, при использовании Times New Roman малых размеров, является явным признаком использования байткода. Вам необходимо использовать метод автоподрисовки(автохинтинг) для того, чтобы избавиться от подобных дефектов. Это происходит оттого, что официальное построение байткода для этих шрифтов приравнивает эту черту к простой линии -- без учёта ширины и, следовательно, без какой-либо площади. Монохромная отрисовка в обоих реализациях определяет это как диагональную линию, но прорисовка в режиме оттенков серого при вычислении площади определяет отсутствие таковой, и поэтому она не прорисовывается. | |
It looks likely that Microsoft fonts are meant to be drawn monochrome at all times, even when subpixel rendering is desired. There seems to be numerous artifacts when grayscale rendering is used for small sizes. I do wonder how exactly Microsoft's implementation does do subpixel rendering, because it gets better results than Freetype ever does, at least for its own fonts. | Похоже, что шрифты от Microsoft изначально создавались для монохромной отрисовки -- даже тогда, когда нужна субпиксельная прорисовка. Появляется множество артефактов при прорисовке шрифтов маленького размера в режиме градаций серого. Я не представляю, как именно реализация Microsoft делает субпиксельную прорисовку, но в итоге мы получаем результат гораздо лучший, нежели тот, который мы можем видеть у Freetype, по крайней мере для "родных" шрифтов. | |
My theory is that it does it all in the final resolution of the glyph, and and the only difference is that the rasterizer differs: it gets instructions to draw a line from (0,0) to (5,5), say, and this part is subpixel aware and it knows how to smoothly do this. In contrast, freetype generally renders the font with 3x the horizontal resolution in grayscale and then converts the pixel values to RGB components and does a bit of FIR filtering to spread the average energy across 3 pixels. | Моя теория такова, что оба метода делают это при завершающем анализе глифа (пиксельного символа) с той лишь разницей, что используются разные алгоритмы растеризации (подгонки символа под конкретное разрешение): в методе Microsoft он получает команду нарисовать линию, скажем, от (0,0) до (5,5), при этом зная, как субпиксельно нарисовать эту линию так, чтобы она получилась наиболее гладкой, а в противоположность ему Freetype обычно прорисовывает шрифт, трижды больший по горизонтали, в режиме градаций серого, а потом конвертирует пиксельные значения в режим RGB и производит небольшую FIR-коррекцию, что приводит к усреднению каждых трёх смежных пикселей. | — >> в методе Microsoft он получает команду нарисовать линию, скажем, от (0,0) до (5,5), при этом зная, как субпиксельно нарисовать эту линию так, чтобы она получилась наиболее гладкой ужасный кусок, если у кого-то есть светлые идеи по его коррекции -- вэлкам =) — nanoflooder — FIR filtering - это применение фильтра с конечной импульсной характеристикой, finite impulse response. Не стоит переводить это выражение как "коррекцию". — real-dummy |
Know your subpixel order. If you use monitors in pivot position, the true order of subpixels change. You have to use the vertical RGB or BGR mode. You can use any magnifying tool, such as looking through binoculars in reverse (with ocular 1-2 cm from the screen) to see the subpixel order, or you can trust your eyes for what looks less coloured when you try both. | Узнайте в каком порядке у вас расположены элементы пикселов. Если пользуетесь мониторами в повёрнутом положении, реальный порядок расположения элементов пиксела меняется. Вам требуется использовать либо RGB или же BGR режим. Когда пробуете оба режима, можете использовать какие угодно увеличивающие приспособления, например просмотр через бинокль в обратном направлении (на расстоянии 1-2 см от экрана), чтобы увидеть имеющийся у вас порядок расположения элементов пиксела, или же можете довериться своим глазам в определении какой из них выглядит менее цветастым. | — кошмар... опять же, если у кого-то есть хорошие идеи по устранению косноязычия в этом абзаце - сразу же делайте это, у меня, по-моему, это не очень получилось. — nanoflooder |
— Фигасе, да наоборот в винде отстой — ivan.borzenkov