Аналогичное обсуждение возникло и в упомянутой рубрике. Я предложил эмпирический способ оценки потребности в генераторах хтмля: если данных больше чем тегов - теги надо генерить и подставлять в данные. Если тегов больше чем данных - данные надо генерить и подставлять в теги. По-моему вполне объяснимо и логично.
Если середина-наполовину, значит вы работаете без паттерна.
Выяснилось что GD не понимает CMYK. То есть понимает по-своему, логически. Профилей, без которых цмик не существует - не подразумевает. Кто-то там выше заяснял что его классновый GD покруче будет imagik'а, или как он там. Имярек профили поддерживает между тем.
Почему не было поддержки GIF'а в течении некоторого времени. По известной причине:
Цитата:
Please do not ask us to send you the old GIF version of GD. Yes, Unisys still holds a patent on the LZW compression algorithm in some countries. The best solution is to move to legally unencumbered, well-compressed, modern image formats such as PNG and JPEG as soon as possible.
Чтобы вконец поставить точку попробую объяснить на каком расстоянии это GD находится от современных способов манипулирования изображениями. О профилях уже было. Профилей нет. Сделайте multichannel из RGB, добавьте альфу, попробуйте сохранить полученное в jpeg как CMYK, то есть без сжатия хроматической, с четырьмя голимыми яркостными каналами. На другом конце разберите - вот вам и альфа в jpeg.
Без имхи - последнее значение только приедет. Теоретически через get позволено и изображение массивов передавать - &brands[0]=1&brands[1]=2; - но обычно так не делают.
Писанины меньше и от структуры хтмля отвязаны. Можете сделать body, потом tfoot, затем thead и наконец собрав инфу про таблицу запихать ее в caption. А на выводе все будет как w3c.org хочет. (Добавление)
Кстати, таблица любой размерности из результата запроса рендерится вот такой процедурой
(Добавление)
Нет, про отвязку я конечно перебрал, потребуется класс посложнее. В рубрике про ООП говорят что подключить целиком класс построения DOM'а очень даже ничего. Я, конечно, сомневаюсь. Загляните в нее, там как раз про отрисовку таблицы тема есть.
Потому что GIF не несет с собой альфа-канала. Следовательно этот формат сперва надо особо конвертануть в RGBA.
Все на этом. Разумеется я не знаю как на php обходятся с "прозрачными" гифами, потому что мне это не стучит и стучать не будет.
Что требовалось поправить - что никаких особых методов искать не надо - о чем и было высказано предположение. О чем и поведал ваш прелестный класс - в нем все обычно. Так обычно и делают. Ну, попроще, конечно, без гемора с полотнами.
Кстати jpg в расширении адобы может содержать альфа-канал. Приложения, правда, не поддерживают, но техническая возможность имеется и в своем собственном приложении можно воспользоваться.
Другими словами тот самый водяной знак, логотип и прочие метки можно сохранить в jpeg с альфой.
Собирайте в массив. Массив сделайте объектом с методами которые сами в него будут все добавлять. В финале echo выведет на волшебный __toString() из которого вы все и вывалите обычным return join(PHP_EOL, get_object_vars($this));
esterio, третий пункт реализован в классе двумя строчками кода.
Ничего там не реализовано и быть не может. Вы просто поздно сообразили прочитать что я пишу. В смысле в самом начале написал. И, кстати, с ошибочкой.
Прозрачный индекс лежит не в общей пол-литре, но в расширении формата, а именно тут:
Цитата:
23. Graphic Control Extension.
a. Description. The Graphic Control Extension contains parameters used
when processing a graphic rendering block. The scope of this extension is
the first graphic rendering block to follow. The extension contains only
one data sub-block.
Я не знал и узнавать не собирался, вы заставили. Да, imagecreatefromgif() прозрачно превращает прозрачные индексы в альфу. Поэтому и не было ответов на вопрос как преобразовать гиф в rgba. Потому что нет такого вопроса - берешь функцию имярек и она все конверит.
Следовательно если взять два гифа и сконвертить их оба и сплющить с сохранением альфы, то получится так же RGBA.
Но записать RGBA в гиф нельзя. Я и проверять не собираюсь, но верю что imagegif попросту проиндексирует альфу на thershold 50% Что никак не повлияет на внешний вид результата если изначально это были два индекса ни один из которых _НЕ_ интерполировали.
Иначе, если один был не гиф, а пинг, если один из бывших индексов сжали или растянули методами со сглаживанием (билинейной интерполяцией например), то результат записи в GIF89a окажется плачевным.
В общем господа, вопрос такой: на кой черт вам сдался этот геморрой с "прозрачными" гифами???
Их давно уже нет. В качестве основы изображения - подавно. В качестве штампа, лого, ватермарки - юзайте пинг. Ну годы же мучились дуря браузеры - наконец можно законно профтыкать пинг где хочешь. Нет, блин, тянет на старенькое.
Кстати, спец по графике в пхп знает почему в GD на протяжении ряда лет не было поддержки GIF? (Добавление)
---
С самого начала я предложил отказаться от дурной затеи и тема было заглохла и правильно.
Потому что я даже представить не могу изображением чего должна быть картинка с прозрачностью, на которую еще и ватермарку надо налепить.
В отличии от носителя могучего ЧСВ, я в графике провел чуть больше десяти лет и за все время мне не попался ни один деловой и проштампованный гиф. Это же изначально либо хлам, либо чертежи и тексты. Которые штампить смысла нет.
Заштампить ценную анимашку? Одуреть...
Отсюда я предположил что ТС хотел бы это все воткнуть до кучи. Типа все форматы, бла-бла-бла. А сам наверно ни разу гифа живьем не видел.
И последнее. Палитра в GD не управляемая. Я видел - писали лет пять-десять назад всякую хрень по растеризации альфы и оптимизации палитры - но поскольку нормального управления цветами нет, то и смысла в этом гифе не остается. Вам прилетит 4 цвета, а вы сделаете 255. Нафига? (Добавление)
---
В публичных местах делают просто: чего бы ты не закачал - сохранится jpeg и досвидос. Варианты типа синхронизации файлов идут через БД где все равно ради сохранения уникальности имен файлы переименовываются. Так какая разница тогда. Был flower.gif, стал 00008767363.jpg?
Знаете почему? Потому что прежде чем писать на php классы с использованием графических функций, надо сперва научиться разбираться в графике. Ну и в классах тоже.
Таким образом вопрос темы остается открытым.
По классу.
Что касается косяков. save() вызывается из scope __toString(). Исключение из save() будет передано в __toString() и далее до ловушки. Но до нее не дойдет, потому что из туСтринга вывалится в фатальную ошибку. Короче вместо исключения получите приключение типа
Цитата:
Fatal error: Method image::__toString() must not throw an exception in...
Нелепость это ФШ на php. Который как известно рожден умереть. Классный автор же создает инстансь, которая изображает из себя документ. Типа вот вам полотно, делайте на нем чего хотите. А что можно сделать-то? Умора. Консольный ФШ это, могучий ход, конечно.
Короче, еще раз для невежд. вы _НЕ_ можете сделать "полупрозрачный" GIF как отмечено в п.3 хотелок ТС, просто потому что полупрозрачность это технология альфа-канала, а в спецификации формата GIF никакой альфы не предусмотрено вообще и не будет отныне.
Если какая-то функция из GD PHP может превратить индексы в RGBA - значит изображение сохраненное в GIF можно композить. Но никакая функция не сможет записать альфу обратно в GIF.
Так уже понятно, или пойдете сами читать про этот никому не нужный отстой - Graphic Interchange Format?
Это я не вам писал, а вообще. Ну, например тем кто рискнет расширять ваш "функционал".
Ваша проблема в ЧСВ, за которым вы не видите косяков и нелепостей. На вопрос темы вы так и не ответили - делает ваш класс полупрозрачный гиф (см, п. 3) или не делает?
Кто-нить сделайте эксепшн в save() проверить - врет мана или правду говорит.
Вполне понятно применять такое для массовой обработки изображений нельзя.
И опять же я не понял где там лого, а где картинка в примере по именам ImagePNG - ? ImageGIF - ?
Вопрос риторический. Можете не отвечать. (Добавление)
Цитата:
Третий пункт реализовать невозможно в принципе
Решу в пару строчек кода без проблем
Пошел в гастроном за попкорном. Надеюсь когда нажарю увижу полупрозрачный гиф.
Третий пункт реализовать невозможно в принципе, но, если вам удалось избежать
Цитата:
водяной знак становится полностью черным
а среди использованных функций GD ничего чудесного не замечено, то значит так и делается обычно - никто особенностями гифа не париться, библиотека сама его размачивает и смачивает обратно.
Это я и предположил сразу когда не заметил ответов на вопрос что делать с гифами. Если ответов нет - значит и вопроса такого нет.
Однако были вопросы что делать с пингами - как их в гиф с "прозрачностью" записать. Я не читал, потому что было нерелевантно.
Я вообще искал среди волшебных методов такой, который бы позволил складывать объекты обычным путем. Скажем $ImagePNG = $ImagePNG + $ImageGIF. Что позволило бы и умножать: $ImagePNG = $ImagePNG + $ImageGIF * 0.25. Предварительно вписав в проперть штампа положение его в пространстве документа: $ImageGIF->bottom('right') например, или наоборот ImageGIF->right('bottom'), или слева ImageGIF->left('bottom'), а по умолчанию - посредине середины что идеально для водяных знаков. Кроме того поля удобно внести заранее чем париться расчетами $ImageGIF->margin(20); $ImageGIF->margin(10, 20) задает для двух полей - горизонтального и вертикального. Названия полям давать нельзя, потому что в зависимости от выравнивания они поменяются логически. Было поле левое - станет правое.
Так вот, и не нашел. Такое вообще возможно реализовать - плюсовать объекты?
Понятия не имею как обычно оперируют гифами с "прозрачным" цветом, но если у вас оно работает - то есть кладет "прозрачный" гиф на "прозрачный" гиф и сохраняет в "прозрачном" гифе - значит обычно так и делают.
Кстати, пытаясь понять что там вообще делается смутно вспомнил и проверка показала что вспомнил розовую плашку правильно, а именно
Цитата:
Warning
You cannot throw an exception from within a __toString() method. Doing so will result in a fatal error.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 59
