» ScanKromsator СканКромсатор (Часть 2)

noveagle, установите новую версию программы. Возможно, Вам удастся избежать подобных проблем в будущем.

Скачать текущую версию

shch_vg

Цитата:

StudentFS
А на закладке Page галки в Automargins слева и справа стоят?

не, никогда не стоят. Никогда автополя не использую, только по резакам.

StudentFS

Цитата:

не, никогда не стоят. Никогда автополя не использую, только по резакам.

Вот и ответ на Ваш вопрос.
Именно при галках в полях Automargins обеспечивается добавление полей, причем непроставление галки, допустим, по вертикали справа от Automargins приведет к добавлению полей по горизонтали и обрезанию по тексту по вертикали.

shch_vg
спасибо за ответ
bolega
ну а если мне не нужны автополя, я имею в виду произвольная расстановка резаков? Я сам выставил резаки точно как надо, дальнейший интелект программы по их передвижению мне не нужен, Мне нужна точная обрезка по выставленным резакам с добавлением пустых полей до более-менее общего размера. Чтобы только экстраординарные страницы вылезали за размер, а все меньшие приводились к общему. Я понимаю, что это не общепринятая идеология работы программы, все работают с автополями, но я уже говорил, мне авторасстановка не нравится, расставляет совершенно от балды. Поэтому зачем мешать два разных режима - авторасстановку резаков и добавление полей? Может можно сделать чтобы я сам точно расставлял резаки а прога просто добавляла пустые поля меньшим до среднего?

StudentFS

Цитата:

Поэтому зачем мешать два разных режима - авторасстановку резаков и добавление полей?

Это Вы мешаете две абсолютно разные никак не связанные между собой возможности.
Я уже довольно давно отказался от Draft Kromsate, расставляю резаки вручную, но автоматически , а Automargins использую всегда, когда мне нужно получить одинаковые размеры всех страниц.

StudentFS
Вы вновь (или это были не Вы?) путаете резаки с границами блока текста. Первые Вы выставляете автоматически с помощью Draft Kromsate и не обращаете никакого внимания на то, как они расставлены (если, конечно, они не отрезают что-нибудь лишнее, или не включают что-нибудь лишнее - к примеру, слишком темную тень от корешка, мусор и т.п.). Вторые же Вы вообще не видите на этапе предобработки. Увидеть их можно только на этапе постобработки - в режиме Result View (даны пунктиром).
Первое и второе - две разные вещи. Первое необходимо для того, чтобы правильно определить второе. Поля добавляются НЕ ОТНОСИТЕЛЬНО ПЕРВОГО, А ОТНОСИТЕЛЬНО ВТОРОГО - именно это Вы и не можете понять, судя по Вашему сообщению.
Да, первое может в некоторых случаях совпадать со вторым, можно сделать, чтобы они совпадали. Но пока Вы не разберетесь, в чем между ними разница, об этом лучше не говорить

shch_vg
ghosty

pasibo za otveti


Цитата:

Увидеть их можно только на этапе постобработки - в режиме Result View (даны пунктиром).

нету у меня в результатах пунктира почемуто

Окей, я путаю эти две разные фигни. Проблема с прогой в следующем. Пусть стоит галка у avtomargins. Тогда даже если выставил резаки (ПЕРВОЕ) правильно, программа при создании результата (ВТОРОГО) залезает за границы выставленных резаков (ПЕРВОГО) и может схряпать часть текста. А именно: когда ты, вконец замудохавшись, выставил все резаки как надо, на результирующих рисунках очень часто схряпываются (исчезают) номера страниц. Что вызывает обильные матюгания по принципу "Я же тебе сказал как делать, а ты опять все попортила". Поэтому приходится отбивать галку avtomarging. В результате (о, счастье!) реальные границы текста (ВТОРОЕ) начинают наконец точно совпадать с выставленными резаками (ПЕРВОЕ). И если выставить галку ауто у ширины страницы (о счастье опять) все маленькие страницы дополняются полями до границ среднего. Но западло в том, что если сделал чтото неправильно и надо переделать только один файл, то автоматически выставленное fixed уже нихрена не работает. Уф!

StudentFS
Цитата:

на результирующих рисунках очень часто схряпываются (исчезают) номера страниц.

Если Вы хотите, чтобы при Draft Kromsate резаки не теряли нумерацию, выставляйте в окне Draft Kromsate галочку в поле Safe top/bottom.
Если нужно обезопасить нумерацию от удаления на стадии обработки, я в закладке Options устанавливаю в нужные позиции два движка Text sensitivity. Верхний (vert.) я ставлю в среднее положение, нижний (horiz.) в крайнее правое. Почему так, я обсуждать не готов, просто где-то в этой теме прочел, и мне это помогает. Кстати, если эти движки не выставить и обработка даже не режет нумерацию, то очень часто текст по вертикали смещается на отдельных страницах, поэтому я их так выставляю всегда.

Порядок обработки сканов в Кромсаторе. Краткое описание.

Оригинал: Результат:

shch_vg

Цитата:

Если нужно обезопасить нумерацию от удаления на стадии обработки, я в закладке Options устанавливаю в нужные позиции два движка Text sensitivity.

Вау! Пасибо, очень полезный совет, я про это не знал. Но использовать все равно не буду. Представьте себе вполне реальную ситуацию (по пять раз на книгу случается) когда скан бледный или из ровной границы текста вылазит на край какаянибудь плохо прописавшаяся циферка. Тут никакая чувствительность не поможет. А проверять текст еще раз сравнивая каждый результат с книгой в руке - это выше человеческих сил. Я уже сделал это один раз когда поправлял резаки. Да и сложно это, кстати в этом смысле программа нихрена не помогает, хотя могла бы в легкую. И допустим я нашел где чтото не вошло в результат. Режим avtomargins мне даже не позволяет ввести коррекцию. Надо отбивать галку этого режима.

По итогам состоявшейся дискуссии следующие предложения для
bolega
которые к сожалению опять наверно будут отклонены.

1. Галка avtomargings имеет слишком многофункциональное значение. Как я понял, многие работают в режиме, когда после расстановки резаков требуется обрезка текста точно по выставленным резакам без работы исскуственного интеллекта. Поэтому хорошо бы иметь четкую галку, привязанную только к включению-отключению режима коррекции границ отрезаемого текста по сравнению с резаками.
2. Работа ширины страниц auto/fixed совершенно напрасно привязана к работе галки avtomargins. В режиме отбитой галки avtomargins желательно сохранение работы галки auto/fixed.
3. Хотелось бы всетаки использовать режим работы исскуственного интелекта avtomargins после расстановки резаков. Проблема в том, что этот режим съедает отдельные циферки и бледный текст по краям. shch_vg предлагает повышать чувствительность Options-Text sensitivity. Но это не работает всегда. Представьте себе очень слабо прорисованную циферку за границей плотного текста. Она всегда будет неучтена исскуственным интелектом. Какой здесь выход? Брать в руки книгу и сверять все-все-все с книгой в руке? Это невозможно. Программа здесь совсем не помогает. Хотелось бы по типу резаков на ИСХОДНОМ рисунке где еще весь мусор или на рисунке ограниченном резаками видеть
как работает режим avtomargins с возможностью корректировки как сделано для резаков.


Добавлено:
ghosty
Очень полезный рисунок, позволит легче объясняться тут. Только вопрос. Скажите, в Вашей методичке Вы уверены, что к Т добавляются поля до К и дальше обрезание идет по границе К? А не наоборот? Текст обрезается по Т, а дальше к нему добавляются пустые поля до К?

ghosty
Поместите, пожалуйста, или все под more, или вообще без этого тэга. Иначе читать неудобно - туда-сюда приходится прыгать.

НАРОД!!! ПОМОГИТЕ!

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

Вот, выкладываю пару страниц: http://webfile.ru/1969928

Gajver100
Я тут не профи, но я б делал в ч.б. без изысков. Если же всетаки хочется сохранить красный цвет для текста я б сделал как original или как картинку с original.

StudentFS

Цитата:

не, для такой замороченной проги просто жизненно необходим не менее замороченный хелп.

Вот поэтому я конкурс и предложил Если не будет простой инструкции, миф о замороченности СК действительно начнет крепнуть, а армия недовольных увеличиваться
Итак, теперь Вы понимаете, что так называемые "резаки" служат всего лишь для того, чтобы "открамсывать" все лишнее (мусор). Это, в свою очередь, необходимо для обеспечения правильности автоматического определения границ блока текста.
Именно поэтому резаки не нужно устанавливать точно. Между прочим, их можно (а иногда необходимо) выставлять под углом - попробуйте тянуть ползунок резака с нажатой клавишей SHIFT.
Еще раз: неважно, как стоят резаки. Главное, чтобы 1) они не захватывали блок текста; 2) весь крупный мусор оставался за резаками (с внешней стороны) – см. выше


Цитата:

А именно: когда ты, вконец замудохавшись, выставил все резаки как надо

А просто не надо "мудохаться", будете спокойнее
Всю обработку можно разделить на три этапа. Пусть они называются «предобработка», «обработка» и «постобработка». Попробую как можно подробнее рассказать об этих этапах с точки зрения определения границ текста.
[more]1.    Первый этап (этап предобработки). Первое, что всегда нужно сделать после загрузки файлов в СК, это нажать кнопку «Draft Kromsate» (иконка c ножничками; далее DK) - в меню: Edit -> Draft Kromsate. Если обрабатываем разворот, ставим в окне DK галочку “Split pages”. DK позволит нам расставить резаки автоматически. Как правило, этого вполне хватает, и необходимо просто проверить правильность расстановки. Но иногда могут появляться систематические ошибки.
Причиной этих ошибок может стать, к примеру, слишком бледный скан или номер страницы, расположенный слишком далеко от блока текста и от того воспринимающийся как мусор. Если это происходит (можно для пробы обработать 10-20 страничек и посмотреть), можно поставить также галочку “Safe Top/Bottom”. Если даже это не помогает, то есть возможность увеличить чувствительность DK по вертикали – на закладке “Advanced” ->” Text vert. sensitivity”.

ghosty
Спасибо! Все правильно, за исключением одной вещи: в режиме Compare пунктиром показывается периметр, построенный по резакам, а не по расчетному контуру (этот контур определяется при обработке, и не сохраняется в задании, поэтому показать его невозможно). Пунктир (контур резаков) показывается с одной целью: чтобы визуально увидеть косяки драфта, если тот поставит резак неправильно).

StudentFS
Я понял Вашу проблему. Заключается она в том, что Вы отключаете целиком automargins, а не ее подопции! Делать этого категорически не нужно! Если хотите задать какой-то резак, отключайте соответствующую ему под-галку automargins (T,B,L,R)! Отключение всех под-опций не эквивалентно полному отключению automargins!

ghosty
bolega
Спасибо за ответы! Попробую на следующей книге. Если получится значительно облегчит работу.

ghosty

Ваша методичка есть очень ценный продукт, хотелось бы, объединив с рисунком, прилепить куда-нить в шапку, чтоб не потерялась. Не очень ясным, даже после коммента bolega остался вопрос, что происходит, если отключена одна из под-галок avtomargins. Я так понимаю, обрезание пойдет точно по резаку. Или по резаку плюс поля? Но этого еще никто четко не сказал. А что будет, если общая галка стоит, а все четыре под-галки отключены?

Вы меня конечно извините, господа, но лажа. Причем, ПОЛНАЯ ЛАЖА. Вот сделал я все в режиме avtomargins. Скажите, как я должен проверять, все ли вошло в результат, что было нужно? Вы советуете режим compare. Окей, я что, должен сравнивать внимательно все циферки по всем границам, не дай Бог сабж в текст влез? Вы советуете смотреть на пунктир. Так, как привильно сказал
bolega,

Цитата:

в режиме Compare пунктиром показывается периметр, построенный по резакам, а не по расчетному контуру (этот контур определяется при обработке, и не сохраняется в задании, поэтому показать его невозможно).

Проверено, действительно так. Циферка прекрасно входит в пунктир и теряется в выходном рисунке.
А скажите, нахрена мне уже при обработке результата видеть, где резаки стояли, когда они фактически уже ничего не определяли? Мне нужно видеть, где прошла РЕАЛЬНАЯ ГРАНИЦА, по которой был обрезан текст. Которая "не сохраняется в задании, поэтому показать его невозможно". Жаль, что не сохраняется, если бы ее можно было бы показать, сразу было бы видно, что реально потеряно. А так, если хочешь быть уверен в результате, сиди сам глазами эту границу проводи, сравнивая два текста по все четырем краям. Нет уж, дудки, возвращаюсь к полному отключению режима avtomargins.

StudentFS
Экспрессии много, а дела мало. Давно уже можно было выложить проблемный скан, на котором можно наблюдать указанное Вами с приложением Вашего варианта обработки его (файл spt), тогда был бы предметный разговор.
А так это все немного напоминает всем известное "вся рота идет не в ногу, один поручик в ногу".
P.S. Вроде бы автор программы не накладывал никаких ограничений на использование его программы. Каждый пользуется ею по своему разумению.

Дело не в скане, скан могу выложить, не проблема. Проблема в том, что режим avtomargins напоминает чёта мне Скайнет. Как он сработает предугадать нельзя заранее, результаты работы тоже очень трудно проверить. Еще раз цитирую bolega

Цитата:

в режиме Compare пунктиром показывается периметр, построенный по резакам, а не по расчетному контуру (этот контур определяется при обработке, и не сохраняется в задании, поэтому показать его невозможно).

То есть рамка в режиме compare вовсе не означает границу того, что вошло в текст. И таким манером проверить нельзя. Как тогда?


Добавлено:
Вот скан и обработка:
h__p://rapidshare.de/files/39558204/2004-10__Oct_.rar.html
Предупреждаю сразу, чувствительность к тексту в опциях не повышалась. Также поля выставлены в ноль. Сделано это специально, чтобы показать как работает режим автомарджинс. В режиме compare Вы увидите, где идет пунктир и как на самом деле был обрезан текст. Заранее прежупреждая Ваши ответы, скажу, что лечится чувствительностью и полями. И отключением одной из галок. Но вопрос не в том как вылечить, а как выловить это в книге из 1000 страниц например. И это еще легкий слуйчай. Сегодня постараюсь выложить пример скана из книги, где вообще нихрена работать не будет.

StudentFS
В Вашем примере выставил на закладке Options движок Text vert. sensitivity в среднее положение, после чего появилась отрезаемая в Вашем случае нумерация страницы 12.
Режим compare на предмет проверки обрезания я не использую, а только для адекватного расположения обработанного текста по сравнению с исходным.
Интересно заметить, что два движка с закладки Options имеют не соответствующие действию названия. В Вашем примере я использовал движок Text vert. sensitivity для ГОРИЗОНТАЛЬНОЙ обработки, а для вертикальной использую движок Text horiz. sensitivity.

shch_vg
Я понимаю Ваш совет, и понимаю что при повышении чувствительности скорее всего все войдет. Но...
Вот очень характерный пример
h__p://rapidshare.de/files/39561307/1.rar.html
Здесь пропадает кусок текста с бока страницы. Я понимаю, что если я повышу чувствительность, то этот кусок захватится. Но как я могу быть уверен в этом. Представьте, что скан очень бледный и слово прописалось чередой отдельных пикселов. Я таких книг видел тучу - слабая печать на глянцевой бликующей бумаге. Тут никакая чувствительность не поможет. Еще раз, вопрос не в том как исправить, тут все понятно. Вопрос в том, как понять где что сделалось неправильно. Можно конечно наплевать, авось все захватится. Но мне чёта как правило хочется быть уверенным. Работа большая, и не хочется слажать изза какойто фигни. Это я тогда должен сидеть и проверять все символы на всех границах? Увольте, проще резаки выставить как надо и убрать автомарджинс.
bolega
А проблеме помочь очень просто. Надо лишь в режиме compare отрисовывать пунктиром не резаки а контур который "определяется при обработке, и не сохраняется в задании". В чем может быть проблема, почему егонельзя отобразить?

StudentFS
Вы внимательно прочли мои рекомендации, скрытые под тегом [no][more][/no]???

C пунктиром в режиме Compare я действительно ввел Вас в заблуждение, извините. Просто раньше я сам просил bolega именно о такой функции - с отображением автоматически определенной границы блока текста пунктиром в режиме Compare: у меня также были проблемы с проверкой "выступающих" элементов. Поэтому когда недавно я этот пунктир увидел (он добавлен в последней версии), просто подумал, что сбылась моя хотелка

Но ведь нам с Вами нужно решить конкретную проблему: как гарантировать включение определенных элементов, выступающих за границу блока текста, но при этом сохранить всю автоматику. Правильно?
Я Вам и отвечаю, что такого рода мер, как минимум, две - одна полностью автоматическая, другая - "ручная":
1) Смотрим, насколько выступают необходимые нам элементы от границы блока текста - в Вашем случае номер страницы. После этого выставляем значение для поля в два-четыре раза большим этого расстояния (при наличии апсемплинга) - Book->H.Gap.value. Проверяем на нескольких страницах.
2) (Дополнительно перестраховываемся) Ставим резак рядом с этим элементом (номером страницы) и для этого резака снимаем галочку Automargin (резак при этом меняет цвет на розовый) - все, граница блока текста будет проходить по этому резаку, элемент с гарантией будет включен в эту границу.

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

P.S. Кстати, переворачивать страницы лучше еще на этапе DK.
P.P.S. (это уже к bolega) А ведь если сумма одной из сторон блока текста (к примеру горизонтальной) и двух полей (Gaps) будет больше заданной фиксированной стороны страницы (Fixed), то приоритет остается за последним. Т.е. несмотря на задаваемые размеры полей страница все равно обрежется до фиксированных размеров. Думаю, это необходимо как-то контролировать - может быть, хотя бы оповещать пользователя об этом?

StudentFS
Я сделал более 300 книг, такая проблема с отрезанием номеров страниц (обычно, только первых, состоящих из одной цифры) была всегда и у меня. Я сразу вначале внизу отключаю под-галку B(ottom)-Automargin для первых 3 страниц (кстати, это можно сделать просто двойным щелчком на бегунке резака). Чувствительность (на закладке Options2) у меня стоит посередине, этого хватает практически на все случаи жизни. Почему Вы не хотите ее поднять (ведь Вам это уже посоветовали), мне абсолютно непонятно (мазохизм?), ведь именно эта опция решит большинство Ваших проблем.

ghosty

Цитата:

я этот пунктир увидел (он добавлен в последней версии),

Он добавлен еще в незапамятной версии


Цитата:

Т.е. несмотря на задаваемые размеры полей страница все равно обрежется до фиксированных размеров.

Не совсем так. Обрезается, но не более 80% от величины полей.


Цитата:

Думаю, это необходимо как-то контролировать - может быть, хотя бы оповещать пользователя об этом?

А если в задании 500 страниц, и обрезка идет на каждой? А если обрезка, но не играющая роли (5-10 пикселов)?

StudentFS
Какие-то Вы неубедительные примеры приводите.
Выставил во втором Вашем примере движок Text vert. sensitivity в крайнее правое положение положение, и ничего не отрезалось.
Я понимаю, что можно найти еще более блеклые сканы, на которых не сработает и этот вариант (а м.б. сработает?), но, обработав порядка 200 книг, я не сталкивался с такими сканами, хотя у меня самый простой сканер - hp scanjet 2400. М.б. имеет смысл поискать программу сканирования, которая будет делать Вам более качественные сканы?

Спасибо за советы, как исправлять ошибки avtomargins я понял. Но последний вопрос касался не как их исправлять а как их находить. Постараюсь выразить сумбурные мысли яснее. Хотелось бы не просто надеяться, что с повышенной чувствительностью все будет хорошо, а хотелось бы иметь графическое средство для проверки работы avtomargins. Чем хороша расстановка резаков? Тем, что все визуально, наглядно. Все что за линиями - мусор. Хотелось бы иметь такое же наглядное средство проверки работы avtomargins.
bolega
Можно ведь на левый лист в compare добавить еще один пунктир где что avtomargins отрезал? Будет наглядно и со вкусом.
shch_vg

Цитата:

Выставил во втором Вашем примере движок Text vert. sensitivity в крайнее правое положение положение, и ничего не отрезалось.

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

Добавлено:
bolega

Цитата:

Почему Вы не хотите ее поднять (ведь Вам это уже посоветовали), мне абсолютно непонятно (мазохизм?), ведь именно эта опция решит большинство Ваших проблем.

Понимаю я про чувствительность, и поднимаю када надо. Просто как уже сказал, это все равно что штаны через голову одевать - нелогичный обходной путь, который дает неясную гарантию. Еще раз мой совет был бы
1. добавить пунктир в compare.
2. далее еще лучше - если видно в compare, что avtomargins сработал плохо на одной из сторон, давать:
а) не в опциях, а здесь же, на закладках, менять чувствительность для каждой из сторон в отдельности
б) в качестве альтернативы для а) сделать специльную зону, выделение которой на рисунке являлось бы непререкаемым требованием для avtomargins включить эту область в результат. Например, не вошла цифра на границе. Выделяем цифру квадратиком, делаем спецзону - и avtomargins вынужден обрезать с ее включением.

Разве это будет не логичнее чем без 100%-й гарантии говорить, "да вроде все должно входить"?

StudentFS

Цитата:

1. добавить пунктир в compare

ОК, попробую сделать. Может не пунктиром, а бледной подсветкой всего, что вошло, тогда то, что не вошло, будет сразу бросаться в глаза.


Цитата:

б) в качестве альтернативы для а) сделать специльную зону,

Я об этом уже думал. Только не зону, а типа якорька, чтобы кромсатор знал, что меньше, чем его положение, отсекать нельзя. Но подумал, что возиться еще и с ними никто не будет.

Но если по большому счету, то надо просто сделать сам алгоритм более умным. Я тоже об этом давно думаю, да все руки не дошли реализовать. Да и не хотелось мне усложнять обработку (т.е. и замедлять ее), ведь все, что надо, в драфте уже есть, но я не хотел дублировать его алгоритмы еще и при обработке. Да видимо, придется. Тут Вы наверно, правы - лучше дольше, но правильнее и безопаснее, чем быстрее, но с риском

Вау, bolega, у меня появилась шикарная идея! Все эти пунктиры - это все тоже полумеры. Вы со мной должны согласиться, что главное, чего не достает программе - это визуального легкого контроля результата по сравнению с входным результатом. А что может быть проще! В режиме compare вычитаете правые биты из левых и результат подсвечиваете скажем зеленым. Будет видно все что потеряно - мусор, пропавшие кривые графиков, состоящие из крохотных точек - все, все, все! Было б класс!


Добавлено:
P.S. сначала написал, а потом внимательно прочитал, что Вы написали то же самое про подсветку. Ваша идея.

Добавлено:

Цитата:

типа якорька

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

Добавлено:
Про вычитание битов. Проблемой тут может быть, что буквы были сглажены, поэтому буква слева не соответствует букве справа. Поэтому я б сделал так. Пусть лево входные 8 градаций серого. Право - выходной битонал. Бежим по пикселам левого. Выбрали конкретный левый пиксел. Если в окрестности скажем 7 пикселов справа вокруг этой точки есть черный пиксел - ничего не делаем, сохраняем градацию серого. Если в семипиксельной окрестности нету правого черного пиксела, строим шкалу зеленого цвета. Шкала серого от белого до черного заменяется на шкалу яркости зеленого от белого до противно-изумрудно-зеленого. То есть светло-серый переходит в светло зеленый, черный переходит в насыщенный изумрудно зеленый. Все как на ладони будет видно.

StudentFS
Про вычитание битов и пр. даже и обсуждать не будем. Во-первых, слева скан серый, невыпрямленный, с другим dpi, гладкость букв может отличаться в разы. Но даже если все это очень похоже, то сравнение их - это по сути реализация lossy jbig-кодека с элементами fuzzy pattern recognition. Увольте...

bolega
Вы обещали мне помочь. Надеюсь и давно жду )

bolega

Цитата:

Цитата: Т.е. несмотря на задаваемые размеры полей страница все равно обрежется до фиксированных размеров.

Не совсем так. Обрезается, но не более 80% от величины полей.