» Scan Tailor

cuneiform

Цитата:

ВСЕ БИБЛИОТЕКИ МИРА ОТ НЕГО ОТКАЗАЛИСь.

Как Вы громко и смело говорите за все библиотеки мира
Зайдите на Archive.org - это коллектор для книг из разных библиотек мира, обработанных по проектам Google и Microsoft. Там книги доступны в нескольких форматах - многостраничном TIFF, PDF и DJVU.

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

АBBYY напр. сделала прогу из Файнридера для ОЦР готики. Условия: 25000 сканов по счетчику за 8000 чего то там (долларов, евро). Кто будет пользоваться? - Я таких библиотек не знаю.

Потом пошли под сумашедшие деньги президентские проекты - В США и Европе. Видно, кое-что перепало и Лизард'y.

Но библиотеки остаются на ПДФ. Это же легко проверить.
Да и Вы ведь тоже читатель какой-нить библиотеки. И много там дежавю, сорри?

Кста, наша университетская биб-ка купила новый дорогущий станок-сканер. Дык там тока ПДФ.

Я НЕ заводил речь о том что НУЖНО выводить в pdf при помощи st!!

Я лишь отметил что pdf из нескольких jpeg сделать несложно
Изначально хотел попробывать собирать pdf из полноцветных и 1bit слоёв (jpeg2000+jbig2)

cuneiform
Разницы между Lossless 1bit форматами с точки зрения пользователя будь то jb2,jbig2,CCITT Group 4 очень сомнительны и не очевидны. Скорее претензии предъявляются не столько к методу сжатия, сколько к контейнеру c его возможностями(pdf/djvu) и удобству просмотрщика.

И судя по тому что вы говорите

Цитата:

При просмотре во вьюере (ч./б.) цвет легко восстанавливается через 8-12-бит серое (XnView), стабильное лого, малый размер файлов - почти как дежавю. Легкая пакетная обработка. Public domain.
Мнение свое не навязываю. - Во время массового психоза разум слабо работает, факт.

через продолжительное время вам будет стыдно за эти высказывания.
"Мнение свое не навязываю."

ndch
Вопрос: а какой программой (win32) Вы собираетесь сконвертировать результаты вывода ST (TIFF) в jbig2?

Цитата:

сколько к контейнеру c его возможностями(pdf/djvu)

Вот именно, контейнер также может содержать текстовой слой, оглавление и др. вкусности, в отличие от чисто графических форматов.

U235
Лично я, на данный момент - Adobe Arobat 9 pro (jbig2 - по умолчанию в настройках для однобитных ч.б.)
Можно indesign, возможно CVista PdfCompressor. Смотреть надо, разбираться.
А в чём сложность ?

В eBookz перетирают одно и тоже (относительно jbig2)- упаковка множества страниц (как одной) c большим словарём. Пока что мне это не интересно. Я не в восторге от примерения такого рода архивов в повседневной жизни. Мне вообще нравится высокоскоростное извлечение. В этом смысле rar -m0 -mda проигрывает pkzipc -lev=3.
Да, скорее всего размер пострадает.

На данное время разбираюсь, как пользователь, с возможностью создания многослойных pdf с возможностью "подцвечивания" каждого слоя "однобитный" изображений - бывают малоцветные изображения (черный и пурпурный на белой бумаге)

Руборд на счёт этого читать не собираюсь. Прочитав полностью топик "Андеграунд » eBookz » Электронные книги: сканирование, обработка, сборка " за последние 5 лет (5657 сообщений), так и не увидел чтобы кто-то с этим разобрался.

Меня больше всего огорчает что arcobat reader и аналоги не умеют рендерить pdf состоящий из progressive jpeg/jpeg2000 во время быстрого листания не полностью (как браузеры рендерят progressive jpeg проход за проходом). Очень грустно.
С этой фишкой листание pdf'а - было бы сказкой.

ndch

Цитата:

На данное время разбираюсь, как пользователь, с возможностью создания многослойных pdf с возможностью "подцвечивания" каждого слоя "однобитный" изображений - бывают малоцветные изображения (черный и пурпурный на белой бумаге)

Именно так создает pdf сканкромсатор (так называемые раскрашенные зоны) - зона (слой) помещается в pdf как 1-битная, а раскрашивается уже средствами самого pdf. Луше один раз прчитайте спецификацию pdf, и тогда вопросов у Вас поубавится. Будете знать, что pdf умеет, и отталкиваясь от этого, искать "пользовательские" методы реализации

ndch

Цитата:

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

Через продолжительное время нас с вами не будет, так что этот Ваш вариант не имеет смысла вообще. А только вариант здесь и сейчас имеет реальное актуальное значение.

Так что здесь все сотрясают воздух только в своих личных интересах, не более.

Даже ЕС и США до сих пор отсканировав миллионы и миллионы книг, порядка 36-38, нерешили 2 основные проблемы (в порядке их очевидной важности): 1/ проблема авторских прав, 2/ проблема носителей информации - пока нет окончательных решений и более ничего тут сказать нельзя.

Тем более не может просто быть никаких однозначных решений по форматам файлов.
С чем я всех и поздравляю. Аминь.


Добавлено:
ghosty

Цитата:

Там книги доступны в нескольких форматах - многостраничном TIFF, PDF и DJVU.

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

Author: Creighton, James Edwin, 1861-1924
Subject: Logic
Publisher: New York The Macmillan company
Possible copyright status: NOT_IN_COPYRIGHT
Language: English
Call number: AAA-4602
Digitizing sponsor: MSN
Book contributor: Robarts - University of Toronto
Collection: toronto

Copyright-evidence-operator: Marlete Kurten
Copyright-region: US
Copyright-evidence: Evidence reported by Marlete Kurten for item introductorylog00creiuoft on March 19, 2008: no visible notice of copyright; stated date is 1898.
Copyright-evidence-date: 20080319201915
Scanningcenter: uoft
Mediatype: texts
Identifier: introductorylog00creiuoft
Imagecount: 438
Ppi: 400
Camera: Canon 5D
Operator: scanner-james-stevens@...
Scanner: scribe19
Scandate: 20080320001725
Identifier-access: http://www.archive.org/details/introductorylog00creiuoft
Identifier-ark: ark:/13960/t1mg7nc1d
Bookplateleaf: 0010
Scribe: 2
Sponsordate: 20080331

Судя по этому документу (!) формат файлов вообще никого не интересует.

bolega
Я и читаю потихоньку PDF32000_2008.pdf и adobe_supplement_iso32000.pdf
но чтоб прочитать 756 + 140 страниц нужно время. Возникают насущные вопросы - пытаюсь реализовать их решение. Было бы много свободного времени - другое дело.
Кромсатор запускал 2 раза в жизни. Не моё. Я тупой. ;)

Добавлено:
Создал сегодня pdf jpeg2000+jbig2. Понял: ROI играет весьма значительную роль.
Судя по всему, при помощи scan tailor и acrobat сделать компактный (сопоставимый c djvu) pdf не получится.
Либо ждать пока Acrobat поумнеет, либо менять его на что-то другое.

Меня тут потянуло на улучшения юзабилити, вместо реализации высокоприоритетных задач. В результате переделал управление пакетной обработкой и добавил индикацию фоновой активности. Объем работы в итоге получился весьма значительным - это я говорю для monday2000, который считает, что программы вроде ST и SK практически полностью состоят из алгоритмов обработки изображений.
Теперь я думаю никому в голову не придет запускать пакетную обработку последовательно на всех стадиях. И руководства читать не надо.

По поводу визуальных аспектов. Я не совсем доволен кнопками запуска и остановки пакетной обработки, но лучше ничего не нашел. Кнопки нужны были польностью стилизованные - то есть не просто иконка, а вся кнопка в нормальном состоянии, при наведении на нее мышки, и в нажатом состоянии. Лучшее что нашел (точнее единственное приемлемое) - кнопки от плеера Amarok, которые в векторном формате (что хорошо), но там есть только варианты для нормального состояния. Нажатое и наведенное состояния сделал соответственно затемнением и осветлением исходного изображения. Кто может сделать лучше - вперед. Исходные иконки можно взять тут.

Кстати номер ревизии - 316.

Tulon

Цитата:

Кстати номер ревизии - 316

Пока сборок не будет, случайно поставил не ту версию MinGW видимо из-за этого не собирается... Вечером буду разбираться.
Разобрался.

Tulon

Цитата:

это я говорю для monday2000, который считает, что программы вроде ST и SK практически полностью состоят из алгоритмов обработки изображений.

Вообще-то я не совсем так считаю. Я думаю, что самое главное - это графический движок. А алгоритмы - всё же гораздо проще - потому что они по большому счёту уже где-то есть и их можно просто передрать.
Мне один человек сказал, что под Делфи есть несколько коммерческих библиотек, где графический движок уже есть готовый. Интересно - есть ли такой движок в ImageLib - библиотеке, используемой в СК? И как это Билл Гейтс не догадался сделать такой класс в MFC - аж обидно... Сейчас бы горя не знали, а альтернативы СК появлялись бы пачками...

Цитата:

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

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

Скроллбары - это очень важно, без скроллбаров Вам никогда не догнать СК.

Tulon
24 x 24 пикселей это понятно.
Но 129 x 129 пикселей ?!

Цитата:

24 x 24 пикселей это понятно.
Но 129 x 129 пикселей ?!

А там пофигу сколько. Эта кнопка просто должна быть достаточно большой - в конце концов ничего кроме нее в центральной области в режиме пакетной обработки не будет. А как получилось 129 x 129 - очень просто: открыл SVG файл в Gimp с дефолтными размерами холста, сделал на эту кнопку инструмент "выделение связанной области", предварительно понизив чувствительность, потом копировать и вставить как новое - получилось как раз 129 x 129. Посмотрел в масштабе 100% - нормально. Короче точный размер для этой кнопки не принципиален.

monday2000

Цитата:

Скроллбары - это очень важно, без скроллбаров Вам никогда не догнать СК.

Улыбнуло,
Расскажите лучше, в каких именно ситуациях вы ими пользуетесь. Мне например и драг-то крайне редко нужен, а уж скроллбары и подавно.


Цитата:

Я думаю, что самое главное - это графический движок.

Графический движок - понятие растяжимое. Одно дело просто рисование, другое - манипулирование объектами, что тоже понятие растяжимое. В Qt для рисования - QPainter, для манипулирования объектами - QGraphicsView, который я кстати только для ленты предпросмотра использую, а в центральной зоне все манипулирование вручную реализовано. И надо сказать, что ни в плане сложности, ни в плане объема работ эта часть особо не выделяется.
Мнение о том, что все алгоритмы уже где-то реализованы и доступны в open source - тоже ошибочно. Даже те, принцип которых описан в литературе - далеко не всегда можно найти. Построение полиномиальной поверхности - пришлось делать самому, Двухмерный Savitzky-Golay - тоже, А некоторые алгоритмы приходится самому изобретать, как например алгоритм выделения рамки контента или новый хитроумный Despeckle.

Добавлено:
Кстати вот еще одна библиотека компьютерного зрения для коллекции monday2000:
http://gandalf-library.sourceforge.net/
Автором оказался мой шеф на новой работе.

Tulon

Цитата:

Улыбнуло,
Расскажите лучше, в каких именно ситуациях вы ими пользуетесь.

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

Цитата:

Графический движок - понятие растяжимое.

Я под этим понятием подразумеваю способность программы визуально отображать битмапы, зуммировать их при вращении мыши, прокручивать при скроллировании, сглаживать изображение, предоставлять скроллбары для прокручивания. Зуммирование - многопоточное, т.е. колёсико крутанул, а битмап потом в отдельной нити с некоторым опозданием шагами "дозуммируется" до нужного масштаба. При этом, разумеется, никакого противного моргания-мерцания и головокружения как следствие.
Именно такой графический движок имеется в СК (не считая возможности наложения Cope-Paste). Имеется ли в точности такое же в Qt (т.е. уже готовое)? В Visual C++ 6.0 ничего подобного нет. Вроде бы и в Borland C++ и в Borland Delphi точно такой штуки тоже нет.
А в каких-то делфийских коммерческих библиотеках ЭТО имеется. Так вот, отсутствие именно такого графического движка-программного компонента ИМХО и есть главный и единственный камень преткновения на пути массового создания народом альтернатив СК. Допустим, был бы такой графический движок в виде простого в использовании MFC-класса - аналогично CScrollView и пр. - то изготовление альтернативы СК стало бы доступной реальностью.

Цитата:

Мнение о том, что все алгоритмы уже где-то реализованы и доступны в open source - тоже ошибочно. Даже те, принцип которых описан в литературе - далеко не всегда можно найти.

Возможно. Но с алгоритмами всё-таки нет такой полной безнадёги, как с графическим движком. Потом многие алгоритмы взаимозаменяемы - т.е. как-то можно "крутиться" - нет одного - берёшь другой. А вот без движка вообще никуда не попрёшь.

Сейчас проинсталлировал себе из любопытства коммерческую библиотеку ImageLib 6 (на базе которой работает СК) http://djvu-soft0001.nxt.ru/imagelib_corp_suite_6_0.rar (9.20 МБ). Попробовал почитать хелп. Вроде бы там есть уже некий готовый программный компонент для загрузки-отображения битмапов - называется "TPMultiImage". Вот что про него там в доке написано:

Цитата:

TPMultiImage displays and stores PCD, DXF, BMP, CMS, GIF, ICO, JPG, PCX, All TIFFs, PNG, SCM, and WMF (PCD, DXF and WMF are read only) to/from a file. TPMultiImage is a data-aware VCL. TPMultiImage is derived from TCustomControl and has the same properties as Delphi’s TImage.

To load in an Image use PmultiMedia1.ImageName:=MMOpenDialog1.Filename;

More questions and answers (Over one thousand messages at the time being) can be found on news://skylinetools.com
. A few are listed here SkyLine News Group Topics

Вот кое-что по этому компоненту из Яндекса:
Форумы по C++ Builder -> Работа с GIF
http://www.rxlib.ru/forums/index.php?act=ST&f=3&t=9365

Если предположить, что этот компонент "TPMultiImage" и есть готовый к применению графический движок - то тогда это и объясняет ту относительную простоту и быстроту, с которой был создан СК (bolega писал, что он проболел месяц и за это время создал Split - прототип SK 1.0). Потому что, если бы bolega стал бы создавать такой графический движок с нуля - то на это ушли бы многие месяцы кропотливого, нудного, мучительного труда (именно поэтому такой движок никто или почти никто пока бесплатно не создал).

Нет ли здесь специалистов по Делфи или Борланд СИ? Хотелось бы понять, что из себя представляет этот "TPMultiImage", действительно ли его можно назвать "графический движок" или нет и т.п.

Итак: первый баг, относящийся к нововведениям

monday2000

Цитата:

Представьте, что Вам нужно на большом зуме прокрутить скан снизу доверху. Элементарный здравый смысл подсказывает, что скроллбары здесь вне конкуренции.

Чтобы такое представить, нужно знать, зачем это нужно. Например при ручном исправлении наклона это не нужно - там zoom in, zoom out и drag используются, не говоря уже о том, что ручное исправление наклона само по себе крайне редко нужно.


Цитата:

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

Слишком специализированная задача. Например высококачественный рендеринг в отдельном потоке нужен только для очень больших пиксельных размеров. В готовом виде вы такое вряд-ли найдете, но сделать все это средствами Qt - неделя работы и от силы пара тысяч строк кода. Капля в море по сравнению с 50 тысячами строк в СТ. Я даже сейчас поточнее сосчитаю, сколько строк кода ушло на это в СТ. Итак:
ImageViewBase.h: 363 строки
ImageViewBase.cpp: 876 строк
BackgroundExecutor.h: 69
BackgroundExecutor.cpp: 163
imageproc/Transform.h: 68
imageproc/Transform.cpp: 455
Итого: 1994 строки

Есть правда еще кое-какой код, который нужен только для Linux - а именно ручное обращение к XRender и шаманство с клиппингом, которое при этом необходимо. Но в общем и целом - все равно капля в море.


Цитата:

Возможно. Но с алгоритмами всё-таки нет такой полной безнадёги, как с графическим движком. Потом многие алгоритмы взаимозаменяемы - т.е. как-то можно "крутиться" - нет одного - берёшь другой. А вот без движка вообще никуда не попрёшь.

Пишешь свой за неделю. Не с нуля конечно, а на базе QPainter, или там скажем Cairo. Но движок-то пишется один раз, а алгоритмов надо много.




Добавлено:
ndch

Цитата:

Итак: первый баг, относящийся к нововведениям

Это вы про то, что на стадию вывода вас не пускают, а кнопка все равно активна? Или про странное отображение номера этапа?

Добавлено:
Я кстати разобрался, почему иконка в исполнительный файл не встраивается. Оказывается автоматическая обработка rc файлов просто не реализована в CMake для платформы MinGW. Для MSVC - есть. для MinGW - нет. Придется вручную это делать - создавать custom command, вызывать windres.exe, и все такое. Сложно все это вслепую делать - не имея доступа к винде. Буду ждать пока либо новый ноут куплю, либо пока кто-то другой это реализует.

Tulon
Количество строк - это не всегда есть показатель сложности. Порой и однотипные по сложности вещи занимают кучу строк - что относительно несложно. Количество строк - это зачастую показатель трудоёмкости, а не сложности - что разные вещи.

А и 5-10 строк могут быть настолько сложными, что потребуется месяц, чтобы догадаться, что там написать - особенно если речь идёт о недокументированных особенностях стандартных функций, где нужно просто догадаться за счёт метода тыка, что к чему.

Цитата:

Чтобы такое представить, нужно знать, зачем это нужно.

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

Tulon

Цитата:

Сложно все это вслепую делать - не имея доступа к винде.

Может, в виртуальную машину поставить? (Хотя, наверное, этот способ рассматривался и по каким-то причинам не подошел)

Tulon
Добавил 3 скриншота в предыдущий пост
Глюк таков: появляется scrollbar. Совершенно вредный.


Цитата:

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

Не уверен что все так, как кажется.

windres.exe scantailor.exe

windres.exe: scantailor.exe: no resource section
Или windres к объектнику нужно применять ?

Добавлено:
Bug #2

Непереведено

Добавлено:
StageListView.cpp

btn->setStatusTip(tr("Launch batch processing"));

monday2000

Цитата:

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

Резак точно установить - согласен, скроллбар был бы кстати. Ластика пока нет, ручного выделения объектов - тоже. Когда появятся, может и скроллбары добвлю. В любом случае есть гораздо более приоритетные задачи.

Добавлено:
estimated

Цитата:

Может, в виртуальную машину поставить? (Хотя, наверное, этот способ рассматривался и по каким-то причинам не подошел)

Тут у меня архитекрура другая - старый iBook, еще до перехода на Intel. В принципе для PowerPC Маков когда-то существовал эмулятор Интела - старые версии VirtualPC. Но эмулировать другую архитектуру при 933 мегагерцах - занятие для мазохистов.

Добавлено:
ndch

Цитата:

windres.exe: scantailor.exe: no resource section
Или windres к объектнику нужно применять ?

windres компилирует файл ресурсов в объектный файл. В Visual C++ этим занимается утилита rc. Так вот rc CMake поддерживает, а windres - нет. Так что приходится писать ручные правила для сборки файлов ресурсов.


Цитата:

Launch batch processing.
Непереведено

Ага, забыл.




Добавлено:

Цитата:

Глюк таков: появляется scrollbar. Совершенно вредный.

Мда. А ведь там есть код, специально предотвращающий появление этого скроллбара. Он там с самого начала, или появляется потом? Если потом, то когда именно?

Tulon
Берите ноутбук, будете на нём читать электронные книги.

Tulon
Scrollbar появляется при первом "запуске batch"

Насколько могу судить- возникает потому что "графа" стадии 1 "Исправление ориентации" высотой 22 пикселя, а нововведённые изображения высотой 24 пикселя. На что весьма скользко намекал.
Imho, вариантов два:
1.Увеличить высоту минимальной графы до высоты картинки.
2. Уменьшить высоту картинок до высоты минимальной графы.
Честно говоря, замето это еще на первом скриншоте.

Цитата:

Насколько могу судить- возникает потому что "графа" стадии 1 "Исправление ориентации" высотой 22 пикселя, а нововведённые изображения высотой 24 пикселя.

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

-

Разрешите внести свои две копейки.
Недавно опробовал ST, очень понравилось. Огромное спасибо за программу! Есть, наконец, средство, которое не надо объяснять неделями. И встроенные алгоритмы отличные. Но есть несколько вещей, которые бы хотелось улучшить или добавить.
Во-первых, здОрово было бы на этапе распознавания цветного/черно-белого (Смешанный режим) добавить возможность вывода в два файла (один -- черно-белый, другой -- соответствующий ему цветной, как "sep-файлы" в СК), чтобы потом мочь кодировать в DjVu по отдельности, скажем, "методом разделенных сканов". А еще, сам процесс распознавания цветного нельзя никак регулировать -- может быть, можно здесь можно добавить какой-нибудь движок?
То, что файлы нельзя из проекта убрать, не очень удобно. У меня три страницы были (случайно, такие файлы прислали) вдвое больше остальных, и остальные страницы хотели по ним выравниваться. Правда, я нашел выход -- поменял размер в IrfanView, но убрать их и потом запустить отдельно было бы удобнее.
Жалко, что нельзя добавить уже разрезанные-повернутые-макетированные с полями страницы, обязательно надо либо менять поля, либо даже определять полезную область. А если требуется _только_ вывод (увеличение разрешения-сглаживание)? Я попытался определить полезную область автоматически, но автомат не берет номера страниц, а проходить 500 страниц руками -- понятная морока (и обязательно что-то пропустишь). И макету нельзя сказать, чтобы брал страницы "как есть"... Так в результате и бросил этот гигантский PDF, а жаль.
Не будет ли отдельного despeckle? У меня много черно-белых сканов, которые я по лени вообще не пропускаю через кромсатор, а только обрезаю в ирфане, и сразу в DjVu. Было бы здорово удалять из них мусор. Может быть, ST сможет? СК может.
Планируется ли исправление перспективы? Выпрямление строчек?

Цитата:

The OpenJPEG library is an open-source JPEG 2000 library developed in order to promote the use of JPEG 2000.

http://code.google.com/p/openjpeg/

iit512
>>возможность вывода в два файла.
>>чтобы потом мочь кодировать в DjVu по отдельности
Это обсуждалось в ebookz. По наблюдениям пришли к выводу- учиться пользоваться сегментером софта(DEE)

Цитата:

По наблюдениям пришли к выводу- учиться пользоваться сегментером софта(DEE)

А какой-нибудь внятный текст есть на эту тему (на русском или английском)?