Обновление скрипта "Поиск по набору регэкспов" для FBE - тестируем!

Опубликовано пт, 06/09/2019 - 04:13 пользователем TaKir

Дошли руки существенно дополнить, обновить, почистить и структурировать по смыслу скрипт "Поиск по набору регэкспов" для Fiction Book Editor (FBE).

Автор этого скрипта (как и многих других скриптов для FBE) - Sclex, за что ему отдельное гран мерси.

Наполнение скрипта мое, Sclex-а + учтены все возможные пожелания книгоделов из двух старых здешних тем:

Типичные ошибки распознавания...
https://lib.rus.ec/node/268750
и
Курьезы сканировщика:
http://lib.rus.ec/comment/372489

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

Просьба приводить конкретные примеры:

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

Очень приветствуется помощь тех, кто хорошо знаком с регулярными выражениями для дальнейшего совершенствования скрипта.

Ссылка на последнюю версию скрипта (30-09-2019):

https://my-files.ru/p1yq7v

альтернативные ссылки:
https://ru.files.fm/u/j76r8q44
https://anonfiles.com/Yae3t470n2/17_TaKir-Sclex-30-09-2019_js
https://www25.zippyshare.com/v/GgMyWsRc/file.html

Заменить этим файлом имеющийся файл (или положить новый вариант скрипта рядом) в папке:
... /Fiction Book Editor/Scrips/06_Чистка

Скрипту удобнее назначить горячую клавишу F2 (меню: Сервис-Настройки-Клавиши-Скрипты-Поиск по набору регэкспов).

Перед запуском данного скрипта лучше обработать текст скриптами "Генеральная уборка", "Латиница в кириллице"
Тогда будет гораздо меньше лишних срабатываний.

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

P.S. На Флибусте открыта аналогичная тема, можно писать в любую.
http://www.flibusta.is/node/441303

Комментарии

Опубликовано сб, 05/10/2019 - 05:29 пользователем ProstoTac

Мне кажется лишним срабатывание скрипта на знаки препинания в конце сток в эпиграфах и стихах.

Аватар пользователя Антонина82

Опубликовано сб, 05/10/2019 - 08:34 пользователем Антонина82

ProstoTac написал:
Мне кажется лишним срабатывание скрипта на знаки препинания в конце сток в эпиграфах и стихах.

+100500

Опубликовано вс, 06/10/2019 - 14:27 пользователем TaKir

Антонина82 написал:
ProstoTac написал:
Мне кажется лишним срабатывание скрипта на знаки препинания в конце сток в эпиграфах и стихах.

+100500

Это можно легко исправить. Но если в эпиграфе на прозе разрыв абзаца, то пусть так и остаётся?
Аватар пользователя Антонина82

Опубликовано пн, 07/10/2019 - 00:05 пользователем Антонина82

TaKir написал:
Антонина82 написал:
ProstoTac написал:
Мне кажется лишним срабатывание скрипта на знаки препинания в конце сток в эпиграфах и стихах.

+100500

Это можно легко исправить. Но если в эпиграфе на прозе разрыв абзаца, то пусть так и остаётся?

Да. Стихотворения гораздо чаще встречаются в моей работе. И на каждой строке срабатывает скрипт. Мне это не подходит. Как убрать, подскажите.

Опубликовано пн, 07/10/2019 - 02:42 пользователем TaKir

Антонина82 написал:
TaKir написал:
Антонина82 написал:
ProstoTac написал:
Мне кажется лишним срабатывание скрипта на знаки препинания в конце сток в эпиграфах и стихах.

+100500

Это можно легко исправить. Но если в эпиграфе на прозе разрыв абзаца, то пусть так и остаётся?

Да. Стихотворения гораздо чаще встречаются в моей работе. И на каждой строке срабатывает скрипт. Мне это не подходит. Как убрать, подскажите.

Допишите (открыв блокнотом файл скрипта) в соответствующих строках пробел -epigraph и сохраните файл скрипта.

tagRegExp("(?<=<мы-не-внутри-тэга>)([^\»….,:;!\?]|[—–,-])<впереди-закр-тэги-но-не-A>$","","Найдено: концы строк без точек","-title -subtitle -stanza -poem -epigraph");

tagRegExp("(?<=(^|\>)[^\<]*)([^\»….,:;!\?]|[—–,-])()[A-Za-z]+(/s+[^>]+)?>)*$","","Найдено: концы строк без точек","-title -subtitle -stanza -poem -epigraph");

tagRegExp("(?<=(^|\>)[^\<]*)([—–-])()[A-Za-z]+(/s+[^>]+)?>)*$","","Найдено: подозрительные концы строк в стихах","-title -subtitle -epigraph");

addRegExp("^[a-zа-яё]","","Найдено: маленькие буквы в начале строки","-stanza -poem -epigraph");

Опубликовано пн, 07/10/2019 - 01:20 пользователем ProstoTac

А если в эпиграфе на прозе разрыв абзаца такой выбрык автора? А если в качестве эпиграфа стихи?

Аватар пользователя V_E

Опубликовано сб, 19/10/2019 - 03:07 пользователем V_E

Тема обсуждения этого скрипта, похоже, завершилась, тем не менее, хочу поделиться результатами проделанной работы, хотя зачем я с нею связался - самому непонятно.
Исходные данные: взял книгу, сделанную не мною, но совершенно, на мой взгляд, не вычитанную. Книга художественная (детектив). Первый раз вычитал сам, затем начал проверку с помощью обсуждаемого скрипта.
Результаты:
Из 305 срабатываний, действительными (т.е., когда скрипт фиксировал подлинную ошибку) оказались 166, т.е. около 50% Хорошо это или плохо, судить не берусь, излагаю только факты. Значительное число правильных срабатываний было связано с обнаружением пробела после окончания абзаца, т.е. записи в коде типа: конец последнего предложения абзаца. тег конца абзаца (/p)
Это, на мой взгляд, полезно, так как визуально в читалке такой пробел виден не всегда, но может напугать. Помню, открыл одну книгу в CR3, а там в конце каждого абзаца стоит вопросительный знак. Именно потому что пробел между точкой и тегом конца абзаца не убран.
Были и другие правильные срабатывания, но этот - наиболее незаметный при вычитке, особенно когда читаешь с телефона.
Что же касается ложных срабатываний, то здесь картина следующая. Привожу перечень ситуаций в которых скрипт фиксировал возможную ошибку:
нос ( слово нос - у человека, животного или у корабля)
нотам (дательный падеж слова нота)
Итак (вводное слово, с которого часто начинаются рассуждения или выступления: "Итак, мы начинаем!"
из будки (слово будки выделено как возможная ошибка)
будку (винительный падеж слова будка)
рот
ею (об этом я уже писал, но в этой книге, поскольку там фигурировали женщины, это слово встречалось очень часто).
бюстгальтер (выделяет сочетание тг)
Иди (в выражении: Лео! Иди сюда! и в начале диалога: — Иди же, Лео!)
во фрагменте: "...продолжал Дарси, — Джонни видели в..." скрипт выделил сочетание , — Д полужирным сделал я, чтобы было понятнее, о чем речь.
лег (рано лег спать)
смят (смятую сигарету)
нес (он нес два свертка)
вес (политический вес)
оказать (оказать услугу)
пули (не услышал свиста пули)
однако то (однако то и дело оглядывался)
Лас (Лас-Вегас)
будь то (будь то комната в полицейском управлении или вилла)
оп (сопротивляется)
пищу (скудную пищу)
йя (Гавайях)
оео (своеобразном положении)
ияе (солнышко сияет)
яй (из одной яйцеклетки)
ему то (ему то же, что и)
двигался то (двигался то туда, то сюда)
проделывает то (проделывает то же самое)

Повторюсь, никаких выводов и рекомендаций давать не буду, но на один момент думаю, обязательно следует обратить внимание, поскольку скрипт не заметил такую ошибку:
был открыт,‘будто

Аватар пользователя alexej36

Опубликовано сб, 19/10/2019 - 08:50 пользователем alexej36

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

"Генеральная уборка" их бы благополучно съела. Ее стоит запустить раньше чем "Поиск по набору регэкспов". Иначе много ненужной работы.
Да, "Найдено: 3 (4) и более гласных подряд" в топку. Очень много ненужных срабатываний "Проверка орфографии" несуществующие слова покажет.
Аватар пользователя V_E

Опубликовано сб, 19/10/2019 - 10:23 пользователем V_E

alexej36 написал:

"Генеральная уборка" их бы благополучно съела.

Обычно я код чищу "поиском и заменой", но в этот раз ограничился ручной вычиткой, интересно было набрать статистику по работе скрипта.

Опубликовано сб, 19/10/2019 - 12:29 пользователем ProstoTac

1. Про "Генеральную уборку" не факт. Ни она (ГУ), ни "Поиск по набору..." не убирают "левые" пробелы юникода с U+2000 до U+200F, из которых только 2009 является приемлемым. Недавно обнаружил такое после конвертации из .DOCX (встречаются нужные файлы/книги в таком формате) в FB2, про просмотре файла в режиме "код".
2. Да, "Найдено: 3 (4) и более гласных подряд" в топку - не согласен, спорный вопрос.
3. Да, в чем-то "Поиск по набору..." дублирует некоторые скрипты, которые нужно запускать раньше, чем "Поиск по набору...". Но лучше пусть так, несомненная польза от "Поиск..." есть.

Опубликовано вс, 20/10/2019 - 12:15 пользователем GMAP

ProstoTac написал:
не убирают "левые" пробелы юникода с U+2000 до U+200F, из которых только 2009 является приемлемым. Недавно обнаружил такое после конвертации из .DOCX (встречаются нужные файлы/книги в таком формате) в FB2, про просмотре файла в режиме "код".
И правильно делает, что не убирает :-) Ибо не заложено в ём ума и сообразительности, чтобы еще и юникоды по правильному отображению определять. Надо не зацикливаться на "Теле", а почаще в код заглядывать, там не только пробелы, еще и дефисы могут быть некошерные, которые в читалках отобразятся "квадратиками", а в самом FBE, если не смотреть в код, все вроде бы ОК. С другой стороны, поиск/замена этих "квадратиков" осуществляется в коде корректно, поэтому все претензии/предложения к девелоперам FBE, скрипт вряд ли сможет распознать обычный дефис и из расширенной латыни A/B, равно как и другие коллизии в рамках юникода. Кстати, пока разбирался с юнкодами, пришлось переделать в FBE отображение неразрывных пробелов, сейчас у меня там выбор из ¦ (00A6), евроцента (00A2) и плюсминуса (00B1) из набора доп-латиницы (0080-00FF), поскольку что хочется из символов не получается воткнуть, не будет корректно отображаться. Как могли девелоперы выбрать "Символы для рисования рамок" для пробела - тайна сия велика есть.
Вот здесь можно постичь тайны юникода - https://unicode-table.com/ru/#control-character

Опубликовано пн, 21/10/2019 - 05:19 пользователем TaKir

GMAP написал:
Надо не зацикливаться на "Теле", а почаще в код заглядывать, там не только пробелы, еще и дефисы могут быть некошерные, которые в читалках отобразятся "квадратиками", а в самом FBE, если не смотреть в код, все вроде бы ОК. С другой стороны, поиск/замена этих "квадратиков" осуществляется в коде корректно,

Если есть пример текста, можно добавить в поиск скриптом таких вариантов.

Опубликовано пн, 21/10/2019 - 05:20 пользователем TaKir

ProstoTac написал:
1. Про "Генеральную уборку" не факт. Ни она (ГУ), ни "Поиск по набору..." не убирают "левые" пробелы юникода с U+2000 до U+200F, из которых только 2009 является приемлемым. Недавно обнаружил такое после конвертации из .DOCX (встречаются нужные файлы/книги в таком формате) в FB2, про просмотре файла в режиме "код".

Если есть пример текста, можно добавить в поиск скриптом таких вариантов.

Опубликовано пн, 21/10/2019 - 05:28 пользователем ProstoTac

TaKir написал:
ProstoTac написал:
1. Про "Генеральную уборку" не факт. Ни она (ГУ), ни "Поиск по набору..." не убирают "левые" пробелы юникода с U+2000 до U+200F, из которых только 2009 является приемлемым. Недавно обнаружил такое после конвертации из .DOCX (встречаются нужные файлы/книги в таком формате) в FB2, про просмотре файла в режиме "код".

Если есть пример текста, можно добавить в поиск скриптом таких вариантов.


Простите великодушно - там не поиск вариантов, там тупая "поиск-замена".

Опубликовано пн, 21/10/2019 - 06:14 пользователем TaKir

ProstoTac написал:
TaKir написал:
ProstoTac написал:
1. Про "Генеральную уборку" не факт. Ни она (ГУ), ни "Поиск по набору..." не убирают "левые" пробелы юникода с U+2000 до U+200F, из которых только 2009 является приемлемым. Недавно обнаружил такое после конвертации из .DOCX (встречаются нужные файлы/книги в таком формате) в FB2, про просмотре файла в режиме "код".

Если есть пример текста, можно добавить в поиск скриптом таких вариантов.


Простите великодушно - там не поиск вариантов, там тупая "поиск-замена".

Для выполнения "тупая "поиск-замена", нужно хотя бы узнать, какие конкретно "кривые" символы есть в тексте. потому и прошу пример текста.

Опубликовано вт, 22/10/2019 - 04:36 пользователем GMAP

TaKir написал:
потому и прошу пример текста.
http://fb13.online/b/681314
Это уже оптимизированная книга, но в оригинале было то же самое, Aleks_Sim поленился заглянуть в код, поэтому литресовские ошибки юникода так и остались: из торгсиновских 1930-вот здесь вместо правильного дефиса символ U+2010, тоже дефис, но который в читалках и коде FBE отображается "квадратиком".
P.S. Если мало, вот еще один пример http://fb13.online/b/627504 где перед каждым закрывающим тегом </p> впендюрен U+3000
Аватар пользователя alexej36

Опубликовано вт, 22/10/2019 - 07:51 пользователем alexej36

Или:
http://lib.rus.ec/b/627504
U+300 заменить на ничего. "Регулярные выражения" вкл. Выявить проблему помог "Поиск по набору регекспов". Впрочем как и прежняя его версия.

Опубликовано вт, 22/10/2019 - 13:28 пользователем TaKir

alexej36 написал:
Или:
http://lib.rus.ec/b/627504
U+300 заменить на ничего. "Регулярные выражения" вкл. Выявить проблему помог "Поиск по набору регекспов". Впрочем как и прежняя его версия.

Наверное, такое лучше в генуборку бы запихнуть.

Опубликовано пт, 25/10/2019 - 02:38 пользователем GMAP

TaKir написал:
лучше в генуборку бы запихнуть.
Лучше поиск символов в диапазоне U+2000 до U+2C7F(???, если не до 2FFF) и от U+3000 и до U+3FFF(???), детали поиска могут варьироваться, поскольку туда много чего попадает из числа теоретически нужного, хотя и не для беллетристики. Но меня терзают смутные сомнения, что кто-либо, кроме самих девелоперов, может это сделать. Дело в отображении UTF-8/UTF-16, когда один и тот же текст имеет совершенно разные коды. Дефис может выглядеть в хексе как 3E 80 80, а может 20 10 и так далее. Есть один редактор, который поможет понять что есть юникод вообще, юникодные косяки и как их править - Super Unicode Editor Разумеется, он отучен от требований чего бы то ни было (у меня) :-) А сама технология замены одного на другое проста и даже примитивна.

Опубликовано пт, 25/10/2019 - 05:27 пользователем TaKir

GMAP написал:
TaKir написал:
лучше в генуборку бы запихнуть.
Лучше поиск символов в диапазоне U+2000 до U+2C7F(???, если не до 2FFF) и от U+3000 и до U+3FFF(???), детали поиска могут варьироваться, поскольку туда много чего попадает из числа теоретически нужного, хотя и не для беллетристики. Но меня терзают смутные сомнения, что кто-либо, кроме самих девелоперов, может это сделать. Дело в отображении UTF-8/UTF-16, когда один и тот же текст имеет совершенно разные коды. Дефис может выглядеть в хексе как 3E 80 80, а может 20 10 и так далее. Есть один редактор, который поможет понять что есть юникод вообще, юникодные косяки и как их править - Super Unicode Editor Разумеется, он отучен от требований чего бы то ни было (у меня) :-) А сама технология замены одного на другое проста и даже примитивна.

Можно попробовать в лоб ловить вот так (у меня работает):
addRegExp("[^A-Za-zА-яЁё0-9(/[.,\/#!$%\^&\*;:{}=\-_`~()\\x20\\xA0\\t\\n\\r\\f«»„“\"…–'®—§º+№-]","","Найдено: Странные нетекстовые символы");

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

Опубликовано пн, 28/10/2019 - 08:54 пользователем TaKir

TaKir написал:
GMAP написал:
TaKir написал:
лучше в генуборку бы запихнуть.
Лучше поиск символов в диапазоне U+2000 до U+2C7F(???, если не до 2FFF) и от U+3000 и до U+3FFF(???), детали поиска могут варьироваться, поскольку туда много чего попадает из числа теоретически нужного, хотя и не для беллетристики. Но меня терзают смутные сомнения, что кто-либо, кроме самих девелоперов, может это сделать. Дело в отображении UTF-8/UTF-16, когда один и тот же текст имеет совершенно разные коды. Дефис может выглядеть в хексе как 3E 80 80, а может 20 10 и так далее. Есть один редактор, который поможет понять что есть юникод вообще, юникодные косяки и как их править - Super Unicode Editor Разумеется, он отучен от требований чего бы то ни было (у меня) :-) А сама технология замены одного на другое проста и даже примитивна.

Можно попробовать в лоб ловить вот так (у меня работает):
addRegExp("[^A-Za-zА-яЁё0-9(/[.,\/#!$%\^&\*;:{}=\-_`~()\\x20\\xA0\\t\\n\\r\\f«»„“\"…–'®—§º+№-]","","Найдено: Странные нетекстовые символы");

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

Вот такой вариант вполне рабочий получился:
addRegExp("[^\u0400-\u04FF\u0020-\u007F\u0100-\u017F\u00A0-\u00FF\u0370-\u03FF(/[\\x20\\xA0\\t\\n\\r\\f„“–\…—№-]","","Найдено: Странные нетекстовые символы");

Просьба тестировать.

Опубликовано вт, 29/10/2019 - 08:39 пользователем TaKir

Добавил в основной скрипт вот такой блок:

// Ищем все, кроме разрешенных букв, цифр и знаков препинания

// \u0400-\u04FF - кириллический диапазон Юникод символов
// \u0020-\u007F - латинский диапазон Юникод символов
// \u0100-\u017F - расширенный латинский диапазон Юникод символов (Latin Extended-A)
// \u0180-\u024F - расширенный латинский диапазон Юникод символов (Latin Extended-B)
// \u00A0-\u00FF - диапазон Юникод символов (Latin-1 Supplement)
// \u0370-\u03FF - греческий диапазон Юникод символов
// \u2200-\u22FF - математический диапазон Юникод символов
// \u2150-\u218F - дроби диапазон Юникод символов

addRegExp("[^\\u0400-\\u04FF\\u0020-\\u007F\\u0100-\\u017F\\u0180-\\u024F\\u00A0-\\u00FF\\u0370-\\u03FF\\u2200-\\u22FF\\u2150-\\u218F\\x20\\xA0\\t\\n\\r\\f„“–\…—№-]","","Найдено: Странные нетекстовые символы");

При необходимости всегда можно добавить или убрать какой-либо диапазон.
Брал отсюда:
https://unicode-table.com/ru/

Как обычно, за помощь спасибо Sclex!

Аватар пользователя V_E

Опубликовано пн, 04/11/2019 - 10:32 пользователем V_E

TaKir написал:

Как обычно, за помощь спасибо Sclex!

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

Опубликовано вт, 05/11/2019 - 10:18 пользователем TaKir

V_E написал:

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

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

V_E написал:

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

Это вам так кажется. Очень и очень вряд ли это работа какого-либо скрипта после распознавания исходного текста.

V_E написал:

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

Данный скрипт накосячить не может вообще, поскольку он ничего не правит в принципе.

А надергать отдельных регэкспов из данного скрипта - нет проблем, в нем все расписано, что и зачем делается.

Аватар пользователя V_E

Опубликовано чт, 07/11/2019 - 10:44 пользователем V_E

TaKir написал:
Данный скрипт накосячить не может вообще, поскольку он ничего не правит в принципе.

Этим он меня и заинтересовал. Но все-таки промахов, мне кажется слишком много. Впрочем, "будем посмотреть" (В. Каверин). Наработаем статистику на разных типах книг.
Аватар пользователя V_E

Опубликовано вс, 24/11/2019 - 05:22 пользователем V_E

Продолжаем нарабатывать статистику. Правда, не знаю, нужно это или уже тема утратила актуальность? Но, как бы то ни было, проверил очередную сделанную книгу. Сначала, как обычно, ручная вычитка, исправление типичных ошибок на автомате (поиск-замена). Потом, обработка рассматриваемым скриптом. Получены следующие результаты.
Обнаружено реальных ошибок - 72. Главным образом это отсутствие пробелов или лишние пробелы, а также наличие курсива там, где он не требовался. Но было и несколько действительно пропущенных ошибок.
Ложных срабатываний - 61. Причем выделялись как целые слова, так и сочетания нескольких знаков, в том числе внутри слова. Такие случаи я далее выделил полужирным начертанием. Как ошибочные показывались следующие слова и сочетания (о некоторых здесь уже говорилось):
иди, из, нос, рот, будкой, , ко всем (в данном случае перед запятой стояло какое-то слово); наступило то; глаза то; ему то; делал то; булку; булка; яйцом; вес; сияющим; смятенном; фанатично; полета; итак; Рентгена; назад, ко мне; ним то; динамике то; пищу; оказать; а, ко. Ну и, правда не знаю, стоит ли на это обращать внимание, - останавливался на римских цифрах. Но это я за ошибку не считал. На мой взгляд, нужно подумать насчет отслеживания сочтеания "то". Поскольку могут быть разные варианты - с дефисом или без: кто-то, что-то, то и другое и т.д. И тот и иной вариант написания встречается довольно часто. Ну и "булка" и "будка" тоже, хотя тут понятно, почему скрипт ошибается - когда написано "булка", он считает, что должно быть "будка" и наоборот.

Опубликовано вс, 24/11/2019 - 06:01 пользователем ProstoTac

Я бы отметил, что ДО запуска этого скрипта текст следовало бы прогнать предварительно и "Разрыв предложения", и "Латиница в Криллице" и "Слипшиеся слова", не говоря уже о "Генеральной уборке". Меньше остановок будет. А ем больше заложено возможностей, тем больше будет так называемых "ложных срабатываний". Это неизбежно.

Аватар пользователя V_E

Опубликовано вс, 24/11/2019 - 10:05 пользователем V_E

ProstoTac написал:
А ем больше заложено возможностей, тем больше будет так называемых "ложных срабатываний". Это неизбежно.

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

Опубликовано вс, 24/11/2019 - 13:12 пользователем ProstoTac

1. "количество найденных реальных ошибок практически равно числу ложных срабатываний." - я это как уж FR наопределяет. Типа в тексте из правильных буквосочетаний в середине слова "тт" и "тг" сколько будет неправильных буквосочетаний "тт" и "тг"? Кто знает заранее...
2. "слова, типа "фанатик", "пища", "нос", "рот" и т.д. выделяются как возможные ошибки." - уважаемый TaKir предварительно спрашивал у сканировщиков случаи из жизни - значит эти слова похожи на другие правильные, типа "пища - лица, нее - нес, нос - нес, рог - рот" и задача скрипта - обратить внимание на это. Кто должен решить какое из двух правильных слов действительно верное?

Опубликовано пн, 25/11/2019 - 07:19 пользователем TaKir

ProstoTac написал:
1. "количество найденных реальных ошибок практически равно числу ложных срабатываний." - я это как уж FR наопределяет. Типа в тексте из правильных буквосочетаний в середине слова "тт" и "тг" сколько будет неправильных буквосочетаний "тт" и "тг"? Кто знает заранее...
2. "слова, типа "фанатик", "пища", "нос", "рот" и т.д. выделяются как возможные ошибки." - уважаемый TaKir предварительно спрашивал у сканировщиков случаи из жизни - значит эти слова похожи на другие правильные, типа "пища - лица, нее - нес, нос - нес, рог - рот" и задача скрипта - обратить внимание на это. Кто должен решить какое из двух правильных слов действительно верное?

Да, к сожалению, некоторые слова или сочетания букв никак без участия человека не определить - что ошибка, а что нет.
Единственное, что могу предложить - каждый может временно или на постоянно заблокировать наиболее досаждающие строки в скрипте.
Увеличится ли при этом скорость обработки? - Безусловно.
Уменьшится ли от этого количество реальных ошибок в конкретной книге - кто знает?
Я сам частенько блокирую отдельные поисковые строки, если правильный вариант слишком часто есть в конкретной книге.
Потом включаю строку обратно, т.к. в другой книге найденное может быть ошибкой с гораздо большей вероятностью.

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

Аватар пользователя V_E

Опубликовано пн, 25/11/2019 - 10:46 пользователем V_E

TaKir написал:

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

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


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

Опубликовано пн, 25/11/2019 - 11:37 пользователем tvnic

Не уверен, но вроде в начале и в конце строки для игнорирования ее работы ставится восклицательный знак ! Возможно другой символ.
Чтобы вернуть строку в работу, эти символы убираются.

Опубликовано пн, 25/11/2019 - 13:02 пользователем TaKir

tvnic написал:
Не уверен, но вроде в начале и в конце строки для игнорирования ее работы ставится восклицательный знак ! Возможно другой символ.
Чтобы вернуть строку в работу, эти символы убираются.

чтобы игнорировать работу конкретной строки, добавляются слэши в начале этой строки, вот так:

// addRegExp("[а-яё] — [а-яё]","","Найдено: возможно, нужен дефис без пробелов");

это она же, в рабочем режиме:

addRegExp("[а-яё] — [а-яё]","","Найдено: возможно, нужен дефис без пробелов");

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

Править скрипт таким образом можно хоть 100 раз на дню, а можно сделать несколько вариантов этого скрипта, "строгий" и "быстрый" и пользоваться ими по необходимости.
Тут кому как удобнее, так и можно делать.

Опубликовано пн, 25/11/2019 - 13:06 пользователем TaKir

V_E написал:
ProstoTac написал:
А ем больше заложено возможностей, тем больше будет так называемых "ложных срабатываний". Это неизбежно.

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

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

Опубликовано вт, 26/11/2019 - 02:15 пользователем ProstoTac

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

Опубликовано вт, 26/11/2019 - 02:33 пользователем tvnic

Скрипт однозначно нужен. Что-то в его работе может не нравиться, но тогда флаг в руки - можно подстроить под себя.

Аватар пользователя V_E

Опубликовано сб, 30/11/2019 - 09:49 пользователем V_E

tvnic написал:
Скрипт однозначно нужен. Что-то в его работе может не нравиться, но тогда флаг в руки - можно подстроить под себя.

Никто и не говорил о том, что скрипт не нужен. Другое дело - когда и как его лучше применять.

Опубликовано вс, 03/11/2019 - 01:52 пользователем Zadd

не знаю, было или нет.
фобы гробы, фанаты гранаты

Аватар пользователя alexej36

Опубликовано пт, 22/11/2019 - 08:36 пользователем alexej36

TaKir, занялись бы еще "Генеральной уборкой"!
Хороший, годный скрипт! Но требует доработки.

Опубликовано пн, 25/11/2019 - 07:21 пользователем TaKir

alexej36 написал:
TaKir, занялись бы еще "Генеральной уборкой"!
Хороший, годный скрипт! Но требует доработки.

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

Опубликовано пн, 25/11/2019 - 07:57 пользователем ProstoTac

.... - > ... четыре точки на троеточие.
<буква>...<буква> -> <буква>... <буква> троеточие между буквами без пробелов на многоточие с пробелом. Где-то есть в скрипте, но не так, как надо работает.

Опубликовано вт, 26/11/2019 - 09:48 пользователем TaKir

ProstoTac написал:
.... - > ... четыре точки на троеточие.
<буква>...<буква> -> <буква>... <буква> троеточие между буквами без пробелов на многоточие с пробелом. Где-то есть в скрипте, но не так, как надо работает.

Это готово.

Есть мнение, что нужно удалять пробел перед маркерами сносок типа: Тут текст [26] с маркером сноски. Понятно, что обычные квадратные скобки трогать не будем, только именно маркеры сносок.

Есть ли за-против аргументы?
Можно ли это делать для всех видов сносок? Есть ли грабли, которые надо обойти?

Опубликовано вт, 26/11/2019 - 17:43 пользователем ProstoTac

Простите, а где такое в художественном тесте встречается? Что-то не представляю, что это такое и как оно в действительности выглядит/должно выглядеть.

Опубликовано ср, 27/11/2019 - 16:08 пользователем TaKir

ProstoTac написал:
Простите, а где такое в художественном тесте встречается? Что-то не представляю, что это такое и как оно в действительности выглядит/должно выглядеть.

Да это обычные сноски. Просто иногда маркеры сносок в тексте бывают оторваны от слова пробелом, что не очень аккуратно.

Навскидку вот тут можно видеть, о чем я
http://flibusta.is/b/566614/read#anotelink3

Опубликовано чт, 28/11/2019 - 02:17 пользователем ProstoTac

Вкурил. Конечно, пробел перед открывающей квадратной скобкой не нужен - некрасиво однозначно. И неправильно.
И чтоб два раза не вставать - хорошо бы в "Генеральной уборке" предусмотреть замену всех возможных различных вариаций апострофов - ´ ʼ ′ ˙ ΄ - на ' (буква «э» на англ. раскладке), который U+0027.

Аватар пользователя alexej36

Опубликовано пн, 25/11/2019 - 09:36 пользователем alexej36

На Максиме несколько лет назад обсуждалось. И кое-что удалось поправить. http://zalil.su/4677991

Опубликовано ср, 27/11/2019 - 16:00 пользователем TaKir

Сравнение файлов показало пару незначительных исправлений.
Но, в принципе, не удивительно, там и так прописано почти все, что возможно.

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

В режиме обычного Найти (CTRL+F), включить галку на регулярные выражения:

[^\dA-Za-zА-яЁё»…\\.,:;!\\?№«\s%)=„“±×°+><(▫—–\[\]//-]

Ищет всякие нетипичные символы: все, что не буквы, не цифры, не пробелы, не знаки препинания, и не самые распространенные мат. символы.

Аватар пользователя V_E

Опубликовано сб, 30/11/2019 - 09:51 пользователем V_E

TaKir написал:
Сравнение файлов показало пару незначительных исправлений.
Но, в принципе, не удивительно, там и так прописано почти все, что возможно.

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

В режиме обычного Найти (CTRL+F), включить галку на регулярные выражения:

[^\dA-Za-zА-яЁё»…\\.,:;!\\?№«\s%)=„“±×°+><(▫—–\[\]//-]

Ищет всякие нетипичные символы: все, что не буквы, не цифры, не пробелы, не знаки препинания, и не самые распространенные мат. символы.


Интересная запись, попробуем, как будет работать.
Аватар пользователя V_E

Опубликовано вс, 01/12/2019 - 02:49 пользователем V_E

Обнаружил пропуск ошибки.
При обработке скриптом, он пропустил слово, написанное с ошибкой: обратнв (должно быть - обратив. Имеется ввиду "обратив внимание").
Еще одна пропущенная скриптом ошибка: меряла (мерила расстояние).

Опубликовано вс, 01/12/2019 - 03:33 пользователем ProstoTac

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

Страницы
X