Отказ от ответственности:
Я использую iText 5. Я знаю, что это обычно осуждается (вместо использования iText 7), но я работаю со значительным устаревшим кодом, который использует iText 5, и обновление не попадает под мой контроль.
Требования:
- В качестве входных данных принимается «простой» PDF / A (только текст, они генерируются из RTF), а также значение с плавающей запятой, соответствующее требуемой длине первой страницы в дюймах.
- PDF / A должен выводиться так же, как входной PDF, за исключением того, что он разбит на страницы следующим образом: длина первой страницы = входное значение; каждая последующая (не первая или последняя) страница будет заполнять стандартную длину страницы; последняя страница будет усечена на постоянное количество точек ниже содержимого, ближайшего к нижней части страницы. Обратите внимание, что ширина входа и выхода будет одинаковой и постоянной.
Ход / Подход:
Я расширил SimpleTextExtractionStrategy, чтобы сгенерировать XML, содержащий информацию о шрифте (размер и семейство, жирный или курсив и т. Д.), А также информацию о местоположении (относительно абсолютной системы координат, где начало координат находится в верхнем левом углу первая страница входного PDF) для каждого «диапазона» текста, извлеченного из входного PDF.
Затем я генерирую новый PDF-файл постранично (где каждая страница имеет желаемую длину в соответствии с требованиями, изложенными выше), фильтрует извлеченную информацию XML с помощью LINQ на основе границ каждой новой страницы и добавляет соответствующий форматированный текст в соответствующее местоположение, используя ColumnText.ShowTextAligned(...).
Проблема:
Подход, изложенный выше, делает штрафом . Он генерирует PDF-файлы с желаемой структурой страницы, но некоторая информация теряется при переводе, а именно цветной текст и подчеркнутый текст. Хотя цветной текст не должен быть виден в этих PDF-файлах, подчеркнутый текст обязательно должен быть обнаружен.
Этот набор требований должен также включать PDF-файлы с таблицами. Первоначально я планировал реализовать другой модуль, который придерживается того же интерфейса для таблиц PDF, так как они генерируются и используются отдельно от PDF, генерируемых из RTF, а в iText встроена относительно мощная функциональность таблиц.
Две проблемы, о которых говорилось выше, в сочетании с тем фактом, что мой описанный подход был рожден попыткой повторного использования существующего кода, заставляет меня полагать, что совершенно иной подход может быть необходим или, по крайней мере, намного лучше. Мне кажется, что должен быть способ захвата байтовой информации контента и ее обрезки по мере необходимости для «повторной разбивки на страницы» входного PDF, беспокоясь только о перемещении контента, который падает вдоль границы страницы.
По сути, я ищу (основанные на iText) рекомендации для лучшего подхода. Ответы типа псевдокода или просто рекомендации для классов / интерфейсов, которые могут помочь, являются приемлемыми. Хотя было бы неплохо обрабатывать текст и таблицы вместе, любой совет, относящийся к одному или другому, также был бы оценен. Я просмотрел большую часть доступной документации на веб-сайте iText и другие SO вопросы, но не нашел именно то, что я ищу.
Обратите внимание, что в этот вопрос не включен код, поскольку я ищу высокоуровневый подход, который полностью отличается от того, что я пробовал.
Edit:
Я не замечал этого раньше, но способ повторного использования шрифтов (аналогично this ) привел к неожиданному (но задокументированному) поведению. Похоже, мне нужно будет избегать извлечения информации для разбивки на текстовые уровни, так как будет трудно обеспечить непрерывность шрифтов между вводом и выводом.