Adamos

https://htmlbook.ru/html/input/required

В РНР не было принято над этим заморачиваться раньше, а сейчас и вовсе потеряло смысл.
Потому что уж такие детские оптимизации, как копирование массивов и объектов только при изменении, давно реализованы и отлажены.

Недоступны цветовые профили.
В Дебиане они лежат /usr/share/color/icc/ghostscript/ - в Центосе где-нибудь там же.
Проверяйте доступ.
Можно прямо в команде указать

-profile /path/to/gray.icc -profile /path/to/sRGB.icc -colorspace sRGB

появилась проблема что не читает кирилицу

"Доктор, у меня проблема" - сказал старый партизан. И больше никакой информации не выдал!

Ладно, погадаем на гуще. Если раньше все работало и ТС качал (откуда-то) некую "новую версию", можно предположить пальцем в небо, что к этой скачанной версии тупо приложены шрифты без кириллицы. В mPDF шрифт можно подложить буквально при генерации, указав путь. Как там в dompdf - надо гуглить.

convert -list format покажет, что у IM с поддержкой этого формата.
Про SVG должно выдать три подобные строчки:

MSVG  SVG       rw+   ImageMagick's own SVG internal renderer
SVG   SVG       rw+   Scalable Vector Graphics (XML 2.9.4)
SVGZ  SVG       rw+   Compressed Scalable Vector Graphics (XML 2.9.4)

Отдельно в этих строчках стоит посмотреть на права (rw+) - может оказаться, что в /etc/ImageMagick-6/policy.xml запрещено конвертировать из этого формата ввиду теоретических эксплойтов.

Если вам нужна строго определенная точность - забудьте про float. Для этой математики даже 0.7 - бесконечная дробь.
Храните int, при вычислениях делите на миллион, при приведении в строку - втыкайте точку за шесть знаков до конца. Класс на три метода, написать и забыть проблему.

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

switch($functionName) {
  case 'index': return index();
  case 'store': return store();
}

$registry = array(
  'index'  => new ActionIndex(),
  'store' => new ActionStore()
)
$registry[$functionName]->run();

Два самых информативных слова в вопросе - receipt и gazprom. Что делается, из чего - поди догадайся.
Теоретически такие закривулины, например, появляются, когда данные кривой Безье искажаются при пересчете и получившаяся кривая улетает за горизонт.
Косой шрифт, например, может так растеризоваться.
Или векторная графика из Корела и подобных ему любительских программ и клипартов к ним, где кривые состоят из сотен узлов друг на друге.

Ошибки в РНР нужно отлаживать и устранять.
А с AJAX-запросами логично предусмотреть возврат не только запрошенного, но и ошибки, если она случилась.
С соответствующей обработкой.

Редактор статей работает на фронте. РНР тут вообще ни при чем.
А список JS WISIWIG-редакторов - только гугль спросить.

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

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

mPDF позволяет положить исходный PDF фоном и сверху (по координатам) налепить добавки.
Но для произвольного PDF вы просто не будете знать, что куда положить.

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

Ваш класс БД будет работать с таблицами. Зачем ему лезть в файлы? Его задача (и единственная ответственность) - прослойка между кодом, который обращается к БД, и кодом, который реализует хранение. Не нужно в него совать куски ни из того, ни из другого.
Сделайте таблицу отдельным классом, который принимает имя файла в конструкторе. В нем уже читайте и пишите данные в файл.
Сделайте фабрику, которая по имени файла выдает класс таблицы-файла либо создает его, проверяя наличие такого имени в системе и инкапсулируя в себе ВСЮ логику имен файлов, путей и проч. Классу БД об этом знать незачем, классу таблицы - тем более.
В общем, делите код на то, что надо сделать вот здесь на этом уровне логики, и выкидывайте из него все, что требует опуститься на уровень ниже, в соответствующие классы. И работайте только с их методами, не вникая в реализацию. Не размазываете реализацию конкретных вещей по коду - собирайте ее в одно место, и пусть за нее отвечает только один класс.

На сервере делаете очередь задач, которые должны быть напечатаны, и API, по которому локальный компьютер может обратиться, забрать задачу и отметить ее напечатанной.
На локальной машине можно запускать буквально одну HTML-страницу в браузере, в которой JavaScript обратится к серверу, получит PDF, откроет окно печати. Или загрузит все задания, объединит их в одну PDF-ку и уже тогда откроет окно печати. Потом выведет подтверждение пользователю - отметить эти задания как выполненные или повторить печать.
Полностью автоматизировать печать так не получится, но это и не нужно - за этой капризной скотиной-принтером все равно должен постоянно следить оператор...