Ещё было бы хорошо добавить включаемую сетку или линейку для выравнивания страниц.

xyz писал(а) 15.09.2017 :: 11:32:53:

хех. Вспомнилось "гладко было на бумаге. Да забыли про овраги."
Вы сохраняйте возможность восстановить бумажный экземпляр. У читателя экрана, особенно в темах про действительные события - ремесленные приёмы, батальные сцены, описания физических опытов, проектирование предметов - не "включается" тело, потому что экран не имеет объёма. Не работает связь "глаз-рука".
Конечно плохо, что _одна_ страница не отцентрована относительно _последующей_. Кто спорит, и мне это мешало. А если важен вид разворота, задумано так было? Даже не вспоминая разворотный форзац. Двухэкранные книжки так и не существуют.
И "академические" широкие поля не просто так придуманы (пример:серия Классики науки, в первых изданиях особенно). Буквально на неделе читал умную книжку про душу (спасибо тренеру, выпустил наконец свою рукопись в свет), и с радостью бы карандашиком себе - раз личный экземпляр - помечал вопросы к абзацу. Так ведь негде! Не вспомнил редактор-оформитель о таких читателях "с карандашом".
Считаю, что думать надо в сторону либо двух вариантов изготовления, под печать и под экран, либо кодирования прямо в книге размеров и центровки оригинальных полей данной страницы.  Вариантов оформления, существенно влияющих на восприятие смысла, не так уж мало, как кажется. Через мои руки много книг прошло, насмотрелся.
Большинство обоснований для правки полей у вас указывает на неудачные программы-просмотрщики. То он масштабирует некрасиво, то текст гуляет влево-вправо. Это как лечить насморк гильотиной. Напишите или закажите удобную программу. Я почти уверен, что давным-давно у типографов есть стандарт передачи в файле не только пиксельных размеров листа книги, но и прочих геометрических параметров про страницу.

К слову о "чрезмерно" больших полях: в бумажной книге они ещё часто захватываются пальцами, чтоб книга не закрывалась. А электронное устройство держат снизу. Поэтому полностью повторённые академические поля в электронке выглядят несуразно огромными.

Ну STU (в отличие от ST E+F) я пока кручу только на Win XP. Так что все версии тут 32 битные.

STE под  64 я и не видел, таковой тут нету (она точно 32 бит):
https://sourceforge.net/projects/scantailor/files/scantailor-devel/enhanced/

Но как я писал, и ST и STF требуют назначить моим сканам 400 дпи вместо 300.

Засунул в ST и  А3  600 дпи и  А3  300 дпи - он не орёт

Поведение ST 9.11
моим 5000*7000   - 300 дпи   - хочет назначить 400
10200*7020  - 600 дпи - ОК
5900*3500 – 300 дпи - ОК

Есть предложение делать окно Настроек вот таким (картинка кликабельна):



Это дерево с фильтром по содержимому сверху. Узлами в нем являются компоненты программы и этапы обработки. Там же они могут включатся/выключатся. А справа будет полно места: там может быть пара абзацов пояснений (что это, зачем надо, как работает), дефолтные настройки (например для Margins) и дополнительные настройки (например, для Auto-Save project).
Такая компоновка настроек используется, например, в µTorrent


P.S. Сделал переключалку языка приложения из настроек, и выключалку плавающих панелей.

xyz, не пропустили мой пост по поводу настроек?
http://publ.lib.ru/cgi/forum/YaBB.pl?num=1505152856/66#66

1) Poka ne testiroval, net vremeni, rabota...
2) Lusche ne ubiratj "Rectangle"
3) https://xkcd.ru/927/

slava_kry писал(а) 16.09.2017 :: 08:16:50:



Обнаружил, что STU унаследовал от STF  ручное выставление прямоугольных зон.

При зажатом Ctrl:
-выставляется отсутствуюший прямоугольник;
-перетаскивается существующая вершина с одновременной ортогонализацией сторон.


Чтобы реализовать то, что вам хочется, наверное, надо просто дать возможность за вершину перетаскивать весь прямоугольник.
Например, если при этом Ctrl+Shift зажать.


Update
Нашел на форуме monday2000 ветку про STF

http://www.djvu-scan.ru/forum/index.php?topic=1137.0

xyz По поводу проблемы с DPI и памятью. Есть идея, упростить себя задачу и не ломать голову, в какой момент появляется проблема. Если в ST E проблемы не было и в ST F не было, а в ST E+F уже появилась, то возникла она где-то по пути их слияния. Я предлагаю сделать n-ное кол-во exe'шников под Win, соответствующих различным этапам этого слияния. Обозвать их scantailor1.exe - scantailorN.exe. Забросить их кучкой в папку с программой (библиотеки они все старые подцепят). И, учитывая их хронологический порядок, выявить где проходит граница между "еще работало"/"уже не работает" методом деления отрезка пополам. От вас потребуется все это протестировать. Я не думаю, что N будет больше 7-8. Попробуете?

Для STU воспроизвелся известный ранее баг STF:


Цитата:

Я поигрался с вашим тестовым файлом в STU. Это tiff 100mb, ~5000x7000 px. И он не проходит проверку ST по высоте (594mm) при 300dpi. У меня в STU в диалоге fix dpi его высота выводится красным - но STU не ругается - видимо, отключен блокиратор.

При этом при 600 dpi - его размеры в мм ~200 на 300. Т.е. он проходит все проверки. Менять ему dpi было только во вред.
Глянул на память - обработка одной страницы в 300 dpi пиково сожрала 1.5 Гб памяти (но в очень мелаенький промежуток времени: возможно, пик на нормализации). В 600dpi (поменял средствами ST) - только 400 Мб, и заняла гораздо меньше времени. Что согласуется с оценкой автора - 600/300 в квадрате = в 4 раза.

В общем, не стоит им dpi менять. Сходу могу предложить вынести отключаемость блокировки и порог в 500мм в настройки. А еще обвешаться очень подробными warning'ами с описанием всей полноты проблемы. А не просто циферку красным подсвечивать.

При 600 dpi ST должен тянуть размер страницы в 11800x11800 в пикселях. Или 465x465 мм (если ничего не путаю). A3 - 297 × 420 мм.
При 300 dpi - в два раза меньше: 5900x5900 пикселей и ~230x230мм. A4 в мм 210×297! Вот тут может быть слишком жесткое ограничение для одной из сторон и провокация для изменения dpi.

truf

1.
Напомню, что, к сожалению, проблема не просто в блокировке. 
Повторю, о чем писал ранее. При коррекции средствами ST  дпи  до 400 , оригинальный ST обработку делает штатно с выходом 600 дпи, то есть увеличивает мой файл в 1,5 раза.   В то время как STU - при такой же коррекции - выходные файлы в папку вроде как складывает, но ленту не обновляет и экспорт начать не может.

Выходные файлы имеют  размер   (5213*6809 pix). Оригинальный же ST кладёт файлы размером (5212*6808 pix). Любопытная разница на 1 пиксель.


2.
Писал вам в личку на этом форуме, но письмо осталось непрочитанным. Скорее всего, вы это и на руборде видели, но тем не менее.

а) Разработчик плюса на руборде писал, что он вносил изменения в ректангл, взятый из STE. Т.е. какое-то отличие там должно быть, а вот в STF, видимо, он уже из плюса:

Цитата:


б) Разработчик плюса делал объединения версий с мастер-веткой вплоть до  0.9.11  (кстати, там любопытное ридми с описанием логики алгоритма автосохранения):

https://sourceforge.net/projects/scantailor/files/scantailor-devel/plus/0.9.11-2...


3.
Цитата:

Дпи затем и менялось, чтобы на выходе получить файл гигантских размеров и скопипастить из него в ворд картинки, а то они в этой инструкции такие крошечные, что ни черта не видно.


4.
Стал прогонять по новой  - забыл переключить dpi.

STU прекрасно складывает в папку 600 дпи  LZW-тиффы     6789*9001. Но ленту не обновляет, экспорт не начинает.


Переключаю список tiff compression на тиффы без сжатия., делаю вывод по новой   - изменений не вижу.
Он их не заменяет.

(Кстати, может, это и правильно !). Удаляю файлы физически - кладет 179 Mb тиффы. 

Protestiroval, sdelal odnu knizhku, napisal ochenj mnogo v "Issues" https://github.com/trufanov-nok/scantailor/issues
Ne pugajtesj, pozhalujsta.
Poka samoe poleznoe -- kvadratnye vydelenija, eto prosto spasenie.

xyz писал(а) 19.09.2017 :: 05:03:15:

Я не читал руборд. Речь идет о коммите "Carrying the code of the processing the highlighting picture in Mixed…" в ветке Plus. Я не вижу там никаких изменений кода определения прямоугольников (BinaryImage::rectangularizeAreas() ). Зато одним махом в этом коммите автор отключил доставшийся ему от enhanced версии "stretch holes". Это то, что мы тоже отключили:
truf писал(а) 15.09.2017 :: 03:02:19:

Скорее всего, автор получал "паразитную тень" из enhanced, которая увеличила размер описываемых вокруг нее прямоугольников. И когда отключил ее получилось что он
Цитата:

Сам код определения прямоугольников не менялся.

xyz писал(а) 19.09.2017 :: 05:03:15:


Я попробовал оставить оригинальный 600dpi скану и уже на этапе Output поставить ему вывод в 1200dpi. К сожалению, это также привело к точно такому же 4х кратному пиковому потреблению памяти в 1.6Gb. Но хотя бы проверки на dpi были пройдены "легально".

xyz Внушает.. Спасибо!