Pull to refresh

Comments 26

UFO just landed and posted this here
Планировалось, что я напишу скрипт по вытягиванию картинок из pdf-ок. Но пока это делалось контент-менеджером. По сути полная обработка страницы + написание скрипта занимало 8-12 минут, как мы считали.
У вас странное понимание интерактивности журналов.
Под интерактивностью понималось полное анимирование печатного издание.
Эффекты:
— Перевороты страниц, загибание.
— Закладки, предпросмотр.
— Шрифт текста можно было увеличивать.
— Фразы из текста можно было добавлять в цитаты для шаринга.
— Картинки были кликабельны, их можно было увеличивать, некоторые являлись встроенными галереями.
— На страницах был аудио-голос диктора, виде-файлы.
— Был аппарат для рекламных блоков, в том числе и с анимацией вращения.
— Как варианты, планировалось много туда еще внедрить — как, например интерактивные кроссворды, судоку
А изначально PDF нельзя было прислать меньше? к примеру Ваш вес pdf очень похож на вес печатного pdf (300dpi), а из InDesign'a можно выгнать просмотровый pdf (72dpi) и весить он будет гораздо меньше
Это лишь отсрочит проблему — падать будет не через два, а через пять перелистываний.
вообще, конечно, сама по себе постановка вопроса — «сделать интерактивный журнал из PDF-версии» — уже радует

а на результат-то в app store посмотреть можно? что за издательство было?
А чем заказчика не устроили готовые решения для индиза, вроде woodwing'овских ( goo.gl/ZFQ8 )? Или ещё каких. Легче за 500 баксов купить и перевести всё своё добро самим. И продавать через аппстор, а не мучиться с подписками и балансом.
готовые решения для индиза стоят дорого :) хотя да, альтернативы есть, но заказчики о них не слышали, похоже
Даже 500 долларов для заказчика было много на то, чтобы тратить на готовые движки.
Хотя это было бы более рациональное решение.
В плане выпуска приложения журнала через adobe могу сказать.
Мы как Издательский дом сначала пошл по этому пути но цены оказались непомерными, в итоге выпустили два своих журнала через publisher.napoleonit.ru
То Же самый интерактив и все функции но дешевли на порядок. Нечего не вылетало и не падало
А в интерактивности что-нибудь кроме «перелистывания страниц» было?
В ответ на комментарий spycode — я подробно расписал все эффекты.
… регистрации пользователя, пополнения баланса...


А разве Apple не запрещает покупки в приложениях кроме как через App Store?
Apple требует чтобы все эти операции были доступны через app store, если программа предоставляет ещё и свой способ оплаты (в дополнение к app store), то почему бы и нет.
Да apple не запрещает Вам прикручивать оплаты через банковские карты, робо-кассы и прочие сервисы
Почему не рассматривался вариант сохранения в pdf не с полиграфическим качеством, а для просмотра на экране iPad`a? Непонятно как получется 7Мб страница при параметрах 1024×768px 132 px/inch (ppi).
Потому что людям, смотрящим журналы, надо подробности. Увеличить там что-нибудь.
качество журналов было 300dpi.
По этому и писал можно сказать статью, чтобы показать как пришлось выкручиваться из всей ситуации в целом.
Сейчас многие планируют делать электронные издательства, надеюсь кто-нибудь заметит сразу ошибки в своих планах и будущие трудности.
Думается, что применение формата PDF в качестве источника первичной информации ошибочно. PDF задуман для решения задачи гарантированной визуализации, но не для преобразования или разбора на составные части.

Я бы пересмотрел весь процесс издания журнала и генерировал его электронную версию в рамках издательского процесса, а не изолированно — мол, вот вам файл и делайте с ним что хотите. Тут надо общаться с заказчиком и корректировать процесс производста.
Так в конечном итоге — рендерился и не pdf. А набор отдельных блоков текста и картинок — и небольшие pdf-вставки. Для этого и разрабатывал язык верстки журналов.

По сути, в итоге получился готовый движок для построения несложных электроных, анимированных журналов на базе pdf и дополнительных материалов.
А UIPageView из iOS 5 не пробовали? Правда, он сам смотрит за контроллерами отрисовывающими страницы.
Год назад еще не было 5 iOs. Можно будет посмотреть на досуге
Я в пару месяцев назад решил такую проблему таким образом:

Сделал класс, который открывает PDF-ку, и по запросу рисует страницы на нужный контекст. Также класс может возвращать изображения страниц в виде картинок заданного размера.

При получении любого memory warning класс закрывает CGPDFDocument, это позволяет полностью освободить память занятую под документ и страницы (включает внутренний кэш).

При последующем обращении на отрисовку страницы документ опять открывается и рисуется.

В итоге памяти тратится ровно столько, сколько не напрягает девайс, все кэши освобождаются, когда надо. Тестировал все на тяжелых PDF-ках (журналы со сложной версткой и обилием картинок) — все работает нормально. Лагов в момент пересоздания CGPDFDocument не заметно, из-за перерасхода памяти программа не падает. Основная сложность в том, чтобы корректно реализовать конкурентный доступ к классу из нескольких потоков одновременно.
Adobe пакет не пробовали из-за дороговизны? Работает то он нормально?
Sign up to leave a comment.

Articles