Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor (часть 2)

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146

Открыть новую тему     Написать ответ в эту тему

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Scan Tailor


Задача программы - пост-обработка сырых сканов книг для последующей сборки в PDF/DJVU,CBR/CBZ и т.д.
Программа обеспечивает большое удобство для использования, большую интерактивность и не меньшую автоматизацию процесса (по сравнению со СканКромсатором).
Кросс-платформенный (Windows,Mac OS, Linux) проект с открытыми исходниками.


Англоязычный топик по ScanTailor
Ветки:
Scan Tailor Plus (Vadim "DikBSD" Kuznetsov) >>>  последняя версия   (Отличия от авторской версии)
Scan Tailor Еnhanced (Petr "pejuko" Kovar) >>>  последняя версия   (Отличия от авторской версии)
Scan Tailor Featured (monday2000) >>>  последняя версия   (Отличия от авторской версии)
Scan Tailor Advanced (4lex4) >>>  последняя версия (Отличия от авторской версии); ветка develop
 
Документация:
Документация (Wiki) | Зоны картинок в ScanTailor | ScanTailor. Быстрое начало | Видеоуроки и скринкасты новых функций СТ от Tulona
Статья: Scan Tailor. Программа для обработки отсканированных книг
Видеоурок: Создание DjVu с помощью Scan Tailor (зеркало)
Использование Scan Tailor совместно с Djvu Imager (сборка djvu методом разделенных сканов)
Как собрать Scan Tailor из исходных кодов под Windows
Почему нельзя сделать сплошную нумерацию вывода


Автор проекта - Tulon. Почему его здесь не видно? .
DikBSD автор ветки ScanTailor Plus история повторяется.
Юзеры! Будьте скромнее!


Дистрибутивы, форки, дополнения

Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 12:17 17-02-2010 | Исправлено: ndch, 16:47 18-07-2018
TelecomUral

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
4lex4

Цитата:
нитка должна принадлежать изображению

Да, конечно. Я понимаю как это устроено, но не стал загромождать рисунок внутренней связностью окошка, бумаги и скана. И так перегружено. Это "визир", потому что BKSRU явно не понимает, что он видит, когда смотрит в окошко. Поэтому и давит свой подход. Он очевидно не нужен, в интерфейсе ST всё нормально. Даже зачем показ ж.полей отключать, и то неясно. Я на посторонние объекты просто не отвлекаюсь, если они не заслоняют поле работы. А жёсткие поля всегда снаружи, то есть помешать позиционированию контента не могут.  
Достаточно хорошо представлять в объёме, какие рамки каким объектам соответствуют, и тогда понятно, почему они введены. Ни убавить ни прибавить.

Всего записей: 415 | Зарегистр. 15-07-2010 | Отправлено: 06:39 07-03-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
4lex4

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

С этой задачей куда более интерактивнее и нагляднее справились бы 4 направляющие.
 
TelecomUral

Цитата:
Да, конечно. Я понимаю как это устроено, но не стал загромождать рисунок внутренней связностью окошка, бумаги и скана. И так перегружено. Это "визир", потому что BKSRU явно не понимает, что он видит, когда смотрит в окошко. Поэтому и давит свой подход

Напрасно вы так думаете, я достаточно хорошо понимаю то, что я вижу. Но я вижу и альтернативный подход.

Всего записей: 1540 | Зарегистр. 29-01-2009 | Отправлено: 06:49 07-03-2018 | Исправлено: BKSRU, 06:50 07-03-2018
4lex4

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Dmb_2007, на самом деле направляющие и есть линии набора, выполняя абсолютно одинаковые функции, но привязывать их к области контента нельзя, ибо мы должны сделать выравнивание, то есть одно положение для разных страниц, а значит эти разные страницы должны иметь что-то общее, и это явно не область контента. Единственно общее между всеми страницами, у которых установлено выравнивание - внешний прямоугольник мягких полей (с пунктирными линиями). Следовательно и направляющие должны принадлежать этому прямоугольнику.
 
Кстати, отсюда вытекает проблема: дело в том, что этот прямоугольник непостоянен: допустим, на 5й стадии найдена страница, у которой в контент залез мусор, мы фиксим ее, и получаем изменение размера этого внешнего прямоугольника, ибо он начинает опираться уже на другую страницу, что влечет перерасчет мягких полей для всех остальных страниц, у которых включено выравнивание. Соответственно, от этого смещаются все прямоугольники жестких полей, а с ними и контент. И если правила перерасчета мягких полей известны за счет выравнивания (по центру, по углам, по сторонам), то вот для направляющих их не существует и они не могут существовать, то есть непонятно, нужно ли смещать направляющие линии, и насколько.
 
Добавлено:

Цитата:
С этой задачей куда более интерактивнее и нагляднее справились бы 4 направляющие.  

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

----------
ScanTailor Advanced v1.0.16 | Пожертвования

Всего записей: 317 | Зарегистр. 27-01-2016 | Отправлено: 06:57 07-03-2018 | Исправлено: 4lex4, 07:12 07-03-2018
TelecomUral

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
И если правила перерасчета мягких полей известны за счет выравнивания (по центру, по углам, по сторонам), то вот для направляющих их не существует и они не могут существовать, то есть непонятно, нужно ли смещать направляющие линии, и насколько.

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

Всего записей: 415 | Зарегистр. 15-07-2010 | Отправлено: 07:31 07-03-2018
Dashout



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Хотелось бы обратить внимание разработчиков на некую техническую область, которая может служить базой для анализа, расчета и выделения полезной области независимо от полей - это техническая область нумерации страниц. Эта область всегда будет постоянной независимо от заполнения полезной области текстом или картинками. После определения области нумерации страниц и предварительного анализа текстового поля достаточно выставить две направляющих в левом верхнем углу. Все на автомате...
 
4lex4

Всего записей: 1102 | Зарегистр. 15-01-2005 | Отправлено: 08:58 07-03-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
С направляющими и возможностью точного позиционирования контента на самом деле решаются многие проблемы. И я мог бы на этом остановиться . Дальше все самой образуется. Но речь сейчас больше об интерактивности с пользователем.
 
- На 4й стадии определяя полезную область мы даем возможность программе залить все ненужное и вычислить все, что необходимо для начального позиционирования контента: у нас есть точный размер листа и выделены полезные области. Здесь все в порядке и никаких сущностей мы не трогаем.
- Переходим на 5ю стадию полей и проверяем постранично выравнивание, подравнивая если, что не так. Благо с направляющими это будет куда более удобно. У нас наконец то появится ось выравнивания и способы ориентирования на нее. Замечательно.
Теперь, что мы имеем с интерактивностью на этом этапе?
Например, возьмем стандартную страничку с небольшой проблемой. Представим, что у нас появилась возможность отключить ПОКАЗ жестких полей:

Все в порядке, за исключением того, что нам хотелось бы подравнять немного левый край. Сделать это проще простого. Добавляем слева напраляющую с отступом 10мм и притягиваем к ней контент:

Отлично. Теперь при встрече таких страниц мы можем подравнять контент.
Идем дальше натыкаемся на страничку с проблемой справа:

Ставим вторую направляющую с отступом 10мм и притягиваем край контента:

Великолепно! Еще недавно об этом можно было только мечтать. Теперь надеюсь это вскоре станет явью.
На самом деле проблемные странички я мог бы выявить несколько быстрее. Схема знакома. Слева и справа формата выставляем по направляющей с полями желаемых полей: по 10мм. Ставим порядок по убыванию ширины и просматриваем страничку за страничкой.
При более продвинутом алгоритме можно было бы выровнять странички еще быстрее. Ставим выравнивание страниц по левому краю. Выбираем сортировку по убывающему отклонению. При этом отклонение берется по левому полю. Таких отклоненией будет гораздо меньше. И процесс ручного выравнивания ускорится. Но если ничего не поняли, считайте это мыслями в слух.
Полное осознание как использовать направляющие придет при их существовании .
 
Что мне бросается в глаза так это то, что я нигде не увидел целесообразность ПОКАЗА жестких полей. А вот, что хотелось бы увидеть, так это отступы направляющих. Мало того бордовый фон (или бледно фиолетовый) мне так же не нужен. Да и рамка полезной области не особо нужна при наличии заранее выставленных направляющих. Все что мне на самом деле понадобится при ручной подгонке контента (а 5й этап это по существу ручная правка и есть):

Всего записей: 1540 | Зарегистр. 29-01-2009 | Отправлено: 11:33 07-03-2018 | Исправлено: BKSRU, 13:45 07-03-2018
TelecomUral

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKSRU
Ерунда. Если вы на 4й стадии точно вручную определили полезную область, то индивидуальное подравнивание отклонения границы области от придуманной направляющей на пятой стадии не потребуется. Само подсчитается. Равнять придётся только буквицы и тэ пэ. То есть то, что глубоко внутри полезной области.
Я ж говорю - сначала разрушаете смысл, потом его восстанавливаете.

Всего записей: 415 | Зарегистр. 15-07-2010 | Отправлено: 12:01 07-03-2018
gsn13n

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Опять возвращаемся к давно известному лайфхаку: добавление в проект пустой страницы с нулевыми полями - полезной области, заданного размера (установка холста, - для страждущих можно добавить набор заготовок наиболее употребительных форматов , как в СК) и у программы сразу появится базовая привязка. К чему изобретать велосипед?
СТ и в нынешнем состоянии прекрасно справляется с макетированием. С появлением фишки - уточнение полезной области процесс работы значительно облегчился.
Мольба о направляющих больше представляется, как нежелание (неумение?) работать с существующими полями. Для большинства книг с простым форматированием автопозиционирование по центру полезной области (текстового блока) вполне комфортно для восприятия. В СТ весь процесс визуализирован, в большинстве автоматизирован и управляем (в отличии от СК), есть dewarping(пусть чаще в ручном режиме, но работает, правда в последних версиях возникали проблемы с "компенсацией поворота")...
Но управляемая бинаризация, разделение на зоны при обработке и пр. противоречит концепту СТ (простота и дружелюбность к пользователю) и с проблемными сканами он не справляется. Поэтому у меня так и организован рабочий процесс - собираю макет книги в цвете в СТ, а основную работу (бинаризацию и постобработку) доверяю СК.

Всего записей: 852 | Зарегистр. 09-04-2007 | Отправлено: 12:09 07-03-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
TelecomUral

Цитата:
Ерунда. Если вы на 4й стадии точно вручную определили полезную область, то индивидуальное подравнивание отклонения границы области от придуманной направляющей на пятой стадии не потребуется. Само подсчитается. Равнять придётся только буквицы и тэ пэ. То есть то, что глубоко внутри полезной области.

Что то  у вас с памятью. Когда то вы осознали, что полезная область не может всегда являться реальной базой для выравнивания. В данном случае самовыравнивания не произойдет. Выступающие части не позволят выровнять контент на всех страницах. Это чревато тем, что мы зальем полезные части.
Но с другой стороны я исходил из минимализма и то, что предложил вполне достаточно что бы решить все проблемы, если они имеются. На самом деле я на этом не наставиваю. Вполне хватит того, что ожидается. Мне позиция не нравится - критиковать все, не предлагать ничего. Все давно придумано за нас.
 
Добавлено:
gsn13n

Цитата:
 Для большинства книг с простым форматированием

Ключевая фраза.

Всего записей: 1540 | Зарегистр. 29-01-2009 | Отправлено: 12:12 07-03-2018 | Исправлено: BKSRU, 12:20 07-03-2018
TelecomUral

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Это чревато тем, что мы зальем полезные части

Типа кавычек? Которые по ГОСТу должны выступать за край текста? Но они пропадут только в случае если скомандовали их удалить. На то и простота. Нельзя влёгкую определить "вот это вот не мусор, а кавычка, ты, ST, её не чисти". OCR вводить, что ли. Вручную подвинули, и всё, раз уж вы в простой программе захотели сложных изысков макетирования. В СК процесс обнаружения таких краевых символов и соответствующий расчёт полей есть, и это сложная штука. Я предпочитал начхать на точность в один символ, чем портить глаза на микровыравнивании.
 
Тогда уж это надо было решать точечкой "0-0", про которую я выше написал. Какой-то этап, на котором пакет сканов прошивается однозначной неменяемой осью. Тогда фотоснимки книг "идут лесом". Фигня опять и выйдет.  
 
В одну телегу впрячь неможно коня и трепетную лань. В издательском профессиональном софте можно сделать всё что хочет душа. Вон slava_kry про кропбокс в акробате видео записал по моей просьбе. Хошь закропь, хошь откропь обратно, нет проблем. Потому что класс программы другой.

Всего записей: 415 | Зарегистр. 15-07-2010 | Отправлено: 12:33 07-03-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
TelecomUral

Цитата:
Я предпочитал начхать на точность в один символ, чем портить глаза на микровыравнивании.

Вот именно. Поэтому и сделал все возможное, а не ждал с моря погоды, что бы не портить зрение при такой операции. И считаю, что в основном добился. Меня устроит вполне то, что есть. Остальные споры касались не столько возможностей, сколько иной информативности интерфейса. А возможностей теперь хватает. Можно переходить к следующему пункту .

Всего записей: 1540 | Зарегистр. 29-01-2009 | Отправлено: 12:43 07-03-2018 | Исправлено: BKSRU, 12:53 07-03-2018
VSHY

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
4lex4

Цитата:
Дело в том, что нет гарантии, что полезная область на всех страницах одинакова.
Это естественно.

Цитата:
Вы задаете жесткие поля от краев - из-за разности размеров некоторые области с контентом в них не поместятся, а другие будут слишком маленькие, что прикажете делать?
Уменьшить размер полей. Если результат неудовлетворительный (поля на некоторых страницах получаются слишком маленькие), то глобально уменьшить масштаб контента, т.е. выставить, к примеру, 95% и попробовать снова.
Про Word ничего не знаю, т.к. работаю в нём может быть раз в год, если не повезёт.

Цитата:
И опять та же песня - вы простите двигать контент, и двигать его видать опираясь на глаз, да?
Двигать контент внутри листа, так будет корректнее, размещая его внутри указанных полей.
Конечно на глаз! Т.к. только методом подбора понятно, приятно ли глазу те пропорции, в которых размещён контент на странице или нет!

Цитата:
Делать движение контента без опоры бессмысленно, то есть даже для вашей реализации нужны направляющие.
Не понимаю, зачем они мне нужны. Естественная опора - это края страницы.

Цитата:
не вижу смысла делать масштабирование вручную, когда оно может быть высчитано автоматически и точно по полям (см. версию Experimental)
Вы на самом деле тоже масштабируете контент, но только не отдельным удобным инструментом для этого, а полями. Это как вместо того, чтобы вытащить собаку из будки за хвост мы бегаем вокруг будки и стреляем, заливаем, поджигаем будку для того, чтобы она вышла оттуда сама.
При таком подходе масштабировать контент очень трудно, т.к. нужно отдельно изменять значение полей по вертикали и горизонтали, и в каждом случае не совсем понятно, что происходит, т.к. оно прыгает то туда, то сюда.
При изменении масштаба мы бы просто получили пересечение контента с одним из полей, и уменьшили бы масштаб либо уменьшили бы поле.

Цитата:
Сканы выравнивать таким способом нельзя, иначе вы получите различный размер букв на каждой странице.
Я исхожу из того, что DPI у каждого листа одинаков. Тогда глобального для всех листов масштаба вполне хватило бы. Для случаев разного DPI, что я бы подбирал бы масштаб вручную, что вы делаете то же самое, но полями. Тут я не вижу разницы.

Всего записей: 805 | Зарегистр. 19-05-2008 | Отправлено: 13:08 07-03-2018 | Исправлено: VSHY, 13:22 07-03-2018
tlotr

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKSRU
Кажется, даже до меня наконец допёрло, зачем вам нужны направляющие. Речь идёт о блоках текста, где одна буковка (в данном случае, хвостик "J") может чуть выпирать относительно 99% прочих символов, в результате чего, если мы желаем не обрезать данный хвостик, то (и СТ так и сделает) основной блок будет на размер этого хвостика сдвинут вправо.  
 
Именно для этого и нужны направляющие, которые помогут вам визуально сохранить выравнивание блоков текста в одном и том же месте для всех страниц? Опровергните, пожалуйста, мои опасения.

Всего записей: 85 | Зарегистр. 16-09-2009 | Отправлено: 14:51 07-03-2018
4lex4

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
VSHY, еще раз, нельзя масштабировать сканы, если они изначально правильного размера - у вас будет разный размер букв на страницах. Масштабирование нужно для другого, например, для фоток с рук, или ремасштабировать широкую обложку, но регулярный контент со сканера никогда не должен масштабироваться.
 
Добавлено:
gsn13n, просто попробуйте адаптивную бинаризацию. Wolf - один из лучших представителей, является одним из лидеров международного конкурса DIBCO. Старый СТ да, с проблемными сканами не справлялся, сам сталкивался с такими случаями, в СТА это исправлено.
 


С проблемой енхансера разобрался, будет исправлено.

----------
ScanTailor Advanced v1.0.16 | Пожертвования

Всего записей: 317 | Зарегистр. 27-01-2016 | Отправлено: 15:02 07-03-2018 | Исправлено: 4lex4, 15:18 07-03-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
tlotr

Цитата:
BKSRU
Кажется, даже до меня наконец допёрло, зачем вам нужны направляющие. Речь идёт о блоках текста, где одна буковка (в данном случае, хвостик "J") может чуть выпирать относительно 99% прочих символов, в результате чего, если мы желаем не обрезать данный хвостик, то (и СТ так и сделает) основной блок будет на размер этого хвостика сдвинут вправо.  
 
Именно для этого и нужны направляющие, которые помогут вам визуально сохранить выравнивание блоков текста в одном и том же месте для всех страниц? Опровергните, пожалуйста, мои опасения.  

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

Всего записей: 1540 | Зарегистр. 29-01-2009 | Отправлено: 15:11 07-03-2018 | Исправлено: BKSRU, 15:14 07-03-2018
VSHY

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
4lex4

Цитата:
нельзя масштабировать сканы, если они изначально правильного размера - у вас будет разный размер букв на страницах.
Если взять 2 листа с одинаковым DPI, выделить в них разную полезную область и потом её увеличить, к примеру вдвое, то как у них будет разный размер букв???

Цитата:
регулярный контент со сканера никогда не должен масштабироваться
Видимо, каждый отталкивается от той работы, которую он делает.
У меня нет сканера, и я ничего никогда не сканирую. Для всех проектов беру то, что нашёл в сети или кто-то поделился. Потому тут нет какого-то "изначально правильного размера". Если DPI одинаков, считай повезло. Иначе бывает, что 3 листа одинакового DPI, а 4-й растянут или наоборот сужен - заполнен на 2/3 страницы. Т.е. нужно изменять масштаб, вручную подбирая, чтобы размер буковок был везде одинаков.
Либо качество материала отличное, но опять же поля у оригинала большие. В этом случае можно увеличить все изображения проекта, если это видимо не вредит качеству.
Потому в моём случае применений масштабированию масса - оно нужно в большей части проектов.
А иногда нужно чёткое сохранение масштабирования, но при работе с полями контент начинает автоматически сжиматься/растягиваться - это жесть какая-то!.. Может есть новые фичи для этого в последних версиях, пока не смотрел.
Короче, хотелось бы нормально этим управлять, а не то, что мне даёт этот "автомат": если нужно, то сохранить масштаб, если его нужно корректировать, - значит нужно, но гибко и удобно.

Всего записей: 805 | Зарегистр. 19-05-2008 | Отправлено: 15:34 07-03-2018 | Исправлено: VSHY, 15:42 07-03-2018
tlotr

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKSRU
Не сочтите за труд, напомните ссылками на сообщения, какие ещё это случаи? Можно в личку.
 
Конкретно вот это случай (если вообще заморачиваться с устранением данного дефекта) правится уменьшением на пару десятых пунктов значения левого поля.

Всего записей: 85 | Зарегистр. 16-09-2009 | Отправлено: 16:03 07-03-2018
VidelSamogO



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Нельзя ли расширить диапазон выравниявания яркости при бинаризации? А то можно сказать, что выравнивание существует только для галочки. В сущности оно настолько в узких пределах, что его можно сказать совсем нет.


Всего записей: 715 | Зарегистр. 16-08-2008 | Отправлено: 19:06 07-03-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
tlotr

Цитата:
Не сочтите за труд, напомните ссылками на сообщения, какие ещё это случаи? Можно в личку.
 
Конкретно вот это случай (если вообще заморачиваться с устранением данного дефекта) правится уменьшением на пару десятых пунктов значения левого поля.

http://forum.ru-board.com/topic.cgi?forum=5&topic=32945&start=2460#7
И дальше смотрите обсуждение. Кроме того в самом начале я показывал книгу с более серьезным случаем, но типичным в моей практике, когда полезная область некоторых страниц на весь формат, а текстовые блоки внутри полезных зон.
Что касаемо этого конкретного случая для меня имеет смысл. Расхождение в 1 мм для меня уже критично. Меня раздражают скачки краев как по ширине так и по высоте при перелистывании.  
Так же мне довольно часто попадаются книги, когда картинки выходят за рамки текстового блока.
Недавно приводил случай, когда названия глав не имеют ни колонтитула, ни номера страниц. Такие страницы выравниваем единым стилем по удобной базовой поверхности, например орнаменту.  
Помоему достаточно, что бы осознать, что процесс выравнивания в таких ситуациях стоит упростить.

Всего записей: 1540 | Зарегистр. 29-01-2009 | Отправлено: 19:10 07-03-2018 | Исправлено: BKSRU, 19:44 07-03-2018
tlotr

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKSRU
По ссылке:

Цитата:
Есть проблемные странички с выступом по левому краю полезной области - этот край не может являтся базой для выравнивания. Но мы должны исправить положение с наименьшими трудозатратами, максимальной точностью и конечно же быстро, не портя зрение.  

Эти "проблемные" странички легко видны на существующем механизме: прямоугольник, обрамляющий текстовый блок неплотно к нему прилегает. Чуть уменьшаем поля.
 

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

Полезная область корректируется на текстовый блок, без заливки полей
 

Цитата:
Расхождение в 1 мм для меня уже критично. Меня раздражают скачки краев как по ширине так и по высоте при перелистывании.  
Обычно чётные/нечётные страницы имеют симметричное расположение и имеют разные поля от корешка и от края страницы. А то, что чётные номера страниц находятся в одном углу, а нечётные - в другом? Как с этим быть? Вы, я так понимаю, всегда смотрите разворотами? Иначе это бы вас тоже раздражало.  
 

Цитата:
Так же мне довольно часто попадаются книги, когда картинки выходят за рамки текстового блока.  

Правится, например, уменьшением значения соответствующего поля до размера страницы, принятой за эталонную.
 

Цитата:
Недавно приводил случай, когда названия глав не имеют ни колонтитула, ни номера страниц. Такие страницы выравниваем единым стилем

Такие страницы выравниваем единообразно на свой вкус, т. к. даже в книге они ни к чему не привязаны.
 

 

Всего записей: 85 | Зарегистр. 16-09-2009 | Отправлено: 20:25 07-03-2018
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146

Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor (часть 2)

Имя:
Пароль:
Сообщение

Для вставки имени, кликните на нем.

Опции сообщенияДобавить свою подпись
Подписаться на получение ответов по e-mail
Добавить тему в личные закладки
Разрешить смайлики?
Запретить коды



Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2018

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru

Рейтинг.ru