TIFF и Mixed Raster Content mode #32
Comments
|
Емнип STU, STA и наверное что-то им предшествовавшее, реализуют экспорт слоев страницы на этапе output. В отдельные файлы. Экспортируются в т.ч. background и foreground. Маска на этом этапе в этом режиме хранится неявно - у оригинального изображения пиксели 0x000000 И 0xFFFFFF (или только 0x000000 - не помню) резервируются под слой foreground (текст), везде где не picture zone. Т.о. экспорт представляет собой переписывания одного файла в два на основании pixel_color == 0x000000. Эти слои в дальнейшем собираются в djvu по методу раздельных сканов при помощи DjVu Imager. Он понимает только слои в виде отдельных файлов. В общем, ничего кроме лишнего геморроя... |
|
Я использую в основном STA для перевода документов по работе в PDF. В документах дела обстоят так:
Мне нужно, чтобы страница содержала несколько изображений разного формата и разрешения одновременно, обрабатывала каждый из них по-своему, и экспорт нужен в разные форматы сразу. Эта идея вообще никак не совместима с той реализацией, что есть сейчас в любой из версий ST. Тут не то что tiff поправить, тут саму систему хранения и обработки изображений переделывать надо - идентификаторы, кеши, устройство фильтров и видов. Из-за этого я и завел STD, но, похоже, не вывезу; по крайней мере, пока знания по плюсам не подтяну. |
|
@noobie-iv , тогда смотри в сторону pnmtodjvurle. PS: По поводу разделённых сканов. Я пользую CropperTktoPDF. Но хотелось бы иметь поделку на Qt и без reportlab для генерации PDF, ибо он использует кодировку ASCII85. По поводу JPEG, использую комбинацию Info из Crop в PhotoQuick с шагом 16 + jpegtran + jpeg2pdf с полями ( Для комбинации отдельх "слоёв" (PDF) в страницу имеется qpdf. |
А вы можете это сделать в каком-нибудь Photoshop, GIMP или SkanKromsator? Если да - то... Есть пословица паскудная: "лучшее - враг хорошего". ST меня когда-то купил своей простотой. Я лет 8 назад его запустил, два раза куда-то тыкнул - и получил отличный (как мне тогда казалось) результат. Мне какие-то фичи были нужны (преимущественно хоткеи) - я их докрутил. Остальные спрятал в настройки, чтобы сохранить простой UX. До сих пор использую. Потом выяснилось существование метода раздельных сканов и это единственное, к.м.к., недочет ST семейства - что они не форсят создание djvu по этому методу, имея при том полуавтоматический сегментатор слоев внутри. Какие-то попытки изменить первоначальный концепт - например, этапы обработки местами менять - приводят к серьёзным пропихиванием невпихуемого в разные места кода, куда оно идти не должно. Это - возможно, смогут это "не только лишь все" и мало кому это уже надо, но и удивляться что оно идет против шерсти концепта - бессмысленно. |
Видимо оно там тоже было когда-то. Потому что создаётся background слой с маской 0x000000 и 0xFFFFFF прямо на нём. Но как мне в StEx сделать отдельно background+отдельно foreground, а желательно ещё и отдельно маску, я не нашёл.
Ну вот оно уже есть в StEx. Осталось сохранить в тот же tiff (благо в теории формат позволяет даже разбить фон на несколько изображений) Я не думаю, что это прамо архисложно, написать утилиту, которая будет конвертировать tiff+MRC в pdf или djvu. Всё равно, данной функциональности сейчас нет вообще |
|
На майских потыкаю палкой и StEx, и tiff. Если удастся сделать без ущерба к существующему функционалу и реализации, попробую добавить |
|
У нас в строительстве официяльные документы принимают в PDF, потому я DJVU не использую, не у всех на него смотрелки есть. А для быстрой сборки в PDF я свалял простейшую консольку, которая папку OUT после STA разом пакует: https://forum.dwg.ru/showthread.php?t=167830. С этим уже жить можно, я так под тыщщу гостов собрал. Текст у меня обрабатывает STA, а картинки в режиме разделения сканов я как раз в GIMP пережимаю, перед упаковкой в PDF. Деварп мне, собственно, не нужен - сканы обычно не кривые. И всего, чего не хватает - различать не два типа изображений на странице, как сейчас во всех ST, а три за раз, чтобы всю обработку в ST делать, а не ёрзать туда-сюда постоянно. ST, конечно, простые, но у них ограничение - книги либо только с фото, либо только с малоцветками. А наши нормотворцы в новых документах взяли моду вместо ЧБ чертежей, как в старые добрые времена, вставлять что попало, даже фотки низкого разрешения из интернета, даже диаграммы желтым по белому, и прочую ересь. Вот с ними ST и не справляется в автомате. Нужен ST, у которого автомат малость посложнее. И потому же я в отдельную программу ушел, а не в реквесты на исходные STA/STU. |
|
@plzombie , @noobie-iv , етить вашу мать, дайте ссылку на этот ваш StEx! PS: @noobie-iv , пользовать MRC в PDF категорически не рекомендую. В PDF есть родной, простой и понятный способ илюстрирования - кадрирование изображений и наложение их сверху/снизу. А MRC в PDF - это сплошные и дикие тормоза во всех просмотрщиках + проблемы (!!!) с печатью. |
|
@zvezdochiot Я этот форк имею в виду |
|
Кажется я начал понимать за что речь. Но ежели это действительно так, то я "улыбаюсь" с этой истории, ибо всё опять возвращается к макетированию страниц. И без макетирования вы желаемого результата не получите никак. Такие вот дела. ;) |
|
@plzombie say:
Тогда посмотри ещё:
|
|
@zvezdochiot да там ещё и вылетает редко при переходе от зон картинок к зонам заливки. Надо это поотлаживать прежде чем что-либо делать. Но займусь |
|
@zvezdochiot К слову, можешь мне объяснить, что происходит, когда в смешанном режиме выбираешь цвет заливки? Такое ощущение, что за гранью "зоны картинок" он приводится к чб |
|
@plzombie , да, я "химичил" с заливкой из-за Вспомнил ещё один неприятный момент: в |
|
@zvezdochiot say:
А как без него, если STA экспортирует две страницы одного размера - ЧБ+ЦВЕТ. Вот и приходится просто считать ЧБ маской, и сводить с картикной как есть.
Чтобы не было MRC, в этом макете надо сохранять не маску, а набор честных габаритных прямоугольников в пределах страницы. Такой макет совсем не похож на то, что есть сейчас - ссылка на исходное изображение, контур подрезки и поворот. И система хранения другая, и обработка страниц видами другая. А если еще позволить разные разрешения в пределах страницы - то и система хранения изображений другая. Собственно, это я и имел ввиду, когда затевал STD. Ну, пока об нехватку знаний не споткнулся. Если починю там битые превьюшки, есть шанс, что и остальное доделаю (тогда уж и в STEX починить их смогу, и в STA). Но это еще очень нескоро будет. |
|
@noobie-iv , неверно. Совсем. Как раз с изображение делать что то "несусветное" вовсе нет надобности. Надобно либо сохранять отдельно xml макета, для использования его в дальнейшем, либо парсить сам проект STEX. В любом случае надобна дополнительная тулза для генерации PDF по макету из одного (ОДНОГО!) обычного tiff-а. Что то типа DjVu-Imager на новый лад. Такие вот дела. ;) |
Я не сохраняю проекты. Я скачиваю очередной гост, пропускаю в автомате через STA, и пакую как есть. А после STEX разные части картинки еще и перепаковывать надо, каждую в свой формат, это долго и лень.
У меня есть. Мне принципиально надо, чтобы любой фильтр мог прогнать изображение через любую внешнюю команду. Может, деварп сторонний. Может, GMIC. Может, даже в GIMP для ручной правки. А значит, у фильтра своя временная папка заводится под редактированные изображения, чтобы он их дальше передавал, а не оригинал с подправленной рамкой, как сейчас. Но это все в STD должно быть. STEX я не трогаю, пусть остается минималистичным. Да я и STD не трогаю, тупой я для этого, просветления жду 😄 |
|
@noobie-iv , опять таки имеет место быть согласие. Ежели сделать отдельную прогу макетирования страницы, то это решило бы очень много вопросов. А ваши вопросы порешало бы полностью. Необходимость макетирования в STEX для сложных страниц не отпала бы, но конструкция STEX->{GIMP, Krita, ...}->QPageMaket->PDF очень даже логична. |
|
В tiff можно сохранять в передний/задний план отдельные области, а не всё изображение уменьшенное |
|
То есть дело за конвертером MRC TIFF => PDF. Ну и в STEX это добавить (собственно, для чего я этот топик создавал) |
|
@plzombie say:
Нифига. MRC в PDF - это тормозное говно, которое хрен нормально распечатаешь и вообще нафиг ненужно. Другое дело постоение страницы из отдельных блоков по макету. |
Чтобы такое было возможно и полезно, надо, чтобы в TIFF разные слои хранились с разным сжатием, для текста и картинок отдельно. Он так умеет? А лично мне надо, чтобы еще и на одной странице могли быть разные области с разным сжатием: монохром/fax4, фото/jpeg, малоцвет/lossless-palette, полноцвет/lossless.
А их положение на странице он помнит? Например, как в редакторах, работающих со слоями, когда наложенную сверху заплатку можно подвигать туда-сюда? Если да, то из него можно будет честный PDF делать, без MRC. И еще хорошо бы, чтобы это чудо можно было просматривать, а не просто знать, что там внутри особая магия есть. Какой вьюер/редактор так может? |
|
@noobie-iv , по вашим запросам, STEX должен генерить на выходе постраничные PDF, а значит как минимум уметь FAX CCITT GROUP4, либо JBIG2, FLATE, настраиваемый JPEG, либо JPEG2000. Но это не просто и сильно осложнит дальнейшую обработку. Такие вот дела. ;) |
|
По моим запросам надо еще в обработку добавить редактирование через внешние программы. Тогда экспортированный PDF вообще не надо дальнейше обрабатывать. Например, в современных гостах чертежи - это часто скриншоты, пережатые JPEGом до перхоти. Если бы их примитивной кривой пройти, чтобы перхоть выбелить в ноль, а черный чуть затемнить, меня бы результат устроил. А чтобы кривые не писать с нуля, я и хочу их через вызов внешних программ делать. А если делать экспорт под дальнейшую обработку, все равно же придется вместе с картинками еще и контуры/координаты записывать (даже если считать, что они уже записаны в проекте). И такое просто посмотреть уже никто не может, надо конвертер/смотрелку дописывать. А зачем смотрелка, которая смотрит то, что в ST не доделано, и которая, кроме как за ST посмотреть, больше ничего не может? Такая смотрелка должна быть частью ST - это фильтр "Export" должен быть. |
|
@noobie-iv say:
Так это ж S-кривая (сдвоенная дуга) в фильтрах. И стоит уже по дефолту на 0.5. Помимо этого есть C-кривая (чистая дуга). |
|
Мне начало и конец сдвигать надо, а не на месте оставлять. А сама кривая должна оставаться прямой, только повернутой вокруг центра. Такое еще яркость-контраст делают, но менее удобно. А S и C для другого, они тени и света сохранить пытаются, а их срезать надо, там только шум лишний. И кроме кривых, еще иногда палитру выборочную надо сделать. Или еще что-то оригинальное. Проще всего это во внешних программах делать. В идеале - через интерфейс ST. Но он от этого из "простой программы" превращается в комбайн. И с этим много кто несогласен будет. А что еще важнее, в STEX нет разделения вывода, и даже если какой фильтр сработает, результат потом опять обрабатывать надо - картинки выделять, пережимать. Потому я STEX не использую вообще, в моих документах STA+самодельный PDF быстрее выходит, даже с промежуточной ручной обработкой картинок. |
|
@noobie-iv say:
Ну так это только ваша задумка. От того всё сложно и получается, потому как вы эту сложность заложить и пытаетесь. PS: Я больше скажу: в моей задумке перенести вкладки зон с Output на Blocks, тем самым разгузив Output и упростив работу с Zones. PS2: Я конечно могу занести в STEX: PS3: Фильтр, о котором вы говорили - это собственно LevelMean в списке выше. ;) |
|
Емнип, нельзя позволять exception выбрасываться за пределы конструктора, например вот поэтому: https://stackoverflow.com/a/71887635/841424 |
|
@trufanov-nok это всё прекрасно, но прямо любой пример по RAII берёшь, и там конструктор кидает exception. Моя бы воля, я бы в конструкторе вообще ничего не делал кроме инициализации атрибутов простых типов, а всё остальное в методы Create()/Destroy() (ну и в деструкторе |
В любой функции можно сгородить вложенный блок-трюкач. Есть даже специальный синтаксис, когда все тело функции - один большой блок: Так же можно завернуть в блок все тело конструктора или деструктора, тогда из них тоже ничего не вылетит:
Если исключением кидается конструктор, все OK. Просто на уровне какой-то функции (не обязетельно main) надо сгородить трюкача, который разбирается с последствиями. А если кидается деструктор - то один раз так сделать можно, все даже будет работать. Но вот если исключение уже выброшено, и еще не обработано до конца, прямо сейчас идет чистка стека, а чей-то деструктор кинет еще одно исключение - тогда программа вылетает без возможности обработки. Почему так - не пишут, видимо, есть сложности в реализации на уровне компилятора, про которые слишком долго рассказывать. Может, параллельная обработка ломает гарантию чистки в порядке, обратном созданию. Может, добавляет код, который должен работать и в случае, если исключение не выброшено. А может, еще какие фокусы есть. Для себя понимаю так: кидать исключение из деструктора можно, если освобождение ресурса настолько важно, что нельзя его оставить занятым. Если какой-нибудь важный файл не закрылся - значит, все настолько поломалось, что попытка продолжать работу может его доломать окончательно, и лучше вылететь, чем добить его до состояния, когда никто его уже не починит. Но это только в режиме параноика для особо важных программ и ресурсов. А в обычных лучше слушать старших, и в деструкторе не хулиганить.
Еще пишут, что плюсовый код на исключениях работает быстрее, чем сишный на ручной обработке кодов возврата, потому что в основной логике программы нет никаких лишних ветвлений. Вроде как для того исключения и придумали - ускорить код, плюс никогда не забывать про обработку. А вот если исключение вылетело - тут тормоза будут сильнее, чем при ручной обработке, поэтому нельзя включать трюкачей в основную логику взамен всяких if-then, и тем более в нагруженные циклы. Вариант с ручной обработкой через Create/Destroy получается средним - вроде есть автоматическая чистка, но возвращается лишняя писанина с проверкой, которую можно забыть. И если забыть, то появляется объект, который вроде как создан, но внутри-то у него мусор. Из-за этого придется лепить чтото вроде if( ! IsInit() ) Create(); на каждом вызове каждого метода, на случай, что Create забыли сделать при создании. Подозреваю, что для решения этой проблемы придумали паттерн Builder, который весь этот геморрой прячет внутри метода Build - и ловит исключения, и выпускает наружу только правильно созданный объект, и потому позволяет внутри методов лишних проверок не ставить.
Есть такая проблема, да. Я с плюсами на любительском уровне лет 15 знаком, а программистом не стал. Полно книг для чайников, но нет для кофейников. Я и в этот проект полез из любопытства - хоть раз посмотреть, как реальные программы устроены, а не примеры "сложите 2 и 2. подумайте, можно ли их еще и умножать". |
|
@plzombie say:
Сделайте уже нормальный селектор доп.фильтров (к основным относятся только кривые и выравнивание). А то я сам от безысходности его слеплю и это будет откровенно кривая, уродливая и глючная фигня! |
|
@zvezdochiot say:
Ну как то так: 51b8f42 |
|
@noobie-iv say:
Доп. матариал (значительно более простой для разбора): Yet Another Scan Wizard. |
|
@zvezdochiot Win32 - программная платформа, x86-64 - аппаратная. |
|
@plzombie , ну так "этого" я и не распарсиваю. Win32 - это 32-битная винда, а x86-64 - это 64-битная. PS: применяют обозначения либо "win32" и "win64", либо "win-x86" и "win-x86-64", но никак не "win32-x86-64". |
Есть старое апи (называемое Win16), есть Win32, есть UWP Ну и тогда называться должно x86,x64,ARM64 (в терминологии вижуалстудии. или в терминологии линукс-дистрибутивов - i686,AMD64,AARCH64) А обозначения x86-32/x86-64/ARM64 я использую так как так проще было называть установщик, не надо название хардкодить под каждую комбинацию архитектура+разрядность |
|
@plzombie , ❓ так почему не "win-x86-64"? К чему тут "win32"? "32" что значит? |
|
Потому что API называется Win32 |
|
@plzombie , ага, вот теперь наконец распарсил. Ну и "мудрень". X0 |
Не поможет. Я не собираюсь сделать работающую "такую же, но проще" версию. Я хочу понять, как работает ST. Мне хватит пары примитивных фильтров, но чтобы в принципе они были устроены как в оригинале. По факту я потихоньку копипащу код из ST, пока не получится минимально работающее главное окно с центральной картинкой и превьюшками. Потом можно будет попробовать встроить туда макетирование. А потом по аналогии сделать то же в ST. На сегодня у меня есть пустое главное окно с панельками, и полтора десятка классов типа "Получатель", "Возвращатель полученного", "Передаватель возвращенного", "Возвращатель переданного возвращенного обратно получателю через представителя", "Подставной представитель", "Поручитель подставного представителя", "Приниматель поручителя", и т.д. по списку. Программа по-прежнему не делает ничего полезного, а классы пока только ссылаются друг на друга, ни в одном из методов не заканчиваясь хоть каким-то реальным действием. На подходе, видимо, еще десяток-другой аналогичных бездельников. Когда я для теста извлекал деварп, я так больше мегабайта кода вынужден был скопипастить, чтобы он только компилировался; я даже не стал проверять, что он вообще работает. Если тут придется мегабайт с нуля набрать - это мне лет на десять работы выйдет. Пока я не вижу ни одного реального действия в программе, и не могу понять, что тогда все эти "Абстрактно-теоретические заменители реальности" делают. Пока что происходящее напоминает мне известный FizzBuzzEnterpriseEdition |
|
@noobie-iv say:
Ну это ты зря. Многие поклоники SK спят и видят, когда же кто-нибудь "придумает" STM (Scan Tailor Mini), занимающийся только разрезкой, преобразованиями и выравниванием. Это и к твоим целям более ближе: нарезал, выпрямил и выровнял, а дальше в любом редакторе делай что хочешь. Сам же щаз думаю, как бы на этапе 3 "Геометрические преобразования" прикрутить индивидуальный масштабный фактор (по умолчанию 1.0000). Своего рода выравнивание DPI без самого DPI. И нужно именно на 3-ем этапе (в крайнем случае на 4ом, но на 4ом логика этого коэфициента теряется). Такие вот дела. |
Для таких желающих достаточно в ST перевести картинки в цветной режим.
Любой редактор тем и неудобен, что не дает списка листов и повторной пакетной обработки по ним. Фишка ST же в том и есть, что он все в одном за три щелчка может. Вот только набор фукнций лично мне маловат, отсюда и страдания.
Минимум два надо - по X и Y. Здешний деварп слишком любит пропрорции корежить. |
|
Кто-нибудь может мне в фотошопе сохранить TIFF со слоями? Хочу сравнить с тем, что делает GIMP (тупо несколько страниц с X/YPosition) |
|
@plzombie say:
Точно не я, но тут есть участник на макосе: @gasparschott . У него поспрашивай (на буржуйском). |
|
Вот, произвольный многослойный из PS на macOS: dropbox.com Правка от @zvezdochiot : прикрепил к сообщению: PMT.zip (мало ли что с этим дропбокс) |
|
За месяц копипасты с фигурной обрезкой получился такой микротейлор:
Он только показывает фиксированную пару картинок и поворачивает их влево/вправо. До рабочих превьюшек еще далеко. Там всего десяток-другой реально содержательных строк (установка виджета, рисование картинки и т.п.). А общий объем кода уже вышел за 2000 строк. Теперь я понимаю, почему в отладчике не мог понять ни одной строки: гуевый код реально на 99% состоит из обвязки. |
|
@noobie-iv , круть. 👍 Советую сохранить эту "поделку", на случай ежели решишь создать отдельную тулзу для создания макетов страниц (QPageMaket) и генерации PDF-страниц (а возможно и целых книг) на базе макетов. Я всё также, как и раньше, вижу решение "вопросов" к ST именно в наличии отдельной тулзы для макетирования страниц и использования цепочки: PS: И всё же, хотелось бы вынести все (все!) зоны на отдельный этап, перед "Output". Это позволило бы напороч избавиться от мозолящего глаза "Mode" (какой такой режим, ежели всё обрабатывается согласно зон?), а заодно позволило бы добавить так назывемые palette-зоны, с заливкой маски выбранным цветом, как в fill-зонах, но "пипетка" будет работать на оригинальном цветном изображении + 2 зарезервированных (чёрный и белый). Такие вот дела. Да и фильтры можно было бы перенести туда же, чтобы видеть их действие, а не только на "цветном/сером" режиме. |
|
Впомнилось. В ST очень много всего реализовано с нуля. Если бы его делал я - то собирал бы из готовых частей, тащил бы модули из других опенсорс проектов. В свое время намучался с thumbnails list в ST (но больше всего хотелось бы, конечно, заменить машинерию для манипуляций с изображениями (выделение прямоугольником, эллипсом и пр.) ) и полез искать готовые официальные компоненты для Qt. И нашел для thumbnails list, как мне показалось, неплохой. Больше ничего не нашел. Если бы я сейчас переписывал эту часть GUI, то сперва попробовал бы использовать его: https://marketplace.qt.io/collections/all-products/products/longscroll-qt |
А я считаю, что это все как раз и должно быть прямо в тейлоре. Нужен список стадий, которые можно выбирать, а не фиксированный набор. И среди них - встроенные (нарезка страниц, деварп, размер страницы), и внешние (GIMP, GMIC, ImageMagic). Кому не надо - просто не добавляет лишние стадии. Так устроен стек модификаторов в 3D-программах. Если решу делать свое - вот так оно будет. Но литраж моих слюней пока не соответствует емкости желудка 😄. В идеале это должны быть внешние плагины. В линуксах есть программы с плагинами? В винде нет стандартных каталогов, и обычно программа просто ставится в свою папку. А внутри папки, рядом с программой, заводится папка Plugins, куда сваливают плагины-DLL. При загрузке программа сканирует каталог, и если DLL отзывается, добавляет ее в список плагинов. Дописывать плагины, реализуя десяток стандартных функций по образцу, легче, чем пересобирать программу целиком.
Я только начинаю слегка въезжать, что тут в коде происходит. До возможности добавлять стадии мне еще далеко (подозреваю, что несколько лет, если терпения хватит).
Если бы просто с нуля. Там еще отрицательные величины есть. На сегодня мой любимый образец кода выглядит так:
#include <iostream>
class Widget
{
public:
void set(int value)
{
int old_value = m_value;
m_value = value;
if (m_value != old_value)
update();
}
private:
void update()
{
std::cout << m_value << std::endl;
}
int m_value = 0;
};
int main()
{
Widget w;
w.set(1);
}Но это же плюсы. Нельзя же в коде просто проверить значение и обновиться. Оператор if надо инкапсулировать!
#include <iostream>
class Widget
{
public:
void set(int value)
{
Watcher watcher(this);
m_value = value;
}
private:
void update()
{
std::cout << m_value << std::endl;
}
class Watcher
{
public:
Watcher(Widget* owner)
: m_owner(owner)
, m_value(m_owner->m_value)
{
}
~Watcher()
{
if(m_value != m_owner->m_value)
m_owner->update();
}
private:
Widget* m_owner;
int m_value;
};
int m_value = 0;
};
int main()
{
Widget w;
w.set(1);
}Этот маленький шедевр найден в ImageViewBase (класс TransformChangeWatcher). Как говорил джокер бетмену, "с тобой безумно весело" 😄. |
Тут плюсы не при чем. Тут решается конкретная задача. Я уже плохо помню код, но скорее всего update() порождает тяжелые вычисления, и делать их нужно не на каждый чих пользователя, а только когда действительно припрёт. Как пример - рисование зон на вкладке Layers в Mixed mode. Если перегенирировать результат каждый раз, когда пользователь чего-то там двигает - ST повесится. А вот когда он с этой вкладки ушел (миллионом способов он это может сделать), т.е. вызвался ~ImageViewBase() - тогда да. Скорее вот такого отложенного обновления хотели добиться. |
|
@trufanov-nok say:
Ещё как при чём! У меня концы с концами из-за них не сходятся: Стадия 3 "Геометрические искажения":
Вот тебе и не при чём. Угол поворота определяется везде, а прописывается только в варианте 2. Вот это номер! Отсюда отсутствие сортировки по углу и дубляж кода. Вот это "щастье"! Такие вот дела. @noobie-iv say:
Чтобы не быть голословным: Что такое макетирование на примере?: Вот оригинальный материал: page-1-2-origin.pdf [5M]. А вот обработка в STEX + GIMP и простенькое макетирование с помощью python-cropper-tk + gs и пр.: page-1-2-stex_croppertk.pdf [1M]. |
Вроде как Task, CacheDrivenTask, Filter и OptionsWidget имеют указатель на настройки - m_ptrSettings. Внутри любого из них можно вытащить нужную настройку: Если доступен указатель на фильтр - из него можно получить указатель на настройки, а дальше по той же цепочке:
Тут вроде как не плюсы виноваты. Это событийно-ориентированная программа. Не знаю как там в линуксах, а в виндах родное API для графических программ - чистый С без плюсов, со времен первой версии винды. Но в нем программа тоже нелинейная. Там тоже надо написать тучу функций обратного вызова, и сводить передачу данных между ними в уме. Реально линейность сидит где-то внутри очереди событий, которой рулит винда, которая дергает эти коллбеки. Но программист этого не видит, только callback-обрывки, и они тоже срабатывают когда захотят. Синхронизация данных между коллбэк-обрывками - головная боль программиста. Qt - плюсовая обертка, но по факту работает так же. Те же сигналы, что и события винды, те же фишки с установкой фильтров. Те же проблемы с нелинейностью. Был популярный VisualBasic - вообще не плюсы, но работал так же. В автокаде API плюсовое (на старых плюсах - до 11), но и там идеи те же: хочешь свой объект - наследуйся и переопределяй пачку стандартных обработчиков, которых будет дергать автокад. Я бы сказал, тут проблема в том, что большой проект (100 тыс строк) написан в одного, потому не откомментирован, и подключаться к нему тяжело. По WinApi есть описания функций, и примеры программ с нуля. По ObjectARX есть примеры. Про любую функцию есть подробности с примерами - зачем нужна, что за параметры, когда вызывается. А тут надо все три мегабайта кода лопатить, чтобы понять кто где. Я из-за этого и начал свою микропародию писать. Добавляю десяток строк, и смотрю что они делают. В оригинальных мегабайтах я просто завяз, ни одной строки не понимаю: 99% - либо вызовы Qt, которых я не знаю, либо вызовы самодельных классов, про которые даже нагуглить нечего. На сегодня скопипащено 2 тыс строк из 100 - это 2% за месяц. Что эти строки делают - теперь понимаю. На полное понимание таким методом, очевидно, надо 5 лет. Разумеется, я не буду смотреть алгоритмы обработки, только базовую логику. Если примитивно-базовое изображение в единственном рабочем фильтре заняло 2тыс строк, есть шанс, что код превьюшек займет столько же, а после этого (через месяц-другой) я смогу вернуться к STD и уже чинить его до первого релиза.
Я бы тоже хотел макетирование в ST. Мне еще и разных размеров страниц не хватает: сканы строительных чертежей разноформатные. Сейчас в главном окне хранится список ImageId c путями к изображениям, и по щелчкам запускается обработка выбранного Id по цепочке фильтров. Проблема в том, что на этот ImageId завязан весь код всех фильтров, всех виджетов, кеша превью и хз чего еще, Переделка основной логики работы требует перелопатить все три мегабайта кода. Мне такого на несколько лет работы. Самодельный внешний макетировщик, к которому можно потихоньку фильтры прикручивать, может, и проще, но до конца его довести - тоже много лет. |
|
@noobie-iv say:
Ненадо никакого "до конца"! Ну о чём мы говорим? О том, что сейчас я делаю макетирование с помощью откровенного питоновского говна через reportlab, которым даже закодировать "по-людски" никак нельзя (он везде пихает ASCII85). Нафиг мне этот рак, дайте хоть какую-нибудь рыбу! |
|
Нужен макетировщик, который смотрит проект ST с размеченными картинками, и позволяет экспортить в PDF/DJVU? |
|
@noobie-iv say:
Нет. На данный момент в проектах ST необходимого нет. Макет - это фактически плитка из прямоугольных областей, каждая из которых может быть упакованна разным способом (JPEG, JPX, DEFLATE, CCITT FAX GROUP 4, JBIG2) и со своим масштабным фактором. Сейчас же я делаю подобное с помощью указанной питоновской поделки + GhostScript + препарирую (режу на объекты), вычлеяя JPEG и JPX, перекодирую и сшиваю обратно PDF. PS: Один рисунок, в зависимости от формы и величины, может содержаться в нескольких прямоугольниках плитки. |
|
@noobie-iv , @plzombie , @trufanov-nok . Модифицирую 4-ый этап "Полезная область" под регулятор: Вконец запутался: всё есть, но ни шиша не работает. Ненавижу плюсы. Может кто подскажет, где собака порылась? Суть же проста: мне нужно довести коэффициент из ГУЯ в и поставить его вместо 0.0. |
В RFC 2301 написано, что TIFF может содержать три слоя
Насколько я понимаю, Scantailor сейчас не поддерживает такой режим. Изображение созраняется как фон (без маски). Вроде как Scantailor Featured мог сохранять две копии изображения - bg и отдельно mask.
Собственно, предложение. Для смешанного режима реализовать сохранение в mixed raster context. А потом уже разбираться, как сконвертировать это в djvu.
@zvezdochiot @noobie-iv @trufanov-nok (вроде никого не забыл) - нет возражений?
The text was updated successfully, but these errors were encountered: