1. Java / Говнокод #27011

    +1

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    9. 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]

    Запостил: MAPTbIwKA, 08 Октября 2020

    Комментарии (103) RSS

    • какой experiementation))
      Ответить
      • Угу. Между пикселями и физическим размером (в сантиметрах и т. п.) соотношение не фиксированное, а зависит от плотности (в dpi). Автор, видимо, подобрал это соотношение на глаз и решил, что так будет всегда.
        Ответить
    • > Not sure about 1.3

      Т.е. за 2.83464 и 28.3464 ты уверен?

      Напомнило код про invsqrt, где threeHalves было с именем, а какая-то жёсткая битмаска прям так захардкожена.
      Ответить
      • показать все, что скрытоvanished
        Ответить
      • 2.83 на коэффициент эйлера похоже, а 28.34 — на десять коэффициентов эйлера )))

        А 1.3 это просто какая-то питушня, наверное, это должно было быть 3.1, то есть число пи
        Ответить
        • 2.834 у него миллиметры, а 28.34 - сантиметры

          а сделано это для того, чтобы в случае чего их можно было менять независимо друг от друга
          Ответить
    • 1 point = 1/72 in

      На "обычных" мониках вроде как 96 ppi. Т.е. 1 поинт для таких мониторов это 96 / 72 = 1.3(3) пикселя. Что не сильно отличается от экскрементального значения.
      Ответить
      • показать все, что скрытоvanished
        Ответить
      • показать все, что скрытоvanished
        Ответить
        • показать все, что скрытоvanished
          Ответить
          • показать все, что скрытоvanished
            Ответить
          • >То есть point 1/72 дюйма "у нормальных людей", но на самом деле не совсем так.


            Скорее всего Swing это НЕ dpi aware, так что он всегда фигачит поинты из расчета 72 поинта на 96 пикселей, и уже винда потом скейлит пиксели
            Ответить
            • В общем в Java/Swing всё не совсем так, я разобрался.

              И фонты и рисовалки происходят в условных единицах 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 редко когда отражает настоящий размер экрана, но тут уж джава не виновата
              Ответить
              • Блядь, как всё сложно. Именно поэтому я за «CLI».
                Ответить
                • > Именно поэтому я за «CLI»

                  Попробуй нарисовать японский иероглиф в консоли чтобы колонки не распидорасило.

                  Именно поэтому я за "Аску".
                  Ответить
                  • > Именно поэтому я за "Аску".
                    Подтверждаю. Всё, что больше семи бит — не нужно.
                    Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • картография это пиздец
                    шрифты это пиздец
                    локализация это пиздец
                    даты это пиздец

                    и сверху это всё отполировано футом хуя французского короля!
                    Ответить
                  • > кернинговые пары неправильно работают

                    А чем рисуешь?
                    Ответить
                    • показать все, что скрытоvanished
                      Ответить
                      • Речь про жабу?
                        Ответить
                        • показать все, что скрытоvanished
                          Ответить
                          • какой багор

                            ну я тебе могу сказать, что последнее дерьмо, которое было про связку жабы и хтмл, это было flying saucer, от которого как раз нахер отказались

                            а так щревты (а нам нужны были красивые пуксель пёрфект) тогда лечились (барабанная дробь в бубен) заменой одного ждк на другой (это притом, что в жабе как раз свои щревты, не системные)
                            Ответить
                            • насколько знаю, одна из причин, почему ЖБ вообще стали делать свой форк ждк - это именно шрифты
                              Ответить
        • >> Так что px != pixel

          Блядь, как всё сложно!

          К слову, в англоязычных странах по стандарту пункт равен 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/
            Ответить
            • > actual length of the king’s foot

              Блин, ну ещё бы по длине королевского хуя измеряли... Кстати, а после каждой замены короля все расчёты приходилось переделывать?
              Ответить
              • > Блин, ну ещё бы по длине королевского хуя измеряли...

                Плохая идея. Из-за особенностей человеческой психологии с каждым новым королём длина фута бы росла, пока не достигла мили.
                Ответить
                • миля это хуй короля
                  фут это хуй дофина
                  Ответить
                  • My dick cost a late night fee
                    Your dick got the HIV
                    My dick plays on the double feature screen
                    Your dick went straight to DVD
                    Ответить
              • нет, судя по всему, это стандартная величина, просто так называется

                кстати, всяких футов было дохера и больше в разных странах и даже в пределах одной страны
                Ответить
              • Кстати, как это читается?
                >pied du roi

                Пидурой?
                Ответить
              • У железнодорожников есть анекдот на тему, почему в России железнодорожная колея шире западноевропейской.

                Спрашивают инженеры у Николая Первого:
                –— Как в Европе чугунку будем класть или шире?
                —– Нахуй шире?

                Ну вот ровно на хуй шире и сделали.
                Ответить
                • > Кроме того, эта ширина колеи была удобна тем, что выражалась круглым числом — 5 футов
                  - то есть за ширину колеи взяли пять царских хуёв
                  Ответить
                  • А западноевропейская колея (1435 мм) — это две лошадиные задницы. Я серьёзно: её ширину приравняли к ширине колеи древнеримской повозки, которую можно было запрягать парным количеством лошадей.
                    Ответить
        • > В 1984-м году apple сказал, что 1 пиксель у нас равен 1 поинту.
          Так вот из-за кого размер экранных шрифтов теперь задается не в пикселях, а в пунктах. И все разъезжается.
          По хорошему, пункты в пиксели должна переводить программа с учетом физической плотности экрана и масштаба отображения. А для кнопок и менюшек это бессмысленно.
          Но, видимо, тогда так было проще. Ну и, наверное, не было формата типа теперешней веб-страницы, где текст сочетается с пиксельными картинками.
          Ответить
          • Размер шрифтов задается в пунктах со времен человека по имени Father Sébastien Truchet, сиречь с 1699-го года)

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

            Это правда. Ну вот у 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?
                  Ответить
                  • показать все, что скрытоvanished
                    Ответить
                    • Ну вот у меня 10" (!) планшетка с разрешением 1200х1920. Убунта юзает для неё 96 dpi. Да и десятка тоже вроде точно так же делала.

                      З.Ы. EDID у встроенной панели нету, лол. Либо прыщи не знают, как его добыть.
                      Ответить
                      • Лопатофон 6" (шесть дюймов) 1920x1080, кто меньше?
                        Выглядит охуенно, кстати, пиксели еле-еле видны, только если сильно присмотреться.
                        Ответить
                        • > кто меньше

                          Ладно, раз уж хуями меримся - 5.1" 1440x2560.

                          З.Ы. Именно поэтому у андроида "плотность" (для картинок) и "размер" (для лейаутов) - ортогональные вещи. И надо уметь обрабатывать обе.
                          Ответить
                • Походу, реальное значение dpi кроме дизайнеров и чертёжников никому и не нужно.

                  Остальным приложухам достаточно ui scale (т.е. юзер сам выбирает как ему удобно) или класса плотности (обычное аля hdpi, ретина аля xdpi и т.п.).
                  Ответить
                  • показать все, что скрытоvanished
                    Ответить
                  • показать все, что скрытоvanished
                    Ответить
                    • Ага, на ЭЛТ просто размазывали пиксели по зёрнам. С большого расстояния любое разрешение смотрелось примерно одинаково чётко.
                      Ответить
                      • показать все, что скрытоvanished
                        Ответить
                        • У чёрно-белого «зёрна» совсем мелкие и расположены хаотично, как на фотоплёнке. На нём можно получить довольно произвольные разрешения. Естественным будет размер пикселя, равный диаметру луча.

                          У цветного есть щелевая маска или апертурная решётка, а сам люминофор разбит на тройки разных цветов (R, G, B). Для цветного «родной» будет плотность пикселей, равная плотности троек люминофоров. На практике же за ней не гнались, потому что довольно сложно скорректировать развёртку, чтобы пиксели точно попали на эти тройки.

                          Я упомянул диаметр луча. Монитор EGA (родное 640×350) в режимах CGA (320×200) реально уменьшал частоту развёртки, а поскольку фокусировка была рассчитана на 350 строк, между строками были заметные чёрные полосы. В VGA учли этот недостаток, и режимы CGA стали эмулироваться: луч пробегал 400 строк, но каждую строку кадра CGA рисовал два раза.

                          На многих мониторах с рекомендуемым разрешением 1024×768 или 1280×1024 можно было включить режим 1600×1200, однако, поскольку фокусировка была рассчитана на меньшее разрешение, луч цеплял соседние зёрна, и границы пикселей смазывались.
                          Ответить
                          • Хм, а почему бы не менять фокусирующее напряжение при смене разрешения? Или там какие-нибудь искажения полезут?
                            Ответить
                            • Бля, как ты заебал околожелезной хуйнёю своей!
                              Лучше прочитай, как взломать сапёр, удерживая shift.
                              Ответить
    • показать все, что скрытоТеперь то же самое на "PHP":
      $lengthMapping['pt']=strval(1);
      // Not sure about 1.3, determined by experiementation.
      $lengthMapping['px']=strval(1.3);
      $lengthMapping['mm']=strval(2.83464);
      $lengthMapping['cm']=strval(28.3464);
      $lengthMapping['pc']=strval(12);
      $lengthMapping['in']=strval(72);

      Обратите внимание: код выглядит гораздо элегантнее и компактнее, а также нет ебаной буквы "f" (не ёбаной, а именно ебáной).
      Ответить
    • Раз уж речь зашла об экранах и разрешениях...

      Кто-нибудь в курсе, в каком формате правильно выводить цветные пиксели в окно - с линейным маппингом или как sRGB?
      Ответить
      • показать все, что скрытоvanished
        Ответить
        • Ну не только про вулкан и опенгл, а вообще про обработку картинок и видео.

          Моники же вроде бы sRGB пространстве работают, чтобы тёмные детали лучше передавались.

          И если я например возьму цвета 0x808080 и 0xFFFFFF, то они нихуя не вдвое будут отличаються на глаз из-за этой нелинейности?
          Ответить
          • показать все, что скрытоvanished
            Ответить
            • показать все, что скрытоvanished
              Ответить
              • Блин, т.е. получается мне надо картинку на входе преобразовать из sRGB (или adobe, если дизайнер упоролся) в линейное.

                Затем делать все расчёты в линейном пространстве, иначе все цвета распидорасит нахуй даже от банальной попытки сменить яркость.

                А затем перед выводом преобразовать из линейного в sRGB (или что там юзер себе в ICC профиле понаставил), чтобы отменить все эффекты, которые произойдут в монике и показать именно то, что я задумал...

                Как-то так?
                Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • Если там по 8 бит на канал - всяко нелинейное. Линейные 8 бит походу будут выглядеть как говно.
                    Ответить
                    • да, всёименно так


                      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, и текут
                      Ответить
    • Кто чем блокирует вулкандр и прочие рекламные говна?
      Поделитесь.

      Была идея запилить роутер, который бы фильтровал траффик, отпиздовывая на корню все запросы к неугодным ресурсам. Но я обжегся о сертификаты.

      Потом я узнал, что такой функцианал есть в проге "AdVor", - но это прокси-сёрвер, там все запросы только через прокси.
      Ответить
      • Проще пареного хуя: составляешь список плохих сайтов и прописываешь им в "hosts" соответствие IP-адресу "127.0.0.1".
        Ответить
    • "ВКонтакте" перекрасил синюю полосу меню в белый цвет и назвал это новым дизайном.
      Ответить

    Добавить комментарий