Ru-Board.club
← Вернуться в раздел «Программы»

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

Автор: woodyfon
Дата сообщения: 08.12.2010 22:01
monday2000
Знаете сколько bolega сообщений о том, чтобы в SK повилась возможность автоматически определять зоны текста и картинок, что ему как классическая музыка глухому. Я читал некоторые статьи про автосегменитрование изображения в FR в которых говорилось, что были защищены несколько диссертаций. Поэтому сегментирование - это не такая уж легкая задача. Одному человеку ее не решить - надо объединятся
Автор: bolega
Дата сообщения: 09.12.2010 07:37
monday2000

Цитата:
Тут Вам помогут и

За все время существования СК еще никто мне не помогал алгоритмами (не путать с советами и идеями), так что надежда только на себя. Было только одно исключение - когда U235 поделился одним алгоритмом удаления фона, который вошел в СК под именем Safe.


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

А я никому и никогда СК не навязывал и не навязываю.
Во-вторых, МПФ и РТ - это ваши придумки, а не мои.


Цитата:
Такая схема даёт ИМХО наибольшую гибкость и универсальность. Sep-формат может в будущем выступить своего рода "унифицированным интерфейсом" между классом сканобрабатывающих программ и классом DjVu-кодировщиков

Тут вам виднее. Я с этим глубоко не разбирался. Был бы в djvulibre нормальный интерфейс в виде dll тогда другое дело.


Добавлено:
Почитал я про cpaldjvu.


Цитата:
Sep-формат может в будущем выступить своего рода "унифицированным интерфейсом"

Никакой универсальностью тут и не пахнет. Во-первых, рассчитана на малоцветные сканы (т.к. использует палитру). Во-вторых, сам кодирует текст. А использовать djvulibre для кодирования ч/б текста - это самый неоптимальный вариант, т.к. результат получится заведомо хуже и больше, чем например, в DEE. В-третьих, МПФ делает по сути то же самое, что и cpaldjvu. Только у МПФ одно преимущество - он может использовать результат DEE.

Вообще, когда начинаешь пытаться глубоко применять djvulibre, появляется горькое ощущение, что в нем постоянно чего-то не хватает. То того не предусмотрели, то другого. Одна утилита может принимать параметры из тектового файла, другая почему-то нет и т.п. и т.д. Ввели в djvumake возможность раскраски, но выбор наибеднейший: только прямоугольники и только с черной маской (а если я фон хочу раскрасить?), ввод координат зон только из командной строки (это вообще глупость, а если их десятки и сотни?), ввели параметр FGbz, пишут, дайте ему файл с raw-данными, и ни слова как его получить. Некоторые опции вообще не работают. Возьмите из доки к djvused.html приведенный там пример:
djvused myfile.djvu -e 'select 3; size'
и запустите изменив имя файла на свой. Ничего не произойдет, кроме ругани на неправильный синтаксис (похоже, что -e вообще не работает, но работает -f).
И авторы б-ки похоже не очень любят что-то развивать и добавлять, того, что требует жизнь. Это странно, учитывая, что авторы - мэтры и основатели djvu. Напоминает мне одного хорошего, но глухого к реальным потребностям программиста
Автор: monday2000
Дата сообщения: 09.12.2010 12:35
bolega

Цитата:
Никакой универсальностью тут и не пахнет. Во-первых, рассчитана на малоцветные сканы (т.к. использует палитру).

К сожалению, да, недоглядел я - не универсален. Кстати, по спецификации DjVu, FGbz-чанк может содержать палетку до 65535 цветов (пункт "8.3.10 Foreground Color JB2 Chunk: FGbz").



А FG44, насколько я понимаю, не ограничен в количестве цветов (пункт "10.1 Definitions"):

Цитата:
Compound DJVU Images and Photo DJVU Images contain color or grayscale image data. Color IW44 Images contain color image data. Grayscale IW44 Images contain grayscale image data. Color image data is coded using three color components, called Y, Cb, and Cr. These correspond to the usual YCbCr color space, adjusted to facilitate transformation to the RGB


Цитата:
Вообще, когда начинаешь пытаться глубоко применять djvulibre, появляется горькое ощущение, что в нем постоянно чего-то не хватает. То того не предусмотрели, то другого.

Наверное, потому, что её делали учёные, а не практики.

Цитата:
(а если я фон хочу раскрасить?)

Пожалуйста, добавляйте на вход djvumake также и чанк BG44, и всё.

Цитата:
Это странно, учитывая, что авторы - мэтры и основатели djvu.

DjVuLibre ещё и загаживалась Лизардтеком в своё время - по словам Леона. Вообще это ИМХО тёмная история, почему DjVuLibre так неудобен.

Цитата:
Был бы в djvulibre нормальный интерфейс в виде dll тогда другое дело.

Хорошая идея. Но некому это сделать - слишком непросто. Там, впрочем, есть низкоуровневый API, описанный в файле ddjvuapi.h : http://www.djvu-soft.narod.ru/ddjvuapi.htm . И даже DLL уже тоже вроде бы есть - libdjvulibre.dll . Правда, в довесок к ней идёт куча другого малопонятного хлама - другие dll, manifest, и эта dll даёт доступ только к низкоуровневому API - что ИМХО неинтересно. Высокоуровневого API нет, насколько я знаю. Заиметь его было бы здорово, но тяжко.

И ещё мне не нравится, что там присутствуют libjpeg.dll, libtiff.dll, libz.dll - для поддержки обычных растровых форматов. Я бы под Windows прикрутил FreeImage вместо всего этого - куда как проще. Но Леон Боту - линуксоид, Windows даже не имеет, так что ему FreeImage был бы наоборот труднее.

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

А, ну это глюк. Замените апострофы двойными кавычками, и всё заработает. Наверное, это под Линуксом не важно.

Добавлено:

Цитата:
Ввели в djvumake возможность раскраски, но выбор наибеднейший: только прямоугольники и только с черной маской

Нет, не "только с черной маской". Каждый прямоугольник может иметь любой цвет, а также, если я не ошибаюсь, можно "рисовать" два раза по одному месту (в смысле, раскрашивать текст) - имитируя тем самым зоны более сложной формы. Отрисовка идёт в порядке разбора командной строки слева направо. Т.е. можно, например, закрасить текст на пол-скана синим цветом - а потом небольшой кусочек уже синего цвета перекрасить, скажем, в красный текст - и т.д. Для этого нужно в командной строке левее указать синий прямоугольник, а правее - красный.

Добавлено:
bolega
Вообще-то я считаю, что для слоя переднего плана 65 тыс. цветов (как в FGbz) - вполне достаточно. Ведь это цвета не пикселей, а блитов. А, как правило, на одну страницу редко бывает более 10 тыс. блитов. Так что, если на одной странице менее 65 тыс. блитов (а в жизни так оно и будет), то тогда каждому блиту можно назначить свой индивидуальный произвольный RGB-цвет.

Остаётся единственный минус FGbz перед FG44 - невозможность раскраски одного блита более чем одним цветом. ИМХО этим вполне можно пренебречь. Ведь это актуально только для псевдографики, а не для букв текста.

А в будущем, я думаю, что в перспективе возможен даже и такой фантастический ныне вариант - разбивать один блит на нужное количество блитов - не трогая соседние. Свойства формата DjVu это не запрещают вроде бы (надо подумать, конечно, так ли это).

Так что я бы на Вашем месте вариант с FG44 вообще бы не реализовывал - а только с FGbz. Разве что как исключительно редко нужную фичу.
Автор: bolega
Дата сообщения: 09.12.2010 14:19
monday2000

Цитата:
Пожалуйста, добавляйте на вход djvumake также и чанк BG44, и всё

Это понятно. Я имел ввиду красить с помощью FGbz. Под фоном я понимаю белую область вокруг букв. Т.к. FGbz красит только блиты, а белый фон нельзя представить блитом (в теперешней версии), то и закрасить его нельзя. Чтобы поняли о чем речь, представьте такой случай: красный текст на желтом фоне. Текст можно закрасить FGbz, а фон - нет. Если бы djvumake умел для таких областей (для которых нет маски) сам создавать доп.блит (не сливая его с существующим, т.е. блитами текста!), то проблема была бы решена. Сам я это не могу сделать, т.к. блиты текста и фона по сути взаимно-инвертированы и в сумме дают один блит, который как известно двумя цветами не раскрасишь.


Цитата:
А, ну это глюк. Замените апострофы двойными кавычками, и всё заработает.

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


Цитата:
Нет, не "только с черной маской".

Вы не так меня поняли. Под маской я имею ввиду блит. Если мне нужно раскрасить какой-то белый участок, то красить-то будет нечего - блита (маски, stencil) для него нет.


Цитата:
Каждый прямоугольник может иметь любой цвет, а также, если я не ошибаюсь, можно "рисовать" два раза по одному месту (в смысле, раскрашивать текст) - имитируя тем самым зоны более сложной формы

Это действительно есть. Я даже исходник посмотрел. Но если проанализировать хорошенько, то все это чепуха. Хотя бы потому, что для этого прямоугольники нужно описывать в строго определенной последовательности, которую может составить только человек. Представьте еще такую комбинацию: два равнобедренных трегольника, оба наклонены на 45 градусов и смотрят друг на друга (или: взять квадрат, разрезать по диагонали и чуть сдвинуть одну половинку вверх). С помощью синтаксиса djvumake вы не сможете теперь раскрасить их в разные цвета, оба блита всегда будут принимать последний заданный цвет. Это потому, что блиты хоть и не соприкасаются, но их габариты пересекаются. Теоретически это можно обойти, но в общем случае (когда в задаваемом цветном прямоугольнике много блитов) это очень сложная задача. В приведенном мною примере это сделать просто: в качестве прямоугольников задавать не габариты треугольников, а небольшие участки внутри них.

Добавлено:

Цитата:
А в будущем, я думаю, что в перспективе возможен даже и такой фантастический ныне вариант - разбивать один блит на нужное количество блитов - не трогая соседние


Да, это решило бы проблему на 100%.


Цитата:
Так что я бы на Вашем месте вариант с FG44 вообще бы не реализовывал - а только с FGbz. Разве что как исключительно редко нужную фичу

Да я разве против. Но если это не даст (даже иногда) юзеру того, что он хочет, точне, иногда может дать не то, что он хочет, то как же можно использовать. Из принципа что-ли? Пусть будет непредсказуемо, но зато идейно правильно???



Добавлено:

Цитата:
Вообще-то я считаю, что для слоя переднего плана 65 тыс. цветов (как в FGbz) - вполне достаточно. Ведь это цвета не пикселей, а блитов. А, как правило, на одну страницу редко бывает более 10 тыс. блитов. Так что, если на одной странице менее 65 тыс. блитов (а в жизни так оно и будет), то тогда каждому блиту можно назначить свой индивидуальный произвольный RGB-цвет.

А теперь представьте какой-нибудь фотоальбом, где для каждой страницы вполне может задействоваться все 65 тыс.цветов. И посчитайте размер палитры (для каждой страницы!) - около 200кб. И это только палитра! Уж лучше BG44 использовать.
Автор: AndroS
Дата сообщения: 10.12.2010 07:53
Доброго времени суток...
Столкнулся с проблемой - после обработки кростатором получаются пустые/белые страницы (Не все, но порядочно, штук 50 по-моему). Настройки выставлены типовые - как в Scan & Share написано. Резаки выставлены правильно.
С чем это может быть связано?
Автор: bolega
Дата сообщения: 10.12.2010 08:03
AndroS
Скорее всего неправильно выставлены резаки. Например, скан - одиночная страница, а резаки включены все, как будто это разворот
Автор: AndroS
Дата сообщения: 10.12.2010 09:02
bolega
Я как раз и написал, что резаки проверил в первую очередь. Скан - разворот.
Пользую СК 5,93 из шапки. Прилагаю файл проекта, исходники и результат: http://www.onlinedisk.ru/file/569180/ (12 Мб)
Поясните, пож-ста, чего не так у меня...
Автор: bolega
Дата сообщения: 10.12.2010 10:20
AndroS
Спасибо за задание.
Прогнал его, все получилось нормально.
Возможно, у Вас какая-то старая версия СК.
Но есть одно важное замечание: у Вас включена опция merge pages (кстати, никогда не понимал, зачем люди делают по две страницы на листе, для этого ведь в любом просмотрщике, djvu или pdf, есть соответсвующая опция). Эта опция в последних версиях СК больше не поддерживается! Вместо нее следует использовать аналогичную (почти) опцию Merged page (на закладке Page->Special->More). Только нужно помнить, что в отличие от старой опции, опция Merged page page-ориентированная, т.е. может применяться к произвольным разворотам.

Автор: AndroS
Дата сообщения: 10.12.2010 11:24
bolega
А можно ссылку на Вашу версию? Всё одно такая же ерунда.
Как уже говорил - моя версия - 5.93 из шапки темы
Автор: shch_vg
Дата сообщения: 10.12.2010 11:36
bolega

Цитата:
Возможно, у Вас какая-то старая версия СК.

У меня в 5.93 (вроде последняя опубликованная версия) получились пустыми 5, 6, 8 и 9 развороты. В конце же работы еще зачем-то был задан попрос о возможности перезаписи уже имеющегося 1-го разворота. После подтверждения он был, по-видимому, перезаписан, но не изменился.
Что касается просмотра в двухстраничном режиме, то это отдельная песня .
В WinDjView для нормального (как в самой книге) просмотра необходимо, чтобы структура книги была фиксированной, а именно, начальная обложка - одна штука, перед титульным листом ОБЯЗАТЕЛЬНО наличие пустой страницы.
Зато в Foxit Reader все наоборот: наличие пустой строки перед титульным листом недопустимо, зато на первой экране - обложка и титутульнй лист.
Единственное, в чем я могу с Вами согласиться, что читать разворот с двумя страницами менее комфортно, чем отдельно каждую страницу, поэтому я тоже не вижу большого смысла делать двухстраничные сканы.
КРОМЕ одного варианта.
Сейчас я делаю журналы "Шахматы" (Рига), разворот у которых равен А4. Кроме того для ускорения работы, а также для получения визуального представления о нем (нынешние молодые вполне могли его не видеть) я сразу сканы разворотов без обработки (или практически без обработки) в СК компилирую в djvu.
Вот как раз здесь я использую опцию merge pages. Дело в том, что, как правило, 2-ю и 3-ю страницы обложки я сканирую в цвете в 150dpi, а весь текст внутри журнала в сером в 300dpi, поэтому с помощью этой опции объединяю 2-ю стр. обложки с первой страницей текста, а последнюю страницу текста с 3-й стр. обложки.

Добавлено:
AndroS
Об этом давно мечтают все пользователи СК .
Автор: AndroS
Дата сообщения: 10.12.2010 11:49
shch_vg

Цитата:
У меня в 5.93 (вроде последняя опубликованная версия) получились пустыми 5, 6, 8 и 9 развороты.

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

ЗЫ про добавлено: Дом. страничка ув. автора ничего не показывает...
Автор: shch_vg
Дата сообщения: 10.12.2010 12:33
AndroS
Грабли в этой версии СК в опции Illumination. После ее отключения все работает, но фон, конечно, остается.

P.S. Версия 5.92 вообще не дружит с Illumination и заканчивает работу аварийно.

Добавлено:
Проверка показала, что дело не в опции Illumination, а в ее подопции Smart.
При Normal все работает, но устраивает ли Вас такой результат...
Автор: AndroS
Дата сообщения: 10.12.2010 12:46
shch_vg
Понял, спасибо, буду с другими значениями Illumination баловаться...
Автор: monday2000
Дата сообщения: 10.12.2010 14:43
bolega

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

Так а в чём проблема? Жёлтый фон делается при помощи слоя заднего фона BG44. Единственная проблема - что слой заднего фона в DjVu может быть только один, что создаёт некоторые неудобства при создании DjVu "вручную по кусочкам".

Цитата:
Если бы djvumake умел для таких областей (для которых нет маски) сам создавать доп.блит (не сливая его с существующим, т.е. блитами текста!), то проблема была бы решена.

Не пойму я, в чём проблема. Я не вижу тут проблемы. Зачем нужен доп.блит? Рисуйте просто в заднем фоне BG44 нужные цветные объекты - да и всё. Кроме того, нехорошо было бы вводить в маску слишком большие "искусственые" блиты - от этого сильно вырос бы размер файла.

Цитата:
Что говорит о том, что выбранная грамматика командной строки противоречива и неоднозначна.

Скорее всего, это просто глюк. Попробую как-нибудь написать письмо Леону Боту на эту тему.

Цитата:
Если мне нужно раскрасить какой-то белый участок, то красить-то будет нечего - блита (маски, stencil) для него нет.

Как это нечего?! Красьте сам задний фон - т.е. нужные его участки (скажем, прямоугольные).

Цитата:
Но если проанализировать хорошенько, то все это чепуха.

Я совершенно согласен с этим утверждением. Просто никто не хотел вкладывать слишком много своего времени на совершенствование этого синтаксиса (выборочной раскраски маски) - отсюда и такой глупый вариант (этого синтаксиса).

Цитата:
А теперь представьте какой-нибудь фотоальбом, где для каждой страницы вполне может задействоваться все 65 тыс.цветов. И посчитайте размер палитры (для каждой страницы!) - около 200кб.

ИМХО это исключительно маловероятно. Это должно быть что-то вроде "рассыпанного содержимого калейдоскопа" - причём все эти объекты должны быть чёткоконтурные, чтобы претендовать на попадание в маску. Обычно такие вещи отправляются прямиком в задний фон - где им самое место. Можно же задать 100% качество заднего фона - будет очень даже прилично.

Это надо взять обычную страницу, каждую букву разбить на 6 частей (с белым промежутком между частями), да ещё и раскрасить каждый околок буквы в индивидуальный цвет. Или нечто вроде крупного цветного дизеринга. В любом случае, такие вещи вообще не попадут в маску (т.е. тогда уж говорить о том, чем лучше раскрасить маску - через FGbz или FG44, вообще не придётся), а уйдут в задний фон.
Автор: bolega
Дата сообщения: 10.12.2010 15:09
shch_vg

Цитата:
Проверка показала, что дело не в опции Illumination, а в ее подопции Smart

Я сразу заметил, что Smart портит именно эти страницы, но все-равно кое-что от текста остается, а в выложенном задании вообще все чисто.
Кстати, а чем вызвано то, что в задании отсутствует бинаризация?

monday2000

Цитата:
Скорее всего, это просто глюк. Попробую как-нибудь написать письмо Леону Боту на эту тему

И еще напишите, что если в командной строке путь к djvu файлу содержит кириллицу, то утилиты не видят файл.
И заодно попросите хотя бы, чтобы координаты зон раскраски брались бы из текстового файла, а не из командной строки. Наверное, не найдется ни одного чудака, который бы вручную использовал бы эту возможность. Т.е. фича явно ориентирована на внешнюю программу, которая будет формировать командную строку, а ей удобнее сохранять этот массив зон в файл, чем формировать длинющую строку (кстати, ее предельно допустимый размер под windows не резиновый, особенно в win2000)
Автор: shch_vg
Дата сообщения: 10.12.2010 15:31
bolega

Цитата:
Кстати, а чем вызвано то, что в задании отсутствует бинаризация?

Хотя этот вопрос и не ко мне, попробую отгадать ответ на него.С чем-то подобным я встречался при переводе журнала в бинарный вид. Залитые черным области тогда получались излишне ярко-черными, поэтому я при обработке старался заключить такие области в серую picture-зону, получая более мягкий для глаза вид этой области.
Автор: NME
Дата сообщения: 10.12.2010 23:00
shch_vg

Цитата:
В WinDjView для нормального (как в самой книге) просмотра необходимо, чтобы структура книги была фиксированной, а именно, начальная обложка - одна штука, перед титульным листом ОБЯЗАТЕЛЬНО наличие пустой страницы.

вид -> расположение -> первая страница отдельно

bolega

Цитата:
если в командной строке путь к djvu файлу содержит кириллицу, то утилиты не видят файл.

могу сказать про djvused (т.к. пришлось погеморроиться с кириллицей именно с этой утилитой) - там проблема с кодировкой командной строки.. мне удалось выкрутиться только таким способом - созданием bat-файла

Код:
string Path = Application.StartupPath + "\\run.bat";
string resultPath = Application.StartupPath + "\\result.dsed";
File.WriteAllText(Path, " \r\nchcp 1251\r\ndjvused " + "%1" + " -f result.dsed -s", Encoding.UTF8);
System.Diagnostics.Process proc = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo psi = new System.Diagnostics.ProcessStartInfo();
psi.FileName = Path;
psi.WorkingDirectory = Application.StartupPath;
psi.Arguments = "\"" + _fileName + "\"";
psi.UseShellExecute = false;
psi.CreateNoWindow = true;
proc.StartInfo = psi;
proc.Start();
Автор: shch_vg
Дата сообщения: 11.12.2010 14:24
bolega
При импорте pdf в СК некоторые страницы (зоны) вытаскиваются "по Малевичу" - черными (похоже на неверную выборку серого).
Если интересно, то вот пример (10 Стр., 1,5 мб).
Автор: monday2000
Дата сообщения: 13.12.2010 12:14
bolega

Цитата:
И еще напишите, что если в командной строке путь к djvu файлу содержит кириллицу, то утилиты не видят файл.

Я сегодня как раз скомпилировал самые свежие на сегодняшний день исходники DjVuLibre (из CVS). Возьмите и попробуйте - будет ли там проблема с кириллицей? :

http://www.djvu-scan.ru/forum/index.php?topic=11.msg1183#msg1183

Если будет - сообщите. Кириллица должна быть в DOS-кодировке - если запускать из батника.

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

Буду иметь в виду, но не обещаю - т.к. Леон сам ничего делать не будет, он согласен только взять чужой патч. Кроме того, Леон как-то сказал, что он не хочет делать чересчур навороченный синтаксис ком. строки. В общем, тут как повезёт.
Автор: bolega
Дата сообщения: 13.12.2010 13:06
shch_vg

Цитата:
Если интересно

Интересно. Изучаю, в СК баг какой-то на этом примере.

monday2000

Цитата:
Я сегодня как раз скомпилировал самые свежие на сегодняшний день исходники DjVuLibre (из CVS)

Спасибо, попробую
Вчера еще с одним багом (?) djvused -f my.dsed мучался. На команду в desd-файле:
...бла-бла k:\test\test1045\f.djvu
создавался файл в корне с таким именем: k:\testtest1045f.djvu !! Если же в скрипт-файле были две аналогичные строчки, то 2-я команда вообще завершалась с выдачей якобы синтаксич. ошибки. Потом додумался заменить все "\" на "/" и все заработало как надо. Интересно, что такой выкрутас у меня вылез только в djvused. Вообщем, меня эта непредсказуемость djvulibre уже достает.
Автор: bolega
Дата сообщения: 14.12.2010 08:33
shch_vg
Баг нашел и исправил. Даже два. Один связан с черной зоной. Второй - с открытием pdf, кусок из которого Вы привели
Автор: monday2000
Дата сообщения: 14.12.2010 08:38
bolega

Цитата:
создавался файл в корне с таким именем: k:\testtest1045f.djvu !!

Вроде бы этот баг уже пофиксен в новом скомпилированном комплекте.
Автор: shch_vg
Дата сообщения: 14.12.2010 15:00
bolega
А нельзя ли сделать массовое удаление picture-зон?
Иногда требуется удалить все зоны, либо выше или ниже текущего разворота.
Автор: OlegZah
Дата сообщения: 14.12.2010 22:08
В черно-белой книге есть несколько страниц с цветными фотографиями. Как это лучше обработать для минимизации размера книги при сохранении качества?
Автор: shch_vg
Дата сообщения: 14.12.2010 22:43
OlegZah
Заключите цветное фото в picture-зону и задайте в свойствах зоны соответствующий color.
Автор: LVitek
Дата сообщения: 16.12.2010 19:48
bolega:
СК-5.93 из шапки
Создаю свой профиль:выравнивание страницы по горизонтали-центр,по вертикали-вверх.
Открываю задание,применяю свой профиль-в итоге:
выравнивание страницы по горизонтали-центр,по вертикали-автомат.
Это глюк или только у меня?
Ой,извиняюсь-авто,это и есть вверх.
Автор: LVitek
Дата сообщения: 20.12.2010 19:19
Скачал 10 книг в PDF(сканы не чищены),чистятся хорошо,но поподаются страницы с красной полосой,как убрать эти полосы?У меня что-то не получается.
Вот один разворот:
http://narod.ru/disk/1788818001/0031.tif.html
Источник здесь:http://www.all-ebooks.com/2010/07/24/128972-vkhozhdenie-v-rezhim-servisa..html
Автор: monday2000
Дата сообщения: 24.12.2010 08:34

Цитата:
но поподаются страницы с красной полосой

Вот скриншот:

А вообще - звучит как анекдот:

Цитата:
(bolega,как то писал,что его СК(не знаю какя версия)при конверте в PDF глючит и делает эти красные полосы)

Автор: bolega
Дата сообщения: 24.12.2010 11:38
LVitek

Цитата:
конверте в PDF глючит и делает эти красные полосы

Во-первых, СК глючил при импорте pdf, а не при его создании.
Во-вторых, красные полосы образовывались в области, не занятые сканом (когда в pdf страница состояла из нескольких лоскутков, пространство между ними и закрашивалось красным, т.к. из-за бага цвет фоновой закраски был красным вместо белого). И красный цвет был чистым.
Приведенный пример к глюкам СК никакого отношения не имеет. Видно, что красные полосы - это сосканированные полосы!! Они имеют неровные края, что-то вроде темной рамки, неравномерную прозрачность и т.п., характерное для скана.
Не надо пороть чепуху! СК тут ни при чем.
Автор: LVitek
Дата сообщения: 24.12.2010 11:38

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102

Предыдущая тема: мнение о Maxthon


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.