Длинный текстовый ввод от пользователя и генерация PDF

Question

Я создал веб-приложение, которое можно рассматривать как слишком сложную форму приложения. Есть множество текстовых областей с заданным ограничением символов. После отправки формы происходят разные вещи, и одна из них - генерация PDF.

Текст запрашивается из БД и вставляется в шаблон PDF, созданный в iReports. Это прекрасно работает, но основная боль - переполнение текста.

Максимальное количество символов устанавливается на основе «среднего» текста. Но иногда люди предпочитают писать с помощью CAPS или добавлять много строк для форматирования текста. Это приводит к тому, что текст пользователя переполняет пространство, указанное в PDF. К сожалению, документ PDF должен выглядеть как настоящая форма заявки, поэтому я не могу оставить неограниченное пространство.

Какие подходы вы использовали для решения этой проблемы?

• Очистить / ограничить ввод пользователя?
• Рассчитать требования к пространству текста на основе метрик шрифта?
• Обеспечить предварительный просмотр PDF? (слишком плохие пользователи не могут изменять свои входные данные после отправки ...)

Answer 1

Ваши собственные предложенные решения вашей проблемы хороши. Наверное, самый важный вопрос, на который нужно ответить, - как должен выглядеть ваш PDF, если данные, отображаемые в поле, не помещаются? Вам когда-нибудь нужен «полный ответ» для чего-то еще? Когда вы знаете ответ на этот вопрос, у вас будут сокращены варианты.

Например, если поле должно быть ограничено 1/2 страницы, а пользователи иногда вводят более 1/2 страницы текста, вы можете либо 1) ограничьте ввод данных пользователем - при отправке рассчитайте размер (используя метрики шрифта, как вы сказали) и отклоните отправку до исправления. Это предполагает, что вы можете законно заставить пользователя сократить ввод данных. 2) принять пользовательский ввод и усечь в отображении этого отчета. Некоторые системы используют «...» для обозначения усеченных данных и могут предоставить гиперссылку (даже в формате PDF) для получения дополнительной информации.

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

Answer 2

В идеале, рассчитать требование на основе метрик. Я не знаю, как iReports обрабатывает текст, но с iText он все выкладывает сам, вы просто представляете данные в виде потокового документа, поэтому мы не беспокоимся о переполнении текста.

Однако iReport может не поддерживать это, или вам может потребоваться, чтобы макет PDF соответствовал определенным границам. Я бы попытался очистить ввод (то есть: если это все заглавные буквы, строчные буквы / регистр предложений / правильный регистр), убрать лишние пробелы. Если очистка ввода не может быть надежно выполнена, или люди все еще не справились с этим, я бы также ограничил это.

В качестве крайней меры я бы предоставил пользователю PDF для авторизации. Действительно, пользователям не следует давать больше работы, и они все равно не собираются ее делать.

Answer 3

Есть ли у вас контроль над шрифтом, который используется при создании PDF? Если так, я бы искал шрифт в семействе Monospace. Это даст вам одинаковую длину для заданного количества символов независимо от пунктуации, заглавных букв и т. Д.