Планировалось, что я напишу скрипт по вытягиванию картинок из pdf-ок. Но пока это делалось контент-менеджером. По сути полная обработка страницы + написание скрипта занимало 8-12 минут, как мы считали.
Под интерактивностью понималось полное анимирование печатного издание.
Эффекты:
— Перевороты страниц, загибание.
— Закладки, предпросмотр.
— Шрифт текста можно было увеличивать.
— Фразы из текста можно было добавлять в цитаты для шаринга.
— Картинки были кликабельны, их можно было увеличивать, некоторые являлись встроенными галереями.
— На страницах был аудио-голос диктора, виде-файлы.
— Был аппарат для рекламных блоков, в том числе и с анимацией вращения.
— Как варианты, планировалось много туда еще внедрить — как, например интерактивные кроссворды, судоку
А изначально PDF нельзя было прислать меньше? к примеру Ваш вес pdf очень похож на вес печатного pdf (300dpi), а из InDesign'a можно выгнать просмотровый pdf (72dpi) и весить он будет гораздо меньше
А чем заказчика не устроили готовые решения для индиза, вроде woodwing'овских ( goo.gl/ZFQ8 )? Или ещё каких. Легче за 500 баксов купить и перевести всё своё добро самим. И продавать через аппстор, а не мучиться с подписками и балансом.
В плане выпуска приложения журнала через adobe могу сказать.
Мы как Издательский дом сначала пошл по этому пути но цены оказались непомерными, в итоге выпустили два своих журнала через publisher.napoleonit.ru
То Же самый интерактив и все функции но дешевли на порядок. Нечего не вылетало и не падало
Apple требует чтобы все эти операции были доступны через app store, если программа предоставляет ещё и свой способ оплаты (в дополнение к app store), то почему бы и нет.
Почему не рассматривался вариант сохранения в pdf не с полиграфическим качеством, а для просмотра на экране iPad`a? Непонятно как получется 7Мб страница при параметрах 1024×768px 132 px/inch (ppi).
качество журналов было 300dpi.
По этому и писал можно сказать статью, чтобы показать как пришлось выкручиваться из всей ситуации в целом.
Сейчас многие планируют делать электронные издательства, надеюсь кто-нибудь заметит сразу ошибки в своих планах и будущие трудности.
Думается, что применение формата PDF в качестве источника первичной информации ошибочно. PDF задуман для решения задачи гарантированной визуализации, но не для преобразования или разбора на составные части.
Я бы пересмотрел весь процесс издания журнала и генерировал его электронную версию в рамках издательского процесса, а не изолированно — мол, вот вам файл и делайте с ним что хотите. Тут надо общаться с заказчиком и корректировать процесс производста.
Так в конечном итоге — рендерился и не pdf. А набор отдельных блоков текста и картинок — и небольшие pdf-вставки. Для этого и разрабатывал язык верстки журналов.
По сути, в итоге получился готовый движок для построения несложных электроных, анимированных журналов на базе pdf и дополнительных материалов.
Я в пару месяцев назад решил такую проблему таким образом:
Сделал класс, который открывает PDF-ку, и по запросу рисует страницы на нужный контекст. Также класс может возвращать изображения страниц в виде картинок заданного размера.
При получении любого memory warning класс закрывает CGPDFDocument, это позволяет полностью освободить память занятую под документ и страницы (включает внутренний кэш).
При последующем обращении на отрисовку страницы документ опять открывается и рисуется.
В итоге памяти тратится ровно столько, сколько не напрягает девайс, все кэши освобождаются, когда надо. Тестировал все на тяжелых PDF-ках (журналы со сложной версткой и обилием картинок) — все работает нормально. Лагов в момент пересоздания CGPDFDocument не заметно, из-за перерасхода памяти программа не падает. Основная сложность в том, чтобы корректно реализовать конкурентный доступ к классу из нескольких потоков одновременно.
Разработка электронного, интерактивного журнала для iPad