DjVu-Scan Forum

Главное => Общий => Тема начата: monday2000 от 12 јРав 2010, 18:26:41

Название: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 12 јРав 2010, 18:26:41
Давайте обсудим возможные варианты того, по какой системе назначать имена файлам DjVu-книг и какие XMP-метаданные вносить в DjVu-файлы (имеется в виду при самостоятельном создании DjVu-книги).

Сейчас для именования DjVu-файлов используется программа NameCreator http://www.djvu-soft.narod.ru/soft/namecreator.htm .

Есть мнение, что она уже немного устарела.

Идея топика в том, чтобы разработать на базе NameCreator некую новую программу (разумеется, свободно-бесплатную с открытыми исходниками), которая будет как генерировать имя файла для создаваемой DjVu-книги (по некоей системе), так и одновременно при этом позволять записывать XMP-метаданные в этот же самый DjVu-файл (причём будет соблюдаться некое соответствие между именем DjVu-файла и его XMP-метаданными).

(В продолжение темы http://www.djvu-scan.ru/forum/index.php?topic=34.msg262#msg262)

20.03.10
Тема переименована с "Система именования и метаданных DjVu" на "Программа для генерации наименования и метаданных DjVu".

Смысл данной темы - разработка и создание реальной программы, которая будет генерировать "говорящее" имя файла DjVu-книги + XMP-метаданные в этой DjVu-книге.


18.08.10
Тема переименована с "Система именования и метаданных DjVu" на "Программа для генерации наименования и метаданных DjVu и PDF".
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: monday2000 от 12 јРав 2010, 21:56:08
Напомню свою идею "квалификатора качества":
(Из http://www.djvu-scan.ru/forum/index.php?topic=34.msg251#msg251)
Цитировать
По поводу именования файлов: сейчас Name Creator прописывает в имени файла всякие условные обозначения качества DjVu-книги. Например, (T)(C)(K).

Идея хорошая, правда, ИМХО, с недостатками. Дело в том, что подобных признаков качества гораздо больше, чем имеется в Name Creator. Например:

1. Делали ли Deskew.
2. Искривлены ли строки.
3. Какой режим - серый/ч.б./
И т.д. и т.п.

Поэтому я бы предложил иной вариант: взять двоичное число - длиною, скажем, 16 бит. И каждому биту назначить тот или иной признак качества. 0 или 1 в данном бите будет означать наличие/отсутствие того или иного признака качества. Полученное 16-битное число - прописывать в имени файла - в шестнадцатиричном виде (для краткости). Это будет выглядеть как "1FD5" или "34AA".

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

Также можно условно поделить весь диапазон значений 16-битного числа на 5 поддиапазонов - т.е. классы качества. Почему 5 - по аналогии со школьными оценками, т.е. как бы "выставлять" качеству DjVu-книги ту или иную оценку, как в школе - от 1 до 5. Тогда в дальнейшем опытный глаз, глянув на шестнадцатиричный индикатор уровня качества в имени файла, сразу умозрительно прикинет, к какому из 5 классов качества относится данная DjVu-книга. Плюс это можно будет в своей программе показывать.
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: monday2000 от 12 јРав 2010, 22:14:36
Alfizik
Отвечу на Ваш пост http://www.djvu-scan.ru/forum/index.php?topic=34.msg262#msg262:
Цитировать
Качество можно оценивать по объективным и субъективным критериям.
Резонно.
Цитировать
Имхо, тогда оценивать можно по следующей системе (ввести несколько разрядов): 1 - ниже 300 dpi; 2 - 300 dpi; 3 - 450 (400) dpi; 4 - 600 dpi и 5 - выше 600 dpi. Возможно есть смысл  добавить и больше разрядов (короче требует обсуждения).
Я думаю, что для начала, в качестве рабочего варианта, давайте будем записывать DPI "как есть" - поскольку его значение так трудно формализовать. Т.е. так и писать: "300","600","150","200". Всё-таки, так будет наиболее просто и понятно.
Цитировать
2.цвет книги
ч\б, отенки серого, цветная, малоцветная (менее 16, 8 или 4 цветов).
Наверняка там есть различные нюансы.
Не, там всё предельно чётко. Это определяется лишь наличием-отсутствием тех или иных чанков (что можно посмотреть в WinDjView).
Цитировать
Различать ли какую методику применяли для битонизации (приведение к ч\б )?
Если я правильно понял, то нет. Что значит "методика битонизации"? Какой алгоритм бинаризации использовался и с какими параметрами?
Цитировать
Убирали ли фон и приводили ли его к белому?
Это совсем уж экзотика. Думаю, это делают буквально единицы.
Цитировать
Еще слышал можно обложку книги по разному обрабатывать.
Это совершенно несущественно.
Цитировать
3. Deskew

4. Искривление строк

5. Наличие черных полос на разворотах.

6. Закодирована DjVu-книга в двойных разворотах или каждый лист отдельно.

7. Совпадает ли нумерация страниц книги с нумерацией листов в DjVu файле

8. Есть ли OCR-слой

9. Производилась ли чистка сканов от мелкого мусора (точек)?
Забыл как эта функция в СканКромсаторе называется.

10. Обрезались ли сканы и приводилось ли все поля к одному размеру?
Кажется в NameCreator-е это называется kromsated.
Вот это уже ИМХО более правильные критерии.
Цитировать
Субъективные
Пока ничего не могу сказать. Это можно оставить "на потом" (для обсуждения).
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: monday2000 от 12 јРав 2010, 22:56:18
Alfizik
У меня по поводу квалификатора качества такие соображения:

- Квалификатору качества следует иметь номер версии. Вряд ли мы сразу сможем безукоризненно верно определить критерии качества DjVu-книги. Номер версии я предлагаю писать до квалификатора и отделять от него подчёркиванием. Например, "1_FD45". Почему отделять подчёркиванием? Потому что неизвестно, сколько всего будет версий, а значит непонятно, сколько разрядов резервировать под номер версии.

- Программа, о которой я говорю (возможный расширенный аналог NameCreator - с возможностью записи XMP-метаданных), должна, пожалуй, быть способной работать не только с DjVu - но также и с PDF. Ведь XMP вообще-то пришло в DjVu из PDF.

Это означает, что мне потребуется какая-нибудь свободно-бесплатная консольная утилита, умеющая работать с PDF XMP. Кто-нибудь знает такую?

Кстати, давайте пока условно (для удобства) назовём как-нибудь такую гипотетическую программу. Например, "NameCreator-2", или "NC2".

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

Вот мои соображения (в порядке снижения важности - по критерию читабельности). Выражаюсь Вашими же словами:

1.
Цитировать
Цвет книги.
Точнее, правильность выбора цвета книги. Я даже специально сделал пример DjVu, иллюстрирующий неправильный выбор цвета:

http://www.djvu-soft.narod.ru/scan/bad_colored_djvu.rar (120 КБ)

Такую книгу просто невозможно читать - только заново пересканировать.

2.
Цитировать
Закодирована DjVu-книга в двойных разворотах или каждый лист отдельно.

3.
Цитировать
Deskew.


4.
Цитировать
Наличие черных полос на разворотах.
(Немного спорный признак. Бывает, что книга сделана, в общем-то, неплохо - только где-нибудь затесалась узёхонькая черная полоска).

5. 
Цитировать
Обрезались ли сканы и приводилось ли все поля к одному размеру?
Кажется в NameCreator-е это называется kromsated.
Я бы сказал проще: "приводилось ли все поля к одному размеру?" Это ведь автоматически подразумевает обрезку.

Кстати - 4 и 5 как-то похожи друг на друга вроде бы.

6.
Цитировать
Искривление строк.

7.
Цитировать
Есть ли OCR-слой.

8. Есть ли отсутствующие страницы (либо куда-то отдельно это записывать).

9.
Цитировать
Производилась ли чистка сканов от мелкого мусора (точек)?
Забыл как эта функция в СканКромсаторе называется.
Это называется "despeckle".

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

Цитировать
Субъективные
Сюда бы я отнёс такой довольно ощутимый признак, как "качество букв". Не знаю, как это объективно описать. Обычно хорошее качество букв достигается апсемплингом с интерполяцией с 300 dpi до 600 dpi (в Scan Tailor это делается по-умолчанию, в ScanKromsator надо явно указывать). В результате, буквы получаются такими "жирненькими", и читать такую книгу гораздо приятнее.

В общем, субъективно я бы это назвал "колкость текста для глаз". Колкий текст хрен почитаешь - в больших количествах, а проинтерполированный до 600 dpi - одно загляденье. Хотя, в редких случаях, и на 300 dpi получается "жирненькие" буквы, не-колкие.
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: monday2000 от 20 јРав 2010, 13:19:57
Ещё один субъективный признак качества: DjVu, сделанный по принципу DjVu Digital.

Т.е. это DjVu, полученный путём прямой конвертации некоего чисто векторного контента в DjVu. Например, по преобразованию PDF - DjVu, или печать на виртуальном DjVu-принтере текстового файла, или конвертор Office2007-DjVu.

Обычно такой DjVu имеет наивысшее возможное качество. Яркий пример такого DjVu-это спецификации формата DjVu в DjVu.

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

P.S. Тема переименована - см. самый первый пост.
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: monday2000 от 20 јРав 2010, 23:22:23
Ещё один субъективный признак качества: DjVu-книга, полученная при помощи цифрового фотоаппарата - а не сканера.

Вот пример такой книги (довольно любопытно):

http://ifolder.ru/16907196  (10,6 МБ)

Цитировать
Фотик Cannon A540,с выключенной вспышкой. Больше ничего, только после того как выделил в кромсаторе картинки - отдельно каждую (штук 300, включая все буквицы в начале глав) обработал в фотошопе на предмет уровней белого. Иначе очень некрасиво выходило.
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: 57an от 21 јРав 2010, 08:18:18
Цитировать
Ещё один субъективный признак качества: DjVu-книга, полученная при помощи цифрового фотоаппарата
Нужно ли выделять ее из группы "искривление строк"? Другой вопрос, что искривления разные - есть возле корешка - когда буквы в кучу собираются, есть когда корешок прижат хорошо, но страница в другом месте не прижалась - небольшие локальные искривления. А есть фотоискажения - трапеция и (или) подушка всей страницы в целом.
Кстати, отдельная особенность фотосканов - сложность определения dpi. Вот в приведенной книге реальное dpi вполне может колебаться даже для соседних страниц разворота, например 1147.1 на одной странице и 1149.4 на другой - в зависимости от расстояния страницы до объектива фотоаппарата.

По-моему классификацию, как и обработку, следует делить на 3 категории -
качество скана - dpi; фотоскан, сканер, скриншот с электронной книги или электронная книга.

пре-djvu-обработка - тупо по этапам СТ + удаление растра + тоновая коррекция

кодирование в djvu - профиль кодирования - простой - bitonal, photo; или смешанный - scanned или photo+bitonal или photo + posterized (с указанием dpi для background). Плюс степень сжатия background (в приведенной фотокниге при отличном кодировании иллюстрации чуть пережаты - это видно при их увеличении).
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: monday2000 от 21 јРав 2010, 18:19:56
57an
Цитировать
Нужно ли выделять ее из группы "искривление строк"?
Я пока не знаю. Пока просто собираю информацию. Вопрос признаков качества DjVu-книги непростой.

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

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

Это только в больших сетевых библиотеках, надеюсь, станут правильно именовать собранные книги.

Можно сделать, скажем, 2 квалификатора качества: один - краткий - для записывания в имя файла, второй - полный - для записывания в XMP-метаданные DjVu-файла. Хотя не факт, что это нужно - просто как идея.

Такой момент ещё: NameCreator, как известно, не даёт 100% обратимости русский-транслит. Мне это пока что кажется неправильным - хотелось бы именно полную обратимость (для программного преобразования, например).
Название: Re: Программа для генерации наименования и метаданных DjVu
Отправлено: monday2000 от 31 јРав 2010, 10:46:58
Сегодня я случайно заметил, что, оказывается, djvused уже поддерживает работу с XMP-метаданными DjVu-файла! Это видно из её документации http://djvu.sourceforge.net/doc/man/djvused.html (в самом низу страницы выше фразы "LIMITATIONS"):
Цитировать
(metadata ... (key value) ... )
Define meta-data entries. Each entry is identified by a symbol key representing the nature of the meta data entry. The string value represents the value associated with the corresponding key. Two sets of keys are noteworthy: keys borrowed from the BibTex bibliography system, and keys borrowed from the PDF DocInfo metadata. BibTex keys are always expressed in lowercase, such as year, booktitle, editor, author, etc.. DocInfo keys start with an uppercase letter, such as Title, Author, Subject, Creator, Produced, Trapped, CreationDate, and ModDate. The values associated with the last two keys should be dates expressed according to RFC 3339.
То есть, ничего уже даже и придумывать самому не надо - как бы работать с XMP-метаданными DjVu-файла, всё уже придумано.  :)

Скачать самую свежую версию djvused (поддерживающую в т.ч. эту функциональность) можно тут:

http://www.djvu-soft.narod.ru/soft/djvused.rar  (283 КБ)
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 18 °ТУгбв 2010, 17:58:16
У меня возникли некоторые новые идеи относительно программы, обсуждаемой в данном топике.

1. Такая программа должна работать не только с DjVu - но также одновременно и с PDF. Другие форматы я не рассматриваю - т.к. большинство книг в нашей сфере имеют форматы только DjVu и PDF.

2. При генерации информативного имени для PDF- или DjVu-книги для транслитерирования кириллицы в латинницу такой программе следует использовать действующий ГОСТ 7.79—2000: Правила транслитерации кирилловского письма латинским алфавитом.:
http://www.ifap.ru/library/gost/7792000.pdf
http://www.gsnti-norms.ru/norms/common/doc.asp?2&/norms/stands/7_79.htm (в этой HTM-версии есть опечатки, :o так что за основу следует брать PDF-версию строкой выше).

Программа NameCreator, используемая ныне, не использует этот ГОСТ. Использование ГОСТа хорошо тем, что, во-первых мы избежим отсебятины при транслитерации, а во-вторых - этот ГОСТ обеспечивает 100%-обратимость (машинно-алгоритмическую) при прямой и обратной транслитерации! :-* Это довольно важно - и NameCreator такую обратимость, насколько я помню, не обеспечивает.

ГОСТ 7.79—2000 - это очень простой для понимания документ, и его будет легко реализовать в виде алгоритма транслитерации. И это - официально действующий в данный момент документ.

3. Для характеристики качества изготовления электронной PDF- или DjVu-книги ("квалификатор качества") я предлагаю использовать 5-балльную шкалу оценок. Прямо как в школе. Просто я подумал - все эти многочисленные критерии качества почти невозможно строго формализовать. Так пусть уж пользователь сам "выставляет книге оценку", исходя из произвольных собственных представлений о том, "на какой балл она тянет". И это будет достаточно надёжно - в конце концов, на 5-балльной шкале оценок у нас работают все школы и институты - и нормально. Можно лишь составить примерную табличку, где приблизительно сгруппировать все признаки качества по баллам. Но эта табличка будет носить только рекомендательный характер.
5-балльная шкала оценок - это надёжное средство оценивания, опробованное в широких масштабах и в течение длительного времени.

4. Такая программа будет не только формировать информативное имя файла - но также и (опционально) одновременно формировать и записывать XMP-метаданные - как для PDF, так и для DjVu. И чисто техническая возможность для этого уже есть. Для записи XMP в PDF я предполагаю использовать ExifTool http://owl.phy.queensu.ca/~phil/exiftool/ , а для записи XMP в DjVu - djvused.

Остающиеся проблемы:

1. Я пока ещё не решил, по какой типовой схеме генерировать информативное имя файла электронной PDF- или DjVu-книги. Видимо, это будет примерно так же, как и у NameCreator - Название, Автор, и т.д. Вот бы был какой-нибудь ГОСТ именно для этого! :-\ Так не хочется городить отсебятину...  :-[ Можно попробовать обсудить вопрос с крупными электронными библиотеками (типа Либрусека).

2. Возникает проблема корреляции между информативным именем файла и XMP-метаданными. По идее, надо бы сделать их 100% взаимно-обратимыми в автоматическом режиме. Т.е., чтобы мы, скажем, имея только информативное имя файла, могли полностью автоматом генерить XMP (хотя бы частично - понятно, что в XMP сведений помещается гораздо больше, чем в имя файла) - и наоборот. Но тогда возникает вопрос - стоит ли в информативном имени файла разделять его логические части каким-нибудь спецсимволом, например "|" - как в e2dk-ссылках? Это для того, чтобы программа могла полностью автоматически распарсить информативное имя файла на соответствующие поля XMP-метаданных. Но не породит ли использование такого спецсимвола лишние неудобства и проблемы?

Кстати, XMP описан тут:
http://en.wikipedia.org/wiki/Extensible_Metadata_Platform

Я пока ещё не очень с ним разобрался, но похоже, что в его основные поля выглядят так http://en.wikipedia.org/wiki/Dublin_Core :
Цитировать
Title — название;
Creator — создатель;
Subject — тема;
Description — описание;
Publisher — издатель;
Contributor — внёсший вклад;
Date — дата;
Type — тип;
Format — формат документа;
Identifier — идентификатор;
Source — источник;
Language — язык;
Relation — отношения;
Coverage — покрытие;
Rights — авторские права.

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

Audience — аудитория (зрители);
Provenance — происхождение;
RightsHolder — правообладатель.
Каждый элемент опционален и может повторяться
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 19 °ТУгбв 2010, 15:13:38
Пытаюсь пока разобраться с форматом метаданных для PDF и DjVu.

Начал с DjVu разбираться. Пока что всё непонятно. Оказалось, что термин "metadata" в DjVu означает именно "текстовые метаданные" - вроде XMP. А я-то всегда подразумевал под DjVu-метаданными те мета-объекты, которые можно вставить в DjVu при помощи Document Express Editor 6.0 - например, Hyperlink, Text Area, и т.п. Оказывается, эти мета-объекты следует именовать не "метаданные" - а "аннотации". Они именно так и именуются в DjVu-спецификации. А "метаданные" - это лишь один из видов "аннотаций". Вот что об этом говорится в DjVu-спецификации:
Цитировать
7.1.3.4 Annotations and Textual Information
All types of DjVu images may contain annotation chunks. Annotation chunks are used to
describe hyperlinks, to specify more viewer settings (page background, initial zoom, etc), and to hold metadata information. Annotations are contained in “ANTa” or “ANTz” chunks.

Теперь перейдём именно к DjVu-метаданным.

Действующая спецификация формата DjVu не даёт никакого описания DjVu-метаданных. И вообще, в этой спецификации слово "metadata" встречается один раз - как раз в той цитате выше (7.1.3.4 Annotations and Textual Information).

Формат DjVu-метаданных описан официально тут:

http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/doc/djvuchanges.txt

Это документ, содержащий предложения по улучшению формата DjVu - появившиеся уже после принятия текущей спецификации. Я уже убедился на практике, что де-факто этот документ находится в полной власти Леона Боту.

В этом документе Леон предложил свой вариант формата DjVu-метаданных:
Цитировать
4- METADATA

4.1- DJVULIBRE METADATA

DjVuLibre has introduced metadata annotations a few years ago.
Metadata entries for each page are represent by key/value pairs
located in a metadata directive in the annotation chunk.
Metadata entries for the document are represented similarly
using the methods described in the next section.

The metadata directive has the form

  (metadata ... (key "value") ... )

Each entry is identified by a symbol <key>
representing the nature of the metadata entry.
The string <"value"> represents
the value associated with the corresponding key.

Several sets of keys are noteworthy.

* Keys borrowed from the BibTex bibliography system.
  These key names are always expressed
  in lowercase, such as 'year', 'booktitle', 'editor',
  'author', etc. 

* Keys borrowed from the PDF DocInfo.
  These key names start with an uppercase letter:
  'Title', 'Author', 'Subject', 'Keywords', 'Creator',
  'Producer', 'Trapped', 'CreationDate', and 'ModDate'.
  The values associated with the last two keys
  should be dates expressed according to RFC 3339.

4.2- XMP METADATA

The XMP specification describes a general purpose RDF/XML format for
metadata. Just like DjVuLibre metadata, XMP metadata is embedded in
an annotation chunk at the page or document level using the following
annotation directive

   (xmp "<rdf:RDF xmlns:rdf=... [escaped XMP here] ...</rdf:RDF>")

The sole argument of the xmp directive is the serialized XMP data
without the "xpacket" wrapper. The "x:xmpmeta" element may also be
dropped. Only elements from "rdf:RDF" inwards are needed.
Since the XMP data is represented as a string, doublequotes and
backslashes must be escaped.  Other characters may be escaped as well
(see section 2 above).

The full XMP specification is available from Adobe:

   http://www.adobe.com/devnet/xmp/

To maximize interoperability with current viewers, it is recommended
that XMP manipulation programs keep the DjVuLibre metadata in sync.
This is facilitated by synchronizing the PDF DocInfo keys with XMP
properties as follows:

   DocInfo key    XMP property
   ------------   ---------------
   Title          dc:title
   Author         dc:creator
   Subject        dc:description
   Keywords       pdf:Keywords
   Producer       pdf:Producer
   Trapped        pdf:Trapped
   Creator        xmp:CreatorTool
   CreationDate   xmp:CreateDate
   ModDate        xmp:ModifyDate

4.3- DOCUMENT ANNOTATIONS AND METADATA

The above schemes provide ways to specify metadata for each page.
But it is often useful to provide metadata that applies to the whole
document. Document wide metadata are represented using one or
several metadata directives in the shared annotations chunk.

This scheme has a potential drawback. Since the shared annotations
is included by all pages, the document wide metadata also appears as
page metadata for all pages. This might not be adequate for some
uses. As a workaround, the djview4 viewer only displays
page metadata that differ from the document metadata.
A more definitive answer would be the definition of a document
annotation chunk located after the DIRM chunk and before any
component file. This space is already used by the NAVM chunk. 
This is being considered.
Процесс создания этого описания подробно освещён тут:

http://www.djvu.org/forum/phpbb/viewtopic.php?t=530

Из того топика видно, как Леон Боту разрабатывал формат DjVu-метаданных, и делал он это совместно с автором ExifTool http://owl.phy.queensu.ca/~phil/exiftool/ Phil Harvey. Кстати, именно после этого ExifTool начал поддерживать DjVu-метаданные в режиме "только чтение" (а PDF-метаданные он умеет не только читать, но и править и записывать).

Из этого документа становится ясно, что в формате DjVu предлагается использовать целых 3 вида метаданных:

1. В стиле "PDF DocInfo". Что такое "PDF DocInfo" - я не знаю.
2. В стиле "BibTex bibliography system". Насколько я понимаю, описание этого стиля дано тут: http://en.wikipedia.org/wiki/BibTeX .
3. В стиле XMP. Я расспросил Phil Harvey http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,2779.0.html - какой там синтаксис. Вот что он мне ответил:
Цитировать
What goes in the XMP directive is standard XMP as documented in the XMP specification http://www.adobe.com/devnet/xmp/ .
The only difference is that the XMP should not use the "xpacket" or "x:xmpmata" wrappers
indicated in the XMP spec, and any double quotes and backslashes must be escaped with
a backslash.

Any XMP tags mentioned in the XMP spec are allowed in DjVu.  You can use ExifTool to generate the XMP packet if you want by writing to a .xmp file.

I forget now how to use djvused to insert this into a DjVu image, but it shouldn't be too
hard to figure out if you read the djvused documentation.

- Phil
Phil Harvey сделал образец DjVu-файла с метаданными и выложил его на форуме PlanetDjVu. Я взял этот файл и вытащил оттуда метаданные в текстовый формат. Вот что получилось (с небольшими правками):
Цитировать
select; remove-ant; remove-txt
# -------------------------
select 1
set-ant
(metadata
   (Author   "Phil Harvey")
   (Title   "DjVu Metadata Sample")
   (Subject   "ExifTool DjVu test image")
   (CreationDate   "2008-09-23T12:31:34-04:00")
   (ModDate   "2008-11-11T09:17:10-05:00")
   (Keywords   "ExifTool, Test, DjVu, XMP")
   (Producer   "djvused")
   (Trapped   "Unknown")
   (Creator   "ExifTool")
   (note   "Must escape double quotes (\") and backslashes (\\)") )
   (url   "http://owl.phy.queensu.ca/~phil/exiftool/")
(xmp "<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>\n\n
<rdf:Description rdf:about=''\n  xmlns:album=\"http://ns.adobe.com/album/1.0/\">\n
<album:Notes>Must escape double quotes (&quot;) and backslashes (\\)</album:Notes>\n
</rdf:Description>\n\n <rdf:Description rdf:about=''\n  xmlns:dc='http://purl.org/dc/elements/1.1/'>\n
<dc:creator>\n
<rdf:Seq>\n
<rdf:li>Phil Harvey</rdf:li>\n
</rdf:Seq>\n
</dc:creator>\n
<dc:description>\n
<rdf:Alt>\n
<rdf:li xml:lang='x-default'>ExifTool DjVu test image</rdf:li>\n
</rdf:Alt>\n
</dc:description>\n
<dc:rights>\n
<rdf:Alt>\n
<rdf:li xml:lang='x-default'>Copyright 2008 Phil Harvey</rdf:li>\n
</rdf:Alt>\n
</dc:rights>\n
<dc:subject>\n
<rdf:Bag>\n
<rdf:li>ExifTool</rdf:li>\n
<rdf:li>Test</rdf:li>\n
<rdf:li>DjVu</rdf:li>\n
<rdf:li>XMP</rdf:li>\n
</rdf:Bag>\n
</dc:subject>\n
<dc:title>\n
<rdf:Alt>\n
<rdf:li xml:lang='x-default'>DjVu Metadata Sample</rdf:li>\n
</rdf:Alt>\n
</dc:title>\n
</rdf:Description>\n\n
<rdf:Description rdf:about=''\n  xmlns:pdf='http://ns.adobe.com/pdf/1.3/'>\n
<pdf:Keywords>ExifTool, Test, DjVu, XMP</pdf:Keywords>\n
<pdf:Producer>djvused</pdf:Producer>\n
<pdf:Trapped>/Unknown</pdf:Trapped>\n
</rdf:Description>\n\n
<rdf:Description rdf:about=''\n  xmlns:xmp='http://ns.adobe.com/xap/1.0/'>\n
<xmp:CreateDate>2008-09-23T12:31:34-04:00</xmp:CreateDate>\n
<xmp:CreatorTool>ExifTool</xmp:CreatorTool>\n
<xmp:ModifyDate>2008-11-11T09:17:10-05:00</xmp:ModifyDate>\n
</rdf:Description>\n</rdf:RDF>")
.
В этом скрипте для djvused отображены 2 вида DjVu-метаданных - сначала PDF DocInfo-метаданные, а затем XMP-метаданные.

В описании DjVu-метаданных предлагается максимально синхронизировать DocInfo-метаданные и XMP-метаданные (по отделным полям). В том же документе приводится табличка соответствия:
Цитировать
   DocInfo key    XMP property
   ------------   ---------------
   Title          dc:title
   Author         dc:creator
   Subject        dc:description
   Keywords       pdf:Keywords
   Producer       pdf:Producer
   Trapped        pdf:Trapped
   Creator        xmp:CreatorTool
   CreationDate   xmp:CreateDate
   ModDate        xmp:ModifyDate
Кроме ExifTool, DjVu-метаданные ещё поддерживаются в последних версиях DjVu-просмотрщика DjView (в составе DjVuLibre). Тоже "только на чтение".

И ещё DjVu-метаданные поддерживаются в DjVu Shell Extension Pack http://dev.caminova.jp/beta/djvu-wic/ - официальном продукте от компании Caminova. Этот факт ИМХО означает, что Caminova практически согласилась внести в будущем исправление в спецификацию DjVu касательно (предложенным Леоном Боту) формата DjVu-метаданных (если, конечно, спецификация DjVu ещё когда-нибудь будет правиться).

DjVu-метаданные могут быть как для всего DjVu-файла в целом, так и отдельно для каждой его страницы.

В общем, чтобы освоить работу с DjVu-метаданными, нужно освоить PDF DocInfo, BibTex bibliography system и XMP. Всё это, похоже, большая морока. Надо хотя бы понять, какой возможен список полей (какие их имена допускаются), какова максимально возможная длина каждого поля, и т.п.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 19 °ТУгбв 2010, 16:51:16
Хотел посоветоваться на форуме http://gen.lib.rus.ec/forum/ - но пишет "Access denied.". Что за ерунда?
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 20 °ТУгбв 2010, 15:33:03
Я тут немного поискал ГОСТы, которые могут иметь отношение к теме. Выложил их у себя для удобства:

Все они относятся к категории Система стандартов по информации, библиотечному и издательскому делу (коротко "СИБИД") http://bibliography.ufacom.ru/method/gosts/sibid.htm

ГОСТ 7.1-2003. БИБЛИОГРАФИЧЕСКАЯ ЗАПИСЬ. БИБЛИОГРАФИЧЕСКОЕ ОПИСАНИЕ. Общие требования и правила составления.
http://www.djvu-soft.narod.ru/scan/gost_7_1_2003.rar  (259 КБ)

ГОСТ 7.79-2000 (ИСО 9-95). ПРАВИЛА ТРАНСЛИТЕРАЦИИ КИРИЛЛОВСКОГО ПИСЬМА ЛАТИНСКИМ АЛФАВИТОМ.
http://www.djvu-soft.narod.ru/scan/gost_7_79_2000.rar  (1,37 МБ)

ГОСТ 7-80.2000. БИБЛИОГРАФИЧЕСКАЯ ЗАПИСЬ. ЗАГОЛОВОК. ОБЩИЕ ТРЕБОВАНИЯ И ПРАВИЛА СОСТАВЛЕНИЯ.
http://www.djvu-soft.narod.ru/scan/gost_7_80_2000.rar  (103 КБ)

ГОСТ 7.82—2001. БИБЛИОГРАФИЧЕСКАЯ ЗАПИСЬ. БИБЛИОГРАФИЧЕСКОЕ ОПИСАНИЕ ЭЛЕКТРОННЫХ РЕСУРСОВ. Общие требования и правила составления.
http://www.djvu-soft.narod.ru/scan/gost_7_82_2001.rar  (305 КБ)

ГОСТ 7.83—2001. ЭЛЕКТРОННЫЕ ИЗДАНИЯ. Основные виды и выходные сведения.
http://www.djvu-soft.narod.ru/scan/gost_7_83_2001.rar  (259 КБ)

Все в формате "векторный PDF".
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 20 °ТУгбв 2010, 16:14:20
В этих ГОСТах можно почерпнуть кое-что полезное в плане идей насчёт того, как именовать файлы PDF- и DjVu-книг.

Хотя я думаю, что всё равно прийдётся разработать некий свой стандарт именования таких файлов. :-\ Это, конечно, очень неприятное занятие - совместно вырабатывать какой-либо стандарт. Но иного пути не вижу - какого-нибудь ГОСТа, который бы регламентировал именно имена файлы PDF- и DjVu-книг, я не обнаружил. :)

Приглашаю всех желающих высказаться на тему "Каким должен быть стандарт именования файлов PDF- и DjVu-книг". Давайте разработаем совместно такой стандарт. За основу, думаю, следует взять схему работы NameCreator http://www.djvu-soft.narod.ru/soft/namecreator.htm .

У меня пока что такие соображения:

1. Нужен жёсткий порядок следования первых N смысловых элементов в имени файла (типа "Автор", "Заглавие", ...). Допустим, на первом месте чтобы всегда шла фамилия автора (а так оно почему-то всегда и есть в реальной жизни), на втором - название книги, на третьем - год (издательство?), на четвёртом - количество страниц. Жёсткий порядок следования нужен для возможности машинного (полностью автоматического) разбора имени файла на отдельные смысловые элементы - типа "Название", "Автор", ... (при генерации хотя бы того же HTML-списка книг). После первых N элементов порядок оставшихся смысловых элементов пусть будет произвольным (ибо нельзя всё предусмотреть). Порядок следования и количество N нужно обсудить всем вместе.

2. Предлагаю ВСЕГДА разделять первые N смысловых элементов в имени файла каким-нибудь спецсимволом. "|" мне уже не очень нравится - т.к. слишком тесноту создаёт (визуально) в имени файла - неудобно для человеческого прочтения. Как насчёт знака одиночного подчёркивания? Кстати, подчёркивание обычно прекрасно поддерживается на разных системах именования, в разных языках, операционных системах и т.п.
Такой спецсимвол также нужен для возможности машинного (полностью автоматического) разбора имени файла.

3. Предлагаю указывать в имени файла 5-балльный квалификатор качества (см. предыдущие посты топика). И вместо нынешних конкретных признаков качества в духе NameCreator http://www.djvu-soft.narod.ru/soft/namecreator.htm "landscape", "kromsated", "dpi" и т.д. Т.е. указывать просто одну цифру, и перед нею, скажем, букву "Q" - означающую "quality". С буквой "Q", думаю, будет нагляднее (а то, если будет просто одна цифра, все станут себя спрашивать - "что это за цифра?"). Кстати, значение DPI вовсе не всегда есть синоним качества. Я видел и на 300 dpi превосходные книги - и погань на 600 dpi.

4. Никакие классификаторы области знания в имени файла предлагаю не указывать. Такие, как ISBN, УДК, ББК, и т.п. Всё это можно будет записать в метаданных файла - причём все сразу, какие только есть в книге (при желании) - там места много (в метаданных). Почему? Во-первых, слишком удлиняется имя файла. Во-вторых, нет единой стандартной системы такой классификации - старые советские книги используют только УДК, новые - ISBN. Получается несистематизируемый жёстко разнобой. К тому же, такая вещь, как ISBN, не предназначена для непосредственного человеческого восприятия - это более как справочное сведение. В общем, нечего ISBN делать именно в имени файла.

5. Если у книги больше одного автора - то указывать только первого по списку. Так, кстати, рекомендует ГОСТ 7-80.2000 (самый толковый из вышеперечисленных, между прочим).

6. Имя файла писать всегда латинскими буквами. Не-англоязычные названия книг не переводить на английский, а транслитерировать. Транслитерацию при необходимости осуществлять по ГОСТ 7.79-2000.

Вот черновой пример имени файла по такой схеме:

Avtor A. A._Nazvanie_1995_Izdatelstvo_225s_Q4.djvu

Человеко-наглядно, не правда ли? Это тоже важное требование к имени файла (человеко-наглядность).

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

Эта схема, конечно, обрисовывает всё лишь в общих чертах. Естественно, что будут ещё всякие детали.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 20 °ТУгбв 2010, 16:37:22
Ещё неплохо бы обсудить такую проблему, как запись файлов с длинными именами на DVD (CD) болванку. Обычно ведь тот же Nero ругается на такие имена, когда начинаешь делать проект под запись.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 15 БХЭвпСам 2010, 11:22:40
Снова заработал форум http://gen.lib.rus.ec/forum/

Сижу пока читаю там топики - на предмет почерпнуть какие-то соображения для будущего стандарта именования DjVu и PDF-файлов.

Пока что мне стало ясно, что то ли в названии файла, то ли в его метаданных должно фигурировать указание языка книги (в виде 2-3 буквенного идентификатора строчными буквами, наверное) - поскольку книги могут быть в общем случае не только русские или английские - но ещё и китайские, арабские, индийские и т.п.

К тому же, идентификатор языка потребуется для обратной автоматической транслитерации (при автоматическом составлении HTML-списка книг).

Думаю, что для всех этих языков тоже есть некие стандарты транслитерации. Так что, как мне кажется, для книг на любом языке имя файла следует писать на транслите (латинские буквы и обычная ASCII-кодировка).
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 15 БХЭвпСам 2010, 11:28:18
Интересная проблема - как назвать файл, если в названии бумажной книги присутствует символ двойной кавычки ". Ведь в Windows этот символ не может быть в имени файла.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 15 БХЭвпСам 2010, 14:37:08
По поводу метаданных в DjVu.

Оказывается, XMP-метаданные в DjVu ещё не одобрены официально компанией Caminova (владелец формата DjVu).

Официально одобрены пока только PDF DocInfo - метаданные. Точнее, их поддержка внедрена в DjVu Shell Extension Pack - официальный продукт от Caminova:

http://dev.caminova.jp/beta/djvu-wic/
Цитировать
Now uses PDF DocInfo compatible property names to conform to the djvuchanges.txt.
Эти же метаданные поддерживает (отображает) DjVu-просмотрщик DjView - из состава DjVuLibre.

Причём метаданные может иметь как весь DjVu-файл в целом - так и (дополнительно) каждая отдельная страница многостраничного DjVu-файла.

Вот пример скрипта для djvused, позволяющий внедрить в любой DjVu-файл PDF DocInfo - метаданные:
select; remove-ant; remove-txt
# -------------------------
select 1
set-ant
(metadata
    (Author    "Phil Harvey1")
    (Title    "DjVu Metadata Sample")
    (Subject    "ExifTool DjVu test image")
    (CreationDate    "2008-09-23T12:31:34-04:00")
    (ModDate    "2008-11-11T09:17:10-05:00")
    (Keywords    "ExifTool, Test, DjVu, XMP")
    (Producer    "djvused")
    (Trapped    "Unknown")
    (Creator    "ExifTool")
    (url    "http://owl.phy.queensu.ca/~phil/exiftool/")
    (note    "Must escape double quotes (\") and backslashes (\\)")
    (annote    "Did you get this?") )
.
Этот пример взят от автора ExifTool - редактора метаданных для множества форматов.

Из этого примера виден набор полей, поддерживаемых спецификацией PDF DocInfo.

В общем, я к тому, что запись PDF DocInfo-метаданных в DjVu файл уже можно реализовывать в своей программе. А вот надо ли реализовывать ещё и дополнительно XMP-данные для DjVu-файлов - пока неясно.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 15 БХЭвпСам 2010, 15:32:57
Я создал аналогичный топик на форуме либгена:

http://gen.lib.rus.ec/forum/viewtopic.php?f=6&t=786

Попробую также и там обсудить эту тему (если получится, конечно).
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 12:50:59
Вот мне один человек прислал письмо по теме:
Цитировать
очень полезно начинание.

Предлагаю начать с определения цели зачем это надо.

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

Но, как минимум, половина дальнейших рассуждений связана с требованием
"обратимости" имен, т.е. решением обратной задачи - извлечение из
имени метаинформации. Вот здесь, как по мне, и зарыто противоречие. А
именно - зачем извлекать метаинформацию из имени, если это можно
сделать из спец.полей файла или из спец.файла для метаинформации
(fbd)? Туда же все уже запихнуто вместе с формированием имени. Причем,
без всяких преобразований и искажений.

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

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

Потому как по этому номеру всегда можно получить метаинформацию из
он-лайновых баз данных. Судя по всему, у автора не совсем правильное
понимание что это такое, потому как ИСБН упоминается рядом с УДК, ББК
и т.д. Это принципиально разные вещи. ИСБН можно рассматривать как
уникальный код, однозначно определяющий набор метаданных типа
названия, авторов, данные об издании и т.п. Ессно, это немного
произвольная трактовка, звиняйте, но, по-моему, принцип оно отражает:)
Ну, т.е. ИСБН - это те же метаданные, но закодированные в виде набора
из 10 или 13 символов. И "раскодировать" их не представляет никакого
труда.

Ну и, если дополнение к исходной задаче в виде убрать требование
обратимости имени будет принято, тогда можно продолжать.
Ну а если нет - то я пас. Потому как в этом случае я считаю что задача
нерешаемая. Некоторые аргументы приводил БГ, у меня еще есть, но самое
главное - я не верю в возможность корректного решения задач, у которых
противоречия заложены в самой постановке.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 16 БХЭвпСам 2010, 12:57:25
Привет всем!
Выше мое письмо - не знал про здешний форум, увидел задачу на либгене, а там траблы на форуме продолжаются:)

Как вам предлагаемое изменение постановки задачи?
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 13:11:41
Отвечаю на письмо:
Цитировать
Понятно, удобочитаемые имена - полезно. Но для чего? Как по мне - то
чтоб видеть что в файле через любой файловый менеджер.
Да, именно для этого. И чтобы, не скачивая книгу, по её имени понять, что это за книга.
Цитировать
Кстати, придумали также спец. метафайл, содержащий только дескрипторы fb2, назвали его fbd. Предлагаю сразу и туда.
Пока не вижу смысла. Зачем "сразу и туда"? Во-первых, это в принципе не нужно, а во-вторых - всегда потом нетрудно будет сделать. Но вообще метаданные будут записываться одновременно - с формированием "говорящего" имени файла.
Цитировать
А именно - зачем извлекать метаинформацию из имени, если это можно сделать из спец.полей файла или из спец.файла для метаинформации (fbd)? Туда же все уже запихнуто вместе с формированием имени. Причем, без всяких преобразований и искажений.
Смысл есть. А что, если кто-нибудь не захочет пользоваться метаданными - по не важно какой причине? Например, просто не знает, что такое метаданные - и никак не может это понять. Или же не имеет специализированный софт для работы с PDF и DjVu-метаданными. Пример: кто-то захочет на веб-сервере реализовать именование файлов (по новому стандарту). Станет ли он заморачиваться ещё и реализацией поддержки PDF и DjVu-метаданных? Наверняка нет. Ведь метаданные в PDF и DjVu имеют строго предопределёный формат (т.е. набор полей). Абы какие метаданные (FB2-метаданные) в PDF или DjVu вставлять не положено.
Так что отказываться от обратимости имени файла в метаданные (естественно, частичной) не хотелось бы.
Цитировать
Ну и одно замечание что пихать в имя файла. как по мне - что что
угодно, т.е. это должен определять юзер, главное - чтоб имя файла без
проблем поддерживалось ВСЕМИ файловыми системами. Ессно, на
современном уровне:).
Тут у меня пока нет своего чёткого мнения. А зачем юзеру пихать в имя файла что попало (всё, что ему захочется)? Тогда автоматический разбор имени файла не получится. Пусть взамен юзер пихает "что попало" в метаданные - а не в имя файла. Тогда проблем никаких. Там места много, и полей данных достаточно.
Цитировать
Но один элемент - обязательно. Это ИСБН.
А вот это как раз не обязательно - по той простой причине, что не у каждой книги он есть вообще. "Не обязательно" - но "крайне желательно", я так полагаю.
Цитировать
Судя по всему, у автора не совсем правильное понимание что это такое, потому как ИСБН упоминается рядом с УДК, ББК и т.д.
Да, конечно, я не силён пока в этих вещах.
Цитировать
Ну и, если дополнение к исходной задаче в виде убрать требование
обратимости имени будет принято, тогда можно продолжать.
Ну а если нет - то я пас. Потому как в этом случае я считаю что задача
нерешаемая.
Убирать не хотелось бы. А почему именно нерешаемая? Из-за того, что тогда нельзя будет помещать в имя файла произвольную информацию?

Но возможен и компромисс: предусмотреть в конце файла опциональный раздел с произвольной информацией (где юзер будет иметь полную свободу). Этот раздел не будет парситься автоматическим каталогизатором - при разборе книг - ну да и ладно, автоматическому парсеру вполне хватит имеющихся жёстко предопределённых полей.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 16 БХЭвпСам 2010, 14:01:50
Цитировать
Цитировать
Понятно, удобочитаемые имена - полезно. Но для чего? Как по мне - то
чтоб видеть что в файле через любой файловый менеджер.
Да, именно для этого. И чтобы, не скачивая книгу, по её имени понять, что это за книга.
согласен. Ну дык и оставить только єту цель. Потому как чем проще задача - тем больше вероятность ее решения.
Цитировать
Цитировать
Кстати, придумали также спец. метафайл, содержащий только дескрипторы fb2, назвали его fbd. Предлагаю сразу и туда.
Пока не вижу смысла. Зачем "сразу и туда"? Во-первых, это в принципе не нужно, а во-вторых - всегда потом нетрудно будет сделать. Но вообще метаданные будут записываться одновременно - с формированием "говорящего" имени файла.
когда делать - другой вопрос, главное чтобы можно было. Главный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net. Если есть набор таких файлов рядом с книгами. остается натравить его на каталог с файлами - а дальше все будет сделано само.
Цитировать
Цитировать
А именно - зачем извлекать метаинформацию из имени, если это можно сделать из спец.полей файла или из спец.файла для метаинформации (fbd)? Туда же все уже запихнуто вместе с формированием имени. Причем, без всяких преобразований и искажений.
Смысл есть. А что, если кто-нибудь не захочет пользоваться метаданными - по не важно какой причине? Например, просто не знает, что такое метаданные - и никак не может это понять. Или же не имеет специализированный софт для работы с PDF и DjVu-метаданными. Пример: кто-то захочет на веб-сервере реализовать именование файлов (по новому стандарту). Станет ли он заморачиваться ещё и реализацией поддержки PDF и DjVu-метаданных? Наверняка нет. Ведь метаданные в PDF и DjVu имеют строго предопределёный формат (т.е. набор полей). Абы какие метаданные (FB2-метаданные) в PDF или DjVu вставлять не положено.
Так что отказываться от обратимости имени файла в метаданные (естественно, частичной) не хотелось бы.
по порядку. Если кто-то не захочет пользоваться метаданными - пусть не пользуется, никто не заставляет, но вот подменять понятия - в данном случае "метаданные" подменять именем файла не надо никогда, потому как это неправильно в принципе.
Если кто-то не знает, что такое метаданные, то пусть выучит что это, а не изобретает велосипед. Потому как потом хаоса будет больше и порядок в нем наводить гораздо труднее, нежели изначально его не плодить. Во-вторых, метаданными имеет смысл пользоваться только для создания базы. А если понимание дошло до того, что база - нужна, то и понятие "метаданные" уже не будет открытием.

Цитировать
Цитировать
Ну и одно замечание что пихать в имя файла. как по мне - что что
угодно, т.е. это должен определять юзер, главное - чтоб имя файла без
проблем поддерживалось ВСЕМИ файловыми системами. Ессно, на
современном уровне:).
Тут у меня пока нет своего чёткого мнения. А зачем юзеру пихать в имя файла что попало (всё, что ему захочется)? Тогда автоматический разбор имени файла не получится. Пусть взамен юзер пихает "что попало" в метаданные - а не в имя файла. Тогда проблем никаких. Там места много, и полей данных достаточно.
Например, у меня есть электронная читалка и я хочу рассортировать книги в одном каталоге, но чтоб видно было к какой серии (том, издание) они относились. Здесь в имени надо ставить сначала серию, потом - автора. Для другой читалки требования могут быть другими.
Цитировать
Цитировать
Но один элемент - обязательно. Это ИСБН.
А вот это как раз не обязательно - по той простой причине, что не у каждой книги он есть вообще. "Не обязательно" - но "крайне желательно", я так полагаю.
ессно, если ИСБН есть. А на нет - и суда нет:) Тем более, что ИСБН не читаем, и будет дополнением к имени где есть нормальное название. Ну а нету ИСБН у книги - и не будет этого куска.
Цитировать
Цитировать
Ну и, если дополнение к исходной задаче в виде убрать требование
обратимости имени будет принято, тогда можно продолжать.
Ну а если нет - то я пас. Потому как в этом случае я считаю что задача
нерешаемая.
Убирать не хотелось бы. А почему именно нерешаемая? Из-за того, что тогда нельзя будет помещать в имя файла произвольную информацию?
1.основная причина этого - в  разной природе данных.
Имена файлов - короткие - до 255 символов
сюда входят также путь до корневого каталога библиотеки, а это - величина переменная для каждого юзера
2.кодировка-транслитерация. Вобчем, нет ни одного стандарта, где бы описывалась транслитерация ВСЕХ символов. Потому что сейчас транслитерация как таковая уже не очень актуальна. Так, ошметки старых технологий. Все новое и в юникоде прекрасно живет без всякой транслитерации. Т.е. здесь придется городить некий гибрид, трудоемкость создания которогону очччень большая, а смысл?
3.разделение полей в имени. Нормально это только тегами можно сделать, у тебя это токены, но они тоже занимают место, и это все - из тех же 255 символов. А если ты хочешь в имя запихнуть много полей, то у тебя получится, что от трети до половины длины имени уйдет на сами токены. А они ж нужны не для того, чтоб видеть, т.е. для главной задачи, а только для разбора. Т.е. причина - в смешении двух задач в кучу. И в том, что эти задачи - противоречивы.
4.опыт. Работал много на почве создания база данных из имен файлов. Типа, занимался как раз той обратной задачей - извлекал метаданные. И не видел ни одной системы именования, чтобы она позволяла однозначно решить задачу. В лучшем случае будет потеря метаинформации, в худшем- обрезание и смешение разных типов.
Цитировать
Но возможен и компромисс: предусмотреть в конце файла опциональный раздел с произвольной информацией (где юзер будет иметь полную свободу). Этот раздел не будет парситься автоматическим каталогизатором - при разборе книг - ну да и ладно, автоматическому парсеру вполне хватит имеющихся жёстко предопределённых полей.
каталогизация - это совершенно другая задача. ПРичем уже во многих отношениях решенная - см. тот же хокм-либ. Такох прог еще с десяток найти можно. У всех у них основная проблема - где брать метаинформацию, все решают по разному, ну дык и пусть берут ее с фбд файлов. А курочить имена они до сих пор не научилсь. Так почему ты думаешь, что научатся в будущем?

Ну а предусмотреть "опционально" - ну дык и я говорю, что имя изначально должно строиться как юзер захотел. Типа, в ИНИ файле описал шаблон - получил опциональность.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 15:10:43
kv
Цитировать
Главный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net.
Ещё раз повторюсь: форматы PDF и DjVu поддерживают строго предопределённый формат метаданных - т.е. фиксированный набор полей (с предопределёнными именами). И никакой иной формат метаданных (из FB2) применять для форматов PDF и DjVu недопустимо.
Цитировать
Если есть набор таких файлов рядом с книгами. остается натравить его на каталог с файлами - а дальше все будет сделано само.
Набор файлов рядом с книгами - это вообще некрасивое решение. Для этого существуют метаданные.
Цитировать
Например, у меня есть электронная читалка и я хочу рассортировать книги в одном каталоге, но чтоб видно было к какой серии (том, издание) они относились. Здесь в имени надо ставить сначала серию, потом - автора. Для другой читалки требования могут быть другими.
А это уже совсем другой вопрос - не имеющий к рассматриваемому никакого отношения. Пусть это будет головной болью конкретного юзера - а не нашей. Нужна ему некая иная схема именования - так это его проблемы - при чём здесь мы? Нас волнует только то, как упорядочить книги в больших онлайн-библиотеках - И ВСЁ.

Я-то подразумеваю, что мы тут создаём формат именования файлов для больших онлайн-библиотек (и для хранения на DVD их в скаченном виде). А пользователь у себя на компьютере потом пусть переименовывает файлы так, как ему хочется, и как ему вздумается. Естественно, универсальная система именования на все случаи жизни невозможна.
Я же взял за основу программу Name Creator http://www.djvu-soft.narod.ru/soft/namecreator.htm - она существует уже много лет, и как известно, вполне успешно применяется.
Цитировать
1.основная причина этого - в  разной природе данных.
Имена файлов - короткие - до 255 символов
сюда входят также путь до корневого каталога библиотеки, а это - величина переменная для каждого юзера
Ну Name Creator делает ещё более длинные имена файлов - чем мною предлагаемые - и ничего, хватает, видимо 255 символов.
Цитировать
2.кодировка-транслитерация. Вобчем, нет ни одного стандарта, где бы описывалась транслитерация ВСЕХ символов. Потому что сейчас транслитерация как таковая уже не очень актуальна. Так, ошметки старых технологий. Все новое и в юникоде прекрасно живет без всякой транслитерации. Т.е. здесь придется городить некий гибрид, трудоемкость создания которогону очччень большая, а смысл?
Смысл большой - ПРОСТОТА. Мне программно в тысячу раз проще работать на ASCII-коде - чем на Юникоде. И не везде Юникод-имена поддерживаются (Windows 98, например). Большинство книг в PDF и DjVu имеют названия на популярных языках - для которых предусмотрена транслитерация. Если же для каких-то символов не предусмотрена транслитерация - всё равно можно как-то выкрутиться. И Name Creator работает на ASCII-коде - и правильно делает. Я против Юникода. Это дело далёкого будущего - когда ASCII умрёт естественной смертью.
И Юникод не одинаково хорошо везде поддерживается, да и разный он (UTF8, UTF16, с BOM и без него, и т.п.). А сколько гемора бывает при переводе из Юникода во что-то иное? Нет, Юникод - ИМХО сложная и неподходящая сущность пока что, порождающая кучу проблем. Ничего, вполне перебьёмся кодами ASCII - с вполне достаточной точностью (для наших целей).
Цитировать
4.опыт. Работал много на почве создания база данных из имен файлов. Типа, занимался как раз той обратной задачей - извлекал метаданные. И не видел ни одной системы именования, чтобы она позволяла однозначно решить задачу. В лучшем случае будет потеря метаинформации, в худшем- обрезание и смешение разных типов.
Можно подробнее? Желательны какие-то примеры - а то голословно непонятно.
Я опираюсь на опыт работы программы Name Creator. Она давно и успешно работает - я лишь предлагаю её модернизировать.
Цитировать
ессно, если ИСБН есть. А на нет - и суда нет:) Тем более, что ИСБН не читаем, и будет дополнением к имени где есть нормальное название. Ну а нету ИСБН у книги - и не будет этого куска.
Да, я тоже так думаю. А если нет ISBN, но есть, скажем, УДК - то писать UDK ... (по желанию).
Цитировать
каталогизация - это совершенно другая задача. ПРичем уже во многих отношениях решенная - см. тот же хокм-либ. Такох прог еще с десяток найти можно. У всех у них основная проблема - где брать метаинформацию, все решают по разному, ну дык и пусть берут ее с фбд файлов. А курочить имена они до сих пор не научилсь. Так почему ты думаешь, что научатся в будущем?
Но я пока не вижу причин, почему бы нельзя было делать каталогизацию, "куроча имя файлов". Я пока не вижу притиворечия между 2 задачами "сделать говорящее имя файла" и "сделать автоматический разбор имени файла для автоматической каталогизации".
Цитировать
Так почему ты думаешь, что научатся в будущем?
А почему нет? Объясните, пожалуйста. Вот пример имени файла:

Avtor A. A., Vtoroj B.B., Tretij V.V.__Nazvanie_225s_RU_1995_Izdatelstvo_2izd_ISBN 0000000000_Q4.djvu

Смотрите - здесь решены сразу обе задачи.

Задача 1 (Человеко-информативное имя):
По имени файла видна (человеку - не скачивая с сайта книгу) вся основная информация о книге - кто автор, какое название, и т.п.

Задача 2 (Поддержка автоматической каталогизации):
Такое имя файла легко разбивается машинным способом на токены - Автор, Название, Год, Издание, и т.п. Это очень удобно для автоматической генерации HTML-списков имеющихся у юзера книг. Вот юзер, допустим, накачал с Интернета в произвольном порядке таких файлов, и свалил их все в одну папку. А потом запускает некий каталогизатор - и тот юзеру на полном автомате генерирует HTML-список книг - разбивая его на столбцы "Автор", "Название", и т.п. Причём попутно генерируются гиперлинки - кликнув на которые, можно будет открыть PDF или DjVu в просмотрщике.

Разве это не удобно и такой функционал будет лишним? Это же полностью автоматизирует каталогизацию накаченного из Сети (т.е. только PDF- и DjVu-книг).

Вы хотите сказать, что такая схема автоматической каталогизации будет зато негибкой (а слишком строго предопределённой) - и другим юзерам захочется как-то иначе каталогизировать - а потому, дескать, это "задача нерешаемая"?

Да, это негибкая схема каталогизации. Но a что может быть взамен? Да ничего - взамен может быть только вариант с полным отсутствием поддержки автоматической каталогизации. Но будет ли от этого лучше - если вообще отказаться от поддержки автоматической каталогизации? Думаю, нет. Пусть лучше будет хоть плохая - чем вообще никакая.
Цитировать
Главный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net.
Это не довод. Ну и что, что "они уже есть"? А если там, к примеру, не то, что нам нужно? Хотя что там такое - я не знаю - попробую тот сайт почитать.
Цитировать
3.разделение полей в имени. Нормально это только тегами можно сделать, у тебя это токены, но они тоже занимают место, и это все - из тех же 255 символов. А если ты хочешь в имя запихнуть много полей, то у тебя получится, что от трети до половины длины имени уйдет на сами токены.
А с Name Creator всё делается сейчас ничуть не лучше. Там хоть не подчёркивания - так зато пробелы взамен (без пробелов нельзя - они для человеко-понятности нужны).
Цитировать
А если ты хочешь в имя запихнуть много полей, то у тебя получится,
А почему я должен этого хотеть? Мне это НЕ НАДО. Надо лишь довольно ограниченный стандартный набор токенов привести в имени - и ДОСТАТОЧНО. Ради чего ещё что-то пхать в имя файла? Не вижу смысла.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 15:31:54
Вот ещё у меня раньше была мысль - помещать в имя файла книги некий токен, определяющий своего рода "код области знания", к которому относится данная книга. Это для повышения точности/удобства автоматической каталогизации. Тем более, что такой токен есть в Name Creator.

Но потом я от этой идеи отказался - слишком сложно. Практически-нереализуемо. А в Name Creator код области знания - условный, из таблицы кодов знания электронной библиотеки "Колхоз" (так что всем остальным юзерам от него нет проку).
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 16:27:32
kv
Читаю страницу http://wiki.home-lib.net/index.php/%D0%A7%D1%82%D0%BE_%D1%82%D0%B0%D0%BA%D0%BE%D0%B5_FBD
Цитировать
Что такое FBD

FBD - это формат хранения описаний книг.

Файлы описаний используются для хранения библиографической информации об электронных версиях книг в форматах, не позволяющих вносить данную информацию в сами файлы. К таким форматам относятся TXT, DjVu, DOC/RTF и многие другие форматы, изначально не предназначенные для создания на их базе электронных книг.

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

По сути своей, файл в формате FBD является пустым докуметом в формате FB2 с заполненным описанием.

Файлы описаний должны иметь тоже имя, что и файлы книги и располагаться в одной с ними дирректории или архиве. К примеру, если электронная книга имеет имя "Book.pdf", то файл описаний - "Book.fbd"

Они могут содержать в себе такие выходные данные книга, как имя автора, название, серия, обложка, аннотация, данные об исходной книге, жанр и многое другое. Как уже говорилось ранее, самым большим преимуществом в использованини файлов описаний является возможность рабоать с книгами в форматах, отличных от FB2 в автоматическом режиме. Это позволит загружать его в онлайн-библиотеки, скачивать и добавлять в программы-каталогизаторы без дополнительного ввода пользователем информации о книге.
Здесь неточная информация: Формат DjVu уже позволяет осуществлять "хранение библиографической информации об электронных версиях книг" - т.е. другими словами, он поддерживает метаданные. Это раньше так было, что DjVu не поддерживал метаданные - но не теперь - теперь поддерживает.

Естественно, использование метаданных гораздо лучше, чем использование таких вот FBD-файлов.

И, скорее всего, вся та информация, что содержится в FBD-файлах, может быть записана в метаданных DjVu (PDF) файла. Точно не могу сказать - насколько велико совпадение - но наверняка довольно близко.

Кстати - файлы в форматах TXT и DOC я бы предложил автоматически преобразовывать в FB2. Благо, что и софт для этого есть (или реально сделать). FB2 во всех отношениях выигрышнее, чем TXT, DOC и даже HTML.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 16:47:57
kv
Такая фича, как поддержка именем файла автоматической каталогизации, будет не лишней. Тогда можно будет разделять операцию генерации имён файлов и операцию генерации метаданных файлов. Допустим, один человек генерирует "говорящие" имена и загружает в Интернет полученные файлы (названные этими именами). А другой берёт и внедряет в них метаданные - автоматически генерируя их из имён файлов. Естественно, при этом заполнятся не все поля метаданных - а лишь некоторая часть (поскольку в имени файла будут только ключевые данные - в метаданных вообще гораздо больше инфы помещается).

Зачем нужна такая схема? (когда один заполняет имена файлов - а второй на их основе - метаданные) Затем, что у первого человека может не быть технической возможности внедрять DjVu и PDF-метаданные.

По поводу транслита: поскольку в имени файла всегда будет содержаться токен языка книги, то тогда уж всегда будет ясно, по какому стандарту производить обратную транслитерацию из транслита в конкретный язык. Думаю, практически для каждого языка существует что-то вроде ГОСТа (или ISO-стандарта), задающего взаимно-однозначное прямое и обратное транслитерирование.
Зато использование ASCII вместо Юникода даёт максимальную простоту программной работы с именами файлов.

В мире не найдётся компьютера, который не поддерживал бы ASCII - зато сколько угодно компьютеров, не поддерживающих Юникод. (в смысле "по факту" не поддерживающих, а не "вообще")
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 17:07:30
kv
Кажется, я понял суть Вашей критики.

Оказывается, каталогизация может быть разной - для домашней библиотеки - и для онлайн-библиотеки.

Для домашней каталогизации требования гораздо выше, чем для онлайн-библиотеки. Это видно хотя бы из рассмотрения http://home-lib.net/ .

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

Так что задачи и опыт http://home-lib.net/ практически мало применимы для целей данного топика. Для онлайн-библиотеки достаточна лишь самая общая каталогизация. Самая "аскетичная", так сказать. Такую вполне можно утиснуть в предопределённый набор токенов в имени файла.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 17:31:05
kv
Мне пришла в голову такая мысль:

А знаете - мы вполне можем разработать не одну схему именования файлов - а несколько полностью независимых друг от друга таких схем! :o

Ведь у нас есть метаданные - и никто нам не мешает, взяв метаданные, из них автоматически (по определённому шаблону) генерировать имена файлов по самой понравившейся схеме (схеме именования)!

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

Какие-то иные схемы могут быть для иных случаев жизни.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 16 БХЭвпСам 2010, 17:56:08
kv
Кажется, я понял суть Вашей критики.

Оказывается, каталогизация может быть разной - для домашней библиотеки - и для онлайн-библиотеки.

Для домашней каталогизации требования гораздо выше, чем для онлайн-библиотеки. Это видно хотя бы из рассмотрения http://home-lib.net/ .

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

Так что задачи и опыт http://home-lib.net/ практически мало применимы для целей данного топика. Для онлайн-библиотеки достаточна лишь самая общая каталогизация. Самая "аскетичная", так сказать. Такую вполне можно утиснуть в предопределённый набор токенов в имени файла.
неправильно.
Потому как каталогизация он-лайн-библиотек - это ВСЕГДА файлы+база данных. И как именуется файл - здесь вообще по барабану. Например, в либгене файлы именуются по мд5 хешу. Даже без расширения. А хочет юзер скачать себе файл - ему выдается имя файла, сгенеренное "на лету" по полям базы. Так что для он-лайн либов нет проблемы обозвать файл, а есть проблема найти метаданные, чтоб засунуть их в базу.

Я так понял, что ты (сорри, привычка, предлагаю перейти) разрабатываешь эту задачу с целью генерации имен для НОВЫХ ОТСКАНЕННЫХ книг. Вот я и говорю - для них метаданные надо совать в 2 места - в сам файл, в служебное поле, а там можно поизвращаться как угодно, например, данные для которых есть поля, засунуть в поля, а те, что есть - в какое-то поле примечаний и туда уже токены и прочие вкусности. А заодно - фб2 - это вообще просто, это XML файл. Текм самым убиваются решаются 2 задачи
1.ДЛя он-лайн либов легко решается задача добывания метаданных
2.Для домашней либы легко решается задача подключения новой книги посредством каталогизаторов, поддерживающих фбд.

Ну а именование файла - это делается на основе шаблона в ини файле - кто как захотел - тот так и поименовал. Я не берусь предсказать предпочтения сканировщиков.

Касаемо опыта добывания инфы из имен файлов, то посмотри на траблы, что возникли при развертывании либгена.
1.Простое развертывание либы Колхоза на домашнем компе - сложная задача, которая уперлась как раз в 255 символов. В результате BookWarrior наваял инсталлятор в виде батников, который переделывал колхозные имена что файлы тупо можно было скопировать к себе н комп.
2.потом он сколько-то времени курочил колхозные имена файлов стоб добыть оттуда метаданные для базы данных.
3.потом я лично правил поля на предмет правильно разнесения инфы по полям, разных там сокращений, правильного порядка в ФИО и т.д.
4.после этого к базе либгена добавлено еще 220 тыс книг, и примерно для половины из них инфа берется из имен файлов.
5.в результате качество описания книг после 120 тыщи резко пошло вниз, потому как БГ добавляет книги быстрее чем народ правит поля в базе.

Ну а в качестве примера - вот тебе страница, попрактикуйся составлять имена а потом посмотри что получается.
http://free-books.dontexist.com/search?req=%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F+%D1%82%D0%B5%D0%BE%D1%80%D0%B8%D1%8F&nametype=orig




Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 16 БХЭвпСам 2010, 18:18:07
kv
Очень интересно.

Короче говоря, по большому счёту мы приходим к той мысли, что самое главное - это правильно заполнить метаданные - а какое при этом будет имя файла - вообще не важно (главное, чтобы оно было не более 255 символов, включая путь). Я правильно понял главный вывод? :)
Цитировать
Я так понял, что ты (сорри, привычка, предлагаю перейти) разрабатываешь эту задачу с целью генерации имен для НОВЫХ ОТСКАНЕННЫХ книг.
Да-да, именно так. Вот отсканировал человек у себя дома книгу - пускай он её "правильно" назовёт (как минимум) - и только потом заливает в Интернет.
Цитировать
Вот я и говорю - для них метаданные надо совать в 2 места - в сам файл, в служебное поле, а там можно поизвращаться как угодно,
Я и предлагаю, что моя программа будет ОДНОВРЕМЕННО генерировать как инфоративное имя - так и метаданные - и будет эти метаданные записывать - внутрь самого файла.
Цитировать
А заодно - фб2 - это вообще просто, это XML файл.
Вы имеете в виду "формат FBD"? Я надеюсь, что его можно будет полностью автоматически генерировать из PDF- и DjVu-метаданных (точно, правда, не знаю, так ли это - но скорее всего).
Цитировать
1.Простое развертывание либы Колхоза на домашнем компе - сложная задача, которая уперлась как раз в 255 символов. В результате BookWarrior наваял инсталлятор в виде батников, который переделывал колхозные имена что файлы тупо можно было скопировать к себе н комп.
А ведь и вправду это проблема. :) И как это колхозники изначально не дотумкали до этого? :)
Цитировать
2.потом он сколько-то времени курочил колхозные имена файлов стоб добыть оттуда метаданные для базы данных.
Ага, ну вот видите - если бы уже тогда был в ходу такой стандарт, как я предлагаю, то тогда наполнение метаданных (хотя бы частичное) шло бы автоматом - путём парсинга имён файлов.
Цитировать
Ну а в качестве примера - вот тебе страница, попрактикуйся составлять имена а потом посмотри что получается.
Не пойму - что значит "попрактикуйся"? Зачем?

В общем, я так думаю: постараюсь основной упор сделать на правильность заполнения юзером метаданных (в свежеотсканенных PDF и DjVu).
Цитировать
Ну а именование файла - это делается на основе шаблона в ини файле - кто как захотел - тот так и поименовал. Я не берусь предсказать предпочтения сканировщиков.
Я тоже так думаю - генерировать информативное имя файла из его метаданных по заданному шаблону (выбирая шаблон по своему вкусу). С одним уточнением: давайте один такой шаблон сделаем "шаблоном по умолчанию". Всё-таки как-то слишком уж необычно, если юзер будет выкладывать в Сеть файл с именем в виде md5. ;D Давайте уж лучше ему разработаем "шаблон по умолчанию" - с которого я и начал данный топик.

Правда, надо как-то решить проблему 255 символов. Буду думать и искать компромисс. Первое, что приходит на ум - задать ограничение длины имени файла - порядка 240-250 (от силы) символов. С расчётом хранения книг либо в первой папке в корне DVD, либо в папке, скажем "D:\1". Что-то в этом роде.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 16 БХЭвпСам 2010, 20:31:58
kv
Очень интересно.

Короче говоря, по большому счёту мы приходим к той мысли, что самое главное - это правильно заполнить метаданные - а какое при этом будет имя файла - вообще не важно (главное, чтобы оно было не более 255 символов, включая путь). Я правильно понял главный вывод? :)
не совсем. надо добавить
2.чтоб имя содержало только символы, допустимые в большинстве файловых систем.
3.чтоб оно было "удобочитаемым" с точки зрения юзера. Причем здесь должна быть полная свобода понимания термина "удобочитаемость". Вон, например, для БВ допустимы только имена файлов=мд5, мне достаточно название-авторы-год-ИСБН.расширение и т.д. Т.е. поддержка шаблона для формирования имен.
Цитировать
Цитировать
Я так понял, что ты (сорри, привычка, предлагаю перейти) разрабатываешь эту задачу с целью генерации имен для НОВЫХ ОТСКАНЕННЫХ книг.
Да-да, именно так. Вот отсканировал человек у себя дома книгу - пускай он её "правильно" назовёт (как минимум) - и только потом заливает в Интернет.
ну дык тогда главное - дать человеку средство, облегчающий процесс "правильного называния". А это уже зависит от твоих программерских навыков, потому как придумать можно много. Например, если в книге есть ИСБН, то самое правильное - помочь челу вычленить его, а потом пусть прога сама слазит в базу ИСБН и выгребет оттуда все что там есть и предложит поместить это в поля метаданных. В либгене, кстати, такое есть - при добавлении и редактировании книги.
Цитировать
Цитировать
Вот я и говорю - для них метаданные надо совать в 2 места - в сам файл, в служебное поле, а там можно поизвращаться как угодно,
Я и предлагаю, что моя программа будет ОДНОВРЕМЕННО генерировать как инфоративное имя - так и метаданные - и будет эти метаданные записывать - внутрь самого файла.
внутрь - отлично. А сгенерить фбд что мешает? ПОтому как многие каталогизаторы не умеют лазать внутрь пдф или джву, но понимают фбд. Твоя ж задача - облегчить жизнь дальнейшим юзателям твои сканов? Вот и облегчи...
Цитировать
Цитировать
А заодно - фб2 - это вообще просто, это XML файл.
Вы имеете в виду "формат FBD"? Я надеюсь, что его можно будет полностью автоматически генерировать из PDF- и DjVu-метаданных (точно, правда, не знаю, так ли это - но скорее всего).
можно, но таких прог я пока не знаю. Может потому как не искал, но, думаю, что пока нету, потому как фбд- сравнительно новое новшество. ВОт и сделай такой генератор, думаю, будет полезно...
Цитировать
Цитировать
2.потом он сколько-то времени курочил колхозные имена файлов стоб добыть оттуда метаданные для базы данных.
Ага, ну вот видите - если бы уже тогда был в ходу такой стандарт, как я предлагаю, то тогда наполнение метаданных (хотя бы частичное) шло бы автоматом - путём парсинга имён файлов.
дык парсили колхозные имена - там есть достаточно четкая система. Name Creator - сам же говорил. Но вот достать оттуда чтоб однозначно - тяжко. Ну и названия и авторы там обрезаны иногда.
Цитировать
Цитировать
Ну а в качестве примера - вот тебе страница, попрактикуйся составлять имена а потом посмотри что получается.
Не пойму - что значит "попрактикуйся"? Зачем?
в смысле на основании метаданных что есть в базе, попробуй сделать имена по твоему алгоритму. И увидишь, что часть метаданных ты потеряешь. Ну а если не потеряешь - покажи, тебе памятник:)

Цитировать
В общем, я так думаю: постараюсь основной упор сделать на правильность заполнения юзером метаданных (в свежеотсканенных PDF и DjVu).
да, это правильно!
Цитировать
Цитировать
Ну а именование файла - это делается на основе шаблона в ини файле - кто как захотел - тот так и поименовал. Я не берусь предсказать предпочтения сканировщиков.
Я тоже так думаю - генерировать информативное имя файла из его метаданных по заданному шаблону (выбирая шаблон по своему вкусу). С одним уточнением: давайте один такой шаблон сделаем "шаблоном по умолчанию". Всё-таки как-то слишком уж необычно, если юзер будет выкладывать в Сеть файл с именем в виде md5. ;D Давайте уж лучше ему разработаем "шаблон по умолчанию" - с которого я и начал данный топик.
дык а в чем проблема - твоя прога поставляется с одним вариантом ини файла, где записан "твой" шаблон - это и есть по умолчанию. А кого не устраивает и кто поймет как делать другие - сделает себе свой.

Цитировать
Правда, надо как-то решить проблему 255 символов. Буду думать и искать компромисс. Первое, что приходит на ум - задать ограничение длины имени файла - порядка 240-250 (от силы) символов. С расчётом хранения книг либо в первой папке в корне DVD, либо в папке, скажем "D:\1". Что-то в этом роде.
ага, вот в колхозе так и сделали. В результате, собрать колхоз можно только в корне диска. Ну а сейчас когда диски можно монтировать куда угодно в дерево каталогов, ты юзерам подкладываешь свинью.
Вобчем, проблема 255 никак не решается. В принципе. Потому как еще раз - не надо путать имя файла и метаданные. Вот не путай, и у тебя такой проблемы не будет.

Я уже молчу о том, что в либгене есть больше тыщи книг, у которых длина имена книги > 300 символов. Ты их как обрезать предлагаешь - по слову или прямо в середине слова?
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 17 БХЭвпСам 2010, 09:28:55
kv
Цитировать
2.чтоб имя содержало только символы, допустимые в большинстве файловых систем.
То есть ASCII.
Цитировать
Например, если в книге есть ИСБН, то самое правильное - помочь челу вычленить его, а потом пусть прога сама слазит в базу ИСБН и выгребет оттуда все что там есть и предложит поместить это в поля метаданных.
Ну, на такое я пока вообще не замахиваюсь. Может быть, в отдалённом будущем.
Цитировать
3.чтоб оно было "удобочитаемым" с точки зрения юзера. Причем здесь должна быть полная свобода понимания термина "удобочитаемость".
Да, я полностью согласен с обоими положениями.
Цитировать
внутрь - отлично. А сгенерить фбд что мешает? ПОтому как многие каталогизаторы не умеют лазать внутрь пдф или джву, но понимают фбд.
А зачем именно мне генерить FBD? Пусть это делает не лично сам единичный юзер - а автоматическая программа в онлайн-библиотеке - когда юзер уже загрузит туда свою книгу. Или же домашний каталогизатор у юзера.
Цитировать
можно, но таких прог я пока не знаю. Может потому как не искал, но, думаю, что пока нету, потому как фбд- сравнительно новое новшество. ВОт и сделай такой генератор, думаю, будет полезно...
Я не буду (это уже чрезмерно будет лично для меня) - но кто-то иной - вполне сможет сделать.
Строго говоря, генерировать FBD вообще не нужно. Зачем - когда уже есть метаданные в DjVu и PDF. Грубо говоря, FBD и метаданные в DjVu и PDF - это одно и то же. FBD может оказаться выгоднее лишь в бОльшей скорости доступа туда (но не факт).
Цитировать
дык парсили колхозные имена - там есть достаточно четкая система. Name Creator - сам же говорил. Но вот достать оттуда чтоб однозначно - тяжко. Ну и названия и авторы там обрезаны иногда.
Колхозные имена так просто не пропарсишь. Я же предлагаю такой шаблон говорящего имени, который будет парситься полностью автоматически.
Цитировать
в смысле на основании метаданных что есть в базе, попробуй сделать имена по твоему алгоритму. И увидишь, что часть метаданных ты потеряешь.
Да, потеряю. Иначе не получится. В имени файла могут уместиться только самые ключевые метаданные.
Цитировать
дык а в чем проблема - твоя прога поставляется с одним вариантом ини файла, где записан "твой" шаблон - это и есть по умолчанию. А кого не устраивает и кто поймет как делать другие - сделает себе свой.
Да, всё так и будет.
Цитировать
ага, вот в колхозе так и сделали. В результате, собрать колхоз можно только в корне диска. Ну а сейчас когда диски можно монтировать куда угодно в дерево каталогов, ты юзерам подкладываешь свинью.
Вобчем, проблема 255 никак не решается. В принципе.
Да, я согласен с тем, что "проблема 255 никак не решается в принципе". Всё, что тут можно сделать - ввести жёсткое ограничение на длину имени файла порядка 245 символов.
Цитировать
Я уже молчу о том, что в либгене есть больше тыщи книг, у которых длина имена книги > 300 символов. Ты их как обрезать предлагаешь - по слову или прямо в середине слова?
Даже не знаю. А как лучше? Но обрезать-то прийдётся по-любому. Но, надеюсь, в любом случае, 245 символов хватит, чтобы сохранить человеко-понятность имени файла - а точные данные о книге всё равно будут храниться в метаданных.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 17 БХЭвпСам 2010, 10:11:38
Я спросил у хозяина библиотеки Homelab - есть ли у него какие-то соображения по данной тематике? Вот что он мне ответил:
Цитировать
Нет, у меня нет. Сам я именую книги по минимуму трудозатрат (именно потому, что через меня проходит много книг):
- один-два автора или редактор - для поиска по автору
- по возможности точное название книги - для поиска по характерным словам
- год - для того определять новизну книги и издания
- иногда, дополнительно, качество (если плохое) и/или пояснение к книге, если название неинформативно.
Скрипт который делает странички добавляет размер файла (для определения возможности скачивания) и тип файла.
Думаю, что колхозное нименование дает слишком много ненужной пользователю информации, к тому же большинство из них не знает что обозначают всякие символы.

Если что и было бы желательно добавить, так это количество страниц книги.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 17 БХЭвпСам 2010, 10:57:34
Цитировать
внутрь - отлично. А сгенерить фбд что мешает? ПОтому как многие каталогизаторы не умеют лазать внутрь пдф или джву, но понимают фбд.
А зачем именно мне генерить FBD? Пусть это делает не лично сам единичный юзер - а автоматическая программа в онлайн-библиотеке - когда юзер уже загрузит туда свою книгу. Или же домашний каталогизатор у юзера.
Цитировать
можно, но таких прог я пока не знаю. Может потому как не искал, но, думаю, что пока нету, потому как фбд- сравнительно новое новшество. ВОт и сделай такой генератор, думаю, будет полезно...
Я не буду (это уже чрезмерно будет лично для меня) - но кто-то иной - вполне сможет сделать.
Строго говоря, генерировать FBD вообще не нужно. Зачем - когда уже есть метаданные в DjVu и PDF. Грубо говоря, FBD и метаданные в DjVu и PDF - это одно и то же. FBD может оказаться выгоднее лишь в бОльшей скорости доступа туда (но не факт).
хозяин-барин. Ессно, решать что делать - тебе. Но имей в виду, если этого не сделаешь, то твоя прога будет востребована лично тобой и еще может десятком сканировщиков, а твои файлы встроить в либу, что домашнюю, что серверную, будет так же сложно как и сейчас. Потому как кому-то придется писать для этого софт. Не факт что кто-то это сделает. А если сделаешь - то ты решишь не только задачу именования, но и задачу дальнейшего распространения твоих сканов. Надо это тебе или нет - решать тебе.
Цитировать
Цитировать
дык парсили колхозные имена - там есть достаточно четкая система. Name Creator - сам же говорил. Но вот достать оттуда чтоб однозначно - тяжко. Ну и названия и авторы там обрезаны иногда.
Колхозные имена так просто не пропарсишь. Я же предлагаю такой шаблон говорящего имени, который будет парситься полностью автоматически.
это называется "за рыбу гроши". Вроде как уже согласились что метаданные надо доставать из метаданных дву и пдф, я еще и за фбд ратую. А ты снова - парсить имена. Еще раз. Если есть метаданные полные, парсить имена - зло. И не надо делать ничего, что бы облегчило это зло. Надо приучать народ пользоваться правильными данными. Потому я и говорю про фбд - оттуда данные достать проще, чем из пдф и джву. Да и вообще - это текстовый формат, там даже блокнот поможет.
Цитировать
Цитировать
в смысле на основании метаданных что есть в базе, попробуй сделать имена по твоему алгоритму. И увидишь, что часть метаданных ты потеряешь.
Да, потеряю. Иначе не получится. В имени файла могут уместиться только самые ключевые метаданные.
Когда метаданные попадут в имя файла, они ПЕРЕСТАНУТ быть метаданными. Теперь это просто - ИМЯ ФАЙЛА - и ничего больше.
Цитировать
Цитировать
ага, вот в колхозе так и сделали. В результате, собрать колхоз можно только в корне диска. Ну а сейчас когда диски можно монтировать куда угодно в дерево каталогов, ты юзерам подкладываешь свинью.
Вобчем, проблема 255 никак не решается. В принципе.
Да, я согласен с тем, что "проблема 255 никак не решается в принципе". Всё, что тут можно сделать - ввести жёсткое ограничение на длину имени файла порядка 245 символов.
НЕТ. не надо из имен файлов пытаться достать метаданные.
Цитировать
Цитировать
Я уже молчу о том, что в либгене есть больше тыщи книг, у которых длина имена книги > 300 символов. Ты их как обрезать предлагаешь - по слову или прямо в середине слова?
Даже не знаю. А как лучше? Но обрезать-то прийдётся по-любому. Но, надеюсь, в любом случае, 245 символов хватит, чтобы сохранить человеко-понятность имени файла - а точные данные о книге всё равно будут храниться в метаданных.
Чтоб сохранить человеко-понятность, обрезать можно как угодно, да и вообще задача формирования имени очень сильно упрощается. Например, при транслитерации разные умляуты можно менять на соств.символы без диакритики - если есть такая таблица,  а не нашлась - ну и фиг с ним, подчеркивание и все. "Понятности" это не сильно навредит, но - насколько проще! А информацию ты не потерял - потому как все записано в файл метаданных. Но теперь нужны средства работы с метаданными. Вобчем - доставать из имени - это КАЖУЩАЯСЯ простота, которая порождает хаос. А вот для работы с настоящими метаданными надо ПО. Вот я и призываю к созданию такого ПО.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 17 БХЭвпСам 2010, 11:48:01
kv
Да я давно уже согласен с Вашими принципами.
Цитировать
Потому как кому-то придется писать для этого софт. Не факт что кто-то это сделает.
А куда они денутся - формат PDF  - это международный стандарт ISO. А метаданные PDF в входят в спецификацию формата PDF.

Метаданные формата DjVu - это в точности метаданные формата PDF. Т.е., когда владельцы прав на формат DjVu (Caminova.net) решали, а какие бы метаданные ввести в употребление в формат DjVu, какого именно формата - то решили просто без затей взять метаданные формата PDF и внедрить их в DjVu.
Цитировать
Еще раз. Если есть метаданные полные, парсить имена - зло.
Да, я прекрасно понимаю, что "зло". Но всё-таки бывают редкие случаи в жизни, когда по какой-то причине нам надо пропарсить имя файла - и забить извлечённой оттуда иинформацией поля метаданных.

Вот именно ради этой редкой (но тем не менее, реально существующей) потребности я и планирую сделать некий стандарт человеко-узнаваемого имени по-умолчанию - могущий быть полностью автоматически пропарсен в метаданные (естественно, частично).
Цитировать
Надо приучать народ пользоваться правильными данными.
Ну надо, конечно, только вот некоторым хоть кол на голове теши - им всё будет невдомёк, они будут всё говорить "а что такое метаданные?" :)
Цитировать
Потому я и говорю про фбд - оттуда данные достать проще, чем из пдф и джву.
Просто пусть кто-нибудь (не обещаю, что я) сделает автоматический конвертор "метаданные PDF DjVu" -> FBD.
Цитировать
Когда метаданные попадут в имя файла, они ПЕРЕСТАНУТ быть метаданными. Теперь это просто - ИМЯ ФАЙЛА - и ничего больше.
Совершенно верно, я прекрасно это понимаю.
Цитировать
НЕТ. не надо из имен файлов пытаться достать метаданные.
Но, как я говорил чуток выше - парсение имени в метаданные - это крайне редкая необходимость (даже скажем, я это рассматриваю как чрезвычайную меру - когда просто нет иного выхода). В норме в PDF и в DjVu должны будут наличествовать метаданные - а на данные из имени файла тогда можно будет вообще никак не опираться.
Цитировать
"Понятности" это не сильно навредит, но - насколько проще! А информацию ты не потерял - потому как все записано в файл метаданных.
Вот именно, я точно так же тоже думаю.
Цитировать
Вобчем - доставать из имени - это КАЖУЩАЯСЯ простота, которая порождает хаос.
Да, я превосходно это понимаю. Как я написал выше, парсение имени в метаданные будет нужно исключительно как чрезвычайная задача (когда по какой-то причине отсутствуют метаданные).
Пусть изначально юзер помещает в Интернет файл, названный как раз таким именем, которое может быть автоматом (частично) пропарсено в метаданные. Потому что - а вдруг по какой-то причине юзер затруднится одновременно ещё и метаданные засунуть в выкладываемый впервые в Сеть PDF или DjVu-файл.

Тогда уж такой файл, попав, скажем, в либген окольными путями, сможет быть автоматически обработан - с целью автоматической генерации (из имени файла) и вставки части метаданных в PDF или DjVu-файл. Однако, видимо, всё равно потребуется человеческий контроль над этой операцией - но тем не менее, я попытаюсь хоть как-то заведомо её облегчить.

Мне кажется, что всё это будет не лишним.
Цитировать
А вот для работы с настоящими метаданными надо ПО. Вот я и призываю к созданию такого ПО.
Да, я теперь займусь именно этим. Ведь та программа, которую я планирую, она будет ОДНОВРЕМЕННО генерировать человеко-понятое имя (и тут же его присваивать файлу PDF или DjVu) и генерировать метаданные (и тут же их вставлять - в PDF либо в DjVu).

Но освоение программной работы с PDF-метаданными - это долгая песня - потребуется читать и вникать в спецификацию формата PDF и XMP.

Вот описание XMP: http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
У XMP своя отдельная спецификация - выложена у Адобов на сайте:
http://www.adobe.com/devnet/xmp/

Плюс ещё и метаданные в формате "PDF DocInfo". C ними тоже надо разбираться ещё (это где-то внутри спецификации формата PDF).

Кстати - а почему бы формату FB2 не принять к использованию такие же метаданные, как и в PDF и DjVu - PDF DocInfo и XMP? Вот было бы здорово - было бы такое единообразие. Врочем, это необязательно.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 17 БХЭвпСам 2010, 12:49:05
Цитировать
Еще раз. Если есть метаданные полные, парсить имена - зло.
Да, я прекрасно понимаю, что "зло". Но всё-таки бывают редкие случаи в жизни, когда по какой-то причине нам надо пропарсить имя файла - и забить извлечённой оттуда иинформацией поля метаданных.

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

НУ а парсить имена - без токенов это сделать нельзя. А с токенами - у тебя в имя файла влезет еще меньше метаданных, чем в колхозе. Правильную транслитерацию тоже сделать невозможно. Вобчем, твоя программа будет еще одним источником хаоса.
Цитировать
Цитировать
Надо приучать народ пользоваться правильными данными.
Ну надо, конечно, только вот некоторым хоть кол на голове теши - им всё будет невдомёк, они будут всё говорить "а что такое метаданные?" :)
зачем кому-то что-то говорить. Все проще. Есть поля - название, авторы и т.д - ну как в метаданных пдф, и до тех пор, пока минимальный набор из них, тот, что можно узнать из книги, не заполнишь - файл дразнится по мд5 хешу. Вот и весь кол. Ессно, возможны и друuие варианты.
Цитировать
Цитировать
Вобчем - доставать из имени - это КАЖУЩАЯСЯ простота, которая порождает хаос.
Да, я превосходно это понимаю. Как я написал выше, парсение имени в метаданные будет нужно исключительно как чрезвычайная задача (когда по какой-то причине отсутствуют метаданные).
Пусть изначально юзер помещает в Интернет файл, названный как раз таким именем, которое может быть автоматом (частично) пропарсено в метаданные. Потому что - а вдруг по какой-то причине юзер затруднится одновременно ещё и метаданные засунуть в выкладываемый впервые в Сеть PDF или DjVu-файл.

Тогда уж такой файл, попав, скажем, в либген окольными путями, сможет быть автоматически обработан - с целью автоматической генерации (из имени файла) и вставки части метаданных в PDF или DjVu-файл. Однако, видимо, всё равно потребуется человеческий контроль над этой операцией - но тем не менее, я попытаюсь хоть как-то заведомо её облегчить.

Мне кажется, что всё это будет не лишним.
благими намерениями вымощена дорога...

Счас в либгене несколько тыщ. книг где в базе данных числится в поле Название нечто типа VTA0075rtk.pdf. У БГ принцип - добавить в либген, а потом видно будет. В результате, эти файлы через интерфейс найти нельзя, потому как никому не прийдет в голову делать запрос c буковсками. Вот тебе пример мануалов по панасоникам
http://free-books.dontexist.com/search?req=-DS&nametype=orig

Вобчем, повбивав бы:)
Цитировать
Цитировать
А вот для работы с настоящими метаданными надо ПО. Вот я и призываю к созданию такого ПО.
Да, я теперь займусь именно этим. Ведь та программа, которую я планирую, она будет ОДНОВРЕМЕННО генерировать человеко-понятое имя (и тут же его присваивать файлу PDF или DjVu) и генерировать метаданные (и тут же их вставлять - в PDF либо в DjVu).

Но освоение программной работы с PDF-метаданными - это долгая песня - потребуется читать и вникать в спецификацию формата PDF и XMP.
именно поэтому я завел разговор про фбд. С ним точно будет быстрее.

Да и с метаданными пдф тоже не все так просто. Например, ты уверен что туда должны вставляться данные по содержимому файла а не по самому файлу? Вот, например, что там должно быть, если в файле - сборник выдранных откуда-то статей?
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 17 БХЭвпСам 2010, 14:14:44
kv
Цитировать
нельзя быть чуть-чуть беременной. Если прога будет позволять создавать файлы БЕЗ метаинформации, то все будут именно так и делать. Потому как проще это, меньше работы, а человек всегда ищет легкие пути:)
Ну, если человек не захочет создавать метаданные - то я его не заставлю. :) А в моей программе одни и те же токены будут сразу идти как в имя файла, так и в метаданные. А потом надо будет просто ещё дописать остающиеся метаданные.
Цитировать
А с токенами - у тебя в имя файла влезет еще меньше метаданных, чем в колхозе.
Неправда. Ровно столько же и влезет - просто кое-где колхозные пробелы заменятся на подчёркивания и всё - так что без разницы. И даже больше влезет (за счёт того, что вместо указывания конкретных признаков качества будет указываться 5-балльный квалификатор качества - который гораздо короче по длине). И у меня не будет дурацких колхозных круглых скобок (где 2-я скобка - это чистая потеря длины имени на 1 символ).
Цитировать
Правильную транслитерацию тоже сделать невозможно.
Для наиболее распространённых языков - возможно. А как же тогда по-Вашему существует NameCreator - и почему-то многие им реально пользуются? Правда, многих он и отпугивает чрезмерной замороченностью. Я-то как раз предлагаю куда как более простую систему именования файлов.

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

Но я думаю, что для большинства рунетовцев наиболее актуальны только русский и английский языки. Посмотрите на любую большую онлайн-библиотеку PDF-DjVu. Все остальные языки буду добавлять в программу индивидуально - по мере необходимости (в смысле, буду добавлять таблицу транслитерирования для конкретного языка - как это сделано в NameCreator).
Цитировать
Вобчем, твоя программа будет еще одним источником хаоса.
Забавно. Но NameCreator - явно устарел. Так что его по-любому надо менять на что-то новое. Мой стандарт будет предназначен для простых смертных - не желающих особо заморачиваться. Вот NameCreator - тот слишком сильно заточен именно под Колхоз, так неправильно, это многих отпугивает (от NameCreator).
Цитировать
благими намерениями вымощена дорога...
А что Вы можете предложить? Не делать в имени поддержку авто-парсинга? Я считаю - делать, поскольку это совершенно несложно сделать - а выгоды налицо.
Цитировать
Счас в либгене несколько тыщ. книг где в базе данных числится в поле Название нечто типа VTA0075rtk.pdf.
Так забейте руками - в чём проблема? Времени нет? Да ну на это всегда время можно найти - каждый день перед сном по 20 минут тратить - через месяц всё и забьёте. Научитесь привлекать добровольцев-упорядочивателей библиотеки - да, это сложно, но всё-таки не абсолютно нереально.
Вон у SpaceLib есть проги, вытаскивающие из OCR-слоя тексты из книг, с большой долей вероятности имеющие библиографическую информацию о книге.
Цитировать
Вот, например, что там должно быть, если в файле - сборник выдранных откуда-то статей?
А что сочтёте нужным - то и пишите. Если контент PDF или DjVu файла имеет официальное библиографическое название - используйте его. Если не имеет - придумайте своё название.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 17 БХЭвпСам 2010, 14:57:34
kv
Цитировать
нельзя быть чуть-чуть беременной. Если прога будет позволять создавать файлы БЕЗ метаинформации, то все будут именно так и делать. Потому как проще это, меньше работы, а человек всегда ищет легкие пути:)
Ну, если человек не захочет создавать метаданные - то я его не заставлю. :) А в моей программе одни и те же токены будут сразу идти как в имя файла, так и в метаданные. А потом надо будет просто ещё дописать остающиеся метаданные.
я написал один вариант как можно заставить. Тогда работать с именем надо в таком порядке - сначала вводятся метаданные, потом по шаблону будет автоматом построено имя. Нет метаданных - нет имени.
Цитировать
Цитировать
А с токенами - у тебя в имя файла влезет еще меньше метаданных, чем в колхозе.
Неправда. Ровно столько же и влезет - просто кое-где колхозные пробелы заменятся на подчёркивания и всё - так что без разницы. И даже больше влезет (за счёт того, что вместо указывания конкретных признаков качества будет указываться 5-балльный квалификатор качества - который гораздо короче по длине). И у меня не будет дурацких колхозных круглых скобок (где 2-я скобка - это чистая потеря длины имени на 1 символ).
Цитировать
Правильную транслитерацию тоже сделать невозможно.
Для наиболее распространённых языков - возможно. А как же тогда по-Вашему существует NameCreator - и почему-то многие им реально пользуются? Правда, многих он и отпугивает чрезмерной замороченностью. Я-то как раз предлагаю куда как более простую систему именования файлов.

Для единичных экзотических случаев, плохо поддающихся транслитерации, можно всё равно что-то придумать приемлемое. Жизнь покажет. Всё заранее не предусмотришь - какой-то процент проблем/ошибок пусть остаётся - иначе до финиша никогда не доплывём.
Подожди, а ты примеры делал? Сколько у тебя влезло? Конкретно, с циферками, можно посмотреть? Ну а насчет "экзотических случаев", то во многом и из-за них либген так долго из колхоза и собирался. И до сих пор проблемы есть с добавлением файлов, где в имена кодируют метаданные. Дело колхоза живуче. Вобчем, классика - исключения только подтверждают правило. Правило - нельзя метаданные кодировать в имя файла.

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

Цитировать
Цитировать
Вобчем, твоя программа будет еще одним источником хаоса.
Забавно. Но NameCreator - явно устарел. Так что его по-любому надо менять на что-то новое.
ага, на новый генератор хаоса:)
Цитировать
Цитировать
благими намерениями вымощена дорога...
А что Вы можете предложить? Не делать в имени поддержку авто-парсинга? Я считаю - делать, поскольку это совершенно несложно сделать - а выгоды налицо.
я написал - выгоды и простота - КАЖУЩИЕСЯ. Написал причины. Имеешь свое мнение - докажи. Хотя бы на примерах.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 17 БХЭвпСам 2010, 15:46:40
kv
Цитировать
Но да, надо сменить парадигму - типа, начать работать с метаданными, а не с именем файла. Знаю, это непросто:)
Это всё, конечно, понятно - но почему Вы упорно не желаете рассматривать тот случай, когда юзер не захочет формировать метаданные - а вот информативное имя - как раз захочет? Что тогда прикажете делать? Пример: реализация на Веб-сервере функционала программы NameCreator. А попробуйте-ка на сервере реализовать программную работу с PDF и DjVu-метаданными. Это только я в своей программе волен делать всё, что захочу. А поскольку речь идёт о разработке стандарта именования - то ещё неизвестно, как другие люди в своих программах этот стандарт реализуют.
Цитировать
я написал - выгоды и простота - КАЖУЩИЕСЯ. Написал причины. Имеешь свое мнение - докажи. Хотя бы на примерах.
Вот Вам и доказательство - случай, когда человек может и хочет работать с именами файлов - но в упор не хочет и не может работать с метаданными.
Цитировать
я написал один вариант как можно заставить. Тогда работать с именем надо в таком порядке - сначала вводятся метаданные, потом по шаблону будет автоматом построено имя. Нет метаданных - нет имени.
Думаю, что это на деле приведёт к игнорированию подобной программы. А если человек не знает, как заполнить хотя бы одно поле метаданных? Силой Вы юзера не заставите.
Цитировать
Подожди, а ты примеры делал? Сколько у тебя влезло?
Ещё не успел. Но это пока не важно. Потому что, чтобы там у меня ни вышло - а выбора всё равно нет - имя файла обязано быть первоначально человеко-понятным - а не в виде md5. А раз уж оно обязано быть человеко-понятным - тогда уж пускай одновременно оно будет с поддержкой автопарсинга в метаданные - потому что иначе было бы просто глупо не воспользоваться такой возможностью.
Цитировать
Дело колхоза живуче.
А как Вы думаете, почему? Потому что так правильно. Ещё раз повторюсь - имя файла обязано быть первоначально человеко-понятным. Можете принять это как аксиому. А вот внутри либгена - пусть имя хранится хоть в виде md5.
Цитировать
И исключений НЕТ. Но да, надо сменить парадигму - типа, начать работать с метаданными, а не с именем файла. Знаю, это непросто:)
А что же тогда юзеру писать в имени файла, когда он свою книгу впервые выкладывает в Сеть? Предлагаете ему писать имя файла в виде md5? :)
Цитировать
Самое смешное -  в моем подходе до финиша доплыть быстрее, потому как задача гораздо проще. Никаких заморочек с транслитерацией, длиной, приданием "смысла" токенам и оптимизацией состава.
Ну хорошо - вот я отсканировал книгу в DjVu. Сам. Затем заполнил в ней метаданные - всё, как Вы хотите. Ну а имя - какое по-Вашему имя файла мне теперь задать, перед тем как выкладывать в Интернет? В виде md5? :)
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 17 БХЭвпСам 2010, 16:21:33
kv
Цитировать
Но да, надо сменить парадигму - типа, начать работать с метаданными, а не с именем файла. Знаю, это непросто:)
Это всё, конечно, понятно - но почему Вы упорно не желаете рассматривать тот случай, когда юзер не захочет формировать метаданные - а вот информативное имя - как раз захочет? Что тогда прикажете делать? Пример: реализация на Веб-сервере функционала программы NameCreator. А попробуйте-ка на сервере реализовать программную работу с PDF и DjVu-метаданными. Это только я в своей программе волен делать всё, что захочу. А поскольку речь идёт о разработке стандарта именования - то ещё неизвестно, как другие люди в своих программах этот стандарт реализуют.
потому что я - последователен. И предложил и отстаиваю одну идею на протяжении всего треда. А не шарахаюсь со стороны в сторону.Типа, да, зло - а потом аксиома прямо противоположного плана. И я помню о первоначальной задаче - программа для сканировщика. О каком Веб-сервере ты говоришь? Ты что, собираешься через броузер сканить книжки? Или это мордв некой базы данных, куда надо будет заносить отсканенные книги? Ты уж определись, а о сферическом коне в вакууме в виде некоего "стандарта именования" говорить смысла нет, потому как стандарт - это совсем другое. Здесь сначала надо изучить что такое RFC и с чем его едят.

Ну и, если это программа для сканировщика, то где ты видел сканирощика, что не знает, что такое название книги или автор? А если совсем молодой, то пару раз заполнит, а там, глядишь и издательство и ИСБН научится находить:)

Ну а работать с пдф и джву - это ж ты собрался, я могу максимум или в фбд поковыряться или прогой Спейслиба воспользоваться:)

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

Хотя, оно все понятно - дальше ты пишешь - чтоб не получилось - не важно. Снова классика - если факты не устраивают, значит факты отбрасываем. Твоя аксиома это только подтверждает. Т.е. ты для себя уже все решил, и теперь тред перешел в стадию банального стеба, типа
Цитировать
Ну хорошо - вот я отсканировал книгу в DjVu. Сам. Затем заполнил в ней метаданные - всё, как Вы хотите. Ну а имя - какое по-Вашему имя файла мне теперь задать, перед тем как выкладывать в Интернет? В виде md5? :)
ты хоть читал, что я писал? Еще раз. Если заполнены метаданные, имя сгенерируется автоматически по заданному шаблону. Задал, что там будет идти автор-название-издательство-год - так и будет. НО, при этом, в дальнейшем, парсить имя будет не нужно - потому как метаданные уже БУДУТ СОЗДАНЫ. Их надо будет только достать. Вот откуда - я говорю что проще из фб2 - наряду с пдф и джву. Значит надо туда и записать.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 17 БХЭвпСам 2010, 19:41:37
kv
Цитировать
О каком Веб-сервере ты говоришь?
Я имею в виду следующее: в первую очередь я намерен создать стандарт человеко-понятного имени. Который (стандарт) далее реализую в своей программе. Но - этот же самый стандарт сможет использовать любой другой человек, в смысле, любой другой человек сможет написать свою программу, где (также как я) программно воплотит данный стандарт. Например, на Веб-сервере. А вот зачем на Веб-сервере может понадобиться делать подобное - я не знаю. Но вот с NameCreator был такой случай - когда на PHP сделали на веб-сервере программу, которая делала то же самое, что делает NameCreator.

Соответственно, если кто-то на своём веб-сервере реализует программно мой стандарт именования файлов - то где гарантия, что этот человек захочет одновременно там же (в той же программе) сделать внедрение метаданных?
Цитировать
Здесь сначала надо изучить что такое RFC и с чем его едят.
Я имею в виду, разумеется, самодельный стандарт - упрощённого образца.
Цитировать
Доказательво - соображения общего плана доказательсвом быть не могут.
Да ну что за ерунда - могут конечно же. Для человеко-понятности 245 символов всегда за глаза хватит в имени файла.
Цитировать
Еще раз. Если заполнены метаданные, имя сгенерируется автоматически по заданному шаблону. Задал, что там будет идти автор-название-издательство-год - так и будет. НО, при этом, в дальнейшем, парсить имя будет не нужно - потому как метаданные уже БУДУТ СОЗДАНЫ. Их надо будет только достать.
Да я со всем этим не спорю. Ну, а если НЕ будут заданы метаданные - что тогда-то делать? Все Ваши рассуждения хороши, только если метаданные есть. А если их нет - но зато есть хотя бы имя файла, могущее быть авто-пропарсено в часть метаданных - то это какой-никакой - но выход. А иначе прийдётся забивать руками метаданные (ну или вытаскивать из OCR-слоя - но это слишком ручной труд).

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

Короче говоря, я представляю себе всё это практически вот как:

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

Далее, например, библиотека Homelab просматривает этот книжно-новостной сайт и выкачивает себе все новые книги. Допустим, Homelab забирает себе этот DjVu, и видит: "ага, метаданных почему-то нет. Зато есть такое имя файла, которое можно пропарсить в метаданные - ну хотя бы частично. Что ж, хорошо. Парсим имя файла и заполняем частично метаданные." И всё - все дальнейшие возможные сценарии уже сводятся к Вашим вариантам (с опорой на метаданные). То есть после заполнения метаданных можно смело как угодно менять первоначальное имя файла - и это будет уже не страшно.

Разве плохо придумано?

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

А концепцию можно назвать как "обязательность первичного инфоимени". Сформулировать её можно так:

Все PDF и DjVu-файлы, впервые попадающие в Сеть, обязаны иметь инфоимя.

А вот будут ли все такие PDF и DjVu-файлы, впервые попадающие в Сеть, ОДНОВРЕМЕННО с инфоименем иметь ещё и метаданные (как ВЫ того хотите) - ещё не факт. По разным причинам (технические проблемы и человеческий фактор) такие файлы могут и не иметь метаданных. А вот инфоимя сгенерировать - можно будет даже и вручную накрайняк - глядя на описание стандарта инфоимени (которое я опубликую на своём сайте). Может, у человека не окажется под рукой программы - генератора инфоимени и метаданных - а PDF или DjVu-книгу надо строчно выложить.

Второй постулат я предлагаю сформулировать так:

"Запрет потери данных инфоимени"

Если PDF или DjVu-файл уже лежит в Сети и у него нет метаданных - запрещается менять его инфоимя до заполнения метаданных. (в смысле до автоматического частичного заполнения метаданных путём парсинга инфоимени)
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 18 БХЭвпСам 2010, 02:25:35
kv
Цитировать
О каком Веб-сервере ты говоришь?
Я имею в виду следующее: в первую очередь я намерен создать стандарт человеко-понятного имени.
отступление. Давай посмотрим как это было у других.
Одни хотели создать стандарт, и придумали семиуровневую модель и сеть Х.25. Теперь семиуровневую модель рассказывают на одной лекции а Х.25 можно увидеть в музее.

Другие хотели решить практическую задачу и придумали юникс и TCP/IP. Теперь после единственной лекции о семиуровневой модели говорят почему TCP/IP лучше нее и еще с десяток а что же это такое, железки с TCP/IP внутри клепают даже в гаражах индийских деревень а юникс растащили по кусочкам все - кому хватило ума и бабла - от мелкомягких и фруктовых и до разно-ксовых.

А вся разница - кто к чему стремился тогда, давно.

Цитировать
Который (стандарт) далее реализую в своей программе. Но - этот же самый стандарт сможет использовать любой другой человек, в смысле, любой другой человек сможет написать свою программу, где (также как я) программно воплотит данный стандарт. Например, на Веб-сервере. А вот зачем на Веб-сервере может понадобиться делать подобное - я не знаю. Но вот с NameCreator был такой случай - когда на PHP сделали на веб-сервере программу, которая делала то же самое, что делает NameCreator.

Соответственно, если кто-то на своём веб-сервере реализует программно мой стандарт именования файлов - то где гарантия, что этот человек захочет одновременно там же (в той же программе) сделать внедрение метаданных?
поясни мне, что на веб-сервере будет далать сканировщик. Вот ты, например. без воплощения, а как юзер.
Цитировать
Цитировать
Здесь сначала надо изучить что такое RFC и с чем его едят.
Я имею в виду, разумеется, самодельный стандарт - упрощённого образца.
что это такое. Приведи пример.
Цитировать
Цитировать
Доказательво - соображения общего плана доказательсвом быть не могут.
Да ну что за ерунда - могут конечно же. Для человеко-понятности 245 символов всегда за глаза хватит в имени файла.
еще раз. Проблемы "человеко-понятности" НЕТ. Есть проблема извлечения метаданных из строки в 254 символа. Потому как метаданные занимают БОЛЬШЕ. И из строки в 254 символа извлечь метаданные в 1000 символов НЕЛЬЗЯ.

Цитировать
Цитировать
Еще раз. Если заполнены метаданные, имя сгенерируется автоматически по заданному шаблону. Задал, что там будет идти автор-название-издательство-год - так и будет. НО, при этом, в дальнейшем, парсить имя будет не нужно - потому как метаданные уже БУДУТ СОЗДАНЫ. Их надо будет только достать.
Да я со всем этим не спорю. Ну, а если НЕ будут заданы метаданные - что тогда-то делать? Все Ваши рассуждения хороши, только если метаданные есть.
Приведи мне практическую ситуацию из опыта сканировщика, который только что отсканил книгу и у него НЕТ метаданных. Я представить могу только единственный вариант - он НЕ ХОЧЕТ заполнить метаданные (ессно, я предполагаю, что он работает с прогой, которая позволяет задать метаданные - т.е. с твоей будущей прогой). Итак, ответь на вопрос - почему ты, как сканировщик, не хочешьт заполнить метаданные. Ты ж на сканирование потратил от 1 до много часов, заполнить метаданные - несколько минут. В чем дело?

Итак, кто НЕ ХОЧЕТ - пусть пользуется NameCreator. Но твоя прога будет же лучше. Ведь правда? Вот и пусть платой за дополнительные удобства будет заполнение метаинформации.

Цитировать
А если их нет - но зато есть хотя бы имя файла, могущее быть авто-пропарсено в часть метаданных - то это какой-никакой - но выход. А иначе прийдётся забивать руками метаданные (ну или вытаскивать из OCR-слоя - но это слишком ручной труд).
а давай с такой стороны. Представим, что твоя прога есть, и она такая как я говорю, т.е. если ею пользоваться - то метаданные всегда есть. Ну и зачем тогда парсить имена, ведь метаданные естьих надо только извлечь.

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

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

Короче говоря, я представляю себе всё это практически вот как:

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

Далее, например, библиотека Homelab просматривает этот книжно-новостной сайт и выкачивает себе все новые книги. Допустим, Homelab забирает себе этот DjVu, и видит: "ага, метаданных почему-то нет. Зато есть такое имя файла, которое можно пропарсить в метаданные - ну хотя бы частично. Что ж, хорошо. Парсим имя файла и заполняем частично метаданные." И всё - все дальнейшие возможные сценарии уже сводятся к Вашим вариантам (с опорой на метаданные). То есть после заполнения метаданных можно смело как угодно менять первоначальное имя файла - и это будет уже не страшно.

Разве плохо придумано?
Плохо. Потому как ты игнорируешь факты. А именно - нельзя запихать метаданные в имя файла. А вот как я говорю - можно. Потому как ничего запихивать не надо. Надо просто ИМЕЮЩИЯСЯ метаданные сохранить как это положено. Почему ты этого не хочешь?

Цитировать
А вот будут ли все такие PDF и DjVu-файлы, впервые попадающие в Сеть, ОДНОВРЕМЕННО с инфоименем иметь ещё и метаданные (как ВЫ того хотите) - ещё не факт. По разным причинам (технические проблемы и человеческий фактор) такие файлы могут и не иметь метаданных.
ну вот нравятся мне рассуждения "взагали"!

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

Вобчем, будь проще - и народ к тебе потянется:)
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 18 БХЭвпСам 2010, 21:53:53
kv
Цитировать
что это такое. Приведи пример.
Это будет простое словесное описание, и по-возможности краткое. Т.е. написанное в произвольной форме - а не по каким-то лекалам - как настоящие стандарты.
Цитировать
поясни мне, что на веб-сервере будет далать сканировщик. Вот ты, например. без воплощения, а как юзер.
Я не знаю. Да мне это и не нужно знать. Вот мне как-то человек прислал письмо и показал, как он у себя на сервере реализовал функционал NameCreator - а зачем - я не знаю.
Цитировать
еще раз. Проблемы "человеко-понятности" НЕТ. Есть проблема извлечения метаданных из строки в 254 символа. Потому как метаданные занимают БОЛЬШЕ. И из строки в 254 символа извлечь метаданные в 1000 символов НЕЛЬЗЯ.
Я уже немного устал всё время повторять "да" :). Хорошо, повторю ещё раз - я полностью согласен с этими словами. Из строки в 254 символа можно извлечь метаданные в также 254 символа - и это будет гораздо лучше, чем взамен извлечь из имени файла 0 (ноль) символов в метаданные. Но опять-таки - всё это будет нужно, только если у нас нет метаданных.
Цитировать
Я представить могу только единственный вариант - он НЕ ХОЧЕТ заполнить метаданные
Вот именно - он может не захотеть заполнить метаданные. А почему - да мало ли. Ни Вы, ни я не сможем заведомо продумать все возможные жизненные ситуации - чтобы ответить на вопрос, почему юзер заполнит инфоимя, но не заполнит метаданные.
Цитировать
(ессно, я предполагаю, что он работает с прогой, которая позволяет задать метаданные - т.е. с твоей будущей прогой).
Э нет, вот это Ваше кардинальное заблуждение. Когда я сделаю стандарт инфоимени - то такое инфоимя можно будет и руками сформировать. Или же вот пример: я сделаю прогу под винду - а в Линуксе что? Хорошо, если кто-то реализует мой стандарт инфоимени под Линукс - в некоей своей программе. А что, если в той линуксовой проге работа с метаданными вообще не будет предусмотрена? Это же так муторно - реализовывать работу с метаданными.
Цитировать
Итак, ответь на вопрос - почему ты, как сканировщик, не хочешьт заполнить метаданные. Ты ж на сканирование потратил от 1 до много часов, заполнить метаданные - несколько минут. В чем дело?
Увы, на этот вопрос ответить невозможно. Мы с Вами никогда не сможем заведомо просчитать все возможные варианты поведения юзера. Мало ли - не поймёт, что такое метаданные, или не захочет понимать, поленится в конце концов, или просто забудет (заполнить метаданные) - вариантов много.

Надо лишь, делая любую программу, не ущемлять свободу юзера. "Не хочешь заполнять метаданные - не заполняй" - вот тот принцип, которого я буду вынужден в своей программе придерживаться. Потому что, если я попытаюсь силой заставить юзера ВСЕГДА заполнять метаданные - то тогда моей программой просто не будут пользоваться.
Цитировать
Итак, кто НЕ ХОЧЕТ - пусть пользуется NameCreator. Но твоя прога будет же лучше. Ведь правда? Вот и пусть платой за дополнительные удобства будет заполнение метаинформации.
Немного наивные ИМХО рассуждения. Плевать юзеру на мои или Ваши указивки. Юзера можно только просить - а указывать или заставлять - бесполезно.
Цитировать
т.е. если ею пользоваться - то метаданные всегда есть.
Опять же - Вы не рассматриваете вариант сторонней реализации в чужой программе моего стандарта инфоимени. В этом случае инфоимя может быть - а метаданных может не быть.
Цитировать
Вывод - ты целенаправленно не хочешь работать с метаданными.
Вывод неправильный. Просто я трезво смотрю на жизнь, и понимаю, что, как бы мы с Вами ни не хотели, чтобы метаданные всегда были в самого начала - но суровая жизнь всё равно не даст возникнуть такой идеалистической картине на 100%. Как именно не даст, почему - это заведомо оценить невозможно.

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

А вот и может (что не будет метаданных). Потому что реальный мир несовершенен.
Цитировать
Слушай, а давай проще.
"Проще" нельзя. Не стОит пытаться втиснуть сложность мира в простые схемы. Вот, к примеру, Scan Tailor - там тоже автор пытался всё сделать "проще" - получилась ерунда в итоге.
Цитировать
Обеспечь, чтобы лично твои книги, попадая в сеть, имели метаданные. Сделай для этого прогу. Ты ж понимаешь, как это важно, ну, в смысле, чтоб метаданные были?

Я-то лично, конечно, это обеспечу. Т.е. у меня будет одновременно формироваться инфоимя около 245 знаков - и одновременно автоматически метаданные такой же длины (245 знаков). Так что юзеру не потребуется лишний раз шевелить пальцем, и, даже если ему неохота будет заполнять метаданные - они всё равно автоматом хотя бы частично (245 знаков), но заполнятся.

И для ответственных пользователей будет возможность дополнительно заполнить метаданные полностью (с 245 знаков до конца).

Делать сразу заполнение метаданных целиком - а чтобы инфоимя потом из части метаданных автоматом формировалось - не хотелось бы, так это будет уже насилие над юзером (и как следствие посылание моей программы подальше).
Цитировать
Полезность метаданных уже сейчас многие понимают. Ну а нет - то ты поможешь понять. На своем сайте, например.
В этом отношении я сделаю всё, что смогу.
Цитировать
Все равно не долго уж осталось, время ее прошло.
Да, NameCreator устарел: он и метаданные не поддерживает вообще, и слишком под Колхоз заточен (например, коды областей знания в имени книги там - сугубо внутриколхозные). Представления NameCreator о параметрах качества исполнения эл. книги - тоже уже кажутся скудноватыми. Да и длина имени там не ограничивается ~ 245 символами - что оказалось неприемлемым.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 18 БХЭвпСам 2010, 23:30:46
ни на один свой вопрос ответа я не увидел. На основании этого и анализа твоих последних постов я делаю вывод - ты не принимаешь мое предложение об изменении постановки задачи, изложенное в моем первом посте. Ну что ж, это - твое право. Я правильно тебя понял?
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 20 БХЭвпСам 2010, 09:16:55
kv
Цитировать
ты не принимаешь мое предложение об изменении постановки задачи, изложенное в моем первом посте. Ну что ж, это - твое право. Я правильно тебя понял?
В общем, да. Но вообще-то я на все Ваши предложения ответил, как мне кажется.

Да Вы не переживайте - в жизни нет ничего идеального. И потом - совместная выработка какого-либо стандарта - всегда вызывает определённый конфликт интересов - это нормально.

Может, Вы правы, а я ошибаюсь - но мне это пока не очень очевидно. Если я в дальнейшем на своём опыте увижу, что лучше сделать как-то иначе - я переделаю.

Я считаю, что то, что предлагаю я, является разумным компромиссом между моей и Вашей позициями. Вы же бескомпромиссно настаиваете на своей позиции - и в этом я с Вами пока не согласен. Может, в будущем и соглашусь, не знаю - но пока что не хотелось бы (соглашаться на Ваш бескомпромиссный вариант на 100%).
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: kv от 20 БХЭвпСам 2010, 17:22:50
kv
Цитировать
ты не принимаешь мое предложение об изменении постановки задачи, изложенное в моем первом посте. Ну что ж, это - твое право. Я правильно тебя понял?
В общем, да. Но вообще-то я на все Ваши предложения ответил, как мне кажется.
ок. У нас разное понимание что такое ответ. Реальные примеры ты делать не хочешь, стандарт воспринимаешь как "простое словесное описание притом краткое". Ну дык давно бы уже написал это описание, а то на форуме ого-го сколько, а простого и краткого, как не было, так и нет. И вообще, я не понимаю что здесь можно "стандартизовать". Давал тебе ссылку на хоум-либ. Там есть задание правила именования файлов, в настройках это занимает 1/3 формы. Вот оно
(http://pikucha.ru/693813/image.jpeg) (http://pikucha.ru/693813)
Ну я б еще добавил длину поля, типа %f:40 - для полной ясности, так сказать. Ну и что тебе еще надо?
Цитировать
Да Вы не переживайте - в жизни нет ничего идеального. И потом - совместная выработка какого-либо стандарта - всегда вызывает определённый конфликт интересов - это нормально.
а с чего мне переживать? Да, потратил несколько часов на треп на форуме - ну и ладно. Это время я рассматриваю как потраченное на понимание, будет с этого польза или нет. Лично мне - при моей работе с либами, в смысле. Не будет. НУ а куда гробить личное время тебе - дело хозяйское, как грится.

Цитировать
Может, Вы правы, а я ошибаюсь - но мне это пока не очень очевидно. Если я в дальнейшем на своём опыте увижу, что лучше сделать как-то иначе - я переделаю.

Я считаю, что то, что предлагаю я, является разумным компромиссом между моей и Вашей позициями. Вы же бескомпромиссно настаиваете на своей позиции - и в этом я с Вами пока не согласен. Может, в будущем и соглашусь, не знаю - но пока что не хотелось бы (соглашаться на Ваш бескомпромиссный вариант на 100%).
у нас не позиция разная, а мировоззрение. Потому как я говорю, что прежде чем что-то делать, надо УМЕТЬ это делать. Например, с моей точки зрения, прога должна помогать в вычленении в сканах метаданных, должна сама лазать в базы ИСБН и выбирать все имеющееся. А у тебя - только заклинания, что хочу чтоб лучше чем NameCreator, но простой стандарт. Ну, хоти:)
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 21 БХЭвпСам 2010, 09:10:01
kv
Цитировать
Например, с моей точки зрения, прога должна помогать в вычленении в сканах метаданных, должна сама лазать в базы ИСБН и выбирать все имеющееся.
Хорошая мысль. Возможно, в отдалённом будущем попробую и это сделать.
Однако, это непросто. Потребовалось бы делать визуальное окошко в программе - а я пока так не умею.

Теперь буду разбираться с реализацией метаданных.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 14 ЅЮпСам 2010, 11:40:03
Я задал Леону Боту несколько вопросов насчёт DjVu-метаданных. Как известно, djvused умеет напрямую работать с ними. Для этого там используются команды print-meta и set-meta - см. http://djvu.sourceforge.net/doc/man/djvused.html . Но некоторые подробности всё же неясны.

Вот мои вопросы и ответы Леона на них:

1. Где можно увидеть полный список всех возможных тегов DjVu-метаданных? Включая "BibTex bibliography system" (что это?) и "PDF DocInfo".
Цитировать
For the PDF tags, see the file djvuchanges.txt that comes with djvulibre.
For the BibTeX tags, a full list is way too long. 
But see the wikipedia entry http://en.wikipedia.org/wiki/BibTeX
and also the http://www.kfunigraz.ac.at/~binder/texhelp/bibtx-7.html.
2. Какова максимальная разрешённая длина для значения любого тега? Это очень важно.
Цитировать
I do not believe there is a maximum.
But things won't be pretty if they are more than 1024 characters long.
3. Разве "BibTex bibliography system" поддерживается хоть одним Caminova-продуктом? Вот "PDF DocInfo" поддерживается программой "DjVu Shell Extension Pack" - поэтому с "PDF DocInfo" уже можно связываться в своей программе (а насчёт того, стОит ли реализовывать в своей программе "BibTex bibliography system", я пока не так уверен).
Цитировать
Lizardtech did not have a metadata system.
We introduced the metadata annotation and specified the bibtex tags.
Lizartech eventually adopted the metadata annotation but uses the PDF DocInfo tags.
Very few people ever used the bibtex tags.

Here is the list of tags recognized by the tool "ExifTool":
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/DjVu.html
4. Какие могут быть шансы, что Caminova примет XMP в качестве DjVu-метаданных?
Цитировать
See again the file djvuchanges.txt and the annotations in the attached djvu_with_xmp4.djvu.
This is what we push for.  Of course they may do something different some day, but the only thing we can do is push back.

Вот ещё ссылка по теме - в самом низу страницы люди обсуждают DjVu-метаданные:
http://i.posters.ec/node/157529

И вот статья про метаданные в JRA Publish: http://www.djvu-soft.narod.ru/planetdjvu/metadata_storage_for_djvu_files.htm .

По поводу длины данных: раз уж официального ограничения нет, то я тоже не стану ограничиваться 1024 байтами. Может, и сделаю какое-нибудь ограничение, но уж точно побольше. Допустим, 8 КБ. Надо подумать. Конечно, совсем без ограничения длины как-то неуютно.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: ExeN-321 от 20 ґХЪРСам 2010, 19:12:00
Предлагаю свой вариант указания качества книги в имени файла. Простую 5и бальную систему я считаю непригодной, так как она неинформативна. Вариант с шестнадцатиричным числом тоже требует определенной квалификации пользователя. Я. вот, например не могу "в уме" перевести из шестнадцатиричной системы в двоичную, то есть этот код больше подойдет для программного разбора. На мой взгляд необходимо определиться с наибоее важными параметрами качества и уже им назначать оценку по 5и бальной системе либо записывать 0 и 1 как признак наличия/отсутствия информации. (к примеру отсканирована ли книга разворотами). От остального имени файла (надеюсь, что мы придем наконец-то к общему результату) предлагаю его отделять например скобками (как это принято при обмене фильмами). Например для DPI как и прелагалось ввести систему от 1 до 5 и присвоить букву D; есть ли OCR слой 0 и 1 и присвоить букву O и аналогично (извиниите не могу процитировать).Т.Е. имя файла пример такой вид: Habibulin I.Sh. - Samouchitel XML - 2003(D4O1).pdf. Кстати информацию отсюда можно брать и для шестнадцатиричного идентификатора или же распарсить сразу этот идентификатор. В случае появления новых критериев этот идентификатор можно легко масштабировать можно легко масштабировать.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 21 ґХЪРСам 2010, 10:05:12
ExeN-321
Цитировать
Вариант с шестнадцатиричным числом тоже требует определенной квалификации пользователя.
Этот вариант уже и мне не нравится - 5-балльная система лучше.
Цитировать
Простую 5и бальную систему я считаю непригодной, так как она неинформативна.
А как же школы и институты, работа которых базируется на 5-бальной системе? Для них, значит, достаточно информативна. И попробуйте представить себе работу школы, где вместо оценок ставят набор конкретных формализованных признаков качества.
Цитировать
На мой взгляд необходимо определиться с наибоее важными параметрами качества
Это нереально. Совершенно никак невозможно сделать (в общем случае). Понятно, что в случае наличия сдвоенных разворотов мы можем сказать - да, это один из "наиболее важных параметров качества".

Но есть куча других случаев, когда один и тот же признак для одной книги существенен - а для другой почти неощутим. Например, DPI. Для сканов высокого качества может оказаться практически несущественным то, что они, скажем, на 300 dpi - а не на 600. А для мелкого текста - наоборот - 600 dpi или 300 - уже важно.

Кроме того, если взять поганые сканы на 150 dpi и переделать их в Scan Tailor в 600 dpi - то они лучше от этого практически не станут - хотя формально эти сканы обретут признак "600 dpi". И что, считать DPI после этого серьёзным признаком качества?

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

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

Нельзя всё многообразие мира втиснуть в малый набор формальных признаков.

Мы не в силах ЗАРАНЕЕ предугадать, какой именно признак качества окажется решающим для данной эл. книги. Например, бывает так, что сделана плохая бинаризация - отчего буквы и особенно чёрно-белые картинки выглядят как днище корабля, обросшее ракушками. Вот и попробуйте формализовать этот признак. И таких признаков наберётся много.
Цитировать
есть ли OCR слой 0 и 1
А это я бы вообще не считал как признак. Если OCR-слоя нет - никакой проблемы нет его сделать - практически в автоматическом режиме (под Windows, но, если очень постараться - то можно будет и под Linux). Можно вообще сделать такую программу, которой указываешь некую папку с книгами, и она чтобы автоматически обходила итеративно эту папку и все в неё вложенные, искала в ней DjVu-файлы, проверяла, есть ли там DjVu-файлы без OCR-слоя, и, если нет, делала бы его. И всё это полностью автоматически - на базе FineReader. И тогда пусть там хоть тысячи книг - какая разница - запустил программу и ушёл на работу - а к вечеру все DjVu в папке гарантированно обретут OCR-слой - и всё это полностью автоматически.

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

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

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

А ещё, даже переделка книги из плохого качества в приемлемое не всегда гарантирует достижение нормального качества данной книги. Хотя, казалось бы, тут и развороты уже порезаны, и DPI уже стало 600, и все прочие нужные манипуляции проделаны (deskew, despeckle) - а качество всё-таки не то. И тогда только человек может интуитивно сказать, какое всё-таки качество получилось в результате переделки - 3, 4 или 5.

Вопрос определения качества - это тонкий и субъективный процесс, его невозможно формализовать.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: Alfizik от 22 ґХЪРСам 2010, 12:52:33
Прошло не так уж и мало времени, поэтому хотелось бы узнать сдвинулось ли что либо в плане метаданных в DjVu (появились ли утвержденные спецификации и программы (желательно с графическим интерфейсом) по внедрению\редактированию метаданных в DjVu)?
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: monday2000 от 22 ґХЪРСам 2010, 13:17:52
Alfizik
Я ничего не делал пока в этом направлении. А Леон Боту сделал поддержку XMP-метаданных в djvused.

Не ждите от меня быстрых результатов с метаданными. С ними ещё нужно будет разбираться, как ими конкретно пользоваться, что означают конкретные поля, что туда писать, и т.п.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: ExeN-321 от 05 јРЩ 2012, 13:48:42
Сам сейчас вплотную столкнулся с этой проблемой. Накопилось большое количество книг, все не пойми - как названы. Для себя решил использовать следующую схему наименования:
папка библиотеки \ категория\подкатегория\ файл.
Насчет категории - ИМХО, юзер имеет полное право выбирать что угодно, хотя надо будет присмотреться к классификаторам УДК и ББК. ISBN я считаю лучше использовать в метаданных. Почему я склоняюсь к произвольному названию категории? Потому что если предположим у некоего сферического юзера в вакууме есть предположим 200 книг по Photoshop, то не есть хорошо их складировать в одну папку. Классификаторы с точки зрения пользователя для меня под вопросом, потому что как правило в домашней библиотеке хранится много файлов по нескольким отраслям из этих классификаторов.
Что касается имени файла, то я пока остановился на таком варианте:
Иванов И.И., Петров А.А. - Супер-пупер книга (2000).djvu. На мой взгляд двух авторов вполне достаточно, разделители так же могут быть автоматически распарсены на веб-сервере. Что касается имени файла, то оно может быть также сгенерировано/транслитерировано/распарсено на веб-сервере. Представляю себе процесс следующим образом (взгляд со стороны пользователя):
Он разыскивает/сканирует книгу, обрабатывает ее моей программой, тем самым получая человеко-информативное имя файла и его расположение. Расположение важно потому, что не все (личное мнение) захотят пользоваться какими - либо специальными программами для выбора файла, а обычные файловые менеджеры являются неотъемлемой частью любой ОС. На этом этапе у меня встает следующий вопрос, который уже обсуждался в данном топике, но однозначный ответ на него так и не найден:
Цитировать
как заменять спец.симовлы в названии книги?
. Также интересует следующее: в наш 21 век ко многим книгам прилагаются электорнные сопроводительные материалы (диски, дискеты с исходниками программ, например). На мой взгляд они должны также находиться в библиотеке, но вот как их именовать/сохранять?
Двигаемся дальше. Вот юзер захотел выложить книгу в электронную библиотеку. На странице загрузки необходима форма, в которой указываются основные данные книги. Далее на веб-сервере они записываются в его БД. После проверки правильности заполнения (модерации) данные записываются в метаданные файла и файл становится доступным для скачивания. Я считаю, что ответственность за книги, попадающие в сеть должны нести администраторы ресурсов, т.к. среднестатистический пользователь не будет задумываться о правильности заполнения метаданных, когда книга сделана для себя, а вот когда собирается ее выложить, то почему бы и нет?
В конце - концов если кому - либо необходима локальная БД для книг это можно реализовать программно, но на уровне ее заполнения для пользователя, то есть скажем так сделать предварительную загрузку файлов на сервер; на основании метаданных, найденных в книге заполнить поля формы, предлагая дополнить недостающие.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: ExeN-321 от 05 јРЩ 2012, 14:28:49
Кстати, 245 символов на имя файла ИМХО очень много, т.к. зачем навязывать пользователю ограничение на размещение каталога?. например если некий Ivanovivaninanovitsh захочет сохранить свою библиотеку в "Моих документах", то под WinXP получится примерно следующее: Диск:\Documents and Settings\Пользователь\Мои документы. На мой взгляд чем меньше символов в имени файла (при сохранении названия, понятного для человека) тем лучше. Как я писал (см.пост выше), у меня уже есть некоторые наработки (самые простейшие) "для себя". Пока сыровато получается, чтобы выкладывать, как доделаю - обязательно выложу здесь (оринтировочно на следующей неделе). Исходники тоже не жалко, но это моя первая программа, сейчас находится скажем так на стадии альфа-тестирования и опрелеления необходимого функционала.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: ExeN-321 от 13 јРЩ 2012, 15:11:18
 Как и обещал - выкладываю свое творчество для ознакомления всем желающим. Жду предложений по доработке.
http://ifolder.ru/30449417 (http://ifolder.ru/30449417)
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: ExeN-321 от 15 ёоЭм 2012, 15:17:31
Устранены ошибки, улучшен интерфейс, добавлены возможности версия 1.1
http://ifolder.ru/31121820 (http://ifolder.ru/31121820)
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: 57an от 17 ёоЭм 2012, 09:10:37

Программа без наличия папки d:\\books вообще не запускается.
Подписи у текстовых полей либо нет, либо справа, либо над, либо под - нужно один раз определиться и сделать одинаково.
Подумайте над группировкой полей - почему верхнее без названия, а нижние с названием.
Кнопка показать название лишняя - поле предпросмотра должно автоматически обновляться по мере заполнения полей.

Равномерное и симметричное распределение полей и кнопок по форме - это еще не интерфейс.
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: ExeN-321 от 17 ёоЭм 2012, 15:19:48
Спасибо, учту Ваши замечания
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: nau от 26 ЅЮпСам 2012, 02:52:52
Здравствуйте, предлагаю свой вариант метаданных. Думаю, что для полноценного поиска и сортировки необходима некоторая избыточность информации. 
http://www.onlinedisk.ru/file/987425/
Название: бланк заявки на участие в монополию
Отправлено: ApktuksKa от 10 ПЭТРам 2016, 17:20:06
Сейчас при мысли о сестре он плотно сжал губы, и его лицо исказила недовольная гримаса. С недовольным лицом он вошел в котельный цех, и таким оно оставалось в течение всего рабочего дня. Его лицо стало еще более мрачным, когда около четырех часов пополудни к нему подошел высокий темноволосый молодой человек. На юноше была серая спецовка, но его руки, в отличие от рук рабочих, не были выпачканы мазутом. Стоя рядом с Джо, он молча наблюдал, как тот вколачивает заклепки в предназначенные для этого отверстия, соединяя таким образом два изогнутых стальных диска. Молодой человек наклонился и прокричал что то ему на ухо, стараясь перекрыть шум цеха, но Джо сделал вид, что не расслышал. Когда к ним подошел Джон Хеверингтон и повторил слова молодого человека, Джо опять притворился, что не слышит. #3232875
Название: Лучшее порево - смотреть порно видео спорт связали
Отправлено: Charlesnal от 18 ПЭТРам 2016, 11:06:14
Лучшее порево
Смотреть порно (http://uvlajnenie.ru/)
 
фильмы с участием анны полины и карлы кокс автомобили и цены порно скачать безплатно мр4 порно грудастых зрелых онлайн минет в бюстгалтере
Название: Лучшее порево - смотреть эротику по русски с мамами
Отправлено: Charlesnal от 18 ПЭТРам 2016, 11:40:51
Лучшее порево
Видео (http://uvlajnenie.ru/)
 
пизда татяны супер толстуху ебут руками порно порно рассказы о сексе наедине с матерью sensual jane онлайн порно русский минет с игрушками ласкает точку джи
Название: Re: Программа для генерации наименования и метаданных DjVu и PDF
Отправлено: nau от 24 °ЯаХЫм 2018, 22:56:14
Прошу прощения! Тематика еще жива?  Есть полный пакет формирования метаданных.