Представлен (https://www.mail-archive.com/freetype-announce@nongnu.o...) релиз FreeType 2.10 (http://www.freetype.org/), модульного шрифтового движка, предоставляющего единый API для унификации обработки и вывода шрифтовых данных в различных векторных и растровых форматах.
Наиболее значительным новшеством (https://sourceforge.net/projects/freetype/files/freetype2/2..../) в новой версии стало добавление поддержки контурных глифов с различными цветными слоями (варианты глифа в разных цветах, например, применяется для emoji). Добавлена порция новых функций для чтения и обработки данных COLR/CPAL в цветных слоях шрифтов OpenType: FT_Palette_Data_Get, FT_Palette_Select, FT_Palette_Set_Foreground_Color, FT_Get_Color_Glyph_Layer, FT_Bitmap_Blend. Полностью переработано руководство по API (https://www.freetype.org/freetype2/docs/reference/site/index...).
URL: https://www.mail-archive.com/freetype-announce@nongnu.o...
Новость: https://www.opennet.me/opennews/art.shtml?num=50335
От релиза к релизу все хуже. Сижу на древнем 2.5.5, до этого сколько мог сидел на 2.3.1. Но со временем приходится обновляться, потому что остальной софт перестает их поддерживать.
как по мне с 2.7 как раз нормально и можно сидеть) до этого был ужаснейший рендер (если не использовать патчи)
Может еще зависеть от fontconfig, его самого я обновляю, а вот правилам наверно лет 10 уже. Ничего в них не менял, беру от релиза 10-летней давности и перезаписываю ими от новых релизов.При этом пытался и freetype, и fontconfig синхронно обновлять от того, что предоставлено в дистрибутиве (Gentoo) мейнтейнерами - как по умолчанию, так и играя с флагами. Нет, все так же отвратительно. Возможно дело в том, что обе библиотеки подбивают под всякие Droid Sans, но субъективно мне они не нравятся, предпочитаю классику - Tahoma, Arial, MS Sans Serif и т. д.
Кто-нибудь может внятно объяснить как правильно настраивать шрифты? С помощью ftview подобрать наиболее приятные параметры и записать их в правила fontconfig? Или еще как-то? Проблема в том, что какие бы параметры на вышеуказанных шрифтах я не перебирал, они все страшные на новых версиях freetype, с различными патчами и без них.
> Кто-нибудь может внятно объяснить как правильно настраивать шрифты?Насколько я понимаю, исторически параметров всего два: субпиксельное сглаживание (rgba) и уровень хинтинга (hinting). Ну плюс сама настройка включения сглаживания (antialias). Всё остальное - временные решения под текущие версии; всяких FREETYPE_PARAMS два релиза назад не было и два релиза спустя тоже не станет.
В плане rgba режимов два:
- rgba=none: без субпиксельного сглаживания, как на современных macOS,
- rgba=rgb: с цветным ореолом на границах букв, но на маленьких размерах шрифтов буквы получаются чётче (для большинства десктопных мониторов, вообще зависит от структуры матрицы монитора).В плане hinting:
- hintnone: отсутствие подгонки размеров буквы под пиксельную решётку монитора; буквы выглядят немного "пушистыми" (и не всегда это приятно), однако форма букв наиболее близка к реальной. То есть, например, текст, сглаженный с hintnone на простом мониторе, будет ближе к тому, что пользователь увидит на ретине, чем шрифт, сглаженный с hintfull).
- hintslight: то же, что предыдущее, но с минимальной подгонкой букв под пиксельную сетку монитора. Буквы немного деформируются, что особенно заментно при маленьком размере шрифта.
- hintfull: максимальная подгонка букв под пиксельную сетку монитора. Буквы получаются более чёткими, однако их вид не очень похож на то, что дизайнер заложил в ttf файл. Кроме того, из-за сильной подгонки к пиксельной сетке, если этот режим включён в браузере, то если нажимать Ctrl-+ (увеличение масштаба), то толщина элементов букв в определённый момент увеличится очень резко, то есть нежирный шрифт 18 размера больше похож по толщине букв на жирный шрифт 16 размера. При использовании hintslight толщина увеличивается примерно равномерно, при hintnone - абсолютно равномерно, то есть при увеличении масштаба не будет такого, что в определённый момент покажется, что шрифты стали жирными.Лично мне нравится rgb+hintnone или none+hintnone. Если вы не привереда в плане точности отрисовки шрифтов, то можете использовать hintslight - текст будет выглядеть более чётким. Выбор между none/rgb всегда индивидуальный - кому-то нравятся более гладкие буквы (rgb), кому-то нравится, когда на границах букв нет радуги (none). Кроме того, rgb+hintfull, на мой взгляд, создаёт самый "радужный" текст, так что его бы я не рекомендовал.
> для большинства десктопных мониторов, вообще зависит от структуры матрицы монитораИмел ввиду, что для большинства десктопных мониторов rgba=rgb, а в общем случае конкретный выбор между rgb/bgr/vrgb/vbgr завиист от структуры субпикселей матрицы.
Спасибо за ликбез. Мне больше нравится сглаживание как в Винде, и ни один режим фритайпа не приближается к ней. Пусть буквы и пушистые, но они по крайней мере остаются ровными, без внезапных исчезновений половины завитушки у Й, одной из точек у Ё и так далее. Меньше всего подобных артефактов как раз у фритайпа 2.5.5 с совсем уж древними правилами fontconfig.
Удваиваю, после 2.7 слез с убунтового рендера и прочего самосбора. 2.7 просто манна небесная.
Без патчей не было (и нет) ClearType, ещё бы не шг было. Спасибо патентам и дистростроителям.
Теперь самопал впилили, более менее ничего.
Не можешь пересобрать - получай или Harmony (или вообще ничего). Пересобрал, получай мерзкий патентный, но не шг ClearType.
Вообще, можете заглянуть в ArchWiki или гентушную, там есть про fontconfig, и вообще всякого полезного.
какой странный аноним.Обычно люди без синдрома утенка, попробовав линукс, ставят на винду GDI++ (или как там оно называется, лет 7 уже не юзал), чтоб сделать нормальное сглаживание, как в этих наших линуксах, а этот наоборот клиартайп захотел...
> Обычно люди без синдрома утенка, попробовав линукс, ставят на винду GDI++Это те, кто исповедует линукс-бусидо. "Верх - это низ, белое - это чёрное, ошпариться мягким, а затем убить себя на глазах у изумлённого врага".
Начиная с 2.7 хрен отобьёшься от автохинтинга и сглаживания
конечно перестает - нужно ж отрисовать цветную какашку - а у тебя какой-то мамонтов кал, не позволяющий любоваться тонкими переходами тонов коричневого.
export FREETYPE_PROPERTIES=truetype:interpreter-version=35, Luke!
// b.
Неа. Не помогает.
Не помогает в чём?Сижу на Fedora 29 - рендеринг шрифтов такой же, как был >5 лет назад.
// b.
У меня это в /etc/X11/Xsession.d/99freetype. И всё стало на свои места после перехода с последней вменяемой версии 2.6.x на 2.7+.
оно, afair, нынче требует ключей сборки при компиляции, и, помнится, все равно уже где-то необратимо поломанно, так что можно уже и не париться.
скриншот в студию
Поддерживаю. Старый freetype, msttcorefonts (и убить всё остальное), отключение сглаживания и автохинтинга, включение интерпретатора байткода - на выходе имеем чистейшие, читаемые в любых размерах шрифты.
> msttcorefontsТолько croscore, только хардкор.
Ручных хинтов нет - в тoпку
> на выходе имеем чистейшие, читаемые в любых размерах шрифтыпока какая-нибудь мурзила или хромой не начнут просто отказываться работать, не в силах отрендерить цветную какашку. :-( Это уже очень скоро.
Да и пёс с ним, там один хрен сторонние шрифты отключены. Я как-то без цветных какашек жил и дальше проживу. Уж ближайшие лет пять-семь - точно, а там видно будет.
Обнови до последней версии и включи автохинтер вместо субпиксельной шняги -- становится не в пример лучше. А как в браузере поменять я не знаю, у него свои настройки.
Вот же мутанты!
Я им заслал патч для сборки Cmake вместо ихнего корового автотулса https://savannah.nongnu.org/bugs/index.php?55235
а они нифига не сделали.
А он (CMake) им нужен? Или кому-то еще, кроме вас?
Мне.
Мне. Я хочу, чтобы freetype собирался бы на любом калькуляторе.
так он и собирается - autoconf'ом.Без необходимости тащить на этот калькулятор миллиард зависимостей cmake, зависящих от cmake.
> так он и собирается - autoconf'ом.
> Без необходимости тащить на этот калькулятор миллиард зависимостей cmake, зависящих от
> cmake.Я лучше притащу зависимостей, они выкачаются и соберутся быстрее, чем отработает autoconf для freetype.
и шаг вправо, шаг влево от единственноверной платформы "linux 64bit/windows 7+" - вообще ничего не собирается, потому что стопиццотая зависимость зависит от cmake, а cmake без нее не собрать.правильно, "ваш новый стандарт".
> и шаг вправо, шаг влево от единственноверной платформы "linux 64bit/windows 7+" -
> вообще ничего не собирается, потому что стопиццотая зависимость зависит от cmake,
> а cmake без нее не собрать.И что это за зависимость? Что среди зависимостей cmake может помешать собрать его в *bsd, в minix, os/2, beos?
> правильно, "ваш новый стандарт".
Да. Забота о minority -- это хорошо, но до поры до времени. Если эта забота требует удвоить время сборки, то пускай minority заботятся о себе сами.
> Забота о minority -- это хорошо, но до поры до времени. [...] пускай minority заботятся о себе сами.Если бы ни это minority в конце 90х-начале 2000х, сидели бы вы сейчас на винде с их сборщиком (хз как называется), собирающим только под текущую версию винды, и радовались. Так, может, так и сделаете? Linux - это же такое minority - меньше пары процентов десктопа.
>> Забота о minority -- это хорошо, но до поры до времени. [...] пускай minority заботятся о себе сами.
> Если бы ни это minority в конце 90х-начале 2000х, сидели бы вы
> сейчас на винде с их сборщиком (хз как называется), собирающим только
> под текущую версию винды, и радовались.И чё? Я не буду следовать безумию, даже если носитель этого безумия мне симпатичен или я испытываю к нему благодарность.
И да, autotools родом из 80-х. Я бы счёл безумие социально опасным, если бы оно породило autotools в конце 90-х. В конце 90-х autotools _уже_ был не нужен, его уже _тогда_ использовали просто по старой памяти. Все проблемы, которые autotools решает, вполне возможно было решить без него, гораздо проще и эффективнее. И для этого даже не надо было запиливать meson, было бы достаточно удалить все копии autotools со всех носителей, так чтобы мейнтейнеры дистрибутивов, вместо того чтобы балду пинать, взяли бы и стандартизовали сборочное окружение, чтобы всё что надо знать на этапе сборки системы можно было бы извлекать из pkg-config или хидеров в /usr/include. Но устранить autotools было невозможным, а GNU при этом давила своим авторитетом и всем рекомендовала autotools, вместо того, чтобы взять на себя роль организатора, надавать пинков мейнтейнерам и допилить системы до уровня, когда кроссплатформенный билд не надо подпирать костылями из портянок на bash/m4 в десятки тысяч строк кода. И что мы видим? Мы видим что ситуация эскалировалось до невыносимого уровня, когда каждый пишет свою сборочную систему. Да здравствует GNU! Самый погнутый гну среди всех погнутых гну.
И, я отмечу, это вообще такое погнутое личностное свойство у gnu. Именно поэтому llvm смог подвинуть gcc. Не из-за лицензии, а из-за того, что gnu своим нежеланием дать к gcc внятный, документированный программный API, создала свободную нишу. Вакуум некоторое время держался вакуумом, туда заваливались лишь всякие мелочи типа sparse (а если бы не GNU то никакого sparse могло бы и не быть: стал бы Торвальдс его писать, если бы у него была возможность воспользоваться парсером gcc). А потом появился llvm. Я верю, что в течение лет пяти кто-нибудь подвинет emacs, потому что этот кусок окаменевшего дерьма уже лет двадцать-тридцать просит переписывания -- попытки его переписать давно предпринимались, но они были либо безумны (типа climacs), либо недостаточно радикальны (типа guile emacs). Но, опять же, emacs в том виде, в котором он есть, так и просит полной реимплементации. Кому вообще кроме Столлмана нужен этот местечковый диалект lisp'а, который не умеет ни в натив код, ни в ffi, ни в потоки с преемптивной многозадачностью? Который при этом не понимает Common Lisp'а и не позволяет подгружать его пакеты. В котором мысль о том, чтобы взять и запилить буфер, который будет хранить древовидные данные, отображаться деревом, и иметь приятный для GUI event-driven API, моментально трансформируется в то, что надо дерево отображать псевдографикой в текстовом буфере (насрав на вопросы эффективности расходования процессорных тактов), а вместо обработки event'ов предлагать клиентскому коду пихать хуки во все щели, чтобы не забывали каково оно было писать на ассемблере под DOS.
> Так, может, так и сделаете?
Нет. Старпёров, уходящих на покой, кто-то должен заменять. И вот он я тут такой.
> Linux - это же такое minority - меньше пары процентов десктопа.
И чё? cmake работает и на windows тоже. Причём получше всяких там autotools.
Диванный теоретик детектед. Ну или быдлокодер-формошлеп
> Диванный теоретик детектед. Ну или быдлокодер-формошлепНу да, ну да. Нечего сказать, включай ad hominem. Я знаю. Говорят работает. А ты как думаешь?
Какой тут ad hominem, просто видно, что человек некомпетентен в вопросе, но мнение высказать хочет
> Какой тут ad hominem, просто видно, что человек некомпетентен в вопросе, но
> мнение высказать хочетad hominem, дабы ты знал, это аргумент сводящийся к заявлению о личности оппонента. "мой оппонент некомпетентен" -- это тоже такой аргумент.
Я смотрю, вы не ищете легких путей.
> Я смотрю, вы не ищете легких путей.Что по вашему лёгких? Все сложности здесь решаются пакетным менагером. Все, кроме того, сколько времени это займёт. Сложности хождения по ссылкам и выкачивания -- это не мои сложности, потому что они автоматизируются.
Видимо, ИМ он тоже нужен, раз они CMakeLists.txt в репозиторий положили.
он там уже пять лет лежит, синенький, потому что мертвенький.
Выложил очередной парашутист-торопыга, "мне некогда вашего autoconf ждать, смузи киснет" (что он запускается один-единственный раз, если не менять структуру проекта, ему и невдомек), но допилить до рабочего состояния тоже было некогда.
Ну вот я и допилил до рабочего, настолько что у меня в системе оно без проблем работает.
И результат получается сопоставим.
Пришлось по всему мерзкому автотулсу лазать чтобы сделать рабочее.
Ваще да, я же не единственный кто собирает.
Автотулс сплошная боль.
А в чем, проблема, собственно? Чтобы собрать достаточно плюс-минус тех же configure && make.
В том, что:
1. автотулс собирают ощутимо дольше
2. автотулс - это ворох файлов с разными синтаксисом, а cmake в данном случае хватает и одного файла.
А кто систему сборки поддерживать будет? Ты?
Там поддерживать нечего, они мало что меняют.
Вся самая сложная работа уже сделана в патче.
> Там поддерживать нечего, они мало что меняют.
> Вся самая сложная работа уже сделана в патче.Напиши о патче где-то на реддите, найдутся однодумцы, которые ввяжутся в обсуждение и помогут протолкнуть патч. Жаль, когда полезная работа пропадает.
Полезная для кого? Если бы разработчикам была бы полезна, взяли бы давно
Я там не обитаю и не планирую, запости если не трудно.
Пиши им в рассылку, они больше по ней реагируют.
Что-то как-то боязно. Опять всё разлетится...
в виду отсутствия в системе возможность её сбэкапить, с последующим восстановлением в случаи сбоя?
переходит на систему с "контрольными точками", вместо юзанья "доса с кучей батников" :)
либо какой нибудь акронис/goback/... имеющий свойт вменяемый загрузчик и меню восстановления "как было час назад"
> с последующим восстановлением в случаи сбоя?
> либо какой нибудь акронис/goback/...Опять виндузня лезет …
Во-первых:
Восстановление из-за сбоя после смены шрифтового движка - это конечно сильно, но перефразируя одно изречение - "not everything is like Windows!"))Во-вторых:
у ябловодов вообще-то есть Машина Времени.В-третьих, удобные бэкапы придумали еще до основания акрониса с нортоном:
man dump restore
NAME
dump, rdump – file system backup
HISTORY
A dump utility appeared in Version 4 AT&T UNIX.NAME
restore, rrestore – restore files or file systems from backups made with
dumpHISTORY
The restore utility appeared in 4.2BSD.
В-четвертых, можно банально сделать бэкап пакета
% pkg create freetype2
Creating package for freetype2
и откатить, в случае чего, именно его.
nixos/guix самое то для таких "откатов"
ну а так вообще снэпшоты средствами lvm, btrfs или других файловых систем то можно настроить независимо от дистрибутива, в том числе и "при-триггерить" это дело к пакетному менеджеру
> dumpто то его никто не использует в линуксе! Удобное, да
а как его использовать в линуксе, если он существует только для ext*, и то не факт что совместим с самыми распоследними багофичами, и при этом иногда портит данные - потому что еще в 2004м Линус заявил что он ненужно, "tar'ом вот пользуйтесь, я же вот пользуюсь, у меня все работает" ?
>> dump
> то то его никто не использует в линуксе! Удобное, даЭто исключительно проблемы пользователей линукс.
Хотя говорят, в пингвине этих бэкапщиков все равно вагон и маленькая тележка.
только для использования всего этого зоопарка необходима рабочая операционка и целая файловая система, в отличии от ...
ни у кого нет своего загрузчика и резервирования места вне файловой системе
> только для использования всего этого зоопаркаНу да, пакетник с возможностью бэкапа пакета и бэкапщик уровня ФС - это слишком много выбора и поэтому зоопарк! Нужно что-то срочно упростить!
> необходима рабочая операционка и целая файловая система, в отличии от ...
И рабочий компьютер, да.
Во-первых:
рабочая ОС делается при первом бэкапе хоть при помощи dd (да-да, оно просто работает после клонирования, без необходимости шаманить с образом, в отличие от). Хоть разбивая диск как нравится, в любом гуе/куе/ассистенте и
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 da0
# mount /gpt/backuprootfs /mnt
# cd /mnt
# dump -0Lauf -C16 -b64 /gpt/rootfs | restore -rf -
у нас рабочий клон системы. Ух.
Хоть просто скачивая образ, ведь копии полноценной рабочей ОС почему-то никто не зажимает.Во-вторых
> целая файловая система, в отличии отИнтересно, что там за "целая файловая система" на кассетах раньше была?
> ни у кого нет своего загрузчика и резервирования места вне файловой систем
Предположим, у меня есть __свой__ загрузчик (хоть он все равно пинает загрузчик ОС), а вот наличие своего загрузчика у вас немного сомнительно ))
Ну и говорят что они бесплатны, а лайв образов вообще хоть одним местом ешь.
"Резервирование места вне файловой системы" - это наверное для лучшего убивания данных по ошибке, прихоти вашей "умной" ОСи или очередного шифровальщика с прямым доступом к диску?
Иначе такой изврат нафиг не сдался, ведь бэкапы превратятся в тыкву вместе с носителем.
Но повторю для специалистов из лагеря Окон - образ dump или тот же tar можно писать без всяких ФС, прямо на кассе^W флешку или хард. И даже читать обратно данные. Просто неудобно без ФС это делать.
видно, что не работали плотно не с акронимом, не с гоубеком...
dd, как и большенство(все?) перечисленное выше похерит всю проделанную работу после создания архива, в отличии от... :)вобщем радуйтесь своим кассетам и обилию свободного времени, пока dd/dump/rsync/прочее создают очередную копию архива системы и пользовательских данных.
p.s. а dd в состоянии востоновить один файл в том виде, в котором он был в пятницу, а dd запускался в среду и субботу?
> видно, что не работали плотно не с акронимом, не с гоубеком...Видно, что не пользовались возможностью мгновенного создания контрольных точек (снапшоты) в ФС, иначе бы не советовали нортоновское жручее пропритарное угребище над-ФСного уровня :)
> dd, как и большенство(все?) перечисленное выше похерит всю проделанную работу после создания архива, в отличии от... :)Неужто загрузочная ОСь для восстановления прокиснет и испортится? Нехорошо-то как!
Вообще-то, внезапно, все способы бэкапов, привязанные к конкретым временным или контрольным точкам, предполагают похерение изменений после создания такой точки. Принцип работы такой.
Кстати, dd не создает никаких архивов, оно работает немножечко на других принципах.Однако, четкое разделение ОС и пользовательских данных вполне позволяет не маятся дурью и делать бэкап системы хоть раз в месяц, хоть в полгода.
Список софта и настройки позволят восстановить при наличии интернета все полностью в течении получаса.
ls -laht /var/backups/pkg_dump/backups|head
total 528
drwxr-x--- 5 root wheel 512B 19 марта 00:56 ../
drwxr-x--- 2 root wheel 5,5K 19 марта 00:56 ./
-rw-r----- 1 root wheel 80B 19 марта 00:56 00_56__19_03_2019.dump
-rw-r----- 1 root wheel 80B 18 марта 00:06 00_06__18_03_2019.dump
-rw-r----- 1 root wheel 80B 17 марта 00:06 00_06__17_03_2019.dump
-rw-r----- 1 root wheel 80B 16 марта 00:48 00_48__16_03_2019.dump
-rw-r----- 1 root wheel 80B 15 марта 00:06 00_06__15_03_2019.dump
-rw-r----- 1 root wheel 80B 14 марта 00:06 00_05__14_03_2019.dump
Это вам не 6 часов Окошку апдейты скармливать ))> вобщем радуйтесь своим кассетам и обилию свободного времени, пока dd/dump/rsync/прочее создают очередную копию архива системы и пользовательских данных.
По натужной шутке о кассетах (после нахваливания умения некроникса обходиться без файловой системы, да), об обилии свободного времени и перемешиванию всего подряд видно чОткое знание о(б)суждаемых технологий.
Dump запускается в лайв-режиме, в фоне делает копию изменившихся с последнего бэкапа данных и закидывает их через сеть в инкрементальное хранилище.
Причем, оно работает на уровне ФС, поэтому не перебирает каждый файл по отдельности.
Восстановить, кстати, тоже можно без проблем в текущем режиме, в отличие от.
И да, rsync тоже не требует перевода диска в офлайн.> p.s. а dd в состоянии востоновить один файл в том виде, в
> котором он был в пятницу, а dd запускался в среду и субботу?git checkout.
Ну или "dump -i -". Достигается банальной лайв-синхронизацией хомяка рсинком на отдельный раздел и запуском dump -Lf1 $date$time по крону хоть каждые пять минут.
Или переводом хранилки на zfs и созданием мгновенных контрольных точек хоть раз в минуту с дублированием в сеть.
До первого багфикс-релиза это бета.
как будто после первого багфикс релиза не понадобятся второй, третий и до бесконечности.
Это релиз, они у нас все такие.
а я пользуюсь шрифтами от гугл и по привычке включаю мепиксельное сглаживание
Парни, а кто знает, какие еще параметры доступны в FREETYPE_PROPERTIES ?
Может настройки фаттанга еть.
Google сломался?Полный список: https://www.freetype.org/freetype2/docs/reference/site/ft2-p...
// b.
и как им пользоватся?
на не стандартном PPI есть проблема с фиттингом глифов и пиксели
можно как-то подобрать удобные значения?
Ссылка не алё. У меня 404 Not Found :(
Нашел. Правильная ссылка: https://www.freetype.org/freetype2/docs/reference/ft2-proper...
У меня в фулл хд при перезагрузке из винды в линукс всегда следует 5 минут глазного кретинизма на адаптацию. А обратно - это как ты оказывается всё это время болел коньюктивитом и не знал об этом и тут тебя вдруг волшебной палочкой тресь и вылечили в одно мгновение. И это при том, в линуксе у меня шрифты всегда больше. От 10 кегля и выше. Потому что на 9 уже начинает кашеварить в глазах, а на 8 вообще уже mess. В то время как на винде 9 кегль - стандартный рабочий.
> У меня в фулл хд при перезагрузке из винды в линукс всегда
> следует 5 минут глазного кретинизма на адаптацию. А обратно - это
> как ты оказывается всё это время болел коньюктивитом и не знал
> об этом и тут тебя вдруг волшебной палочкой тресь и вылечили
> в одно мгновение. И это при том, в линуксе у меня
> шрифты всегда больше. От 10 кегля и выше. Потому что на
> 9 уже начинает кашеварить в глазах, а на 8 вообще уже
> mess. В то время как на винде 9 кегль - стандартный
> рабочий.dpi одинаковый? Вангую, что нет.
И 96 как в винде был и расчётом по монитору тоже был - разницы на глаз нет. ШГ и ШГ.
https://pastebin.com/raw/GMTBrGz8 положить в ~/.config/fontconfig/fonts.confhttps://pastebin.com/raw/f3z00J6e положить в ~/.Xresources
Перезапустить иксы ну или перезагрузить компутерг.
поздравляем, теперь кроме ШГ у него еще и мыло мыльное.
Если у него мыло мыльное то пусть выкинет свой монитор в окно.
Когда сглаживание как в форточках завезут? Есть патчи которые клали на все патенты?