Исток-Системы - Форумы
Поддержка пользователей программных продуктов и библиотек

Сейчас cl-pdf не поддерживает альфа-канал в png-изображениях. Это какое-то принципиальное ограничение, или можно теоретически надеяться (или самому попробовать пропатчить) на реализацию такой поддержки в будущем?

Точно сказать не могу - я не специалист по изображениям. Исходный алгоритм чтения PNG-файлов, который был переведен на Коммон Лисп, этого не поддерживал.

Разбираться нужно, начиная со спецификации PDF. Если есть желание самому пропатчить, обещаю патчи интегрировать. Только не надо тащить salza2 и прочие излишества

Хорошо. Я понял.

P.S. Странное у вас отношение к "прочим излишествам", и я склонен списывать её на недостатки платформы (windows) На моей платформе (Gentoo) в этом нет совершенно никакой проблемы (установка пакета и всех зависимостей одной командой) и, конечно, никто бы не стал включать сторонние библиотеки (зависимости) в состав своей библиотеки (как это сделано cl-pdf). Ну да ладно

Странно, что Вы ещё не сталкивались с потребностью включать стороннюю библиотеку.

Часто она оптимизируется, "слегка улучшается", подгоняется под свои нужды и т.п. Затем Вы делаете попытка передать их в общий код - отказ.

Чтобы защитить свою от необходимости отслеживать "значительные улучшения" и неконформные изменения в чужой библиотеке, просто ее замораживаете у себя.

Как так? Я представляю, что было бы, если бы все так делали Я не знаю, каким образом Вы используете cl-pdf, но я загружаю эту библиотеку в "сервер приложений", в который загружается большое количество пакетов (около сотни). Конечно, между ними много зависимостей. И многие библиотеки имеют общие зависимости. Это нормально и, как мне кажется, большинство разработчиков принимают такое положение вещей. Конечно, версии всех пакетов должны быть согласованы между собой. Но это, по большей части, проблема разработчиков дистрибутива (в Windows, это, разумеется, Ваша проблема). Так что, я продолжаю склоняться к мысли, что такой подход есть следствие используемой платформы.

Как бы там ни было, в итоге я просто создал git-репозиторий, который синхронизируется с subversion и в который я внёс (вношу) нужные мне изменения: разные излишества, например, поддержку salza2 и zpb-ttf

Не вижу, каким образом это может быть связано с платформой. ASDF-файлы везде одинаковы. Просто, нечасто бывает нужда вникать в чужую библиотеку. Но по-поводу salza, ещё Марк решил её заморозить - можно из архива рассылки поднять. Позже я оптимизировал один файл под LW 32-bit арифметику - он так и остался в CL-PDF.

Разумеется, в своей практике я использую собственные версии некоторых файлов из CL-PDF/Typesetting. Это, в основном, идеи "не представляющие" большого интереса или потециально опасные для других платформ или "не одобренных". Это жизнь.

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

> страшновато такой зоопарк содержать - нужно же время всё это добро согласовывать


В том то и дело, что нет. Все пакеты входят в дистрибутив (точнее, я использую gentoo-lisp-overlay, но не суть). Я просто ставлю нужные мне пакеты с помощью инструментов, предоставляемые дистрибутивом (например, команда emerge hunchentoot поставит hunchentoot и все его зависимости). И что бы я не поставил, и в какой-бы комбинации не загрузил, все пакеты (с очень большой долей вероятности) будут согласованы между собой. Это обеспечивают разработчики дистрибутива (точнее, разработчики gentoo-lisp-overlay, но не суть). Мне не нужно прилагать дополнительных усилий для поддержки согласованности версий.

Кстати, в gentoo при установке cl-pdf каталог salza просто удаляется и используется salza, установленная штатным образом.

Ну да ладно, к поддержке альфа-канала в png это никакого отношения не имеет