Telerik Document Processing позволяет из кода создавать, читать и изменять PDF, DOCX, RTF, HTML, Markdown, XLSX, XLS, XLSM, CSV и текстовые документы: объединять и разделять PDF, заполнять формы, ставить цифровые подписи, формировать таблицы и диаграммы, выполнять подстановку данных в шаблоны и выгружать результат в поток или файл. Основные инструменты разделены по моделям фиксированной страницы, потокового документа, электронной таблицы и потоковой записи больших книг, поэтому для каждой задачи можно выбрать точный уровень контроля и расход памяти.

Обычный рабочий процесс начинается в проекте .NET: разработчик добавляет нужные пакеты, выбирает формат-провайдер, импортирует файл из потока, меняет объектную модель и экспортирует результат в новый поток. Визуальная часть работы сосредоточена в Visual Studio или другой среде разработки, в мастере конфигурации ссылок, отладчике и просмотрщике полученного документа; отдельного окна с панелями ручного редактирования у библиотек нет.

Практическая ценность набора проявляется в серверных сценариях, где документы должны формироваться одинаково по данным из базы, очереди или API: счета превращаются в PDF, договоры собираются из DOCX-шаблона, отчёты выгружаются в XLSX, а подписанные формы проверяются без запуска Microsoft Office или Adobe Acrobat. При этом качество результата зависит от правильно подключённых формат-провайдеров, доступных шрифтов, корректных тайм-аутов и одинаковых версий всех пакетов в проекте.

Как устроен рабочий процесс

Telerik Document Processing не навязывает единую модель всем форматам. PDF описывается как набор страниц с фиксированными координатами, потоковый документ — как последовательность секций, абзацев и встроенных объектов, а книга Excel — как рабочая книга с листами, диапазонами и ячейками. Такое разделение важно не только для терминов API. Оно определяет, что произойдёт при вставке текста: в PDF разработчик задаёт положение или использует блок автоматической компоновки, в DOCX текст сам перетекает между страницами, а в XLSX новое значение занимает конкретную ячейку и может повлиять на формулы.

В проект обычно подключают базовый пакет Core и пакет модели, соответствующий документу. Для PDF используется Fixed, для Word-подобных файлов — Flow, для книг — Spreadsheet, а для последовательной записи крупных таблиц — SpreadsheetStreaming. Формат-провайдеры добавляются отдельно там, где конкретный формат не включён в модель. Поэтому ошибка тип провайдера не найден чаще означает не повреждение файла, а отсутствие нужной ссылки или смешивание пространств имён двух пакетных семейств.

Мастер конфигурации в Visual Studio показывает зависимости по назначению: рядом с Documents.Fixed подписан RadPdfProcessing, рядом с Documents.Flow — RadWordsProcessing, а отдельные пункты отвечают за PDF-экспорт потоковых документов и Open XML для таблиц. В крупном решении полезно фиксировать тот же набор ссылок в файле проекта, чтобы локальная машина, сборочный сервер и контейнер восстанавливали одинаковые зависимости.

Подключение пакетов без конфликтов

Главное правило установки — не смешивать Telerik.Documents.* и Telerik.Windows.Documents.* в одной цепочке обработки. Первое семейство рассчитано на переносимые проекты и современный .NET, второе использует Windows-ориентированные сборки. Классы могут называться похоже, но CLR воспринимает их как разные типы: объект страницы или размер из одного семейства нельзя без преобразования передать методу другого. Если компилятор сообщает о неоднозначном типе, сначала проверяют полные пространства имён и дерево транзитивных зависимостей.

Все пакеты Document Processing в проекте должны иметь один и тот же номер выпуска. NuGet способен восстановить комбинацию, где Core обновлён, а Fixed остался прежним, но такая сборка может завершиться ошибкой загрузки метода или типа уже во время выполнения. Надёжная схема — централизованно задать версии в Directory.Packages.props, запретить плавающие диапазоны и проверять файл блокировки зависимостей в CI. Обновление проводят сразу для Core, модели и всех формат-провайдеров, после чего прогоняют набор эталонных документов.

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

Импорт, изменение и экспорт через потоки

Формат-провайдер отделяет байтовое представление файла от объектной модели. Для чтения разработчик создаёт поток, передаёт его методу импорта и получает RadFixedDocument, RadFlowDocument или Workbook. Для записи выполняется обратная операция: провайдер сериализует модель в выходной поток. Такой подход одинаково удобен для файла на диске, объекта в облачном хранилище, тела HTTP-запроса и массива байтов, но поток должен поддерживать операции, которые ожидает конкретный провайдер.

Перед импортом проверяют позицию потока. Если тот же MemoryStream сначала заполнялся кодом приложения, его курсор часто остаётся в конце, и провайдер видит пустой ввод. Установка Position = 0 устраняет этот тип ошибки. После экспорта положение, напротив, оказывается в конце; перед отправкой массива клиенту поток перематывают или используют ToArray. Не следует закрывать входной поток до завершения импорта, если провайдер выполняет отложенное чтение ресурсов.

Методы импорта и экспорта принимают тайм-аут. Он нужен не только для защиты веб-запроса от зависания, но и для предсказуемой отмены обработки сложного файла с огромными изображениями, таблицами или повреждённой структурой. Значение выбирают по реальным размерам документов, а исключение отмены отличают от ошибки формата. В очереди фоновых заданий полезно хранить тип операции, размер входа, длительность и имя провайдера — без содержимого конфиденциального документа.

PdfProcessing: две стратегии создания PDF

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

Выбор уровня следует делать до написания шаблона. Если счёт должен совпасть с утверждённой формой до миллиметра, используют фиксированную страницу и рассчитывают позиции в device-independent pixels. Если длина описаний товаров меняется, применяют блоки и таблицы с автоматической компоновкой, иначе строки начнут перекрывать друг друга. В одном документе можно сочетать подходы: фон и реквизиты размещать точно, а переменную часть выводить как потоковый блок внутри заданного прямоугольника.

Создание начинается с RadFixedDocument и страниц. У каждой страницы задаются размер, поворот и область содержимого. Редактор контента умеет рисовать текст, изображения, линии, прямоугольники, кривые Безье и другие геометрии. Состояние графики — матрица преобразования, кисть, перо, прозрачность и клип — следует сохранять и восстанавливать вокруг локальных операций, иначе изменение масштаба или поворота распространится на последующие элементы.

Страницы, объединение и разделение PDF

Для объединения небольших документов можно импортировать их модели и последовательно добавлять страницы в целевой RadFixedDocument. При этом нужно учитывать ресурсы страницы: шрифты, изображения, формы XObject и ссылки должны переноситься вместе с содержимым. Простое копирование коллекции без клонирования способно оставить страницу привязанной к исходному документу. API клонирования нужен именно для создания независимого дерева объектов.

Для больших файлов предусмотрен потоковый API PdfFileStream. Он полезен, когда задача ограничена добавлением, извлечением, объединением или разделением страниц и нет необходимости держать полную модель в памяти. Практическая разница заметна на пакетной обработке сотен многостраничных сканов: полная модель удобнее для глубокого редактирования, но требует памяти пропорционально содержимому, тогда как потоковый путь последовательно переносит данные.

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

Текст, шрифты и поиск в PDF

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

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

Замена текста в существующем PDF сложнее обычного Replace: новая строка может быть длиннее выделенной области, использовать другой набор глифов или пересекаться с соседними объектами. Надёжный сценарий — определить область исходного фрагмента, удалить или закрыть его, подобрать шрифт с нужными символами и заново разместить текст с контролем размера. Для массовой персонализации безопаснее генерировать документ из структурированного шаблона, чем переписывать произвольный PDF.

Изображения, XObject и размер файла

Изображения декодируются по требованию, поэтому импорт PDF не обязан сразу расходовать память на все растровые данные. При простом переносе страницы полезно сохранять исходный закодированный поток, а не повторно сжимать картинку. Повторное декодирование и кодирование JPEG может ухудшить качество и увеличить время. Если изображение действительно меняется, параметры качества экспорта выбирают по назначению: экранный отчёт, печать или архив.

Повторяющийся логотип, штамп или сложную векторную группу выгодно оформить как Form XObject. Один ресурс можно размещать на многих страницах с разным масштабом и поворотом, не дублируя команды рисования. Это уменьшает файл и упрощает синхронное изменение шаблона. При клонировании страниц проверяют, что XObject перенесён в таблицу ресурсов нового документа.

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

Закладки, назначения и навигация

Закладка PDF содержит отображаемое имя и действие перехода. Для длинного регламента или отчёта создают иерархию разделов, а дочерние элементы связывают с конкретной страницей и координатой. Закладка не обязана совпадать с печатным оглавлением: она может вести к приложению, форме или таблице, которую пользователь часто открывает.

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

Аннотации и интерактивные элементы

Аннотации располагаются поверх содержимого страницы и имеют собственную геометрию, внешний вид и действие. В прикладных системах чаще используются текстовые заметки, ссылки, выделения и виджеты формы. Координаты аннотации должны учитывать ориентацию и поворот страницы: прямоугольник, рассчитанный для неповёрнутого листа, после импорта может оказаться в другой части экрана.

Внешний вид аннотации желательно формировать явно. Некоторые просмотрщики способны построить его по свойствам, другие показывают только заранее записанный appearance stream. Если документ будет открываться в разных клиентах, проверяют минимум в двух независимых просмотрщиках и на печати. Для неизменяемой разметки аннотацию можно сплющить в содержимое, но после этого пользователь уже не сможет редактировать её как отдельный объект.

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

Интерактивные формы

PdfProcessing позволяет создавать поля ввода, переключатели, флажки, списки и подписи, заполнять значения и извлекать уже введённые данные. Поле формы и его визуальный вид связаны, но не тождественны: изменение значения без обновления appearance может дать документ, где программно читается новое значение, а просмотрщик показывает старое. После заполнения формируют внешний вид или проверяют, что целевой клиент делает это корректно.

Имена полей лучше проектировать как устойчивые идентификаторы, например customer.address.city, а не как подписи на русском языке. Тогда шаблон можно переводить без изменения интеграции. Радиокнопки объединяются общей группой и различаются экспортными значениями; если все варианты имеют одинаковое значение, извлечённый результат перестаёт однозначно показывать выбор.

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

Цифровые подписи и проверка

Цифровая подпись связывает хэш документа с сертификатом X.509 и позволяет обнаружить изменения после подписания. В прикладном процессе сначала полностью формируют документ, затем создают поле подписи, вычисляют подпись и сохраняют результат. Любое последующее обычное сохранение может изменить байты и сделать проверку отрицательной, поэтому дополнительные подписи добавляют инкрементальным обновлением, не переписывая уже подписанные ревизии.

Проверка не ограничивается математической корректностью. Приложение должно построить цепочку сертификатов, оценить срок действия на момент подписания, доверие к центру сертификации и статус отзыва. Для долгосрочной проверки используют метку времени доверенного сервера и данные валидации. Если среда не имеет доступа к CRL или OCSP, результат следует обозначить как неполный, а не как безусловно действительный.

Закрытый ключ может находиться в файле PFX, системном хранилище, аппаратном модуле или внешнем сервисе подписи. В последнем случае библиотека готовит данные для подписи, приложение отправляет хэш провайдеру и внедряет возвращённое значение. Секреты нельзя записывать в исходный код и журналы; пароль к контейнеру передают через защищённое хранилище и очищают из памяти настолько быстро, насколько позволяет платформа.

Пароли, разрешения и шифрование PDF

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

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

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

PDF/A, PDF/UA и долговременное хранение

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

Доступность PDF/UA связана со структурным деревом, порядком чтения, альтернативными описаниями изображений и семантикой заголовков, списков и таблиц. Визуально аккуратная страница может оставаться непригодной для экранного диктора. Если исходный PDF не содержит тегов, автоматическое восстановление структуры по координатам ограничено; лучше создавать семантику на этапе генерации из известных данных.

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

Работа с повреждёнными и нестандартными PDF

В реальных потоках встречаются файлы с неправильной таблицей перекрёстных ссылок, отсутствующими ключами словаря, обрезанным концом или объектами, которые формально нарушают спецификацию. PdfProcessing умеет обходить часть распространённых дефектов, но приложение всё равно должно считать вход недоверенным. Любая коррекция записывается в журнал задания, а исходный файл сохраняется отдельно для диагностики.

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

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

WordsProcessing: модель потокового документа

RadWordsProcessing представляет документ как RadFlowDocument: секции содержат блоки, блоки — абзацы и таблицы, а абзацы — фрагменты текста, изображения, поля и другие встроенные элементы. Страницы не являются первичным объектом модели, потому что их количество вычисляется при компоновке. Изменение поля, шрифта или размера бумаги может сдвинуть весь последующий текст и изменить нумерацию.

Для построения содержимого удобен RadFlowDocumentEditor. Он хранит позицию вставки и позволяет последовательно добавлять абзацы, текст, изображения, таблицы, разрывы и поля. Стили лучше назначать через именованные определения, а не копировать одинаковые параметры на каждый фрагмент: это уменьшает размер DOCX и даёт единое место для изменения оформления.

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

DOCX, RTF, HTML, Markdown и текстовые форматы

DOCX сохраняет наиболее полную модель: стили, таблицы, изображения, колонтитулы, поля и другие элементы Open XML. RTF полезен для обмена с системами, где DOCX недоступен, но отдельные современные свойства могут быть представлены иначе. HTML предназначен для веб-содержимого и не гарантирует точное совпадение страниц, потому что его базовая модель потоковая и зависит от CSS.

Импорт старых DOC и DOT поддерживается как чтение, а обратная запись в эти двоичные форматы не является симметричной операцией. Поэтому сценарий миграции строят как DOC → RadFlowDocument → DOCX или PDF. Перед пакетной конвертацией проверяют шаблоны с полями, внедрёнными объектами и нестандартными шрифтами: именно они чаще всего расходятся с простыми текстовыми документами.

Markdown и обычный текст подходят для обмена содержимым, но теряют сложную верстку. При экспорте в TXT таблица, изображение и форматирование не могут быть сохранены в исходном виде. Приложение должно явно выбирать, что считать текстовым представлением: только абзацы, подписи изображений, значения полей или также содержимое колонтитулов и примечаний.

Таблицы, изображения и плавающие объекты в Word

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

Встроенное изображение занимает позицию как символ в строке и перемещается вместе с текстом. Плавающее имеет якорь и располагается относительно страницы, колонки или абзаца; вокруг него настраивается обтекание. Плавающий логотип удобен в фирменном бланке, но при изменении полей секции способен сдвинуться. Для шаблонов, которые редактируют пользователи в Word, предпочтительнее простые и устойчивые привязки.

Размер изображения в документе и размер исходного растра — разные величины. Вставка фотографии на ширину пяти сантиметров не уменьшает число пикселей автоматически, поэтому DOCX может остаться огромным. Перед вставкой изображение масштабируют до разумного разрешения и выбирают формат: JPEG для фотографий, PNG для схем с прозрачностью. Повторяющиеся изображения следует переиспользовать, где это допускает формат.

Колонтитулы, поля и водяные знаки

Колонтитулы принадлежат секции и могут различаться для первой, чётных и нечётных страниц. Номер страницы вставляется как поле, а не как заранее вычисленная строка; приложение Word обновит его после компоновки. Если PDF создаётся сразу на сервере, формат-провайдер должен рассчитать поля в процессе экспорта, поэтому проверяют фактический результат, а не только структуру DOCX.

Водяной знак бывает текстовым или графическим и располагается позади основного содержимого. Для отметки Черновик задают текст, шрифт, цвет, поворот и прозрачность; для фирменного знака — источник изображения и размеры. Если знак перекрывает текст после преобразования в PDF, уменьшают непрозрачность и проверяют порядок слоёв, а не вставляют полупрозрачную картинку в каждый абзац.

Поля документа хранят код и отображаемый результат. К ним относятся номера страниц, даты, ссылки и поля слияния. Изменение кода без обновления результата создаёт ситуацию, когда разные редакторы показывают разные значения. В автоматической цепочке поле либо вычисляют перед экспортом, либо оставляют осознанно для обновления в Word.

Шаблоны, mail merge и массовая генерация

Mail merge заменяет поля шаблона значениями из записи данных и может повторять области для коллекций. Типичный процесс загружает проверенный DOCX, сопоставляет имена полей с объектом домена, выполняет слияние, удаляет неиспользованные поля и экспортирует персональный документ. Чтобы отсутствие значения не проходило незаметно, перед генерацией сравнивают список полей шаблона со схемой входных данных.

Форматирование лучше хранить в самом шаблоне. Код передаёт обычные строки, даты и числа, а правила культуры определяют их представление. Если приложение вставляет уже отформатированную строку суммы, шаблон не сможет изменить число знаков или разделитель. Для юридических документов отдельно решают, как выводить пустое значение: пустая строка, прочерк или удаление всего абзаца.

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

Поиск, замена, клонирование и объединение DOCX

Поиск и замена в потоковом документе должны учитывать, что видимое слово может быть разбито на несколько runs из-за разного форматирования. Простое сравнение текста каждого фрагмента не найдёт такую последовательность. API поиска работает на уровне модели и позволяет заменить диапазон, но разработчик должен решить, какое форматирование наследует новая строка.

При объединении документов стили с одинаковыми именами могут иметь разные определения. Если оба файла содержат стиль Heading 1, слепое слияние способно изменить вид одного раздела. Надёжная стратегия выбирает главный набор стилей, переименовывает конфликтующие определения или явно сопоставляет их. Аналогично обрабатываются нумерованные списки, темы и связи изображений.

Клонирование полезно для шаблонных блоков: строки таблицы, карточки товара или секции договора. Копия должна получить новые экземпляры элементов и корректные связи с ресурсами целевого документа. После вставки проверяют идентификаторы закладок, комментариев и разрешённых диапазонов, чтобы они не дублировались.

Комментарии, диапазоны разрешений и элементы управления содержимым

Комментарии сохраняют автора, дату и диапазон текста, к которому относится обсуждение. В автоматическом процессе их можно извлекать для проверки, переносить в систему согласования или удалять из финальной копии. Удаление только визуального маркера недостаточно: нужно очистить и сами записи комментариев, иначе служебная информация останется внутри DOCX.

Диапазоны разрешений позволяют ограничить редактирование отдельных частей документа при включённой защите. Они полезны в шаблоне заявления, где пользователь заполняет только выделенные поля. Но защита Word — это управление поведением редактора, а не криптографическая защита секретов. Конфиденциальные данные всё равно контролируются правами доступа к файлу.

Content controls дают структурированные контейнеры для текста, даты, списка или повторяющейся области. Они устойчивее произвольных маркеров вида {{name}}, потому что отделяют идентификатор от отображаемого текста. При создании интеграции проверяют, какие свойства элемента сохраняет выбранный формат: преобразование в RTF или HTML может упростить структуру.

Экспорт потокового документа в PDF

Для экспорта DOCX-модели в PDF нужен PDF format provider для Flow. Он выполняет компоновку страниц, преобразует текст и изображения в фиксированные элементы и использует шрифтовые ресурсы среды. Разница между результатом Word и серверным PDF чаще всего связана с метриками шрифтов, полями секции, обработкой плавающих объектов и полями документа.

Перед выпуском эталонного шаблона сравнивают число страниц, переносы заголовков, таблицы на границе листа и колонтитулы. Нельзя ориентироваться только на первую страницу: небольшое отличие ширины символов накапливается и сдвигает последующие разрывы. Если точное совпадение критично, фиксируют набор шрифтов и не полагаются на шрифты, установленные вручную на одном сервере.

PDF является финальным представлением; после экспорта редактирование на уровне абзацев теряется. Поэтому исправления вносят в RadFlowDocument и повторяют экспорт, а не пытаются двигать полученные глифы в RadFixedDocument. Исключение — постобработка, например подпись, шифрование, штамп или объединение страниц.

SpreadProcessing: рабочая книга, лист и диапазон

RadSpreadProcessing использует Workbook с коллекцией листов. Доступ к значениям и форматам выполняется через ячейки и диапазоны, поэтому массовые операции лучше задавать диапазону сразу. Запись по одной ячейке с повторным созданием стиля и формата увеличивает время и количество уникальных записей в книге.

Значение, формат отображения и формула — отдельные свойства. Число 0,15 может отображаться как 15 %, дата хранится как числовое значение с форматом, а формула содержит выражение и вычисленный результат. При импорте нельзя считать текстом всё, что показано пользователю: для сортировки, вычисления и экспорта в CSV важен фактический тип.

Имена листов имеют ограничения формата Excel, а ссылки в формулах зависят от них. Перед переименованием листа проверяют, обновит ли операция связанные формулы, диаграммы и именованные диапазоны. При генерации по пользовательским данным имена очищают от запрещённых символов и обеспечивают уникальность.

Формулы, пересчёт и проверка результатов

Библиотека поддерживает большой набор функций и выражений, но не выполняет макросы VBA. В XLSM макропроект можно сохранить при импорте и экспорте, однако код макроса не изменяется и не запускается. Это важное ограничение для книг, где итоговые значения появляются только после Workbook_Open или пользовательской функции.

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

Культура влияет на отображение, но синтаксис формулы в файле не должен строиться из локализованных названий функций и разделителей, показанных в пользовательском Excel. API принимает формулы в ожидаемом внутреннем формате. Данные из CSV сначала приводят к типам, затем включают в вычисления; иначе строка с запятой может остаться текстом.

Сортировка, фильтрация, проверка данных и условное форматирование

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

Фильтр скрывает строки, но не удаляет их. При экспорте или последующем чтении нужно решить, обрабатывать все строки или только видимые. Проверка данных ограничивает ввод в Excel и может показывать подсказку, однако не гарантирует корректность данных, записанных напрямую через API; сервер обязан проверить их самостоятельно.

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

Диаграммы, изображения и гиперссылки в XLSX

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

Изображения привязываются к листу и имеют положение относительно ячеек. Изменение ширины столбца способно сдвинуть или растянуть объект в зависимости от режима привязки. Логотип в печатной форме лучше проверять после настройки страницы, а не только в сетке листа.

Гиперссылка может вести на внешний ресурс, файл или место внутри книги. При обработке недоверенных книг внешние ссылки рассматривают как активное содержимое: приложение может удалить их или разрешить только определённые схемы. Внутренние переходы после переименования листов проверяют вместе с формулами.

Печать и экспорт электронной таблицы в PDF

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

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

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

XLSX, XLS, XLSM, CSV и TXT

XLSX — основной формат Open XML для книги с листами, стилями, формулами и объектами. XLS поддерживает старую двоичную модель и имеет более жёсткие лимиты; при преобразовании современной книги часть возможностей может быть упрощена. XLSM отличается наличием макропроекта: библиотека сохраняет его как непрозрачную часть, но не исполняет и не редактирует VBA.

CSV не хранит несколько листов, стили, формулы как объекты, диаграммы и ширину столбцов. У него нет универсального соглашения о разделителе, кодировке и формате даты. Экспорт должен явно задавать разделитель и кодировку, а импорт — учитывать кавычки, переводы строк внутри поля и BOM. Для русских данных часто проверяют совместимость с Excel, который может ожидать разделитель, связанный с региональными настройками.

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

SpreadStreamProcessing для больших выгрузок

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

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

Потоковый подход не отменяет лимитов XLSX и требований к валидным значениям. Слишком длинная строка, недопустимый символ XML или имя листа остановят экспорт поздно, когда уже записан большой объём. Поэтому значения очищают и проверяют до открытия строки, а временный результат пишут в отдельный объект и публикуют только после успешного закрытия архива.

ZipLibrary и упаковка результатов

RadZipLibrary создаёт, читает и обновляет ZIP-архивы и предоставляет потоки сжатия. Она удобна, когда одно задание формирует комплект PDF, DOCX и XLSX, который нужно отправить одним файлом. Имя каждой записи нормализуют и не позволяют пользовательскому значению создавать путь ../, иначе при распаковке возникнет риск выхода за целевой каталог.

При чтении чужого архива ограничивают число записей, суммарный распакованный размер и коэффициент сжатия. Небольшой ZIP может развернуться в гигантский объём и исчерпать диск или память. Запись извлекают потоком, а не загружают целиком, и проверяют фактический объём независимо от значения, заявленного в заголовке.

DOCX и XLSX сами являются ZIP-контейнерами Open XML, но их внутреннюю структуру не следует менять архивными операциями без понимания связей и типов содержимого. Для редактирования документа используют соответствующую модель Flow или Spreadsheet; ZipLibrary уместна для упаковки готовых файлов и общих архивных задач.

Встраивание в веб-приложение и API

В HTTP-обработчике входной файл принимают в поток, проверяют размер и тип, затем передают в сервис документов. Результат возвращают с корректным MIME-типом и безопасным именем. Тяжёлую конвертацию не стоит выполнять внутри короткого синхронного запроса: для больших документов создают задание в очереди, а клиент получает идентификатор и позже скачивает готовый объект.

Сервис документов должен быть отделён от контроллера. Он принимает данные и параметры, выбирает модель, управляет тайм-аутом и возвращает результат или структурированную ошибку. Такое разделение упрощает тестирование на эталонных файлах и предотвращает размножение различающихся настроек шрифтов, лицензии и провайдеров по всему приложению.

В многопользовательской среде временные файлы размещают в отдельной папке задания и удаляют в блоке finally. Имена не строят напрямую из пользовательской строки. Если используется поток памяти, ограничивают максимальный размер; перевод всей 500-мегабайтной книги в byte[] удваивает пиковое потребление памяти и может остановить процесс.

Фоновые службы, облако и контейнеры

В контейнере заранее устанавливают шрифты, необходимые шаблонам, и проверяют лицензионный файл в контексте пользователя процесса. Различия между локальным компьютером и Linux-контейнером проявляются в путях, регистре имён файлов и наборе графических зависимостей для изображений. Проверку проводят на том же базовом образе, который пойдёт в эксплуатацию.

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

Масштабирование по числу экземпляров эффективно, если задания независимы. Предел параллелизма определяют по памяти и CPU: PDF с изображениями и компоновка Word нагружают процесс иначе, чем потоковая запись CSV. Автоматический регулятор должен учитывать не только длину очереди, но и типы заданий и их размеры.

Производительность и управление памятью

Первое измерение проводят на реальных файлах, а не на пустом документе. Фиксируют время импорта, изменения и экспорта отдельно, пиковую память, размер результата и число страниц или строк. Так видно, где находится узкое место: декодирование изображений, компоновка, формулы, сжатие или передача потока.

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

Параллельность добавляют после профилирования. Один документ обычно обрабатывается последовательным кодом, а масштаб достигается несколькими независимыми заданиями. Общие кеши шрифтов и шаблонов должны быть потокобезопасны; объекты документов и редакторов не следует без доказательств делить между потоками. При исчерпании памяти уменьшают конкурентность, а не только увеличивают лимит процесса.

Безопасная обработка недоверенных документов

Расширение файла не доказывает его формат. Вход проверяют по сигнатуре и затем передают конкретному провайдеру с ограничением времени. Пароли, ключи подписи и персональные данные не попадают в журнал. Сообщение пользователю содержит понятную причину, а технический журнал — тип исключения, стадию и идентификатор задания без содержимого документа.

Активные элементы — внешние ссылки, вложения, действия PDF и макросы XLSM — требуют политики. Даже если библиотека не исполняет VBA, сохранённый макрос запустится позже в Excel при разрешении пользователя. Система, принимающая файлы из неизвестного источника, может удалять макропроект и опасные действия или помещать результат в карантин.

Ограничения задают для страниц, размеров изображений, количества элементов, распакованного объёма Open XML и глубины вложенных архивов. После экспорта проверяют, что файл действительно открывается соответствующим провайдером. Для публичного сервиса процесс обработки запускают с минимальными правами, без доступа к секретам и произвольным сетевым адресам.

Диагностика типичных ошибок установки

Ошибка восстановления NuGet сначала проверяется по источникам пакетов и правилам packageSourceMapping. Пакет может быть доступен в галерее, но конфигурация разрешает префикс Telerik.* только другому источнику. В выводе restore видно, какие источники были рассмотрены. Исправляют карту источников и очищают локальный кеш только после того, как понятна причина.

Сообщение о невозможности загрузить сборку часто означает несовпадение версий. Просматривают транзитивное дерево, удаляют старые прямые ссылки на DLL и проверяют папку публикации. Ручное копирование одной новой сборки поверх старого набора недопустимо: зависимости моделей и провайдеров должны обновляться вместе.

Если два продукта объявляют тип с одинаковым именем, C# может показать неоднозначную ссылку. Полностью квалифицированное имя решает простой случай, а для конфликтующих сборок применяют alias ссылки и extern alias. Такое решение документируют, потому что неочевидный псевдоним легко потерять при переносе проекта.

Ошибки импорта и экспорта

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

Пустой или повреждённый результат часто появляется, когда поток читают до завершения Dispose экспортера или не возвращают позицию в начало. Для потоковых XLSX закрытие писателя завершает ZIP-структуру; преждевременная отправка оставляет архив без центрального каталога. Экспорт выполняют полностью, затем проверяют сигнатуру и только после этого публикуют.

Тайм-аут не следует лечить бесконечным увеличением. Сначала определяют размер и элемент, на котором замедляется обработка: огромное изображение, таблица, формула или повреждённый объект. Затем выбирают потоковый API, уменьшают изображение, разбивают задание либо изолируют файл. Для известных крупных документов можно назначить отдельную очередь с большим лимитом.

Проблемы шрифтов и изображений

Если кириллица заменяется квадратами, проверяют, содержит ли выбранный шрифт нужные глифы и доступен ли он процессу. Название семейства в CSS или DOCX не гарантирует наличие файла. В контейнере перечисляют установленные шрифты и тестируют строку со всеми используемыми алфавитами. Подмена должна быть детерминированной, иначе переносы строк меняются между узлами.

Ошибки изображения могут быть связаны с неподдерживаемым кодеком, повреждённым потоком или отсутствующим format provider для конкретной платформы. Формат определяют по сигнатуре, а не по расширению. Изображение предварительно открывают безопасным декодером, ограничивают размеры и при необходимости преобразуют в поддерживаемый PNG или JPEG.

Размытый результат возникает, когда маленький растр растягивается на большую область или JPEG повторно сжимается. Огромный файл — когда фотография с камеры вставлена без уменьшения. Для каждого типа шаблона задают целевое физическое измерение и разумный DPI, сохраняя исходник отдельно, если он нужен для архива.

Лицензия и воспроизводимая сборка

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

В CI ключ передают секретом и размещают способом, предусмотренным инструментами Telerik; его не сохраняют в репозитории, образе контейнера и артефакте сборки. Лог не должен выводить содержимое ключа. Отдельный тест запускает простую генерацию в опубликованном артефакте, потому что успешная компиляция на машине разработчика не гарантирует корректную активацию в среде доставки.

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

Как тестировать документный конвейер

Модульный тест проверяет данные модели: число страниц, наличие закладки, значение поля формы, текст ячейки или формулу. Интеграционный тест экспортирует файл и снова импортирует его другим экземпляром провайдера. Такой round-trip обнаруживает ошибки сериализации, которые не видны при проверке объекта в памяти.

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

Набор примеров должен включать кириллицу, длинные слова, пустые значения, большие числа, разные часовые пояса, альбомную секцию, таблицу на границе страницы, прозрачное изображение, защищённый PDF и повреждённый вход. Для XLSX добавляют формулы, фильтр, скрытые строки, диаграмму и XLSM с макропроектом, который требуется сохранить, но не запускать.

Метаданные документа и служебные свойства

PDF, DOCX и XLSX содержат свойства, которые не видны на странице: автор, заголовок, тема, ключевые слова, даты создания и изменения, сведения о приложении-производителе. В автоматическом процессе эти поля заполняют из доверенных данных, а не копируют без проверки из пользовательского шаблона. Метаданные могут раскрыть имя сотрудника, путь к файлу или внутреннее название проекта, поэтому перед внешней публикацией выполняют отдельную очистку.

В PDF словарь сведений и XMP-метаданные способны хранить похожие значения одновременно. Если изменяется только один источник, разные просмотрщики покажут разные свойства. Для архива и интеграции значения синхронизируют и проверяют после экспорта. Ключевые слова записывают как осмысленный набор терминов, а не как длинную строку тегов сайта; это улучшает внутренний поиск, но не заменяет извлечение текста.

У книг Excel и документов Word есть дополнительные пользовательские свойства. Их удобно использовать для идентификатора заказа, версии шаблона или номера процесса, если получатель должен видеть эти данные в свойствах файла. Секреты, токены и технические пути туда не помещают: метаданные легко читаются без открытия документа в редакторе. При клонировании шаблона даты и авторство обновляют осознанно, иначе новый договор сохранит сведения исходного автора.

Удаление колонтитулов, водяных знаков и фоновых элементов PDF

Удаление элемента из готового PDF требует определить, чем он представлен. Колонтитул может быть текстом в основном content stream, повторяющимся Form XObject, аннотацией или частью фонового изображения. Универсальная команда удалить верхний колонтитул не может безошибочно отличить номер страницы от обычного текста в той же области, поэтому алгоритм сочетает координаты, содержимое, шрифт и повторяемость на нескольких страницах.

Для шаблонного файла надёжнее найти конкретный объект или ресурс, чем закрывать область белым прямоугольником. Маска не удаляет текст: его можно извлечь, скопировать или увидеть при изменении фона. Настоящее удаление изменяет content stream и затем очищает неиспользуемые ресурсы. Если исходник подписан, любое такое изменение нарушает подпись; приложение должно предупредить об этом до сохранения.

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

Добавление содержимого в существующий PDF

При добавлении штампа, номера дела или QR-кода важно сохранить исходные объекты, формы и подписи настолько, насколько это допускает операция. Новый контент размещают в отдельном потоке страницы поверх или под существующим слоем. Выбор слоя определяет, перекроет ли штамп текст и будет ли он виден на фоне изображения. Для полупрозрачного знака задают графическое состояние, а после вставки восстанавливают его.

Координаты рассчитывают от фактической MediaBox или CropBox страницы. В одном PDF страницы могут иметь разные размеры, а видимая область — не начинаться в нуле. Поворот на 90 или 270 градусов меняет пользовательское восприятие осей. Перед массовой нумерацией строят функцию преобразования из желаемой позиции правый нижний угол в координаты конкретной страницы и тестируют все четыре поворота.

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

Преобразование HTML и различия моделей разметки

HTML в WordsProcessing импортируется как потоковое содержимое, а не как снимок браузерной страницы. Поддерживаемые элементы и стили преобразуются в абзацы, runs, таблицы и изображения RadFlowDocument. Скрипты, интерактивная логика и сложная браузерная компоновка не имеют прямого эквивалента в DOCX. Поэтому шаблон для конвертации делают семантически простым: заголовки, абзацы, таблицы, списки и предсказуемые CSS-свойства.

Относительные пути к изображениям требуют базового адреса или пользовательского поставщика ресурсов. В серверной среде нельзя позволять произвольному HTML загружать файлы из локальной системы или внутренней сети. Разрешённые схемы и домены задают явно, загрузку ограничивают по времени и размеру, а полученные изображения проверяют как недоверенный ввод. Для воспроизводимого результата внешние ресурсы лучше заранее вкладывать в шаблон или передавать контролируемыми потоками.

При экспорте Flow в HTML страничные свойства Word упрощаются: разрывы, колонтитулы и плавающие объекты могут быть представлены иначе, потому что браузер не опирается на ту же пагинацию. Если конечная цель — точная печатная копия, используют PDF. HTML выбирают для редактируемого веб-представления и заранее принимают различия в переносах и размерах.

Данные из базы и локализация документов

Числа и даты следует хранить в модели как типизированные значения, а форматировать на границе документа. Для XLSX задают числовое значение и формат ячейки; для DOCX и PDF применяют культуру при создании строки или поля. Такой подход позволяет одной и той же сумме участвовать в формуле и отображаться с нужной валютой. Передача уже локализованного текста в Excel лишает книгу возможности корректно сортировать и вычислять.

Шаблон не должен выполнять бизнес-расчёты, которые определяют юридически значимый итог. Налог, скидка и округление рассчитываются доменной логикой, а документ отображает полученные значения и, при необходимости, контрольные формулы. Это предотвращает расхождение PDF и XLSX при разных правилах округления. Для денежных сумм фиксируют количество знаков и стратегию округления до начала генерации.

Локализация включает не только перевод подписей. Меняются длина текста, формат адреса, направление письма, шрифт и правила переноса. Для каждой поддерживаемой культуры нужен эталонный документ с длинными значениями и символами соответствующего алфавита. Строки интерфейса ошибки не должны попадать в сам документ; при отсутствии перевода генерация либо использует утверждённый резервный язык, либо останавливается до выпуска.

Поддержка форматов изображений и поставщики ресурсов

На переносимых платформах обработка некоторых форматов изображений может зависеть от дополнительного format provider. Это особенно заметно при импорте DOCX или PDF, содержащего TIFF, необычный PNG или графику, созданную старым сканером. Провайдер регистрируют до импорта, иначе документ может загрузиться без изображения или завершиться исключением в момент первого обращения к нему.

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

Векторная графика сохраняет резкость при масштабировании, но не каждый исходный формат поддерживается одинаково во всех провайдерах вывода. Перед выбором SVG или растра проверяют путь до конечного PDF, DOCX и XLSX. Для печатного логотипа предпочтителен вектор, если весь конвейер сохраняет его корректно; иначе используют подготовленный PNG достаточного разрешения и без лишней прозрачной рамки.

Сравнение Telerik Document Processing с аналогами

Прямые аналоги отличаются не только числом операций с PDF, но и охватом Word и Excel, моделью лицензирования и способом проектирования документа. Таблица ниже сравнивает типичные задачи, а не маркетинговые баллы.

Программа	Лучше подходит для	Главное ограничение
Telerik Document Processing	Единого .NET-конвейера для PDF, DOCX, XLSX, CSV и ZIP с общей системой пакетов	Нет готового окна ручного редактирования; требуется коммерческая лицензия для эксплуатации
PDF Commander	Ручного редактирования, объединения, подписания и подготовки PDF пользователем без программирования	Не заменяет серверный SDK и не строит автоматический конвейер Word или Excel
Aspose.PDF for .NET	Глубокой программной обработки PDF и работы со стандартами PDF/A, PDF/X, PDF/E и PDF/UA	Оценочный режим ставит водяной знак и ограничивает обработку первыми четырьмя страницами
Syncfusion .NET PDF Library	PDF-функций в приложениях Syncfusion, включая формы, сжатие, конвертацию и OCR через дополнительные компоненты	Часть сценариев требует отдельных конвертеров или OCR-пакета и корректной регистрации лицензии
iText Suite for .NET	PDF-проектов с открытыми стандартами, расширениями для HTML, OCR, редактирования и сложной типографики	Бесплатное применение подчиняется AGPL; закрытому продукту обычно нужна коммерческая лицензия
IronPDF	Создания PDF из HTML, CSS и JavaScript с помощью встроенного Chromium и последующей PDF-обработки	Не охватывает полноценную объектную модель DOCX и XLSX, а движок рендеринга увеличивает поставку

Для сотрудника, которому нужно исправить готовый PDF вручную, рациональнее PDF Commander. Telerik выбирают, когда один .NET-сервис должен генерировать и преобразовывать PDF, Word и Excel по данным приложения. Aspose.PDF и iText подходят для PDF-центричных проектов с особыми стандартами или расширениями; Syncfusion удобен в экосистеме его компонентов; IronPDF особенно силён там, где шаблоны уже написаны на HTML и требуется браузерное качество рендеринга.

Практический выбор модели для задачи

Счёт по данным заказа удобнее строить как потоковый Word-документ, если бизнес-пользователь редактирует шаблон, а затем экспортировать в PDF и подписать. Строго фиксированный государственный бланк проще заполнять через PdfProcessing. Аналитическую выгрузку с формулами и диаграммой создают SpreadProcessing, а миллион строк без сложного оформления — SpreadStreamProcessing.

Существующий PDF с сотнями страниц объединяют потоковым PDF API, если содержимое не меняется. Если нужно удалить водяной знак, заменить изображение или заполнить поля, загружают модель. Архив из нескольких результатов упаковывают ZipLibrary после того, как каждый файл успешно прошёл повторное открытие.

Не стоит выбирать модель по расширению конечного файла. PDF может быть результатом Flow или Spreadsheet, а не только RadFixedDocument. Выбор делают по исходной структуре и типу изменений: потоковый текст, фиксированные координаты, ячейки или последовательная выгрузка.

Контрольный список перед внедрением

До разработки собирают реальные образцы и фиксируют обязательные форматы, шрифты, объём, подписи, шифрование и требования к доступности. Затем выбирают пакеты и создают минимальный конвейер импорт — изменение — экспорт — повторный импорт. Его запускают в целевой среде, а не только из IDE.

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

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

Итоговая схема эксплуатации

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

Telerik Document Processing наиболее полезен там, где документы являются частью бизнес-процесса, а не разовой ручной операцией. Точный выбор между Fixed, Flow, Spreadsheet и потоковыми API позволяет сохранить структуру, ограничить память и не усложнять код низкоуровневыми операциями там, где достаточно высокоуровневой модели.

Финальная проверка всегда выполняется над экспортированным файлом: он повторно открывается, проходит структурные и визуальные тесты, а для подписи и архивного стандарта — отдельную валидацию. Только после этого результат публикуется, отправляется пользователю или помещается в долговременное хранилище.