Уменьшаем размер файла pdf, созданного функцией сканирования, и скорость его преобразования
Предыстория
При создании документов в РКК со сканера заметил, что размер файла громадный. 3 мб для одностраничного текстового документа. Стал разбираться и вот, что нашел: документ сканируется сканером в tiff, который сохраняется во временной папке. Затем этот документ подхватывается программой обработки директума и преобразуется в пдф, который и регистрируется в системе, но размер исходного(tiff) и конечного(pdf) файла при этом отличается всего, примерно, на 10%, т.е. 3 МБ и 2,7 МБ.
В техподдержке посоветовали посмотреть в сторону twain драйвера для сканера, но перехватив промежуточный документ(tif) я попробовал его сохранить стандартным принтером win10: "Microsoft Print to PDF" и увидел, что размер файла pdf уменьшился, почти, в 10 раз! 300 КБ - приемлемый размер для документа.
Возникло предположение , что дело в настройках конвертера directum, но установки качества в центре администрирования не привели вообще ни к какому результату.
Поиск решения
Для устранения проблемы решили использовать стороннее приложение.
Для этого был выбран ImageMagick. Эта программа позволяет производить операции над графическими файлами в неинтерактивном режиме и совершенно бесплатна.
Полученный от сканера файл кодирую в jpeg(эта кодировка дала наилучший результат) и сохраняю в pdf(причем, в случае многостраничного документа исходник автоматически разбивается на несколько файлов, которые затем сами собираются в один файл). Результат превзошел ожидания: размер тестового файла уменьшился с 3 МБ до 360 КБ(без видимых потерь в качестве), скорость преобразования - пара секунд для пятистраничного файла(с нативным занимало более 10 секунд).
Описание решения
Скачал портативную версию с сайта и положил в общедоступную папку на сервере директума(расположение может быть любым), путь к которой поместил в константу. Создал функцию(описание из созданной справки):
Функция предназначена для конвертирования файлов в pdf.
Группа:
ОДК
Синтаксис:
ODK_ConvertFileToPDF(
InputFileName: Строка;
OutputFileName: Строка;
[compressType: Строка = 'JPEG'];
[qualityPercent: Целое число = 80])
Параметры:
InputFileName - Имя исходного файла
OutputFileName - Имя выходного файла
compressType - Тип сжатия
qualityPercent - Качество выходного файла в процентах.
Возвращаемое значение:
В случае успешного завершения возвращается 0.
При возникновении ислючения возвращается -1.
При возникновении ошибки конвертирования возвращается значение >0.
Описание:
Альтернатива стандартного преобразования, но с увеличенной скоростью работы и возможностью способов сжатия. В качестве конвертера исопльзуется imagemagick.
Подробнее:
https://www.imagemagick.org
Типы сжатия:
https://www.imagemagick.org/script/command-line-options.php#compress
Качество картинки:
https://www.imagemagick.org/script/command-line-options.php#quality
Текст функции:
//проверяем параметры
CheckParam('InputFileName'; InputFileName)
CheckParam('OutputFileName'; OutputFileName)
//получаем путь к конвертеру(общедоступная папка)
converterPath = GetConstant('ODK_ConverterToPDFPath')
//формируем командную строку
command = format( '"%s" "%s" -compress %s -quality %s "%s"'; arrayof(converterPath; InputFileName; compressType; qualityPercent; OutputFileName))
//запускаем с заданными параметрами
try
Shell = CreateObject("WScript.Shell")
Result = Shell.Run(command; 0; True)
except
Result = -1
endexcept
Далее, вызов функции поместил в начало стандартной функции по преобразованию файла в PDF(DCTSConvertFileToPDF) таким образом, чтобы в случае неудачной обработки нашей функции запускалась стандартная(нативная).
// Объявление констант
ADO_BINARY_TYPE = 1 // adTypeBinary
ADO_READ_ALL = -1 // adReadAll
ADO_SAVE_CREATE_OVERWRITE = 2 // adSaveCreateOverWrite
EXTENSION_MASK = "E"
FIRST_AVAILABLE_TRANSFORMATION_INDEX = 0
// Проверить входные параметры
CheckParam("WSDLFileName"; WSDLFileName; "")
CheckParam("InputFileName"; InputFileName; "")
CheckParam("OutputFileName"; OutputFileName; "")
//исправляем громадный размер файла за счет преобразования в сторонней программе imagemagick
imagemagickResult = ODK_ConvertFileToPDF(InputFileName; OutputFileName)
if imagemagickResult <> 0
//стандартное преобразование
// Инициализация подключения к сервису
SoapClient = CreateObject("MSSOAP.SoapClient30")
//...
//...
//...
ADOStream.Close()
endif
Проверено для версии 5.3 По умолчанию выставлена степень сжатия 80% JPEG
А почему б, до кучи, не прикрутить какую нибудь свободную библиотеку распознавания, и поиск по документу сразу заработает.
Вообще удивлен был отсутствию такого функционала, хотя бы в зачаточном состоянии.
Ильдар, такой задачи не ставилось. Да, и ПК у большинства пользователей, довольно, слабые, поэтому добавление распознавания текста сильно сказалось бы на производительности.
Можно перенести распознавание на сервер, но, опять же, ставилась задача, прежде всего, уменьшения размера скана и ускорения преобразования, а распознавание, наоборот, увеличит время внесения документа в систему.
Кирилл, возможность управлять размером создаваемых сканов и результирующего pdf-документа есть в стандартном функционале (параметры функции создания скана). Размером формируемого pdf-документа также можно управлять через параметры соответствующих типов конвертации на службе преобразования. Но эта информация больше к сведению для остальных участников сайта, у вас уже есть неплохое альтернативное решение ;)
А вот существенно выиграть в скорости создания PDF из скана, действительно, сложно, если на транспорт от клиента до сервиса со службой преобразования уходит много времени. Чем слабее клиентский ПК, тем медленнее будет происходить этот процесс (речь только о потерях на транспорт, без самой конвертации).
Далее уже немного вопросов: используете ли вы штрих-коды на документах и какова стабильность их распознавания при печати\копировании с такими сжатиями? Чудес, к сожалению, не бывает и рано или поздно малый размер\низкое кач-во дают о себе знать...
Каким образом распространяете на клиентские ПК дополнительный модуль с нужным ПО? Ставите ли всем или только делопроизводителям?
Константин, у меня возникало предположение , что дело в настройках конвертера directum, но установки качества в центре администрирования не привели вообще ни к какому результату.
Возможно, я что-то пропустил? Где-то еще есть настройки?(может быть потому, что у меня версия 5.3, в которой еще не реализована часть настроек)
Потому что все, что там было я уже покрутил, причем совместно со службой поддержки Directum. Все предложенные варианты не сработали и мне было предложено поиграть с настройками TWAIN драйвера сканера.
Штрихкодов и распознавание текста не используем, но не думаю, что с этим будут проблемы, поскольку размер файла и качество(по визуальной оценке) не отличается от варианта, который получается при преобразовании исходного TIFF документа со сканера с помощью стандартной утилиты windows 10 Microsoft Print To PDF.
Если у кого-то возникнут с этим проблемы, то качество можно задать в параметре: qualityPercent.
Распространение ПО не требуется. Портативная версия программы располагается в общедоступной папке на сервере(в нашем случае это сервер директума). К этой папке всем пользователям необходим доступ на чтение. Поэтому никаких дополнительных установок не требуется.
Конечно это надо делать на стороне сервера, у нас с RXом это очень заметно - создавали какой нибудь документ многостраничный размером в пару десятков мб, он три часа заливается в облако, и затем каждый кто его пытался просмотреть так же по три часа скачивал его себе это сильно тормозит работу и злит сотрудников. Решилось запретом на сканирование средствами директум, благо лицензии на файнридер есть.
на сколько я знаю файнридер можно прикрутить виде сервиса на облако, почему не реализовать готовый функционал и брать за это денежку дополнительную?
Ильдар. Распознавание - это только первый этап того, что можно делать с контентом. Интеллектуальные инструменты работы с контентом могут больше!
Приходите на наш вебинар 3 апреля. Будем рассказывать о таких инновационных инструментах в составе системы DIRECTUM. Будет эксклюзивная информация. ;)
Регистрация https://www.directum.ru/events/practicum_directum_intellektualnaja_esm__dolojj_rutinu
Ильдар,
На клиенте делать распознавание в большинстве случаев не катит из-за необходимости дополнительных лицензий. Делать это надо на сервере. А значит на сервер надо заливать оригинальный, не сжатый файл, чтобы распознавание лучше работало.
А сделать распознавание/сжатие на сервере довольно просто, это уж каждый может себе сделать через софт, на который есть лицензия/который нравится.
Как-то в Directum была проблема у пользователей, работающими через VPN, со скоростью предпросмотра тяжеловесных документов-изображений. В итоге сделали автоматическое формирование на сервере легковесной (в 10-100 раз легче) превьюшки в последней действующей версии документа, сохраняя при этом оригинал.
Кирилл,
Проблемы с ШК будут, если сжимать, там требуется хорошее качество. Но с ШК обычно немного другой процесс и там можно сжимать сразу после распознавания ШК.
И да, DCTS в плане сжатия - отстой. Решение, представленное в статье - супер!
"установки качества в центре администрирования не привели вообще ни к какому результату"
"И да, DCTS в плане сжатия - отстой."
И это притом, что Native2 работает уже на порядок быстрее остальных вариантов.
А для конвертации всевозможных картинок в наше время рекомендуется использовать libvips в различных вариантах. Как консольные утилиты, так и до полноценных серверов преобразований.
Кирилл, спасибо большое! Это самая полезная статья про службу ввода на всём клабе.
Авторизуйтесь, чтобы написать комментарий