Конвертер PDF в Word

PDF (ISO 32000-1 для PDF 1.7 и ISO 32000-2 для PDF 2.0) — формат с фиксированным макетом, содержимое страницы которого представляет собой поток операторов рисования (`Tf` для выбора шрифта, `Td` для позиционирования текстового курсора, `Tj` для вывода строки глифов, `Tm` для текстовой матрицы), а не модель потокового документа. На уровне файла нет концепции абзаца, заголовка или таблицы — это визуальные артефакты, созданные абсолютно позиционированными группами глифов. Конвертация в DOCX (Office Open XML, ECMA-376 / ISO/IEC 29500), который ЯВЛЯЕТСЯ потоковой моделью с абзацами `<w:p>`, таблицами `<w:tbl>` и свойствами текстовых фрагментов внутри ZIP-контейнера, представляет собой задачу реконструкции, а не трансляции. Само извлечение текста зависит от `ToUnicode` CMap шрифта внутри каждого встроенного шрифта: если CMap отсутствует или отображает идентификаторы глифов в кодовые точки пользовательской области Unicode (частый паттерн защиты от копирования), видимые символы невозможно восстановить без OCR, хотя страница отображается корректно. Загруженный PDF разбирается серверным движком конвертации ToolAct: поток содержимого страницы читается как позиционированные текстовые блоки, поверх которых реконструируется структура документа. Реконструкция абзацев требует кластеризации этих блоков по y-координате (в пределах примерной высоты строки), сортировки по x-координате, определения границ колонок из гистограммы начальных x-позиций и вывода переносов строк из промежутков. Реконструкция таблиц сложнее: таблицы с границами восстанавливаются пересечением операторов линий (`re`, `l`, `S`) в сетку и распределением текстовых блоков по ячейкам; таблицы без границ требуют эвристик определения колонок, как в Tabula или Camelot, а точность резко падает при объединённых ячейках или многострочных строках. Извлекаются изображения из словаря XObject страницы и повторно встраиваются в папку `media/` DOCX. Выход DOCX собирается как ZIP, содержащий `[Content_Types].xml`, `word/document.xml`, `word/styles.xml` и медиафайлы. Точность циклической конвертации ограничена: PDF на основе текста с одноколоночным основным текстом конвертируются чисто; многоколоночные научные макеты, таблицы без границ, математическая вёрстка, лигатуры с отсутствующим CMap и повёрнутый текст — всё это деградирует. 100% сохранение произвольного PDF доказуемо невозможно, поскольку исходная модель строго выразительнее целевой. Файлы удаляются с сервера сразу после завершения конвертации.

• Спецификация PDF: ISO 32000-1 (PDF 1.7) / ISO 32000-2 (PDF 2.0). Содержимое страницы — поток операторов (`Tf`, `Td`, `Tj`, `Tm`), рисующих позиционированные глифы — на уровне файла нет абзацев/заголовков/таблиц.
• Спецификация DOCX: Office Open XML, ECMA-376 / ISO/IEC 29500. ZIP из XML-частей (`word/document.xml`, `word/styles.xml`, `[Content_Types].xml`) с абзацами `<w:p>` и таблицами `<w:tbl>` — потоковая модель.
• Извлечение текста зависит от ToUnicode CMap шрифта; PDF с отсутствующими или отображёнными в PUA CMap отображаются корректно, но извлекаются как бессмыслица, вынуждая использовать OCR.
• Файлы загружаются в серверный движок конвертации ToolAct и удаляются сразу после завершения конвертации.
• Реконструкция абзацев: кластеризация текстовых блоков по y-координате в пределах ~1 высоты строки, сортировка по x, определение колонок из гистограммы начальных x-позиций, вывод переносов строк из промежутков между блоками.
• Реконструкция таблиц: таблицы с границами получаются пересечением операторов линий `re`/`l`/`S` в сетку; таблицы без границ требуют эвристик определения колонок (Tabula/Camelot) и деградируют при объединённых или многострочных ячейках.
• 100% сохранение PDF→DOCX доказуемо невозможно — исходная модель строго выразительнее целевой. Сильнее всего деградируют многоколоночные научные макеты, таблицы без границ, математическая вёрстка и повёрнутый текст.