Поиск в сканированных словарях

Я потихоньку начал писать Windows-версию словарной программы, пока что она не работает, но с текущим кодом можно познакомиться тут: https://github.com/rohkea/opendi

Quase, насчёт формата могу сказать, чего мне не хватает в твоих словарях. Указания страницы в индексе.

До того, как я узнал о твоих индексах, у меня была похожая идея. С одним большим отличием: мне не хватало терпения составить постраничный индекс, а выписывал каждую пятую, а то и каждую десятую страницу (а потом уже, если было желание, заполнял между ними пробелы). И хочу сказать, что каждая десятая — это тоже удобнее, чем искать наобум.

Для такого случая твой текущий формат не подходит.

(11-09-2014 10:13)Agrest писал(а):  Я потихоньку начал писать Windows-версию словарной программы, пока что она не работает, но с текущим кодом можно познакомиться тут: https://github.com/rohkea/opendi

Quase, насчёт формата могу сказать, чего мне не хватает в твоих словарях. Указания страницы в индексе.

До того, как я узнал о твоих индексах, у меня была похожая идея. С одним большим отличием: мне не хватало терпения составить постраничный индекс, а выписывал каждую пятую, а то и каждую десятую страницу (а потом уже, если было желание, заполнял между ними пробелы). И хочу сказать, что каждая десятая — это тоже удобнее, чем искать наобум.

Для такого случая твой текущий формат не подходит.

Ну это смотря как посмотреть.

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

Но индекс сам по себе бесполезен - ему сопутствуют данные разной степени необходимости и переносимости, такие как название словаря или расположение его файла.

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

Какие именно поля имеют смысл для программ-обработчиков - это вопрос. Со словарями у меня на данный момент номинально поддерживаются
Name
Alphabet
InputAlphabet
IndexAlphabet
FirstOnPage
FirstPage
Format
CheckFile
Title
Description
ScanInfo
а также
File,
но его лучше не включать в переносимые файлы, потому что он в принципе непереносимый. Кстати, FirstOnPage как раз указывает, первое слово на странице заиндексировано или последнее (истина - true, t, yes, 1; ложь - false, nil, no, 0, ""). В более ранних версиях был IndexFormat - как раз вид индекса, о котором я говорю. Пока до него руки не дошли.

Стандартизировать данный список полей рановато: например, поля Author явно не хватает.

Кстати, вопрос о разграничении переносимых/непереносимых данных, пользовательских переопределениях и т. п. я решил тем, что данные о словаре могут считываться из нескольких файлов, причём словари идентифицируются по полю Name.

(11-09-2014 20:28)Quasus писал(а):  Кстати, вопрос о разграничении переносимых/непереносимых данных, пользовательских переопределениях и т. п. я решил тем, что данные о словаре могут считываться из нескольких файлов, причём словари идентифицируются по полю Name.

Хм-хм-хм. А что делать, если в двух разных файлах для одного словаря есть два индекса?

(12-09-2014 16:25)Agrest писал(а):  

(11-09-2014 20:28)Quasus писал(а):  Кстати, вопрос о разграничении переносимых/непереносимых данных, пользовательских переопределениях и т. п. я решил тем, что данные о словаре могут считываться из нескольких файлов, причём словари идентифицируются по полю Name.

Хм-хм-хм. А что делать, если в двух разных файлах для одного словаря есть два индекса?

Вообще, если в файлах дизъюнктные данные (например, в одном не указан файл словаря, а в другом - указан), то проблем нет. Если же данные дублируются, естественно предполагать, что данные из одного файла забьют данные из другого. Например, в исходном файле написано FirstPage 30, а я взял и удалил из своей копии первые 29 ненужных страниц; тогда редактировать исходный файл не нужно, а достаточно завести файл

Код:

Name MyDict
FirstPage 1

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

По общей логике получается, что индекс из второго файла заменяет собой индекс из первого. Только зачем?

То есть повторяющиеся поля по-разному обрабатываются в зависимости от того, в одном они файле или в разных. Если в одном файле встретится несколько полей одного типа, то они собираются в списке. Если в разных файлах, то поля второго файла перезаписывают поле первого.

Я правильно понимаю?

Ну да, идея была такая.

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

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

В своих индексах я использую поле Format. Его значение - "символ", который по идее должен влиять на то, как данный словарь открывать. У меня механизм в том, что форматам ставятся в соответствие вюьеры - программы с конкретным набором опций, используемые для открытия. Изначально у меня определены форматы PDF и DJVU, для которых даже есть кое-какая автоматизация; но, в принципе, пользователь может определять вьюеры для каких угодно форматов. Возможный случай использования - INDIRECT_DJVU, который с разным успехом открывается разными программами: например, evince нормально открывает цельные djvuхи, а на indirect подвисает. С другой стороны, хорошо иметь возможность указать два формата, чтобы при отсутствии вьюера для INDIRECT_DJVU использовался бы вьюер для DJVU.

Значит, какими данными словарь/алфавит описывается. Пока вырисовывается как-то так:
Dictionary      symbol
Title           string
Description     string
ScanInfo        string
Author          string?  strings?

FirstPage       integer
FirstOnPage     boolean
Format          list of symbols?  list of lists of symbols?

Alphabet        symbol

DefineAlphabet  symbol
Letters         list of strings
Ligatures       list of strings
CaseSensitive   boolean
InputAlphabet ? symbol
IndexAlphabet ? symbol
...

File            list of strings
CheckFiles      boolean

Dictionary задаёт идентификатор словаря. Файл определяет словарь тогда и только тогда, когда есть это поле.

DefineAlphabet - то же самое относительно алфавита. Компоненты алфавита берутся, естественно, из Letters, Ligatures и CaseSensitive.

Alphabet - имя алфавита, используемого данным словарём. Если имя не указано, словарь использует анонимный алфавит, определяемый с помощью Letters, Ligatures и CaseSensitive.

Была идея ещё различать InputAlphabet и IndexAlphabet (которые фолбечились бы на Alphabet): IndexAlphabet - который парсит индекс, а InputAlphabet - который парсит ввод пользователя. Тогда пользователь мог бы переопределять InputAlphabet по своему усмотрению. Если так, то нужны ещё InputLetters и т. п.

File - файлы словаря, данные очень непортабельные, соответственно, в портабельный файл это поле включать не надо
CheckFiles - следует ли программе беспокоиться, если при установке словаря она не найдёт его файлы. Как она будет беспокоиться (и будет ли) - дело программы.

Format по задумке - некая подсказка программе, как именно открывать данный файл. Стандартными можно считать pdf и djvu (и даже определять их по mime-типам). Другими форматами подобного уровня могли бы быть indirect-djvu и какие-нибудь графические форматы для разодранных на страницы словарей (правда, моя прога их ещё не поддерживает). Также я предполагал, что пользователю будет легко объявлять собственные форматы и назначать на них вьюеры. Сначала я думал, что каждый том словаря может иметь свой формат, потом отказался от этого, а зря, наверно. Также неплохо иметь фолбечные форматы. Описывать их можно было бы так:

Код:

# Example format description for a two volume dictionary
format
  indirect_djvu djvu
  my_cool_pdf_format pdf

Для Description и ScanInfo я допускаю многостроковость: если их значение - список строк, то объединить эти строки разрывами строки. Авторов себе ещё вообще не делал и этого поля не хватает. В принципе, для них можно и список - если авторов много, одного на строку. Хотя не так важно, на менеджер библиографии я не замахиваюсь.

Не читал тему целиком, возможно, уже говорилось: есть ли возможность индексировать словарь по ходу использования?
Например, изначально программа ничего не знает о расположении слов на страницах и выдаёт страницу наугад (например, интерполяцией между A и Z), пользователь листает вперёд или назад до нужной страницы и сообщает программе, какую страницу надо было открывать. В следующий раз программа интерполирует уже точнее — по одному из двух отрезков и т. д.

(20-09-2014 18:25)Teilnehmer писал(а):  Не читал тему целиком, возможно, уже говорилось: есть ли возможность индексировать словарь по ходу использования?

В моей реализации такого нет и никогда не будет по идеологическим соображениями.