Оцифровка книг, опыт работы под линуксом
В этой заметке я постарался собрать и обощить свой опыт сканирования и оцифровки книг под линуксом.
Базовые материалы по теме можно посмотреть здесь.
Железо
Про выбор сканера в интернете написано много больше и лучше меня, поэтому просто перечислю что у меня было и как оно работало.
Если вы сканируете книги редко, по паре в год, то в принципе вам подойдёт любой бытовой сканер. Качество результата зависит больше от самой книги, а не от сканера: книгу в твёрдом переплёте с широкими полями сканировать намного удобнее, чем клееный покетбук в мягкой обложке с полями 3-5 мм. Скажу больше, в последнем случае вам не поможет даже специализированный планшетный сканер, это работа для "боевых марсианских треножников" или для специализированного фотосканера.
Как и всякий начинающий оцифровщик, начинал я с первого попавшегося под руку железа. "Сканирует? Сканирует. Значит подойдёт", -- думал я тогда. И действительно, если ваши потребности не больше пары книг в год - этого вполне достаточно. Смутно помню, что это был древний Mustek BearPaw. Из достоинств таких бытовых сканеров - низкая цена и широкое распространение, основной недостаток - они предназначены для сканирования распечатанных документов A4 поштучно, и не более.
При сканировании, с одной стороны, из-за довольно хлипкой пластиковой конструкции сканера, сильно давить на него нельзя (в лучшем случае заест каретку, в худшем треснет корпус или стекло), не давить - тоже нельзя, иначе область у корешка книги превращается в мыло или сплошную чёрную полосу, т.к. CIS. Но если вы можете себе позволить посидеть лишних пару часов, переделывая кривые/неудачные сканы страниц, и если управитесь с одной книгой за пару выходных - можете считать, что это "довольно быстро".
Однако объёмы сканирования росли, и затрачиваемое время также росло пропорционально этому. Кроме того, выяснилось, что некоторые книги на CIS сканировать просто невозможно, без их расшивки на листы - это те самые покетбуки с мягкой обложкой. Если пойти путём их расшивки, то минусы очевидны: книга фактически уничтожается, желательна гильотина для обрезки корешка, желателен отдельный потоковый сканер для сканирования листов пачкой, или же резко возрастает количество ошибок: перепутанные/пропущенные/дублирующиеся страницы. Поэтому встал вопрос замены сканера на что-нибудь с CCD-сенсором.
Поскольку объёмы сканирования ещё были относительно малыми - 2-3 книги в месяц, на барахолке был присмотрен почтенного возраста Epson Perfection 12XX, с поддержкой sane на уровне "Complete", и торжественно притащен домой на замену. Достоинств у него ровно три: добротный корпус, на котором можно чуть ли не ногами стоять, не заедает, в отличие от старого, и тот самый ГРИП, который позволяет относительно безгеморно сканировать область у корешка книги. Зато недостатков... Главный - это эпически медленное время сканирования - 48 секунд на страницу, на которое я как-то не обратил внимания при покупке. Будете на нём работать - нехило разовьёте способность ждать. Не самая большая книга в 300 страниц - 150 разворотов - по минуте на страницу - примерно 3 часа времени. Что-нибудь формата A3 и такого же объёма - 6 часов.
Ещё одна проблема - с лампой подсветки. Со временем она начинает выгорать, поэтому едет цветопередача, и в принципе требует времени на разогрев. Отошёл налить чаю? Подожди потом ещё две минуты, пока лампа опять включится, и сделай два-три прохода сканирования по минуте, чтобы получить картинки с относительно правдоподобной цветопередачей. Вобщем, сканер для тех, кто никуда не торопится.
Да, после замены у меня появилась возможность сканировать всё, но в то же время я сильно потерял в скорости самого сканирования, поэтому счастье не наступило. Хороший и быстрый CCD сканер стоит уже порядка 10-12 тысяч, что по стоимости приближается к специализированным книжным сканерам начального уровня, вроде Microtek XT3300.
Параллельно были эксперименты с наличным фотоаппаратом-цифромыльницей, можно ли его приспособить в роли фотосканера. Краткие итоги, да, можно, НО: будьте любезны построить для него штатив, колыбель с прижимным стеклом для книги, организовать равномерное освещение, да и сам фотоаппарат тоже желательно сменить. В идеале нужно управление с компьютера, ручной фокус, оптику с минимальной "бочкой" и точное позиционирование самого фотоаппарата по нормали к фотографируемой странице. Это обойдётся тысяч в 20 за сам фотоаппарат с требуемыми характеристиками, ещё тысяч десять на обустройство самого рабочего места, а что самое печальное - будет давать примерно такое же качество, как на обычном бытовом CCD-сканере для ч/б страниц, и худшее - для цветных. Зато с такой вундервафлей на порядок быстрее проходит сам процесс "сканирования" - просто перелистывать книжку в раскрытом положении "лицом вверх" и то же самое, но "лицом вниз" - две большие разницы.
В итоге, помучившись с epson'ом ещё годик, на распродаже со скидкой был куплен Plustek OpticBook 3600, и на данный момент он меня в целом устраивает: быстр, удобен, позволяет сканировать книгу "с угла". Из недостатков: драйверов под линукс нет даже в проекте, а на самом сканере в щель между стеклом и корпусом очень быстро попадает пыль.
В целом, если собираетесь заняться оцифровкой книг, на первое время работайте с тем что есть под рукой, если процесс понравится - подумайте о покупке спецсканера, сэкономите много времени и нервов.
Софт для сканирования
Под линукс у вас есть три основных варианта:
"Консольный": sh "while true" + scanimage (из sane-utils). Даёт широчайшие возможности кастомизации, но вместе с тем неудобен - как минимум превьюшку отсканированного надо велосипедить самостоятельно, управление, автонумерацию отсканированного и прочие плюшки - тоже. В результате получается строго специализированный и весьма развесистый велосипед, которым можешь пользоваться только ты лично.
"XSane": обладает страшным визуально и неудобным интерфейсом из нескольких окон, тем не менее свою работу выполняет. Все настройки рядом, пакетное сканирование есть, если приноровиться с интерфейсом - работать можно. Непонятно какой ментальный инвалид придумал эту концепцию "многооконного интерфейса", но здесь её довели до абсурда: каждый сраный тулбар - это отдельное окно.
"simple-scan": это утилита писанная гномерами для гномеров в их фирменном стиле "однокнопочного интерфейса". Настройки куцые и неполные. Если ты не попал "типовой usе-case" в их понимании, готовься к боли и страданиям. Так например, там до сих пор нет режима сканирования "grayscale", мотивируют тем, что "вы можете его сделать из цветного скана самостоятельно" (всю жизнь мечтал сделать это руками для 50-100-200 сканов, ага). В старых версиях сохранить сканированное можно только один раз (сейчас исправили). До сих пор не умеет экспорт в tiff ни в каком виде, jpg (с потерями), png (lossless) и pdf/jpg (тоже с потерями). Из достоинств - простой интерфейс, live-превью, пакетное сканирование, быстрый поворот картинки (применяется и для следующих сканов). Иногда встречаются вылеты всей программы, такое было неоднократно на прошлом сканере, который любил физически заедать при сканировании.
Про "родной" софт plustek'а под винду нужно сказать отдельно. Как программа именно сканирования, он может заменить популярный VueScan, но большего от него ждать не надо. Про автокроп, повороты страниц и прочие плюшки забудьте сразу: работают они так, что лучше бы их не было вовсе. Перевод на русский - кривейший промт с опечатками, как на алиэкспрессе. Множество бестолковых функций, добавленных чисто по требованию маркетоидов, типа "отправки сканов на email". Множество функций, которые ведут себя не так, как ожидается, например при сохранении в tiff есть два варианта: "uncompressed" и "compressed". С первым всё понятно, а вот второй на самом деле - не "compressed", а "lossy", т.е. "сжатый с потерями" и не tiff, а jpeg(!) в контейнере tiff. Очевидно, ни писавший софт индус, ни составители техзадания явно не знали специфику применения этого сканера.
Также, драйвер сканера сильно завязан на "родной" софт - если хотите пользоваться кнопками на корпусе, то запускают они именно его, и переопределить это никак нельзя. В других приложениях кнопки не работают.
Форматы
Для сканирования и всех операций со сканами, по моему опыту удобнее всего tiff. Не мылит (в отличие от jpeg'а), умеет многостраничность (в отличие от png), легко собирается/разбирается на страницы, имеет большое разнообразие режимов хранения картинки (bilevel, gray, indexed, color), имеет возможность сжатия данных разными алгоритмами (как с потерями, так и без). Вобщем, может прикидываться почти любым форматом с любыми необходимыми параметрами.
К сожалению, его многостраничность плохо поддерживается разнообразным софтом для просмотра изображений - даже хуже анимированных gif'ок. Видимо это связано с тем, что необходимо реализовывать второй режим просмотра - покадровый, в дополнение к пофайловому и этим никто не заморачивается.
Из вышеперечисленного софта под линукс, первые два умеют сохранять сразу в tiff, с simple-scan лучше сохранять в png, иначе он выдаст pdf/jpeg с мылом (ни степень сжатия jpg, ни альтернативные форматы хранения внутри pdf не настраиваются, гномософт как он есть).
Для работы непосредственно с форматом потребуется libtiff-tools. В принципе их достаточно для всех частоиспользуемых операций: собрать/разобрать многостраничный файл (tiffcp/tiffsplit), перевести в grayscale (tiff2bw) и bilevel (tiffdither), посмотреть информацию о файле (tiffinfo).
Отдельно обращаю внимание на tiffcp (позволяет сделать из множества файлов - один многостраничный, без потери качества), tiffsplit (обратная операция) и tiff2pdf (конвертация многостраничного tiff в pdf, также без потери качества). Все остальные утилиты из этого пакета нужны гораздо реже.
Постобработка
Для неинтерактивного приведения сканов в порядок используется unpaper или самописные узкоспециализированные скрипты, для интерактивного - scantailor или один из его форков (scantailor-universal и scantailor-advanced). Последний настоятельно рекомендую посмотреть, т.к. там добавили много вещей, существенно облегчающих жизнь. Например, ручное и автоматическое выделение квадратных областей картинок в "смешанном" режиме вывода, сортировка по величине поворота страницы, ширине и высоте полезной области, поддержка ускорения рендеринга вывода с VAAPI.
После обработки сканов, итоговую пачку tiff можно упаковать в один из "бытовых" форматов, или использовать для распознавания текста.
Сборка pdf
Тут всё относительно просто: используйте tiffcp + tiff2pdf или graphicsmagik.
Если исходные файлы без сжатия, то можете покрутить опцию -c у tiffcp, которая позволяет прямо на месте
сжать страницы хоть без потерь (deflate/lzw), хоть с потерями (jpeg/jbig/ccitt g4).
Сколько у вас займут сжатые картинки страниц, примерно столько же будет и итоговый pdf-файл.
Размер типовой книги в 300 страниц - 15-30-50 мегабайт, в зависимости от наличия/отсутствия картинок.
Но pdf - это слишком просто и неспортивно, гораздо интереснее в этом плане...
Сборка djvu
Здесь мы можем получить размер итоговых файлов от 800Кб на ту же 300-страничную книгу, средний же размер книги будет порядка 7-10 мегабайт. Это связано с использованием ряда технологий, предназначенных именно для хранения цифровых версий документов. Подробнее о самом формате можно почитать хотя бы в википедии, а я предполагаю, что вы уже сталкивались с этим форматом, хотя бы как читатель.
Рекомендуемое dpi здесь зависит от типа кодирования: 600+ для jb2 (ч/б страницы), 300+ для IW44 (серые/цветные страницы). Более того, возможны разные dpi для разных слоёв одной и той же страницы (jb2 для текста, iw44 для картинок). Для ч/б слоя переднего плана (mask) рекомендуется разрешение в 600dpi (если исходник позволяет), для цветного (paletted/indexed) слоя переднего плана (foreground) - 300dpi, для цветного слоя заднего плана (background) - 150-200dpi, меньше не надо.
Наиболее востребованный софт для создания djvu:
minidjvu -- Собирает djvu напрямую из файлов страниц bmp/pbm/tiff, при этом даёт наименьшие по размеру файлы, за счёт использования в полной мере преимуществ jb2, в том числе - общих "словарей" графических символов на несколько страниц. Крупный недостаток - принципиально не поддерживает кодирование IW44, которое необходимо для хранения серых/цветных картинок и фонов страниц. В случае, если из картинок в книге только обложка, этот недостаток можно обойти, добавив первую страницу позже (см. djvm из пакета djvulibre).
- 2 618 209 байт # с дефолтными настройками
- 2 641 819 байт # --lossy
- 7 361 132 байт # --no-prototypes --aggression 0 --pages-per-dict 1
В последнем случае видно, насколько возрастает размер файла с отключенной оптимизацией кодирования.
Структура типового файла:
FORM:DJVM [2659440]
DIRM [2068] Document directory (bundled, 271 files 260 pages)
FORM:DJVI [28038] {scan-002_2R.iff} [I]
Djbz [28026] JB2 shared dictionary
FORM:DJVU [11112] {scan-002_2R.djvu} [P1]
INFO [10] DjVu 3244x4815, v24, 600 dpi, gamma=2.2
INCL [15] Indirection chunk --> {scan-002_2R.iff}
Sjbz [11058] JB2 bilevel data
FORM:DJVU [21448] {scan-003_1L.djvu} [P2]
INFO [10] DjVu 3244x4815, v24, 600 dpi, gamma=2.2
INCL [15] Indirection chunk --> {scan-002_2R.iff}
Sjbz [21394] JB2 bilevel data
FORM:DJVU [7202] {scan-003_2R.djvu} [P3]
INFO [10] DjVu 3244x4815, v24, 600 dpi, gamma=2.2
INCL [15] Indirection chunk --> {scan-002_2R.iff}
Sjbz [7148] JB2 bilevel data
Лучшим случаем применения этого кодера будут книги, где достаточно только монохромных изображений страниц. Таблицы, формулы, простые линейные графики в этом случае не пострадают.
djvudigital из djvulibre -- по моему опыту наилучший баланс между качеством работы и удобством использования. Для своей работы требует разовой компиляции специальной версии ghostscript (драйвер pdf2djvu имеет патентные проблемы и поэтому по-умолчанию отключен и не собирается), но после этого работает без нареканий. Работает строго с одной страницей, и прямую конвертация "куча tiff -> многостраничный djvu" в одну операцию тут не сделать, для этого утилиты слишком просты, но для этого есть минимум два обходных пути:
Первый состоит в том, что мы сначала собираем кучу tiff в один многостраничный файл с помощью tiffcp (lossless), затем этот файл конвертируем в многостраничный pdf с помошью tiff2pdf (тоже lossless), и уже последний конвертируем непосредственно в djvu с помощью djvudigital.
Второй путь состоит в конвертации каждой страницы в djvu (tiff (+tiff2pdf) -> pdf (+djvudigital) -> djvu), а потом объединение этих страниц в один файл через djvm. Этот вариант имеет два преимущества относительно предыдущего: просто добавлять текстовый слой и можно работать с проектами очень большого размера.
Так например, страницы одного иллюстрированного путеводителя формата A3 в tiff у меня заняли порядка 6Гб, и при существующем ограничении формата tiff в 4Гб на один файл, собрать его по первому варианту невозможно. Да, есть расширение формата BigTIFF, где это ограничение снято, но ...его поддержка в остальном софте оставляет желать лучшего.
pdf2djvu -- попытка сделать "умный конвертер" распространённого pdf в "продвинутый" djvu. Не слишком удачная, на мой взгляд, слишком много ненастраиваемой "магии".
Сильно зависит от структуры исходного файла pdf, в некоторых случаях размер итогового djvu может увеличиться на порядок. Примером кривой эвристики может служить pdf, со страницами уже запакованных в виде tiff ccitt g4. Вместо того, чтобы просто "как есть" перенести эти страницы в djvu в виде mask-слоя Sjbz, он зачем-то ещё добавляет им "белый" фон из FG44/BG44, хотя в этом нет никакой необходимости.
Ниже приведен пример отличий. Один и тот же проект, один и тот же исходник, те же самые страницы (37я - чисто текст, 38я - текст с картинкой). Первый файл собран с djvudigital, второй - pdf2djvu, отличия в размере - в 2,5 раза (67Мб против 154Мб).
# djvudigital
FORM:DJVU [64755] {scan-1-037.djvu} [P37]
INFO [10] DjVu 4776x6601, v24, 600 dpi, gamma=2.2
Sjbz [64725] JB2 bilevel data
FORM:DJVU [306644] {scan-1-038.djvu} [P38]
INFO [10] DjVu 4776x6601, v24, 600 dpi, gamma=2.2
Sjbz [6] JB2 bilevel data
FGbz [6] JB2 colors data, v0, 1 colors
BG44 [30585] IW4 data #1, 72 slices, v1.2 (color), 1592x2201
BG44 [33116] IW4 data #2, 11 slices
BG44 [72614] IW4 data #3, 10 slices
BG44 [170246] IW4 data #4, 10 slices
# pdf2djvu
FORM:DJVU [727410] {p0037.djvu} [P37] (37)
INFO [10] DjVu 4776x6601, v24, 600 dpi, gamma=2.2
INCL [15] Indirection chunk --> {shared_anno.iff}
Sjbz [692747] JB2 bilevel data
FGbz [34322] JB2 colors data, v0, 64 colors
BG44 [270] IW4 data #1, 97 slices, v1.2 (b&w), 398x551
FORM:DJVU [305773] {p0038.djvu} [P38] (38)
INFO [10] DjVu 4776x6601, v24, 600 dpi, gamma=2.2
INCL [15] Indirection chunk --> {shared_anno.iff}
Sjbz [6] JB2 bilevel data
FGbz [6] JB2 colors data, v0, 1 colors
BG44 [30514] IW4 data #1, 72 slices, v1.2 (color), 1592x2201
BG44 [32845] IW4 data #2, 11 slices
BG44 [71984] IW4 data #3, 10 slices
BG44 [170323] IW4 data #4, 10 slices
Отличия в размере сжатой "текстовой" страницы - на порядок, второй страницы - практически одинаково. У первой страницы очевидно неэффективным образом покодирован jb2 (700 против 64 кб), и добавлен бесполезный белый фон на 35кб.
csepdjvu -- более низкоуровневая утилита-кодировщик из djvulibre. Позволяет собирать одну страницу djvu из нескольких картинок: маски (чб/цветного), фона и набора управляющих команд, которые позволяют добавить странице текстовый слой, ссылки, заголовок и элементы оглавления.
djvumake -- ещё более низкоуровневая утилита из того же пакета. Позволяет собирать одну страницу djvu, с полным контролем над её структурой и содержанием на уровне отдельных блоков (INCL, Sxx, FGxx, BGxx).
В djvulibre не хватает утилит для работы с общими словарями символов, их поддержка пока рудиментарна. В csepdjvu есть возможность добавить как сам словарь, так и указатели на него, в cjb2 есть поддержка распознавания символов и составления их словаря для одной страницы, но нет утилит для работы с данными самого словаря символов.
Впрочем, никто не запрещает комбинировать различные кодировщики. Так например, для книги с цветной обложкой и блоком иллюстраций, можно конвертировать их через pdf2djvu, а весь остальной массив текста - через minidjvu, что позволяет существенно экономить в размере файла. Эти частичные djvu потом объединяются в один файл с помощью djvm. Так, книга в ~400 страниц (600 dpi, 3232x4647 px, ~360 страниц текста) сжатая через просто djvudigital занимает порядка 18Мб, а "комбинированным" методом - 5,7Мб.
Для себя я наваял скриптик, который на основе "separated" вывода scantailor самостоятельно определяет тип страницы, кодирует их наилучшим способом для этого вида страницы утилитами из djvu-libre, и потом собирает в один файл. Т.е. по сути воспроизведение автоматики из djvudigital, но с одним важным достоинством: мой вариант не требует кастомной сборки ghostscript'а.
Распознавание текста (ocr)
С распознаванием именно текста на линуксах всё достаточно неплохо. Есть вполне рабочий tesseract, есть альтернативные движки, вроде gocr, есть даже кастрированная проприетарщина от ABBYY. Однако, все опенсорсные движки до сих пор крайне плохо дружат с форматированием, даже таким простым как курсив и жирный шрифт. Т.е как текст они его распознают нормально, но в выводе никаких намёков на форматирование не будет.
Этого достаточно для создания текстового слоя для pdf/djvu, но если вы собираетесь делать полноценный fb2/epub - поддержки будет сильно не хватать.
Отсутствие поддержки хорошо видно на практике, если посмотреть вывод в формате alto или hocr: там нет ни упоминаний стиля текста, ни выделенных блоков иллюстраций. Курение исходников tesseract'а версии 4.1 подтверждает, что за реализацию пока даже не брались.
Поддержка анализа макета страницы (таблицы, картинки, ...) есть (см опцию --psm tesseract'а), но достаточно простая: блоки текста и колонки определяет неплохо, но на сложных случаях не справляется (фотография листа с рукописным текстом определяется как "тоже текст" и превращается в набор закорючек).
В некоторых софтинах (ocrfeeder) попытались это компенсировать путём анализа макета страницы и скармливания tesseract'у только отдельных фрагментов картинки с текстом, но до удобства использования им ещё далеко. Да и написаны они гномерами и на питоне, что не добавляет стабильности самому софту.
Для быстрого создания текстового слоя есть утилита ocrodjvu, которая представляет собой писанный на питоне враппер для tesseract'а и утилит из djvulibre. В теории, ничто не мешает использовать tesseract и djvused напрямую, но тогда вы столкнетесь как минимум с необходимость конвертации .hocr (формат вывода tesseract) в .dsed (скрипт djvused).
Наиболее читабельный вариант текста можно получить в xhtml из hocr, подвергнув его несложной обработке. В моём случае это 30-строчный скрипт на perl с mojo::dom.
Создание fb2/epub
Если распознанный текст нужен не только для поиска по pdf/djvu, то его неплохо бы оформить в один из форматов электронных книг: fb2/epub. Мне лично больше нравится первый, за лаконичность и простоту формата.
Перед конвертацией необходимо провести предобработку текста: пройтись по структуре глав (всё ли на месте), нарезать иллюстраций из оригинала (tesseract их игнорирует), посмотреть правильность распознавания таблиц и сносок (обычно там проблемы из-за мелкого шрифта).
В качестве промежуточного формата для текста удобен xhtml. С одной стороны, он почти без изменений конвертируется в epub и fb2, с другой его можно смотреть в браузере и исправлять в любом текстовом редакторе. doc/odt - не рекомендую, намучаетесь.
Из специализированных графических редакторов есть:
- для fb2 -- недоделанный и заброшенный fb2edit (файлы созданные с его помощью не проходит валидацию, и их приходится выправлять руками, см. этот баг)
- для epub -- вполне рабочий sigil
Я собираю fb2 при помощи обычного vim'а с обвесом и пачки скриптов. Из дополнительных утилит часто бывают нужны: xmllint (из libxml2-utils), base64 (openssl), perl для запуска скриптов и софт для работы с картинками: gimp/graphicsmagick/...
Конфиг vim'а:
:syntax on
:set number
:set modeline
:set expandtab
:set autoindent
:set shiftwidth=2
:set tabstop=2
:set foldenable foldmethod=indent
:set spell spelllang=ru_ru,en_us
Хорошее описание формата fb2 см. здесь. Там же можно скачать файлы схемы для валидации файла с помощью xmllint.
Обычный порядок работы:
- создаём файл будущей книги из шаблона (декларация xml, <FictionBook> с одним <description>, без <body> и <binary>), по-максимуму заполняем все поля
- переносим текст из распознанных страниц (как правило это xhtml), попутно заворачивая его в <section>, и каждый раз выставляя содержимому нужный отступ, чтобы работали fold'ы по каждой секции (это даст удобство и быстроту навигации, позволяя видеть структуру файла в целом)
- воссоздаём структуру глав (вложенность, заголовки правильного уровня, нумерацию)
- оформляем цитаты, таблицы и стихи
- добавляем сноски и вторую секцию <body> (если есть)
- добавляем обложку и иллюстрации (в последнюю очередь, т.к. сильно раздувает размер файла)
После каждого из пунктов 2-6 прогоняем xmllint, чтобы выловить ошибки. Надо отметить, что xmllint всё-же не гарантирует отсутствие логических ошибок, таких как "висячие" ссылки на картинки или сноски в тексте, поэтому все ссылки внутри документа, которые у вас указаны в href="..." - проверяем самостоятельно, любым удобным способом.
Также рекомендую ознакомиться с местами устаревшей, но весьма интересной книгой М.Кондратовича «Создание электронных книг в формате FictionBook 2.1: практическое руководство». Как минимум её историческая её часть и описание самого формата с пояснениями актуальны до сих пор.
Вычитка
Часть орфографических ошибок устраняется на этапе создания и редактирования файла (если вы настроили проверку орфографии в vim'е), но всё же итоговый файл как правило требует вычитки.
В моём случае используется обычный китайский планшет с coolreader3. Методика такая: запасаемся чаем с бутербродами, берём кота и садимся на диван читать книгу. Когда натыкаемся на ошибку, просто ставим на неё закладку, и читаем дальше, не прерываясь на исправление. Это очень удобно, т.к. coolreader не просто запоминает место в тексте, но и позволяет выделить его конкретный фрагмент, чем я и пользуюсь.
Впоследствии, эти закладки можно экспортировать в файл и уже на компьютере поправить одним махом. Закладки имеют следующий вид:
## 27.73% - comment
## 3. Дискуссии о плане и рынке
<< следующим Шагом на этом
>>
<пустая строка>
Библиотеки
Разумеется, после того, как сканированная или текстовая книга готова, ей рекомендуется поделиться с остальными. Свободные сетевые библиотеки держатся на энтузиастах и принципе "сделал сам - дай прочитать другим" (см. общественное благо). В результате такого объединения усилий в сети можно найти практически любые книги, хотя нужно потратить какое-то время, чтобы понять, где и что искать.
Две наиболее крупные библиотеки книг в русскоязычном сегменте интернете - это Либген и Флибуста. В первой хранится в основном не-художественная литература в виде сканов, во второй - преимущественно художественная и преимущественно текстовая литература.
Оттуда новые книги активно растаскиваются по сети в другие библиотеки и ресурсы: livelib, lib.rus.ec, twirpx, т.е. можно быть уверенным, что труд не пропадёт даром.