SeVlad, комрад saanvi, говорит о том, что метод упаковки данных в PNG создан на основе Deflate алгоритма. (в отличииот GIF, который использовал проприетарный LZW)
Этот же алгоритм используется, например в ZIP
соответственно, там имеется возможность настройки степени компрессии.
Другой вопрос, нафейхуа настраивать степень компрессии, если 90% файлов занимают не более 1 мегабайта, а сам по себе алгоритм отличается высочайшей производительностью, особенно в случае распаковки. Вот если бы файлы были по 1Тб, тогда еще имелся бы какой-то смысл в этом---------- Добавлено 04.02.2018 в 21:05 ----------
Именно так. потерь там нет, Про это написано даже в стандарте
Уровень сжатия, это есть уровень компрессии, как в ZIP---------- Добавлено 04.02.2018 в 21:10 ----------
http://www.libpng.org/pub/png/pngintro.html
vladkristsun, "качество сохранения" возможно только там, где есть потери на сжатии. в png нет потерь.
то-есть если на входе было ff ff ff ff cf cf a4 cf то на выходе будет то-же самое.
поэтому, ПНГ (как и gif) можно использовать для скрытого хранения информации (например ключей)
человеческий глаз разницы между #ffffff и #fefefe не заметит никогда, а программно это три бита данных
TIFF это вообще не формат, это контейнер. Как матрешка (mkv) в видео. Туда можно пихать всё, что угодно. от несжатого, (как bmp) да еще и в слоях до вполне себе упакованного jpg
svg идеален для анимации и иконок, ведь его можно красить из стилей. Да и вообще крутить как душе угодно.
только тсс.
в текст впишите вместо 2018
%year%
а потом в шаблоне сделать что-то вроде <?= str_replace('%year%',date('Y'),$content); ?>
это сферический пример в вакууме
Не знаю, как в DLE с шаблонами дела обстоят
avatar2020,
О, сколько нам открытий чудныхГотовят просвещенья дух,И опыт, сын ошибок трудных,И гений, парадоксов друг,
Просто работать надо по 12 часов в сутки. Нет. лучше по 16. Причем в коллективе людей, которые сильнее вас в той или иной области.
Тогда и "чувство макета" придет, причем быстро.
Всероссийский агрегатор женщин с пониженной социальной ответственностью.
я прошу прощения, вы, часом, не из МВД?
Ну а если по сабжу, подойдет что угодно, от вордпресса с друпалом, до юми и битрикса
SeVlad, то-есть так и запишем, вы не знаете, какая бригада программеров должны это делать.
Всё ясно. И не надо спускаться в схоластику.
я же остаюсь при своем.
Программист, не должен профессионально уметь верстать. для этого есть отдел верстки, в котором сидят верстаки и технологи.
Программист должен, по факту, подставить во вьюхи необходимые значения.
И он совершенно не должен разбираться в том "почему блок съехал на 10 пикселей, после того, как короткий текст заменили на длинный" хотя бы потому, что если он будет отвлекаться на выпиливание таких мелочей, то у него не будет времени на собственную работу. А программисту задачи могут идти как на конвейере. И от кол-ва решенных задач зависит его зарплата
для таких целей создается таск в джирре с приоритетом от normal до critical и верстальщик, работающий над проектом выпиливает собственный косяк.
то же самое касается и js. для этого есть технологи работающие над проектом
В противном случае, после релиза, "автора" бага хрен найдешь. Все будут друг на друга кивать
Sitealert, на самом деле так и есть.
тем более. что таблица со значениями должна состоять из n столбцов, каждый из которых соответствует определенному типу поля и имеет null по умолчанию
правда, подобный подход несколько усложняет генерацию запроса. Но зато позволяет систематизировать и упорядочить поля со свойствами.
самый простой вариант, это сделать две таблицы, в одной - тип объекта и поля идентичные для всех объектов, например название и id
вторая таблица - представляет собой коллекцию уникальных полей для всех элементов
вторая таблица выглядит как
id поля
тип поля
значение поля
id объекта
(прочая служебная информация, как то описание, дата последнего изменения, id изменения для отката и пр)
далее, чтоб выбрать все данные по какому-либо параметру, достаточно будет произвести выборку по ид поля, после чего мы получим все объекты содержащие в себе эти поля.
все в общем то просто.
основная сложность заключается в том, что если у вас несколько миллионов объектов с уникальными характеристиками, то таблица с характеристиками будет достаточно тяжелой, что может сказать ся на производительности.
Но как показала практика (мы это делали в 2010м году для каталога сайта "из рук в руки", при правильной настройки индексов падение производительности оказывается мизерным)
ну а по части вывода пользователю, думаю, что оптимально было бы сделать так, как это сделано в старом я.маркете (посмотрите на вебархиве)
конечно же делитанты, куда нам до вас, о ГУРУ форума бог сжатия в "джипех"
только объясните мне, кто должен писать раздел "вам может понравиться"
https://screenshots.firefox.com/KIIm2LOH4J8mtYxo/www.lamoda.ru вот тут
и 2. расскажите кретерии по которым происходит подбор,
или "сопли" на любом новостном ресурсе?
