Создание PDF-файлов из текстовых полей iOS
Я работаю над требованиями и спецификациями для нового приложения для iOS, предназначенного для использования некоторыми специалистами, работающими "в поле". Весь день в течение нескольких недель подряд эти люди несут значительное бремя отчетности перед начальством, используя стандартизированные формы, которые отслеживают все виды информации. Традиционно эти формы находятся в формате PDF, просто распечатываются и заполняются чернилами, а затем передаются десяткам сотням других, выполняющих ту же операцию. Иногда они используют PDF с полями формы, чтобы данные можно было набирать, а затем распечатывать как часть формы. В любом случае, учитывая их рабочий процесс, время и стрессовые нагрузки, а также другие факторы, это не очень продуктивный способ создания стандартизированных форм отчетности.
Приложение, которое мы задаем, будет предлагать пользовательский интерфейс iOS (и Android, если это возможно, но второстепенное или даже третичное требование) для отслеживания данных, которые они вводят в поле, упорядочивая их для каждого логически. индивидуальный пользователь, и с нажатием кнопки, взять все эти данные и автоматически создать их PDF-файл, используя стандартизированную форму.
Конечно, формы строго и жестко стандартизированы в этой отрасли, и любое отклонение в формате, структуре или представлении просто недопустимо.
Таким образом, я подходил к проекту, думая, что приложение будет поддерживать внутренний репозиторий исходных стандартизированных форм от аккредитующей организации, с каждой возможной областью данных, определенной как поле. Приложение будет:
- откройте необходимую PDF-форму для поставленной задачи;
- анализировать его словарь для идентификации конкретных полей данных;
- для каждого отдельного поля определите соответствующие данные из собственного пользовательского интерфейса приложения iOS и таблиц данных и назначьте эти данные соответствующему полю из PDF/ словаря
- экспортируйте PDF-файл в НОВЫЙ PDF-файл, который приложение отправит по электронной почте или сохранит через iCloud, Dropbox или другую форму обмена файлами.
Суть #4 в том, что этот файл PDF должен оставаться редактируемым стандартными приложениями PDF в Windows и Mac (Acrobat, Preview и т. Д.), Поэтому все поля должны оставаться. И PDF должен быть одинаково доступен для просмотра на Windows или Mac.
Теперь НИКОГДА не нужно будет отображать PDF-файл (ни оригинал, ни экспортированный окончательный документ) НИКОГДА в приложении iOS, и при этом не имеет особого смысла делать это.
Я не знаю, возможно ли это. Это наш первый iOS-проект, и мы склонялись к созданию приложения с использованием Moai или Corona или какой-либо другой инфраструктуры, чтобы сэкономить время разработки и упростить перенос на разные платформы. Тем не менее, если это невозможно сделать с помощью Lua и одной из этих платформ (я по-прежнему скептически отношусь... они, похоже, ОЧЕНЬ сильно ориентированы на игры), мы не против того, чтобы делать это непосредственно в Objective C и создавать версию для Android некоторое время вниз. дорога.
Но в любом случае, я не могу оценить, является ли это практическим мероприятием. Наши требования ясны, и, честно говоря, если этого не сделать, проект не будет продолжен. Но я определенно мог бы использовать некоторую помощь от вас, ребята, в определении моих возможностей, могу ли я сделать это в Lua, и какие SDK были бы наиболее полезны для достижения этой цели.
3 ответа
Рассматривали ли вы просто создание нового PDF-файла с использованием изображения формы в качестве фона для PDF-файла и просто запись данных пользователя в необходимые области поверх изображения формы. Уменьшит сложность попыток разбора оригинальной формы PDF-файлов.
Исходя из того, что вы сказали, кажется, что нет оснований для выполнения части работы над мобильным устройством в формате PDF, поскольку:
- вам не нужно отображать его на Ipad
- вы планируете отправить его по электронной почте или хранить в облаке
- если вы напишите это для iOS, вам придется писать снова для Android, как вы уже упоминали
Можете ли вы упростить мобильную часть ваших требований, сосредоточившись на сборе и проверке данных, а затем отправившись на сервер для создания документа? Это даст вам гораздо больше гибкости в инструментах, которые вы можете использовать для объединения данных в PDF-документы. Если это так, вы можете посмотреть на создание PDF-файлов или заполнение полей из кода, используя что-то вроде iText (C# или Java). Если вы не хотите создавать свой собственный серверный сервер, вы можете попробовать что-то вроде Docmosis Cloud - но это может не позволить вам получить ваши точные макеты.
Конечно, улов, который вы упомянули, - необходимость сохранять PDF-файлы редактируемыми со своими полями - важный шаг во всех случаях. Если вы сможете убедить заинтересованные стороны в том, что лучше генерировать итоговые документы из вашей системы (генерировать черновик, просматривать, обновлять данные, генерировать заново и т. Д.), А не генерировать редактируемые документы, которые затем теряют контроль и отслеживание, тогда вы будете миль впереди.
Надеюсь, это поможет.
Это заслуживающий обсуждения вопрос, но у нас нет идеального ответа. Я склонен думать об этом как о почти идеальном сценарии - его было бы значительно легче разработать. Есть два ключевых вопроса с этим подходом, которые заставили нас подать заявку, за исключением крайних случаев:
Пользователи этого продукта будут работать в поле. Это поле может быть буквально где угодно - на улицах Манхэттена, в зоне бедствия с инфраструктурой, которая была серьезно повреждена или даже разрушена, или в самой разрушенной войной стране третьего мира. Если бы это были улицы, скажем, Манхэттена, нет проблем - их устройства iOS или Android будут иметь доступ к 3G или Wi-Fi практически везде, где бы они ни находились. В последних двух сценариях (которые, возможно, более распространены в этой отрасли), эта возможность подключения может быть очень ограниченной. Проблема заключается в том, будут ли возможности конечного пользователя работать продуктивно или видеть и обмениваться данными со своими коллегами, будут слишком сильно ограничены, если у них нет достойного сигнала. Честно говоря, даже сегодня они часто даже не используют мобильные устройства, вынуждая их возвращаться в местоположение типа штаб-квартиры или использовать радиоприемники для обмена информацией, фактически отрицая мою точку зрения здесь. Но если мы не собираемся значительно увеличивать их производительность в полевых условиях, это просто дает нам паузу, чтобы подумать, достаточно ли у нас ценностного предложения, чтобы попросить их довольно существенно изменить свои методы ведения дел.
К вашему последнему пункту, нет, нет никаких убеждений заинтересованных сторон, что эта новая система является лучшим подходом. Даже если бы они были, на это ушли бы годы. Эти формы являются частью четко определенного десятилетнего стандарта, используемого буквально тысячами организаций.