Объединение изображений и pdf файлов в единый pdf файл

0. 287 13.02.20 08:10 Сейчас в теме
Обработка позволяет объединить все изображения и pdf файлы из каталога в единый pdf файл.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. aezdakov 13.02.20 11:05 Сейчас в теме
C:\Program Files\gs\gs9.50\bin>gswin64c -dBATCH -dNOPAUSE -dSAFER -sDEVICE=png16m -r300 -dPDFFitPage=true -dFIXEDMEDIA -sOutputFile="C:\Temp\test-%02d.png" "C:\Temp\СчФ выданный (2).pdf"

и не нужон этот ImageMagick ваш. Ghostscript прекрасно сам с этим справляется.
Но с этими конвертациями есть проблемы. Я использовал это, чтобы ZBar-ром распознавать штрихкоды, а из пдф получается файлы с большими потерями (как бы я не игрался с качеством), достаточными, чтобы ZBar их не распознавал в подавляющем большинстве случаев. Пришлось отказаться от идеи разбирать пдф.
2. 77dream77 287 13.02.20 14:21 Сейчас в теме
напрямую я не пробовал Ghostscript преобразовывать
преобразовывал с ImageMagick в png и распознавал текст потом на картинке, практически всегда распознавалось отлично
Также ШК распознавал на страницах, проблем не наблюдалось. Практически всегда ШК распознавался верно.
Возможно ImageMagick использует другие параметры преобразования или как-то дополнительно обрабатывает старницу после преобразования
Пробовал преобразовывать с ImageMagick в jpg, там да, качество получается плохим для распознавания
3. aezdakov 13.02.20 16:07 Сейчас в теме
(2)я первоначально ImageMagick тоже использовал, но когда увидел, что он использует Ghostscript, то перешёл напрямую на него, разницы не увидел.
jpg это jpg, он очень сильно отличается от png и в не лучшую сторону.
По штрихкодам, хорошо Вам. Лично я так и не смог решить проблему распознавания пдф через его конвертацию. По всем пробным тестам определил для себя минимум в виде сканирования в формат jpg с 300dpi, качество меньше - рост доли нераспознаных ШК близится к экспоненте, а выше особо не влияет, только увеличивает время на обработку одной страницы.
С командой Ghostscript я тоже очень долго игрался, то что выложил - это то, что осталось в загашнике, возможно эта команда лучшее, что смог добиться для себя. В конечном итоге я её не использую, отказался от идеи с пдф, так как по времени было эффективнее перестроить процесс, а не обуздать его логикой конвертаций. Да и концептуально стало такое решение лучше, так как пользователи скармливают сканеру стопку в 500 страниц за раз, а программа уже сама всё комплектует и распределяет по документам, а раньше пользователи сперва сами формировали пакет в разрезе документов (РТУ, ПТУ и т.д.) и видов печатных форм (СФ, акт, торг и т.д.).
Если, вдруг, попробуете поиграться с прямой конвертацией через GS, то сообщите ответом на мой комментарий, интересно узнать результат. Положительный для Вас будет отказ от ImageMagick, а для меня - понимание, почему у меня не взлетело.
4. 77dream77 287 28.02.20 23:03 Сейчас в теме
(3) а у Вас какие ШК? типовые code128?
сейчас на очередном проекте по автоматическому распознаванию столкнулся с тем, что распознается менее 1% штрихкодов.
И тут я вспомнил, что во всех предыдущих проектах применял EAN13 (кроме одного), он большой и распознавался хорошо, процент всегда был больше 90-95.
Только один раз клиент убедил использовать типовые ШК code128, но у него сейчас процент распознавания ШК больше 96%
я сравнил сканы на новом проекте и на старом - разница колоссальная, на новом проекте сканы не такие четкие и ШК "размыт" получается, из-за этого не распознает нормально ни zbar-ом, ни чем другим
Оказывается у старого клиента используются промышленный потоковый сканер KYOCERA, стоимостью 200-300 тыс. рублей
поэтому там файлы пдф получаются очень качественными и ШК распознается без проблем.
На обычных офисных сканерах у меня не получилось добиться такого же качества, да и улучшить не получилось ни настройками сканера, ни обработкой сканов через image magic
Может быть у Вас та же проблема
5. aezdakov 02.03.20 10:52 Сейчас в теме
(4)128, стоит обычный офисный сканер с автоподатчиком. Конкретно что за модель и марка не скажу, сам же тестировал на обычной МФУ KYOCERA, в районе 40 тыс. рублей. вот на нём почти все пдф в топку уходили, на других не тестировал. Может в этом и причина.
У меня пару раз 128мой распознавался как EAN-8, один раз как EAN-13. Может больше случаев было, это что помню. Все эти потоковые сканеры иногда сканируют лист под углом, небольшим, но достаточным, чтобы zbar его уже не смог распознать. Мы для себя приобрели (дешевле было приобрести, нежели писать самостоятельно, хотя у меня руки чешутся до сих пор) вот эту компоненту: https://infostart.ru/public/542683/ Она, как я понял, построена на том же базе, но умеет листы поворачивать, правда делает это под углом в 15 градусов и никак не настраивается. Компонента злая до оптимизации, первый раз она показала ужасный результат, примерно 30% брака, скорость работы удручала, а сервер приложений 1С за 500 страниц пожертвовал 10гигами оперативки и освобождать их не стал (оказалось, положить инициализацию компоненты в функцию, исполняемую внутри цикла, было плохой идеей). Сейчас же она работает быстрее zbar, его же приходится из-под винды запускать (я использовал функции БСП), да и она компенсирует смещения угла, эта же особенность иногда помогает, когда пользователи задыроколили наполовину высоты штрихкод, zbar с такими штрихкодами не справлялся вообще, а эта компонента справляется, но всё же не всегда.
По поводу точности увы не скажу, у меня есть макеты, которые идут без штрихкода на каждой странице.
Оставьте свое сообщение
Вопросы с вознаграждением