- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
[code]
lengthMapping.put("pt", Float.valueOf(1f));
// Not sure about 1.3, determined by experiementation.
lengthMapping.put("px", Float.valueOf(1.3f));
lengthMapping.put("mm", Float.valueOf(2.83464f));
lengthMapping.put("cm", Float.valueOf(28.3464f));
lengthMapping.put("pc", Float.valueOf(12f));
lengthMapping.put("in", Float.valueOf(72f));
[/code]
Т.е. за 2.83464 и 28.3464 ты уверен?
Напомнило код про invsqrt, где threeHalves было с именем, а какая-то жёсткая битмаска прям так захардкожена.
Это JDK
>invsqrt
Это число Кармака?
А 1.3 это просто какая-то питушня, наверное, это должно было быть 3.1, то есть число пи
а сделано это для того, чтобы в случае чего их можно было менять независимо друг от друга
На "обычных" мониках вроде как 96 ppi. Т.е. 1 поинт для таких мониторов это 96 / 72 = 1.3(3) пикселя. Что не сильно отличается от экскрементального значения.
а у питуха может быть другой dpi, так-то
4к-бляди должны страдать и носить очки.
где res это Returns the screen resolution in dots-per-inch.
Тоись питух берет 1px за пиксель, 1pt за 1/72ю res итд
Но этот режим нужно явно включать.
Видимо код такое древнее говно, что css2 еще не было
В типографии размеры указывались в points: одна point -- 1/72 дюйма.
Люди привыкли так считать, и чтобы избразить текст высотой в дюйм они говорили "у него высота 72 поинта".
Но кроме текста были еще и картинки, где размер был в пикселях, и нужно было как-то замапить пиксели на дюймы.
Кроме того, экран же тоже был в пикселях.
В 1984-м году apple сказал, что 1 пиксель у нас равен 1 поинту.
То есть 72 пикселя это всегда 1 инч.
Это было удобно для типографии: что у тебя на экране, то и на печати.
Но MS понял, что люди обычно сидят от монитора дальше, чем от печатного издания, и им мелковато читать текст.
Тогда MS сказал, что у них будет 96 пикселов в дюйме.
То есть шрифт "1 дюйм" стал занимать не 72 а 96 пикселей, и стал крупнее.
Поскольку пиксель в идеальном мире равер размеру зерна (dot) ЭЛТ монитора, то стали говорить про
DPI (dots per inch), хотя правильнее было бы сказать PPI: Pixels per inch.
Если человек указывал шрифт в поинтах, то его нужно было умножить примерно на 1.3, чтобы получить такую же
высоту у MS:
96/72 = 1,3
Иными словами, 1px был равен 0.75 point: 96*0.75=72.
CSS2 явно сообщил нам:
pt: points — the points used by CSS are equal to 1/72nd of 1in.
px: pixel units — 1px is equal to 0.75pt.
То есть ЗАКРЕПИЛ отношение px/pt. Но так как Pt все еще 1/72 дюйма, то px теперь равен пиксеу только про 96 DPI.
Так что px != pixel на самом деле, если у тебя другой DPI:)
Most users are familiar with the idea of using point size to specify the size of glyphs in a font. This point size defines a measurement between the baseline of one line to the baseline of the following line in a single spaced text document. The point size is based on typographic points, approximately 1/72 of an inch.
То есть point 1/72 дюйма "у нормальных людей", но на самом деле не совсем так.
"pt" у них равен пикселу на нормальном DPI платформы.
То есть на винде он равен 96, но если я повышу DPI, то увеличится и шрифт.
Получить нормальный шрифт можно c помощью getScreenResolution() который вернет Returns the screen resolution in dots-per-inch.
Соответственно, его на винде надо поделить на 96, и умножить на их "поинты", чтобы получить настоящий размер шрифта в пикселях.
Так, шрифт 20 жабапоинтов будет 20 пикселей на DPI 96, а на DPI 120 он будет где-то 25.
При нолрмальном dpi на винде 1pt будет 1.333 "жабиных PT" или 1 нормальный pt (который 1/72 инча)
1 px будет 1 "жабин pt" или 1px виндовый.
То есть ровно так, как это сделано у браузера.
При пидарском же режиме (из этого поста) при нормадьном DPI
1pt будет 1 жабий pt или 1px
А 1px будет 1.33 жабих pt, или вообще хуй пойми что.
Скорее всего Swing это НЕ dpi aware, так что он всегда фигачит поинты из расчета 72 поинта на 96 пикселей, и уже винда потом скейлит пиксели
И фонты и рисовалки происходят в условных единицах user units. Это такие device independent пикеслы.
Далее, к компоненту привязан AffineTransform , который может как-то эти пиксели поскейлить.
По умолчанию для экранов (не для принтеров!) он их не скейлит никак, потому что считается, что экран примерно 72 точки на дюйм или как-то так.
Так что 1 поинт шрифта есть один user unit есть один пиксел. Оттуда он попадает видимо в GDI или API X11.
На прыще и XP вообще пофиг на dpi в этом случае, а вот Vista+ уже этот пиксель может поскейлить, ибо скейлит всё.
Но можно так же заказать getNormalizingTransform(), которая
Returns a AffineTransform that can be concatenated with the default AffineTransform of a GraphicsConfiguration so that 72 units in user space equals 1 inch in device space.
То есть пытается честно сделать user unit равной 1/72 инча.
И на винде, и на прыщах они берут DPI, и делять его на 72, и получают scale, на который потом умножают.
То есть ты рисуешь линию длиной 72pt (инч), а винда или X11 (Xft не используется, джава сама всё рендерит) тебе сообщает, сколько тебе нужно пикселей чтобы получить реальный инч.
Но тот инч, опять таки, виртуальный, потому что DPI редко когда отражает настоящий размер экрана, но тут уж джава не виновата
Попробуй нарисовать японский иероглиф в консоли чтобы колонки не распидорасило.
Именно поэтому я за "Аску".
Подтверждаю. Всё, что больше семи бит — не нужно.
Пиздец, шрифты это пиздец. У меня блядь вот кернинговые пары неправильно работают
шрифты это пиздец
локализация это пиздец
даты это пиздец
и сверху это всё отполировано футом хуя французского короля!
А чем рисуешь?
Вот оказалось, что кроме всего прочего, она не учиытвает кернинг, и напрмир заглавная "T" отталкивает следующую букву, образуя мустое место
Ну вон сначала оказалось, что нужно явно включать W3C режим через clientProperties, иначе .px в .css файле будет в 1.3 раза больше, чем нужно.
Теперь там не работает kerning, который Swing вообще-то поддерживает, но JEditorPane -- нет, и люди делают так
http://java-sl.com/gp_effects.html
Потом наверное окажется, что криво работает хинтинг или еще что
Оценить масштаб багра можно тут
https://bugs.openjdk.java.net/browse/JDK-8148746
До кучи HTMLEditorKit умеет только HTML 3.2 со всеми вытекающими.
Надо бы переделать на JCEF, но там есть свои проблемы
ну я тебе могу сказать, что последнее дерьмо, которое было про связку жабы и хтмл, это было flying saucer, от которого как раз нахер отказались
а так щревты (а нам нужны были красивые пуксель пёрфект) тогда лечились (барабанная дробь в бубен) заменой одного ждк на другой (это притом, что в жабе как раз свои щревты, не системные)
Блядь, как всё сложно!
К слову, в англоязычных странах по стандарту пункт равен 1/72,27 дюйма. Пункт, равный 1/72 дюйма, придумали в «Адобе», вероятно, потому что поняли, что плавающий питух — априори говно. Т. е. адобовский пункт равен 72,27/72 = 1,00375 британского/американского пункта.
Был ещё пункт Дидо, который равен 1/72 французского дюйма (который равен 2,706 см), т. е. 2,706/2,54 ≈ 1,066 адобовского пункта или 1,07 британского/американского пункта. Но его вроде сейчас уже нигде не используют, хотя формально на него ссылаются стандарты.
Так точно
The point is a typographic unit invented by Father Sébastien Truchet in 1699 to describe
the arithmetic progression of type sizes [276]. This unit, related to the Paris foot (pied
du roi, the actual length of the king’s foot), was redefined by Pierre-Simon Fournier
in 1664 and later by François-Ambroise Didot in 1783. Since the end of the nineteenth
century, the Anglo-Saxons have used the pica point [87]. The PostScript language sought
to simplify calculations by defining the point to be exactly 72 1 of an inch. Today we have
points of three different sizes: the pica point (approximately 0.351 mm), the Didot point2
(approximately 0.376 mm), and the PostScript point (approx. 0.353 mm)
Читаю вот эту книжечку сейчас: https://www.oreilly.com/library/view/fonts-encodings/9780596102425/
Блин, ну ещё бы по длине королевского хуя измеряли... Кстати, а после каждой замены короля все расчёты приходилось переделывать?
Плохая идея. Из-за особенностей человеческой психологии с каждым новым королём длина фута бы росла, пока не достигла мили.
фут это хуй дофина
Your dick got the HIV
My dick plays on the double feature screen
Your dick went straight to DVD
кстати, всяких футов было дохера и больше в разных странах и даже в пределах одной страны
>pied du roi
Пидурой?
Спрашивают инженеры у Николая Первого:
–— Как в Европе чугунку будем класть или шире?
—– Нахуй шире?
Ну вот ровно на хуй шире и сделали.
- то есть за ширину колеи взяли пять царских хуёв
Так вот из-за кого размер экранных шрифтов теперь задается не в пикселях, а в пунктах. И все разъезжается.
По хорошему, пункты в пиксели должна переводить программа с учетом физической плотности экрана и масштаба отображения. А для кнопок и менюшек это бессмысленно.
Но, видимо, тогда так было проще. Ну и, наверное, не было формата типа теперешней веб-страницы, где текст сочетается с пиксельными картинками.
>По хорошему, пункты в пиксели должна переводить программа с учетом физической плотности экрана и масштаба отображения.
Это правда. Ну вот у Apple Macintosh экран был как раз такого размера, что 72 пикселя на нем были размером с дюймовочку.
А у MS 72 поинта превращались в 96 пикселей. Причем "дюйм" тоже стал виртуальным, и зависел от размера экрана и разрешения.
> А для кнопок и менюшек это бессмысленно.
Да.
Это привело к багру: если при увеличении DPI просто менять кол-во пикселей в поинте, то шрифт выедет за пределы кнопки: кнопка-то в пикселях, а не в поинтах.
В XP так всё и работало, потому менять DPI в XP лучше бы не.
Начиная с Vista появилось два способа реакции на смену DPI:
* Если приложение НЕ dpi-aware (не стоит ключик в заголовке) то винда тупо скейлит всё: и пиксели и поинты.
* Если приложение dpi-aware, то оно само должно разбираться.
Выглядит позорно, к слову. Но всяко лучше, чем распидорашенные окошки во времена XP.
XP бы не распидорашивало, если бы так могли бы указывать ширины кнопок в поинтах, но в GDI так было нельзя, а если бы и можно было, то иконки то всё равно в пикселях.
А вот в Direct2D (поверх которого работает WPF) появился Device Independent Pixel, который равен 1/96 "виртуального дюйма" (в котором 72 пункта), и он зависит от DPI.
Алсо, посмотрел, как это в прыщах.
В прыщах есть DPI у сервера. Он сам скейлит шрифты, если ты рендеришь их на сервере.
А если ты рендеришь их через Xft (как примерно все сейчас делают), то есть ресурс Xft.dpi.
Если его установить, то он будет использоваться. Если нет, то Xft откатится к DPI сервера.
Этот ресурс перезаписывает гном если ему поменять скейлинг экрана.
Проверил на слаке:
* forefox и chrome читают Xft, но скейлят И картинки и текст (как винда)
* gvim скейлит только текст и размеры кнопок (полагаю, так делают Qt и GTK все). Иконочки остаются страые, и выглядят как говно
* xfontsel, xcalc, xterm без -fa (то есть все, кто рендерит шрифты на сервере) зависят только от DPI сервера, и меняют только размеры шрифтов
Так что XP/GDI слегка соснули у GTK и QT (там кнопки скейлятся), но в целом прыщи соснули у Vista-style scaling: скелйить и картинки и шрифт умеют только хром и файрфокс, а напрмиер gvim не умеет.
А вообще это всё говнище адское. DPI не имеет никакого отношения к количеству точек на дюйм. Там и дюйм-то блядь виртуальный.
Вот кстати да. Если на 13" монике с фуллхд въебать размеры в реальных дюймах, то там ничего не влезет. Т.е. высокая плотность не всегда означает, что мы хотим рисовать крупнее.
З.Ы. И для таких моников, скорее всего, репортится классическое 96?
Кстати, X умеет DPI посчитат сам.
Если ты ему задал размеры мона в инчах в конфиге, он может зная разрешение посчитать DPI.
А если нет, то может сходить в EDID за этой информацией. А если ее там нет, то откатится на странное значение 75 (видимо это что-то из времен сановых воркстанций). Ну это не важно: монов без EDID уже нет в природе
З.Ы. EDID у встроенной панели нету, лол. Либо прыщи не знают, как его добыть.
Выглядит охуенно, кстати, пиксели еле-еле видны, только если сильно присмотреться.
Ладно, раз уж хуями меримся - 5.1" 1440x2560.
З.Ы. Именно поэтому у андроида "плотность" (для картинок) и "размер" (для лейаутов) - ортогональные вещи. И надо уметь обрабатывать обе.
Остальным приложухам достаточно ui scale (т.е. юзер сам выбирает как ему удобно) или класса плотности (обычное аля hdpi, ретина аля xdpi и т.п.).
Просто пиши пунктах или пикселях (где=то они равны, где-то у них отношение 0.75), это все замапица потом в виртуальный дюйм из расчета 72 пункты на виртуальный дюйм, а он уже потом поскейлится пользователем вместе с остальным.
Класс нужен, чтобы подставить картинки @2?
Кстати, а скринщоты делаются-то в виртуальных пикселях, то есть ДО того, как их поскейлили или ПОСЛЕ?.
это потому что он из фреймбуфера пиздит прямо данные?
GDI++
Font.Font
unit [in]
Type: Unit
Optional. Element of the Unit enumeration that specifies the unit of measurement for the font size. The default value is UnitPoint.
UnitPoint Specifies that a unit is 1 point or 1/72 inch.
а мог бы быть
UnitDisplay Specifies display units. For example, if the display device is a monitor, then the unit is 1 pixel.
А вообще я за ЭЛТ: там просто умнеьшали разрешение, и текли
Я всё мог указывать в пикселях, и вообще не думать про DPI.
А если мне мелко, то я просто ставил 640x480, и все пиксели становились крупнее
Хотя наверное "родное" разрешение у ЭЛТ это пиксель равный зерну?
У цветного есть щелевая маска или апертурная решётка, а сам люминофор разбит на тройки разных цветов (R, G, B). Для цветного «родной» будет плотность пикселей, равная плотности троек люминофоров. На практике же за ней не гнались, потому что довольно сложно скорректировать развёртку, чтобы пиксели точно попали на эти тройки.
Я упомянул диаметр луча. Монитор EGA (родное 640×350) в режимах CGA (320×200) реально уменьшал частоту развёртки, а поскольку фокусировка была рассчитана на 350 строк, между строками были заметные чёрные полосы. В VGA учли этот недостаток, и режимы CGA стали эмулироваться: луч пробегал 400 строк, но каждую строку кадра CGA рисовал два раза.
На многих мониторах с рекомендуемым разрешением 1024×768 или 1280×1024 можно было включить режим 1600×1200, однако, поскольку фокусировка была рассчитана на меньшее разрешение, луч цеплял соседние зёрна, и границы пикселей смазывались.
Лучше прочитай, как взломать сапёр, удерживая shift.
Обратите внимание: код выглядит гораздо элегантнее и компактнее, а также нет ебаной буквы "f" (не ёбаной, а именно ебáной).
Кстати, зачем нужна буква "f"? "Java" такая тупая, что не может догадаться о дробности числа по наличию точки?
в перле нет ни на что разделений, лол
Увы, есть - существуют функции "parseFloat" и "parseInt" (последнюю я всегда заменяю на "*1").
>>>"в перле нет ни на что разделений, лол"
Это чудесно, но в остальном "Perl" - помойное говно. Поэтому я всё ещё за "PHP".
В меднолобой "Java" такое, поди, невозможно?
но красиво никак, да.
В котлине можно
Кто-нибудь в курсе, в каком формате правильно выводить цветные пиксели в окно - с линейным маппингом или как sRGB?
ты про вулкан?
Моники же вроде бы sRGB пространстве работают, чтобы тёмные детали лучше передавались.
И если я например возьму цвета 0x808080 и 0xFFFFFF, то они нихуя не вдвое будут отличаються на глаз из-за этой нелинейности?
Я не настоящий сварщик, но вот как я это понимаю.
sRGB это такое device-independent пространство RGB. Оно нужно, потому что "белый" на разных мониках выглядит по разному. Это sRGB пространство используют в форматах картинок.
А при выводе на экран можно конечно передать его как есть, надеясь, что моник его выведет верно. Но у крутых чуваков установлены ICC Profiles. Эти профайлы мапят sRGB в то, что на самом деле умеет монитор, и цвета получаются более честные.
Профиль можно также заембедить в каритнку.
Мапит условно говоря устройство внутри карты, называемое LUT: lookup table.
Причем насколько я понимаю, замапить можно и CMYK. И тогда картинка в формате CMYK (.psd так умеет) будет более "честно" отображаться.
То есть моник может уметь куда больше, чем sRGB. Просто sRGB это общий делитель того, что умели камеры, ЭЛТ и сканеры в 90-е.
Так что правильный способ это либо вывод sRGB напрямую, либо прогонка его через ICC Profile, если он есть.
Кроме sRGB есть куда более развернутый AdobeRGB: он умеет больше цветов, и .psd можно сохранять в нем.
При выводе картинки винда старается использовать профиль, если он есть,.
Если нет -- скатывается к sRGB
след коммент дам ссылки
Ссылки для самостоятельного изучения
MSDN про ICC Proflles и Windows Color Profiles:
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/basic-color-management-concepts
sRGB и bitmap (DIB) с подробным объяснением
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/srgb--a-standard-color-space
Трансформирование цвеов посредством профайла
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/createcolortransform
ICC profiles глазами юзера
https://pcmonitors.info/articles/using-icc-profiles-in-windows/
История появления sRGB и его реализация (объясняется gamma, LUT итд)
https://www.w3.org/Graphics/Color/sRGB.html
Сравнение AdobeRGB и sRGB
https://fstoppers.com/pictures/adobergb-vs-srgb-3167
Затем делать все расчёты в линейном пространстве, иначе все цвета распидорасит нахуй даже от банальной попытки сменить яркость.
А затем перед выводом преобразовать из линейного в sRGB (или что там юзер себе в ICC профиле понаставил), чтобы отменить все эффекты, которые произойдут в монике и показать именно то, что я задумал...
Как-то так?
To compose to the screen or perform floating-point operations, you need to work in the correct color space. We recommend that you perform floating point operations in a linear color space. Then, to present your images to the screen, convert the data to standard RGB data (sRGB, gamma 2.2-corrected) color space.
https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/converting-data-color-space
Ну а sRGB уже винда сама в профайл переведет, наверное. Если он выбран, и присобачен к экрану. У большинства пользователей НЕ присобачен, если они не проф дизайнеры. Сидят на своем sRGB, и текут
Видимо для таких моников должен быть вариант с выводом в 16 бит на канал или даже флоаты...
а, ты хочешь сказать, что переведя всё в sRGB ты урежешься? хочешь сразу из линейного в мон?
А в color management у меня нет профайлов для мона (ток для принтера)
ну я ломанулся тушканчиком в Ингтернет, и скачал "драйвер".
"Драйвер" состоял из
* .inf файла
* файла профиля .icm
* .cat (это подпись)
* .pnf (это скомпилированный .inf файл видимо)
.inf файл содержал много AddReg, записывающих мне имя моника и вендора, модлайны (которые ващет отлично читаются через EDID*!), и самое главное -- IC Profile.
Теперь у меня появился калор профайл
*EDID Viewer под винду показывает всё
А вот у новых походу уже сразу заводская калибровка под sRGB норм, разницы не заметно.
Думаю, что в 2020 профиль нужен в двух случаях
* ты супер крутой дизайнер, и тебе важен каждый оттенок
* твой мон умеет куда больше, чем sRGB. И ты хочешь смотреть .psdшки в AdobeRGB, и тебе нужно их как-то мапить в твой мон
Кстати, в винде есть встроенный калибровщик: там ты крутишь колесико, пока точки не сольются с фоном) И он создаст тебе профиль. А вроде бы были еще и внешние калибраторы
Поделитесь.
Была идея запилить роутер, который бы фильтровал траффик, отпиздовывая на корню все запросы к неугодным ресурсам. Но я обжегся о сертификаты.
Потом я узнал, что такой функцианал есть в проге "AdVor", - но это прокси-сёрвер, там все запросы только через прокси.