Ычан: [d | au / b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 26066)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5120 кБ.
  • Ныне 3637 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
410.png - (24.25KB, 500×500)
26066
No. 26066  
В сей нити мы упорядочиваем усилия по доработке местного движка.

Репозиторий: https://codeberg.org/FBE410/fbe-410
1. Для ваших предложений предназначена ветка public.
2. Только администрация 410чана решает, что в этом движке надо, а что не надо. Соответственно, не стоит излишне пропихивать всякие там революционные идеи. Одобренные потенциальные изменения перечислены на багтрекере (записи, созданные владельцами репозитория).
3. Тестирование предложенных изменений и развёртывание принятых ведётся при наличии у администрации свободного времени на это. Обычно это делается по выходным.
4. Код выложен как есть. Никаких неопубликованных скрытых функций и частей не существует.

Предыдущая нить: >>20450
104 сообщений пропущено. Показаны 50 последних сообщений
No. 26911  
>>26910
При установке движка есть несколько нюансов, которые нужно соблюсти, и несколько ошибок, которые нужно устранить. Также у нас не указаны необходимые движку PHP-модули, также отсутствуют некоторые миграции. Оно все мелочи, но накопительный эффект от этого есть - получается такое "испытание на входе в древний храм". Нужно иметь некоторый профессиональный опыт, чтобы все правильно интерпретировать, починить, и автобус завелся.
No. 26985  
Добавил забытый баг из предыдущей нити: https://bitbucket.org/Therapont/fbe-410/issues/54/suspend
No. 27043  
Лично моего опыта для рѣшенія проблем >>26911 не хватает, поэтому я просто воздерживаюсь и от установки FBE, и от сочинения такого кода FBE, провѣрка которого требовала бы именно установки FBE, а не подобных >>/dev/20224 средств и не «тут и так понятно, провѣрять нечего».
No. 27058  
Реквестирую https://bitbucket.org/Therapont/fbe-410/pull-requests/77 для учёта возможности неsRGBшной цвѣтности (контуры которой сообщениями >>/b/196588 и >>/b/199138 и их обсуждением намѣчены) примѣнительно к миниатюрам (thumbnails).

Попутно улучшил развёртыватель миниатюр.
No. 27066  
>>27043
А наличие в репозитории докер-файла для поднятия FBE помогло бы?
No. 27067  
>>27066

Мнѣ — нѣтъ, не помогло бы.

Они ж не ставятся на Windows 7.
No. 27068  
151312326915[1].jpg - (3.60KB, 295×33)
27068
А ни у кого не сохранились скрипты на пикрелейтед?
В старом треде за 2017 год только пастбины протухшие.
No. 27075  
Я рад видѣть запрос >>27058 удовлетворённым недѣлю назад (и исходный код вмёрдженным) — однако, наперёд терпеливо подождав недѣлю, теперь с любопытством поинтересýюсь: а когда эти правки кода собираетеся накатить непосредственно на 410чан? Есть какие-нибудь планы?
No. 27079  
Вижу, что исходный код пошёл въ дѣло.

Спасибо.
No. 27099  
Разработка движка в целом померла, но я завёл новую задачу: https://bitbucket.org/Therapont/fbe-410/issues/55/
No. 27133  
Сообщение >>26279 отправлено в прошлом году, сейчас вдругорядь июнь, а воз и нынѣ тамъ.

Во-первых, всё ещё нѣтъ новой AVIF-понимающей версіи ImageMagick на сёрверѣ 410чана.

Во-вторых, всё ещё нѣтъ упомянутой в сообщении >>26866 новой версіи GD в новой версіи PHP на сёрверѣ 410чана. Но кабы и была, то проблемы из постскриптума к сообщению >>26881 повылазили бы на свѣтъ Божій.

Что же в-третьих тогда? Можно оперѣться на возможности FFmpeg. Однако я вижу, что у FFmpeg примѣрно такие же проблемы с утратою прозрачности AVIF при создании миниатюр файлов, какие в сообщении https://410chan.org/dev/res/20450.html#20573 наблюдалися (1 сентября 2018 года, без мáлого подесятка лѣтъ назадъ!) с утратою прозрачности GIF.

Можно ли разсудить дѣло такъ, что «на безрыбье»-то «и так сойдёт», или никоим образом нельзя пренебречь утратою прозрачности миниатюр AVIF на 410чане? — вопрос не риторический, я это всерьёз спрашиваю.
No. 27134  
>>27133
Я предполагаю, что в последующие недели или месяцы на сервере будет обновлён «Дебиан», тогда и будем смотреть, что там поддерживается. Сроков обновления пока нет. Спрашивать их не надо.
No. 27137  
screenshot.webp - (77.74KB, 1280×892)
27137
Чувствую, что для пользы дальнѣйшаго тестирования не помѣшалъ бы примѣръ такого AVIF, который был бы:

① анимированным,

② с частичною прозрачностью.

По адресу https://take-me-to.space/iKlueGf.avif примѣръ такого AVIF прилагаю.

Ѿдѣльно сообщаю, что в сообщении >>27133 машинально записал «оперѣться», но правильно записывать «опереться» без «Ѣ».

На обновление «Дебиана» не возлагаю значительных надежд, так как по адресу https://packages.debian.org/search?keywords=imagemagick вижу ImageMagick 6 (скриншот прилагаю).

В эту старую ветку (в отличие от ImageMagick 7) ужé никто и никогда не станет впиливать поддержку новых форматов, и это не одного только AVIF впрямую касается, но и JPEG XL также. Никогда, никогда!
No. 27149  
5xdmc0vxqhd21.jpg - (34.23KB, 640×661)
27149
Кажется, fbe на php8.2 который теперь в debian stable по умолчанию, работать не будет.
No. 27150  
https://bitbucket.org/Therapont/fbe-410/issues/56/php-8
Завёл задачу по обновлению движка под ПХП 8.2. Движок оказался совсем неработоспособен, чтобы его своими силами быстро починить, так что помощь не просто приветствуется, но всячески необходима.
No. 27154  
monkey triple facepalm.webp - (7.00KB, 534×534)
27154
https://www.php.net/manual/en/migration80.incompatible.php
No. 27169  
screenshot.webp - (339.75KB, 900×945)
27169
По адресу https://t.me/exploitex/8944 встрѣтилося упоминание того, что вскорѣ «Битбакету» настанет кирдык.

Если это правда, то тогда эвакуируйте репу.

Скриншот упоминания прилагаю.
No. 27170  
>>27169
Лично мне такая лабуда не приходила пока.
No. 27179  
На всякий случай проясню мою реакцию >>27154 словесно. Так как по адресу https://www.php.net/manual/en/migration80.incompatible.php упоминается изрядное количество несовмѣстимыхъ отличий восьмой версии PHP от седьмой, то я:

① вижу, что задача потребует установки FBE (поэтому я от её рѣшенія по причине >>27043 воздержусь) и послѣдующаго пристального вглядывания в появляющиеся ошибки, так как просто перелопатить кучу кода в поисках несовмѣстимостей за один присест и безупречно не представляется возможным (часть их притом не поддастся простому поиску или даже поиску с использованием регулярных выражений, тут будет нужен либо синтаксический анализатор, либо отладка, либо готовность читать всѣ файлы глазами), так что ошибки повылазят непремѣнно,

② заблаговременно выражаю сочувствие и одобрение 410чанькам, готовым взяться за это непростое дѣло.

Суманъ.
No. 27198  
На данный момент все существующие внутренние наработки по переходу на новую версию ПХП доступны в репозитории. Оно по большей части работоспособно, но нужно тестирование; из известных проблем — сломаны предупреждения. В ближайшее время обновлений не будет, видимо.
Если кто-то соберётся новые пулреквесты по этой теме делать, учитывайте это.
No. 27202  
>>27179
А когда новая версия PHP выйдет и опять что-то сломают, по новой переписывать всё? Вот уж действительно неблагодарная работа. Лучше уж один раз переписать на языке, где заботятся об обратной совместимости.
No. 27206  
>>27202
>на языке, где заботятся об обратной совместимости
C, Common Lisp? Какие ещё варианты?
No. 27208  
>>27206
Приходят на ум JavaScript/TypeScript, Java, Go.

С Python ситуация интересная, в пределах мажорной версии не ломают совместимость, при переходе с 2 на 3, конечно, поломали. Но при этом Гвидо заявляет, что Python 4 может не выйти никогда (https://builtin.com/software-engineering-perspectives/python-4). Поэтому включу в список Python 3.
No. 27210  
>>27208
>Go
Да, пока что обещания по поводу обратной совместимости выполняются, иногда в ущерб всему остальному. Разработчики оставили за собой право всё кардинально переломать в версии 2, но её может и не быть, по крайней мере в ближайшие годы.
>JavaScript/TypeScript
Скорее да, чем нет - если не обрастать зависимостями на сторонние библиотеки/фреймворки.
>Python
Совсем, совсем нет. В каждой новой версии что-то меняется или вообще убирается в самом языке и стандартной библиотеке, ломая обратную совместимость. Раз в год точно нужно будет что-то переделывать по мелочи, если пытаться быть всегда на свежайшей версии.
>С Python ситуация интересная
Нет, ломаются вещи именно что в пределах 3-й версии. Ломались небольшие вещи от 3.9 к 3.10, от 3.10 к 3.11, известно, что будут поломки от 3.11 к 3.12 - и уже сейчас видно, что будут ещё более серьёзные поломки обратной совместимости к 3.13.
Грядут изменения для языка в технической плане, самое серьёзное из которых - уход от global interpreter lock. С одной стороны всё это очень хорошо, с другой стороны - про обратную совместимость кода, написанного сейчас и следующую пару лет, в перспективе на 5-7 лет можно забыть.
>Java
Не знаком, но что-то мне подсказывает, что если бы с обратной совместимостью там было всё хорошо, то много людей не сидело бы до сих пор на Java 8 (актуальны сейчас Java 17 LTS и Java 20).
Слышал, что с C#/.NET в этом плане ситуация получше, но не знаю, так ли это на самом деле, и насколько лучше.
No. 27211  
>>27210
> Совсем, совсем нет. В каждой новой версии что-то меняется или вообще убирается в самом языке и стандартной библиотеке, ломая обратную совместимость
Примеры?

> Грядут изменения для языка в технической плане
Например, кроме «ухода от GIL»?

> уход от global interpreter lock
Там же явно написано, что будут соблюдать обратную совместимость:
https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474
> We want to be very careful with backward compatibility. We do not want another Python 3 situation, so any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds
No. 27212  
1260020516120.jpg - (74.07KB, 819×720)
27212
Свалите флудить в другую нить.
No. 27213  
>>27211
>Примеры?
Вот тебе потешный пример, когда багфикс-релизы (одновременно сразу для целого ряда 3.X версий: 3.10, 3.9, 3.8, 3.7) поломали людям библиотеки для научных вычислений.
https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889
Почитай заметки к релизам, погугли "Python 3.X breaking changes".
https://github.com/wazuh/wazuh/issues/13365
https://github.com/python/cpython/issues/100458
https://github.com/aalavender/OilPrice/issues/9
После этого ответь себе, насколько стабильным тебе кажется Python 3.

>Там же явно написано, что будут соблюдать обратную совместимость:
Обсуждение вокруг этого свелось к тому, что выкатывать не-GIL Python они будут стараться мягко и нежно, но обратной совместимости по многим вещам между текущими и ближайшими версиями и "полноценным" не-GIL Python через лет 5 не будет.
No. 27279  
Поскольку произошло описанное в >>27169, репозиторий переехал на https://codeberg.org/FBE410/fbe-410
No. 27335  
Что за «функция предупреждений», упомянутая в >>/b/205318? Имеется в виду весь механизм предупреждений или какая-то одна функция? Что конкретно там поломано?
No. 27336  
>>27335
Страница предупреждений выдаёт пустую страницу. При этом предупреждаемое через кнопку с доски сообщение удаляется без оставления записи об этом в модлоге.
Основной код тут:
https://codeberg.org/FBE410/fbe-410/src/branch/public/inc/classes/warnings.class.php
No. 27337  
>>27336
Открыл pull request.

При развёртывании столкнулся со следующими проблемами:

1. В config.php необходимо было дописать
define('CONGLOMERATE', array());
, иначе была ошибка с несуществующей переменной CONGLOMERATE. Вполне возможно, что вписывать это нужно было в какой-то другой файл.

2. Три PHP-файла содержат ссылку на изображение “410.png”, однако в репозитории есть только “410logo.png”.
No. 27354  
Озабочен я проблемой >>/d/3043. Путём экспериментов я выяснил, что она вызвана наложением двух особенностей движка:

(1) Насильным разбиением переводом строки последовательностей, которые длиннее 150 юникодных codepoint’ов и не содержат пробелов или переводов строки.

(2) Тем, что парсер разметки зачем-то пытается декодировать URL encoding в ссылках.

В результате после (1) из этой ссылки получается

https://ru.wikipedia.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA%D0%BE%D0%B2%D1%8B%D0%B5_%D1%83%D0%BD%D0%B8%D0%B2%D0%B5%D1%80%D1%81%D0%B0%D0%BB%D0%B8%D0%B8_%D0%

(перевод строки)
93%D1%80%D0%B8%D0%BD%D0%B1%D0%B5%D1%80%D0%B3%D0%B0

Первую строку затем парсер пытается декодировать. Получается, конечно же, невалидный UTF-8, который невозможно вставить в БД.

Почему в движке есть (1), ещё можно понять: если какой-нибудь умник запостит очень длинное слово, то страница поломается (появится горизонтальная прокрутка).

Но зачем декодировать URL encoding? Вот что мне непонятно. Просто убрав вызовы функции urldecode в обоих местах в файле inc/classes/parse.class.php, я решил проблему с невозможностью запостить ссылку. Какие новые проблемы появятся от этого изменения, не могу придумать. Открывать pull request или в этих вызовах всё же есть какой-то тайный смысл?
No. 27355  
>>27354
> Но зачем декодировать URL encoding
https://ru.wikipedia.org/wiki/Красота
No. 27356  
По-хорошему же стоит сделать разбиватель строк, который разбивает строку после декодирования URL по юникодной длине с пропуском тэгов разметки и их атрибутов. У UTF8 вроде чёткий и легко имплементируемый механизм нахождения длины символа по его первому байту.
No. 27359  
Совсѣмъ-то по-хорошему надо бы:

① пройтись по полному списку строковых функций PHP, предназначенных для работы с Unicode (этот список по адресу https://www.php.net/manual/en/ref.mbstring.php располагается), и систематически одну из них (наиболѣе подходящую) использовать вмѣсто каждой такой строковой функции, которая игнорирует возможную многобайтовость сѵмволовъ,

② в таких мѣстахъ, в которых длина строки ограничивается дѣйствительно количеством сѵмволовъ (напримѣръ, «нам надо бы эту строку разбавить пробѣлами, чтобы ширину страницы не растаращило до степени появления полосы прокрутки и затруднения чтения»), подумать ещё и об использовании функции mb_strimwidth (или ея аналога, болѣе подходящаго) для учёта отличия полноширинных сѵмволовъ от полуширинных,

③ бережно сохранить учёт байтов въ таких мѣстахъ, в которых длина строки реально ограничена количеством байтов (напримѣръ, «в таблице БД величина имени файла не может превосходить столько-то байтов»), но и там не проигнорировать возможную многобайтовость сѵмволовъ (скажем, использовать mb_strcut для обрѣзанія).
No. 27372  
Провёл исследование: на других имиджбордах и форумах проблема длинных слов либо никак не решена, либо решена с помощью свойств CSS “word-break” и/или “overflow-wrap” (оно же “word-wrap”). Принудительное разбиение на слова на уровне движка (CutWord) выглядит каким-то костылём, доставшимся в наследство ещё от кусабы. Есть ли в нём хоть какой-то смысл сейчас, если можно написать в CSS
.postbody {

  word-break: normal;
  overflow-wrap: anywhere;
}
?

Ещё можно как-то с помощью CSS сделать, чтобы горизонтальная прокрутка была только у провинившегося поста, а не у всей страницы. Но я не смог нагуглить, как это сделать.

Ceterum censeo, вызовы urldecode в парсере разметки нужно просто-напросто убрать, т.е. заменить urldecode(x) на (x). В этом и заключается надлежащее решение.
No. 27375  
>>27372
>чтобы горизонтальная прокрутка была только у провинившегося поста, а не у всей страницы
На контейнеры
overflow-x: hidden;
,
width/max-width: 100vw;
/
...: 100%; box-sizing: border-box;
. На сам пост
max-width: 100%; overflow-x: auto
.
No. 27378  
>>27375
Спасибо, похоже на правду, но идеально воспроизвести у меня не получается (остаётся небольшая горизонтальная прокрутка у всей страницы, а “overflow-x: hidden” это костыль). И ещё я не понимаю, про какие контейнеры ты говоришь. Можешь показать пример страницы, где такое сделано?

Ну и ждём вердикта Соуса.
No. 27379  
>>27372

> В этом и заключается надлежащее решение.

Что, дѣлать нечитаемыми URLы, в которых есть японские сѵмволы или кириллица? Ради чего? Чтобы что?
No. 27380  
google_and_cp1251_0xff.png - (63.47KB, 925×558)
27380
>>27379
Против urldecode в парсере разметки у меня есть три возражения:

(1) Эта функция попросту не предназначена для того, чтобы ей скармливали целый URL (а не некую подстроку URL). Она может исказить его (из URL с одним параметром запроса получится URL с двумя):
$ php -r 'printf("%s\n", urldecode("https://example.org/path?query=x%26y%3Dz"));'

https://example.org/path?query=x&y=z


(2) Вызов этой функции может привести к тому, что корректная с точки зрения стандарта ссылка не сможет быть запощена:
https://example.org/path?query=%FF
является корректной ссылкой, ибо нигде не сказано, что URL encoded-сегменты обязаны быть валидным UTF-8. Более того, и по сей день существуют серверы, которые принимают запросы в кодировках, отличных от UTF-8: например, поиск Google по адресу
https://www.google.com/search?q=%FF
у меня (ваш результат может отличаться) интерпретирует этот один байт 0xFF как букву «я» в кодировке cp1251 (скриншот прилагаю). А в результате декодирования получается невалидный UTF-8, который невозможно вставить в БД.

(3) Это браузер пользователя делает URLы читаемыми или же нечитаемыми: можно запостить
https://ru.wikipedia.org/wiki/Красота
, а можно и
https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0
. Я всего лишь предлагаю отображать ссылки так, как их запостил пользователь. То, что ваш браузер вставляет «%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0» вместо «Красота» при копировании URL, так это особенность вашего браузера, которую, скорее всего, можно решить его настройкой.

На практике декодирование вызывает (вместе с принудительным разбиением на слова) проблему >>/d/3043, а также другую проблему. Если эти проблемы будут тем или иным образом решены, то вопрос о том, нужно ли декодировать, с моей точки зрения, не будет очень существенным. Просто оно для этого не предназначено.
No. 27381  
Хорошие контраргументы.

(Правда, если ими руководиться, то тогда опосля надо будет передѣлать парсер, насколько я понимаю — чтоб русские буквы принималися в URLы, а не означали конец URLов.)
No. 27382  
>>27381
> опосля надо будет передѣлать парсер
Это не так: и старое, и новое (предложенное yakui-lover в открытом PR) регулярное выражение считают кириллицу частью URL.
No. 27386  
Ну что же, открыл pull request, который реализует надлежащее (по моему мнению) декодирование URL.
No. 27391  
Насколько я понимаю, предположение >>27134 превратилось въ нынѣшнемъ мѣсяцѣ въ увѣренность: теперь 410чан дѣйствуетъ на новом PHP и притом ещё, кажется, на новой версии операционной системы.

Настаёт время вдругорядь возвратиться к содержимому сообщения >>27133 и разсмотрѣть его под таким углом: если сёрвер 410чана всё ещё не обзавёлся AVIF-понимающею версіею ImageMagick, то как там хотя бы с наличием поддержки AVIF в GD в PHP?

Собрали ли PHP с поддержкою AVIF?

Сразу скажу ещё, что вглядывание в содержимое трёхлѣтней давности коммита https://github.com/libgd/libgd/commit/f2aa2836ed910ca3510585a47a8a064b5140e148 в репе GD открывает в нём (а именно в коде файла src/gd_avif.c) ряд небезынтересных обстоятельств.

Во-первых, в коде GD жёстко прописана цвѣтовая субдискретизация для AVIF в том случае, когда желаемое качество изображения, измѣряемое баллами от 0 (минимальное качество) до 100 (максимальное качество), указано меньше 90. На мой личный взгляд это жестковато, я бы поставил 80 пороговым значением.

Во-вторых, качество 100 включает, по-видимому, режим сжатия без внесения потерь в изображение.

В-третьих, в коде libavif качество задаётся величиною так называемого квантователя: чѣмъ эта величина больше, тѣмъ качество хуже, а доходить она может до 63. Поэтому в коде GD предусмотрена формула для перевода значений качества (0…100) в значения квантователя (0…63).

Формула эта вот какова: из значения максимального качества (100 баллов) вычитается значение указанного качества, а результат умножается на частное отъ дѣленія максимальнаго квантователя (то есть 63) на максимальное качество (то есть 100), опосля чего округляется. В итоге должна получаться вот какая таблица соѿвѣтствія между баллами качества и величинами квантователей:

0 → 63
1 → 62
2 → 62
3 → 61
4 → 60
5 → 60
6 → 59
7 → 59
8 → 58
9 → 57
10 → 57
11 → 56
12 → 55
13 → 55
14 → 54
15 → 54
16 → 53
17 → 52
18 → 52
19 → 51
20 → 50
21 → 50
22 → 49
23 → 49
24 → 48
25 → 47
26 → 47
27 → 46
28 → 45
29 → 45
30 → 44
31 → 43
32 → 43
33 → 42
34 → 42
35 → 41
36 → 40
37 → 40
38 → 39
39 → 38
40 → 38
41 → 37
42 → 37
43 → 36
44 → 35
45 → 35
46 → 34
47 → 33
48 → 33
49 → 32
50 → 32
51 → 31
52 → 30
53 → 30
54 → 29
55 → 28
56 → 28
57 → 27
58 → 26
59 → 26
60 → 25
61 → 25
62 → 24
63 → 23
64 → 23
65 → 22
66 → 21
67 → 21
68 → 20
69 → 20
70 → 19
71 → 18
72 → 18
73 → 17
74 → 16
75 → 16
76 → 15
77 → 14
78 → 14
79 → 13
80 → 13
81 → 12
82 → 11
83 → 11
84 → 10
85 → 9
86 → 9
87 → 8
88 → 8
89 → 7
90 → 6
91 → 6
92 → 5
93 → 4
94 → 4
95 → 3
96 → 3
97 → 2
98 → 1
99 → 1
100 → 0

Впрочем, эта послѣдняя строка ея остаётся фактически недосягаемою ввиду вышеупомянутаго переключения в режим lossless.

Каждое из этих трёх обстоятельств остаётся и по сей день.
No. 27396  
Если в сообщении >>27391 правильно угадано положение дѣлъ (то есть если поддержка AVIF есть в GD в PHP, однако ея нѣтъ въ ImageMagick), то тогда оснащать FBE поддержкою AVIF придётся как-нибудь вот как:

① приподнять в файле inc/func/posts.php условие «elseif (KU_THUMBMETHOD == 'gd')» (и послѣдующія инструкціи GD-обработки изображений) до того уровня, на котором сейчас находится условие «elseif (KU_THUMBMETHOD == 'imagemagick')» (и послѣдующія инструкціи IM-обработки изображений), да притом ещё дополнить это условие «elseif (KU_THUMBMETHOD == 'gd')» до состояния «elseif (KU_THUMBMETHOD == 'gd' || $filetype == 'avif')» для того, чтобы оно всегда срабатывало насчёт файлов AVIF;

② в функции «gd_create_thumbnail» прибавить к вызовам «gif_gd_create» и «jpg_gd_create» и «png_gd_create» вызов функции «avif_gd_create» для файлов AVIF;

③ только что упомянутую функцию «avif_gd_create» сочинить по образцу функции «png_gd_create» как-нибудь вот как:

function avif_gd_create($source, $destination, $resize_x, $resize_y) {
   $avif = imagecreatefromavif($source);
   $thumbnail = gd_resize(
      $avif, $resize_x, $resize_y, $source, $destination, true, true
   );
   imageavif($thumbnail, $destination, 90, 3);
   imagedestroy($thumbnail);
   imagedestroy($avif);
   return true;
}

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

При этом в вызове функции «imageavif» я в явном виде прописываю качество 90, поскольку это позволит подавить субдискретизацию цвѣта.

Сразу скажу, что если миниатюры такого качества всё же окажутся неприемлемо крупными по объёму, то можно будет обсудить дальнѣйшее снижение качества. Но напомню, что 6 ноября 2020 года (при добавлении в FBE поддержки WebP) обнаружил, что миниатюры WebP с указуемым качеством 85 получаются по объёму меньше, чѣмъ миниатюры JPEG с указуемым качеством 80, а визуально — лучше. Поэтому тут жду примѣрно того же, только ещё +5 баллов.

Предупреждаю, что движок FBE при работе с ImageMagick (то есть въ послѣдніе годы) создаёт миниатюры JPEG с указуемым качеством 80 (и это сносно), но при работе с GD создаёт миниатюры JPEG с качеством по умолчанию, которое (как это по адресу https://www.php.net/manual/en/function.imagejpeg.php говорится) равно 75 — этакие миниатюры и сами собою не так хороши, и как отправная точка для сравнения с миниатюрами AVIF (совершаемого по объёму файла) не очень полезны, потому что могут побуждать похѣрить ещё и их качество ради экономии объёма файла.
No. 27397  
И так как в сообщении >>26066 сказано, что только администрация 410чана принимает рѣшенія, то предлагаю на ея разсмотрѣніе идею >>27396.
No. 27399  
Переход на ПХП8 состоялся, но всякие мелочи ещё остались, поэтому с рассмотрением новых функций и всякого такого пока притормозим.

Тут я описал некоторые известные проблемы:
https://codeberg.org/FBE410/fbe-410/issues/15#issuecomment-1655734

Рекомендую включить показ ошибок в ПХП (https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors ).
No. 27401  
Предлагаю к теме «Futaba» крашеный скроллбар въ цвѣтахъ логотипа:

html { scrollbar-color: #1b7942 #fdffc7; }

Чтобы предпросмотрѣть, введите в отладочную консоль:

$('html').css('scrollbar-color', '#1b7942 #fdffc7')
No. 27402  
>>27401
Оно должно быть в цветах «Футабы», а не логотипа, никак с ней не сочетающихся. Отказано.
No. 27417  
Я считаю, что ни avif, ни webp, ни jxl не нужны. PNG, APNG, GIF и JPEG прекрасно справляются. А новомодные форматы лишь плодят фрагментацию, выбивают станые версии браузеров и вносят уязвимости в новые. Не так давно RCE в webp была. А что творится в AVIF и JXL — вообще мало кто знает. Лучше отключить, а неадекватными сайтами, сделавшими ставку на смузимусор — не пользоваться.
Удалить сообщение []
Пароль  
[Mod]