- 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]
Follow us!
Т.е. за 2.83464 и 28.3464 ты уверен?
Напомнило код про invsqrt, где threeHalves было с именем, а какая-то жёсткая битмаска прям так захардкожена.
А 1.3 это просто какая-то питушня, наверное, это должно было быть 3.1, то есть число пи
а сделано это для того, чтобы в случае чего их можно было менять независимо друг от друга
На "обычных" мониках вроде как 96 ppi. Т.е. 1 поинт для таких мониторов это 96 / 72 = 1.3(3) пикселя. Что не сильно отличается от экскрементального значения.
4к-бляди должны страдать и носить очки.
Скорее всего 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 редко когда отражает настоящий размер экрана, но тут уж джава не виновата
Попробуй нарисовать японский иероглиф в консоли чтобы колонки не распидорасило.
Именно поэтому я за "Аску".
Подтверждаю. Всё, что больше семи бит — не нужно.
шрифты это пиздец
локализация это пиздец
даты это пиздец
и сверху это всё отполировано футом хуя французского короля!
А чем рисуешь?
ну я тебе могу сказать, что последнее дерьмо, которое было про связку жабы и хтмл, это было 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?
З.Ы. EDID у встроенной панели нету, лол. Либо прыщи не знают, как его добыть.
Выглядит охуенно, кстати, пиксели еле-еле видны, только если сильно присмотреться.
Ладно, раз уж хуями меримся - 5.1" 1440x2560.
З.Ы. Именно поэтому у андроида "плотность" (для картинок) и "размер" (для лейаутов) - ортогональные вещи. И надо уметь обрабатывать обе.
Остальным приложухам достаточно ui scale (т.е. юзер сам выбирает как ему удобно) или класса плотности (обычное аля hdpi, ретина аля xdpi и т.п.).
У цветного есть щелевая маска или апертурная решётка, а сам люминофор разбит на тройки разных цветов (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 (или что там юзер себе в 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 норм, разницы не заметно.
Поделитесь.
Была идея запилить роутер, который бы фильтровал траффик, отпиздовывая на корню все запросы к неугодным ресурсам. Но я обжегся о сертификаты.
Потом я узнал, что такой функцианал есть в проге "AdVor", - но это прокси-сёрвер, там все запросы только через прокси.