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

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

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

Widok (17-08-2007 15:16): лимит страниц. продолжаем здесь  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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

   

ghosty



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ScanKromsator: Знаменитый Кромсатор для обрезки получаемых при сканировании изображений, а также для разделения страниц, очистки от мусора и т.п. (есть FAQ). Автор: bolega. http://bolega.hotmail.ru/
 
Старые версии:
 
5.52beta (1,81 МБ) + dll-ки, необходимые для работы программы (405 КБ)
 
Full-версии - вкл. dll-библиотеки и Help к SK v1.0 в формате Pdf:
 
v3.5 (1,52 МБ)  v5.07 (1,98 МБ)  v5.51b (2,06 МБ)  v5.52b (2,05 МБ)  
 
Текущая версия:
 
ScanKromsator v5.6А Full (вкл. dll-библиотеки и Help к SK v1.0 в формате Pdf). (2,25 МБ) What's new  Зеркало
 
Хелп v1.0 для Кромсатора:
 
1. В формате PDF:
http://rapidshare.de/files/1815394/ScanKromsator.pdf.html (размещен временно):
 
2. В форматах HTM и DOC:
http://www.djvu-soft.narod.ru/sk_doc_htm_help_v1_0.rar  (537 КБ)
 
Вопросы и ответы по работе со СканКромсатором последних версий:
http://abab.front.ru/QandA_SK.zip (80 КБ, от 20.06.06)
 
Пособие по Кромсатору: http://www.djvu-soft.narod.ru/kromsator/
(Составлено на базе "Вопросов и ответов" + Хелп v1.0).  См. подробности.
 
ScanAndShare - инструкция в картинках, в том числе и начальные установки SK
1.03 или 1.06

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 12:53 17-05-2005 | Исправлено: vitaly1, 16:02 10-01-2007
Alexx S



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

Цитата:
Сделал мерцание спеклов, как просил shch_vg. На слабых компах лучше не использовать.

Неправда, это я просил!!!
Спасибо большое, а то с этими спеклами мистика какая-то. Последнюю книгу простматривал раза четыре, на разных масштабах, впролоть до 75% (при 600дпи) - и все равное, в готовой спеклы нахожу...
 
А будет в новой версии изменение размеров полей, о котором мы говорили? И Blur с  Denoise очень хотелось бы...

Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 13:12 21-07-2007
bolega

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

Цитата:
Неправда, это я просил!!!

Извините.
 

Цитата:
Спасибо большое, а то с этими спеклами мистика какая-то

У меня такая же история.
 

Цитата:
А будет в новой версии изменение размеров полей, о котором мы говорили?

Напомните, пожалуйста, на какой странице говорили.
 

Цитата:
Denoise

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

Всего записей: 4396 | Зарегистр. 09-09-2002 | Отправлено: 13:34 21-07-2007
Alexx S



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

Цитата:
Напомните, пожалуйста, на какой странице говорили.

Предложение здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=15877&start=1220#3
 
 

Цитата:
Его не будет, слишком пока медленный.  

 
Жалко... Меня бы устроил и десяток страниц в час, уж больно хорошо получается...
 

Цитата:
Все остальные фильтры уже включил

Все остальные - это очень  даже хорошо. Может, тогда пример сделаете с применением размытия и контурной резкости?

Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 17:05 21-07-2007
terminat0r



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

Цитата:
Потестирую еще 2-3 недели и тогда выложу новую версию (5.9) для всеобщего тестирования

йохохо и бутылка рома!
Ждем!

Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 20:26 21-07-2007
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Alexx S
 
По поводу Вашего предложения. Я пока не знаю как сделать обработку полей независимой от обработки.
См. также высказывание на упомянутой Вами странице:
ghosty

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

К этому следует добавить, что кромсатор иногда прибегает к помощи юзера для такого определения, я имею ввиду отключение automargina для какого-либо резака и выставления его вручную. Как быть в этом случае, я не знаю.
 
 
 
Добавлено:
То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой.

Всего записей: 4396 | Зарегистр. 09-09-2002 | Отправлено: 18:13 23-07-2007 | Исправлено: bolega, 18:21 23-07-2007
ghosty



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

Цитата:
То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой.
Я после отпуска пока не в силах выйти на столь высокий уровень абстрагирования Но первое, что приходит в голову: чтобы избавить пользователей от необходимости предварительного кромсания 10-20 страниц для определения "fixed" размеров, можно ввести функцию (что-то вроде) "Compute (Get) fixed width" и "Compute fixed hight" - кнопки рядом с соответствующими полями. При выполнении такой функции Кромсатор случайным образом составлял бы "репрезентативную" выборку из страниц, и вычислял соотв. размер, исходя из среднего арифметического по выборке и заданного пользователем разрешения апсемплинга.
То есть все расчеты проводятся без обработки.
Было бы хорошо ввести также "Compute fixed width/hight using..." -> selected /bold selected...

----------
пропадет-растает

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 18:52 23-07-2007 | Исправлено: ghosty, 18:53 23-07-2007
bolega

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

Цитата:
При выполнении такой функции Кромсатор случайным образом составлял бы "репрезентативную" выборку из страниц

Не пойдет, в эту выборку может попасть страница, состоящая из 2-3-х строк, которая из среднего арифметического сделает полную ерунду. Лучше тогда
Цитата:
"Compute fixed width/hight using..." -> selected /bold selected...

Если для этой выборки не делать выходных файлов (т.е. реально ничего не обрабатывать, а просто посчитать), то это можно сделать очень быстро. Только что потом делать с этими fixed, как убедиться, что они подходят для всех страниц.
 
Кроме того, Alexx S противник именно предварительного расчета fixed, он хочет, чтобы кромсатор сперва просто обрезал по резакам, не прибавляя полей. И только потом, после чистки, по команде искать контур, прибавлять поля и считать размеры. Поэтому я и говорю, что это равносильно и можно сделать просто двумя заданиями, убрав во 2-м задании все, что касается растровой обработки (всякие enhance, deskew, despeckle и т.д.).

Всего записей: 4396 | Зарегистр. 09-09-2002 | Отправлено: 19:21 23-07-2007
Alexx S



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

Цитата:
То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой.

 
Вроде да, все так... В сочетании с тем, что раньше говорилось:
 

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

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

Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 19:54 23-07-2007
ghosty



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

Цитата:
Кроме того, Alexx S противник именно предварительного расчета fixed

Да мы все тут противники, просто нужно решить, как с этим бороться

Цитата:
Не пойдет, в эту выборку может попасть страница, состоящая из 2-3-х строк, которая из среднего арифметического сделает полную ерунду.
Поэтому я и говорил о "репрезентативности". К примеру, так: из 100 страниц выбираются страницы с наибольшими размерами и разбросом этих значений меньше заданного, затем вычисляется среднее арифметическое. Хотя если попадутся одинаковые артефакты какие-нибудь на полях, которые одинаковым образом будут влиять на определение границы текста, может закрасться ошибка, но это как-то маловероятно...

Цитата:
Только что потом делать с этими fixed, как убедиться, что они подходят для всех страниц.
Да, но мы и в случае предварительного кромсания 10-20 страниц не можем гарантировать, что посчитали эти размеры правильно. Поэтому предлагаю убить двух зайцев сразу - отображать рассчитанную границу непосредственно на сырых сканах (сделав обратный перерасчет с учетом апсемплинга). Тогда можно будет увидеть, что будет отрезано, на каждой странице.

----------
пропадет-растает

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 00:52 24-07-2007 | Исправлено: ghosty, 00:52 24-07-2007
bolega

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

Цитата:
К примеру, так: из 100 страниц выбираются страницы с наибольшими размерами

Что есть наибольшие размеры? У меня например, все страницы при сканировании одного размера, а вот размер текста на них разный. Чтобы выбрать наибольшие размеры (не страниц, а контуров текста на них), придется все эти 100 страниц обработать. Тогда зачем вообще нужна выборка из них, нужно считать размеры по всем ста, раз уж они все обработались.
 

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

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

Всего записей: 4396 | Зарегистр. 09-09-2002 | Отправлено: 02:13 24-07-2007
ghosty



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

Цитата:
Чтобы выбрать наибольшие размеры (не страниц, а контуров текста на них), придется все эти 100 страниц обработать.

А что Вы тогда имели в виду в этом случае:
Цитата:
Если для этой выборки не делать выходных файлов (т.е. реально ничего не обрабатывать, а просто посчитать), то это можно сделать очень быстро.

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

Цитата:
Могу сказать однозначно: отображать контуры полей на исходных сканах я не буду.  
Нет, не надо. Опять забыл, извините.

----------
пропадет-растает

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 03:23 24-07-2007
U235

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

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

А если взять медиану?

Всего записей: 881 | Зарегистр. 14-12-2005 | Отправлено: 08:16 24-07-2007
bolega

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

Цитата:
А что Вы тогда имели в виду в этом случае

Это просто. Для определения контуров можно сделать как бы псевдо-обработку, используя упрощенные, но быстрые методы, т.е. fast rotate, fast resample, не сохранять файл на диск и т.д. Это заметно увеличит скорость обработки. Погрешность конечно это внесет, небольшую (3-5 пикселей), но для определения средних размеров это абсолютно несущественно.
Вопрос в другом: что дальше делать с этими fixed. И чем это лучше, например, того, что я использую часто - определяю fixed по первым 20-30 файлам. Только в данном случае я одновременно по выходным файлам могу убедиться, что подсчитанный fixed меня устраивает или нет. Если Вы скажете, что 1-й вариант имеет преимущества, то, я сделаю его. No problem.
 
U235
Примерно так и делается сейчас, только если страниц, которые по размеру отличаются от среднего в большую сторону, не очень мало (>5%), то кромсатор делает небольшую поправку к среднему
 
Я склоняюсь к такому решению: добавить команды "увеличить выходные размеры на столько-то" и "уменьшить выходные размеры на столько-то". С первым все просто. Со вторым сложнее - придется контролировать границы текста, и если есть угроза отрезания его, ничего не делать и метить такие файлы жирным.

Всего записей: 4396 | Зарегистр. 09-09-2002 | Отправлено: 10:31 24-07-2007
Alexx S



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

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

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

Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 11:15 24-07-2007
bolega

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

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

Это должно зависеть от значений v.align/h.align. Точку задавать не нужно.
 

Цитата:
В моем понимании, неплохо бы иметь это отдельной кнопкой - нажал, подождал какое-то время

Ага, часов этак 2-3 подождал... Господа, сканы - это же не векторный word в конце концов!

Всего записей: 4396 | Зарегистр. 09-09-2002 | Отправлено: 15:52 24-07-2007
ghosty



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

Цитата:
Я склоняюсь к такому решению: добавить команды "увеличить выходные размеры на столько-то" и "уменьшить выходные размеры на столько-то".
Эти команды могут быть выполнены на этапе постобработки?
Цитата:
Если Вы скажете, что 1-й вариант имеет преимущества, то, я сделаю его. No problem.
Если так, то почему бы не попробовать. Если этот вариант не будет давать сбоев, то оставим...

Цитата:
Только в данном случае я одновременно по выходным файлам могу убедиться, что подсчитанный fixed меня устраивает или нет.
Опять-таки только по выходным (обработанным) файлам. Вы говорили, насколько я понял, проблема состоит в невозможности проверить остальные страницы. После автоматического подсчета fixed размеров, можно их проверить на 2-5 файлах - но это же не 20-30...
С другой стороны можно предложить вот, что: две функции: "calculate fixed w/h fast" и "calculate fixed w/h with processing". Второй вариант предлагаю делать так: выбранные страницы обрабатываются не с пользовательскими настройками, а с самыми быстрыми, т.е. без лишних алгоритмов обработки, только апсемплинг, если есть, и тот по самому быстрому алгоритму. На полученных при этом страницах можно наносить надпись "Проба", чтобы человек не включил эти страницы в проект по ошибке, либо эти страницы сохранять в системную папку "TEMP".
Просто пытаюсь решить проблему, которая была поставлена не мной, на самом деле. Мне, к примеру, предварительная обработка 10-15 файлов нужна для того, чтобы еще раз убедиться, что установлены оптимальные параметры обработки.

----------
пропадет-растает

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 15:56 24-07-2007
Alexx S



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

Цитата:
Ага, часов этак 2-3 подождал... Господа, сканы - это же не векторный word в конце концов!

Да это понятно, но можно некоторые трудоемкие задачи исключить - тот же апсемплинг, к примеру.
 
Да и вообще, предложение звучало совсем по другому. Да, заранее посчитать ширину страницы было бы не прлохо, но обычный алгоритм дейсвий такой
1. Кромсаем
3. Поворачиваем
4. Апсемплинг
5. Бинаризуем
 
На всех этих этапах нам поля не важны совершенно, мы занимаемся вопросами обработки, поля же - это уже этап оформления книги.  
Во время выполнения этих этапов мы и собираем иформацию для определения ширины страниц. На данный момент кромсатор сам определяет ширину страницы, я в это вмешаться не могу.  
Вот и хотелось бы, чтобы на предварительных этапах осуществлялся сбор информации, после чистки информация уточнялась бы по упрощенным методам (я почистил мусор, это надо учесть) и пользуясь этой информацией я бы сам определял результирующий размер страницы. Опять же, пиксели это одно, а реальная книга другое. Поэтому и поля хотелось бы менять на лету. Опять же, анализа никакого не надо - все уже есть.
 
 
Добавлено:
ghosty
Ответь, плз на личку

Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 16:28 24-07-2007
bolega

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

Всего записей: 4396 | Зарегистр. 09-09-2002 | Отправлено: 16:46 24-07-2007
ghosty



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

Цитата:
Если же окажется, что полученный размер все-таки не удовлетворяет, то наличие команды по изменению размеров уже обработанных файлов думаю полностью снимет проблему.
Если такая команда будет, и если это не приведет к ошибочному отрезанию блоков текста, то да, снимет.  
Хотя сомнения остаются. Например, увеличение/уменьшение размеров должно производиться не просто так, а с учетом заданных пользователем параметров Page h/v align, правильно? Наверно, будут и еще какие-нибудь проблемы, если fixed размеры определены были неверно. К примеру, человек задал слишком большую fixed width и h. align = L. В этом случае поля будут смотреться некрасиво - слишком ассиметрично. Тогда было бы хорошо как-то исправить эту оплошность на этапе постобработки, т.е. изменять размеры полей не равным образом относительно блока текста, а со сдвигом, чтобы поля стали симметричными...
Я с такой проблемой сталкивался не раз.
 
Добавлено:
Alexx S

Цитата:
Ответь, плз на личку
Приехав, обнаружил много писем в личках, имейлах и т.п. Разбираюсь понемногу
 
Добавлено:
В версии NY в функции Process half-page - баг: обрабатываем половинку, затем переходим на любой файл выше в списке, снова обрабатываем половинку. При этом обрабатывается файл, обработанный ранее.

----------
пропадет-растает

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 17:02 24-07-2007 | Исправлено: ghosty, 17:11 24-07-2007
ghosty



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Маленький обучающий ролик о том, как бороться с подчеркиваниями при помощи Кромсатора. Будет интересен как новичкам, так и, возможно, опытным пользователям. Вначале применяется Auto-Clear (чтобы "отцепить" линию от буквы), затем Ctrl-Shift-Click по линии, которую следует убрать.
URL1: http://rapidshare.com/files/44788648/Kromsator.rar.html
URL2: http://rapidshare.com/files/44803886/Kromsator.zip.html

----------
пропадет-растает

Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 21:54 24-07-2007 | Исправлено: ghosty, 23:22 24-07-2007
   

Страницы: 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

Компьютерный форум Ru.Board » Компьютеры » Программы » ScanKromsator СканКромсатор
Widok (17-08-2007 15:16): лимит страниц. продолжаем здесь


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

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru