Moskus

https://www.adobe.com/content/dam/acom/en/devnet/p...

Напечатать из текстового редактора на виртуальном PDF-принтере. Например, Bullzip.

Написать batch-скрипт, в котором через цикл FOR вы пройдете по всем исходным файлам, проверяя несуществование файла с таким же именем в целевой папке и если он не существует, записывая его имя в log-файл.
Делается одной строкой.

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

(1) - самое верное решение. Не надо пытаться навязать пользователю тот способ просмотра, который нравится вам или кому-то еще. Позвольте ему пользоваться тем, который устраивает его, и которое у него настроено (скачивание, просмотр средствами browser-а, что-то еще).
(2) - плохое решение, потому что встроенный в страницу viewer крадет пространство экрана, а если не крадёт, то это эквивалентно (1) в случае просмотра средствами browser-а. Особенно плохи именно всякие хреновины, показывающие разворот, а не страницу. Это чудовищно неудобно и нужно только в одном случае, которого следует категорически избегать - когда, например, есть PDF, сверстанный для печати на разворотах, где содержимое переходит с одной страницы на другую (так бывает с каталогами) и без того, чтобы видеть весь разворот, его просто невозможно читать.
(3) - вообще самое отвратительное решение, потому что теряется возможность копировать текст, менять масштаб, видеть векторные иллюстрации и т.п.

Общий совет: в этом случае (да и вообще, обычно) стоит идти от полезного функционала, а не от украшательства или субъективных критериев типа "выглядит дешево", "слишком просто" (просто для кого и почему?).

Например, так.
https://rossta.net/blog/building-a-pdf-viewer-with...
Плохо искали.

Хитрая генерация PDF. Как?

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

Поскольку файлы создаются в том порядке, в каком строки хранятся в вашем исходном Excel-файле, вы можете написать batch-файл, который в цикле будет обходить pdf-файлы по порядковым номерам и переименовывать их на основе того, какое имя хранится в соответствующей строке. Вам только придется добавить в Excel колонку с номерами по порядку.
Синтаксис и примеры: https://ss64.com/nt/for_f.html

В Acrobat работа с формами более удобна. Создаете в InDesign шаблон, затем в Acrobat Pro добавляете в него формы. Формы с одинаковым именем будут заполнены одинаково (так можно заполнить сразу множество визиток на одном листе, например). Конверсия цветов при этом происходить не должна. Перед экспортом внимательно подготовьте настройки в профиле сохранения PDF, который будете использовать при экспорте - опции различных стратегий внедрения шрифтов там присутствуют, включая полное внедрение.

Вы можете создать PDF где угодно и какой угодно, путем вывода через PDF-принтер из любого редактора (Inkscape, Illustrator, да хоть MS Word). Далее, берется Acrobat Pro, не Reader, и в нем на нужных местах вы создаёте поля формы. На форму можно вешать шаблоны и скрипты.

Например, можно начать со штатных средств самого Photoshop. Экспорт в PDF там использует стандартный механизм preset-ов Adobe. Описано, например, тут: https://helpx.adobe.com/photoshop/using/saving-pdf...

С готовыми файлами можно повозиться средствами оптимизации в Acrobat Pro. Описано тут: https://helpx.adobe.com/acrobat/using/optimizing-p...
Им же, пользуясь функцией Audit space usage..., можно выяснить, в чём конкретно разница между вашими PDF и теми, которые вы считаете достаточно компактными и оптимальными.

PDF, в общем случае, совершенно не предназначен для хранения структурированных данных. Таблица в нем может (при определенных настройках экспорта из некоторых программ, способных создавать PDF) быть сохранена так, что ее можно прочесть, как структурированные данные (при этом сохраняется порядок строк а ячейки разделяются tab-ами, например). Но в общем случае, текст в PDF теряет структуру и хранится просто как векторное изображение, состоящее из текстовых символов.

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

Установить на сервер PDFtk, сделать шаблонный PDF с полями, из отправленных пользователем данных на PHP генерировать FDF-файл с данными формы (формат - текстовый) и далее - через выполнение внешней команды заполнять форму сгенерированными данными.
См. вот это: https://www.pdflabs.com/docs/pdftk-man-page/#dest-...

А кто же его знает?
Могу подсказать путь для исследования проблемы: создайте тестовый PDF, как можно проще, в Prawn. Пара прямоугольников и буква, например. Откройте его в Illustrator, приведите в чувство (если он выглядит неверно), сохраните (используя настройки той же версии PDF), сравните исходный и получившийся, найдите разницу.
Illustrator и Acrobat содержат "референсный" код работы с PDF, так что если что-то создано вне их, и в них выглядит не так, как должно, это означает ошибку в том софте (или в его настройках, что вероятнее), где PDF создан, а не в Illustrator.
Здесь, смею предположить, применен какой-то кривой цветовой профиль, либо применен он правильно, но неправильно указан.

PDFtk Server из командной строки.

Именные копии с внедренными личными данными покупателя.
Но, как верно сказано, скриншоты и OCR никто не отменял, так что любая защита - весьма условна.

Ищите приложения по ключевым словам pdf freehand annotation, их много.
Но вам не понравится.