search

PiRSquared17 / ooofbtools

Automatically exported from code.google.com/p/ooofbtools
0 stars 0 forks source link

Python port #58

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Собственно, альфа-версия доступна здесь - 
https://gitorious.org/lopyfb2tools
В аттаче - собранный экстэншн (на Gitorious - 
только сырцы, без полноценного Питона на 
данный момент не собираются, т.к. в Питоне 
из-под LO/OOo нет инструментов для 
локализации).

Ждать ответа от sloth'а ( с.м. обсуждение на 
http://code.google.com/p/ooofbtools/issues/detail?id=54 ) не стал, 
поставил LGPLv3.

Original issue reported on code.google.com by LRN1...@gmail.com on 24 May 2011 at 5:26

Attachments:

GoogleCodeExporter commented 9 years ago 
Молодец. Проверь только валидацию готового 
файла - выдается сообщение "необработанный 
эксепшн в валидаторе схемы..."  и т.д. - на 
валидном fb2-файле.

Original comment by dik...@gmail.com on 25 May 2011 at 9:49

GoogleCodeExporter commented 9 years ago 
Какой эксэпшн-то? Пиши подробно. Любой 
эксепшн помимо XsvalError (тысячи их!) считается 
"необработанным".
Ну, или документ дай, из которого делал fb2 
(запускать валидатор на готовом fb2 вручную 
сейчас нельзя, значит ты валидировал fb2, 
созданный из odt).

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

Original comment by LRN1...@gmail.com on 25 May 2011 at 10:00

GoogleCodeExporter commented 9 years ago 
Конечно, не здесь надо обсуждать твой порт, 
но все же - напишу. Файл, который я 
конвертировал LOPyFB2Tools - очень маленький - 
Сноски.odt - я на нем отлаживаю экспорт с 
помощью OOoFBTools разных видов сносок. Прогони 
- сам увидишь эксепш.
Теперь о другом. Я прогнал твоим LOPyFB2Tools 
книгу на 264 стр. - без структуры (Уровни, 
стихи и т.д.) - просто текст и обложка. У 
LOPyFB2Tools анализ занял 3,5 мин. У OOoFBTool - 2 мин 32 
сек. Но дальше стадии анализа LOPyFB2Tools не 
прошел - наглухо завис на этапе Создания 
файла - устал ждать, закрыл Редактор. В 
Диспетчере задач (на Винде) остался висеть 
uno.exe, который блокировал "заготовку" 
fb2-файла книги...
1. Проверь на большой книге у себя.
2. Не пойму, в чем преимущество проги на 
Питоне (LOPyFB2Tools ) по сравнению со StarBaisic`ом - 
оба - интерпретаторы, и скорость экспорта у 
OOoFBTools намного выше.

Original comment by dik...@gmail.com on 25 May 2011 at 10:34

Attachments:

GoogleCodeExporter commented 9 years ago 
Вот скрин ошибки валидации.
И еще - то, что я писал выше - когда прога 
зависла, пришлось сносить Writer. Потом, при 
новом запуске Writer`а LOPyFB2Tools ни как не 
реагирует, приходится LOPyFB2Tools удалять (с 
руганью Writer) и устанавливать заново... Может 
эта инфа поможет тебе в отладке.

Original comment by dik...@gmail.com on 25 May 2011 at 10:44

Attachments:

GoogleCodeExporter commented 9 years ago 
А где лучше обсуждать? Создать отдельную 
группу?
К слову, шрифты под юникс и виндовс слегка 
отличаются. На моём компе с виндовс многие 
сообщения обрезаны и строчки наезжают одна 
на другую.

Original comment by yegor.ch...@fbtools.org on 25 May 2011 at 11:25

GoogleCodeExporter commented 9 years ago 
Даже и не знаю, как лучше. Когда я писал 
тебе, что "не здесь надо обсуждать твой 
порт" - у меня в голове сидел твой вопрос 
лицензии, поэтому и подумал, что в ветке о 
лицензии порт лучше не обсуждать. Спутал.

Original comment by dik...@gmail.com on 25 May 2011 at 11:36

GoogleCodeExporter commented 9 years ago 
Сконвертировал Сноски.odt у себя - 
сконвертировался успешно, валидатор 
ошибок не выдал.
Какая у тебя версия OpenOffice/LibreOffice? 
Операционная система?
Попробуй вскрыть экстэншн, открыть 
pythonpath/LOPyFB2Tools.py и сделать enable_debugging = True, 
потом перепаковать и установить. При 
включённом дебаггинге будет при каждом 
запуске конвертера открываться окно с 
логом (знаю, кривота, но под виндой к stdout/stderr 
OpenOffice'а подсосаться не удаётся) - возможно 
там будут более подробные сообщения об 
ошибках. Если там тоже ничего особого не 
наблюдается, то я выложу версию с более 
подробными сообщениями об ошибках.

Если Writer зависает - это скорее всего 
проблема не валидации, а вообще экстэншна и 
Питона.
Вообще, меня немного настораживает 
сообщение о существовании uno.exe. Потому что 
у меня (LibreOffice 3.3.2) его не наблюдается, Питон 
работает прямо внутри soffice.bin, в отдельном 
треде.

Скорость работы выше на очень больших 
файлах. Есть у меня один файл в 2146 страниц, 
на нём анализ у LOPyFB2Tools идёт на порядок 
быстрее, чем у OOoFBTools. А на стадии создания 
файла OOoFBTools вообще падает.

Впрочем, я не утверждаю, что скорость 
работы на мелких файлах нельзя улучшить, 
оптимизацией я занимался по минимуму, есть 
надежда на улучшения.
Я вчерне попрофилировал его вчера, вот 
результаты для example-1:
Без таблиц и картинок - 0.5 секунды
С таблицами - 1.5 секунды
С таблицами и картинками - ~5 секунд
Но example-1 он вообще такой особый - с кучей 
таблиц и картинок, собственно текста там 
мало. Есть, чем заняться.

Кстати, у него ещё и память течёт. Я заметил 
это на первоначальном варианте About'а, 
который был с фоновой картинкой (нет, 
картинку я впоследствии убрал по другой 
причине) - там уносило чуть ли не по 
пол-мегабайта за раз. Тоже есть над чем 
подумать.

Original comment by LRN1...@gmail.com on 25 May 2011 at 2:16

GoogleCodeExporter commented 9 years ago 
Вот та же альфа-версия, только debugging 
включён. Печатает по-прежнему мало 
информации, но по крайней мере эксэпшны 
можно будет увидеть в подробностях.
Ещё прилагаю версию с включённым 
профайлингом. Профайлинг довольно 
примитивный, через декораторы, но на 
безрыбье и кастрюля - соловей.
В заключении - то же самое, но без 
дебаггинга и профайлинга.

Пробовал запускать под OOo 3.3.0 - работает 
исправно (но зато увидел тот uno.exe, о котором 
ты говорил; видимо запуск экстэншнов 
внутри soffice.bin - это либо особенность LO, либо 
новая фича, которой в 3.3.0 пока нет).

Скинь мне на почту файл, на котором у тебя 
вешался конвертер.

И вот ещё что, я сделал грубый (+- 500ms) замер 
времени между нажатием на OK и появлением 
диалога с результатом конверсии example-1 с 
помощью -plain версии - для OOo 3.3 и для LO 3.3.2. Вот 
результаты:
OOo 3.3 - 11216.000080108643ms
LO 3.3.2 - 5542.999982833862ms
Собственно, 5500 для LO - это те самые ~5 секунд, 
о которых я говорил в предыдущем посте.

Original comment by LRN1...@gmail.com on 25 May 2011 at 4:16

Attachments:

GoogleCodeExporter commented 9 years ago 
Ты молодец. Когда доведешь до ума прогу - 
хорошая вешь будет...

Original comment by dik...@gmail.com on 25 May 2011 at 5:23

GoogleCodeExporter commented 9 years ago 
Файл скину завтра на работе.

Original comment by dik...@gmail.com on 25 May 2011 at 5:24

GoogleCodeExporter commented 9 years ago 
У меня стоит OOo3.3.1. На LO не пробовал - может 
твой порт там работает быстрее, чем на Ooo

Original comment by dik...@gmail.com on 25 May 2011 at 5:26

GoogleCodeExporter commented 9 years ago 
Да, если не трудно - скинь мне на почту тот 
большой файл, на котором OOoFBTools падал при 
создании fb2 - хочу погонять под отладчиком.

Original comment by dik...@gmail.com on 25 May 2011 at 5:29

GoogleCodeExporter commented 9 years ago 
Три версии, с исправленным About'ом. Я 
отказался от статической разметки, сделал 
динамическую, растягивается по тексту. Но 
текст должен изначально быть разбит 
переносами строки, иначе диалог растянется 
по нему эдак до 2000x600. Но это в основном 
касается локализаторов. Русскую 
локализацию я обновил соответствующим 
образом.

Original comment by LRN1...@gmail.com on 25 May 2011 at 5:52

Attachments:

GoogleCodeExporter commented 9 years ago 
Да, ещё одна вещь. В LOPyFB2Tools жанры в тексте 
книги (которые отформатированы служебными 
стилями) пишутся в виде кодов (типа comp_soft 
или ref_genre). Это связано с тем, что если 
писать жанр по имени, то он не будет 
читаться в другой локали (ибо имена жанров 
зависят от локали).
Как вариант, можно выделить названия 
жанров во что-нибудь отдельное и шаманить с 
translation(), чтобы загружать названия жанров 
для всех языков разом, и сверять текст из 
книги уже с этим списком.
Но это, конечно, много копать придётся. 
Проще оставить жанр в тексте в виде кода. 
Ну, и в конвертэр можно добавить фичу для 
отображения кодов жанров (сейчас 
показываются всегда только названия, код 
сохраняется под шапкой). А если говорить о 
наборе инструментов (которых в LOPyFB2Tools пока 
нет), то можно сделать инструмент для 
вставки кода жанра по имени.

Original comment by LRN1...@gmail.com on 25 May 2011 at 6:05

GoogleCodeExporter commented 9 years ago 
Оставить просто код жанра - это все-таки не 
есть хорошо для пользователя - не упомнишь 
все коды. Я в свое время массу времени 
потратил для того, чтобы выбор жанра был 
удобнее...

Original comment by dik...@gmail.com on 25 May 2011 at 6:14

GoogleCodeExporter commented 9 years ago 
Сделал более подробный профайлинг. Взял 
99-страничный отрывок из большой книги 
(удалил оттуда таблицу, которая была в 
начале - остался только текст, заголовки и 
по-моему одна поэма). Замерил, сколько 
времени работает Document_parser(). Работает ~900ms.
Начал комментировать в нём разные куски 
кода.
Выяснилось, что ~300ms тратится суммарно на 
Delete_line_break() (взял на заметку, возможно если 
не использовать регулярные выражения, то 
будет чуток быстрее) и Inline_all_parser()
Ещё ~300ms тратится на логику (обработка 
разных типов секций - хотя самих секций нет, 
есть только проверка на тип секции, все 
секции на самом деле оказываются Text) и 
обработку нумерованных списков.
И наконец, когда я убрал оттуда всё и 
оставил вот это:

def Document_parser (self, settings):
  text = self.model.getText ()
  for paragraph in Enumeration_iterate (text.createEnumeration ()):
    for section in Enumeration_iterate (paragraph.createEnumeration ()):
      continue

Я получил ~300ms в остатке. То есть перебор 
(без обработки!) содержимого документа по 
параграфам занимает 1/3 времени 
относительно перебора с обработкой.
Пробовал отказаться от враппера 
Enumeration_iterate(), результат ощутимо не 
изменился.
Из этого я сделал вывод о том, что Document_parser() 
дальнейшей оптимизации не подлежит (разве 
что изменится алгоритм работы). То есть 
парсинг простого текста (без всего) 
работает близко к своему теоретическому 
пределу.

Медленная обработка 264-страничного текста, 
который ты упоминал, скорее всего является 
отражением замедления (в два раза), которое 
я обнаружил в OOo по сравнению с LO (см. 
предыдущие посты). Ну, и ещё у тебя 
процессор медленнее моего, причём 
значительно - у меня этот документ скорее 
всего секунды за 3 обработается, а не за 2 с 
половиной минуты. Хотя не, там же ещё запись 
в файл...
А вот сохранение одной картинки (обложки) 
вполне может также всё обломать - в 
нынешней реализации обработка некоторых 
картинок серьёзно замедляет работу.

Original comment by LRN1...@gmail.com on 25 May 2011 at 10:04

GoogleCodeExporter commented 9 years ago 
Да, мой процессор сегодня только в 
антикварном магазине найти можно :). 
Пробовал потр на работе а там - допотопные 
машины.

Original comment by dik...@gmail.com on 26 May 2011 at 1:44

GoogleCodeExporter commented 9 years ago 
Новая серия экстэншнов. Валидатор теперь 
работает параллельным процессом (разница 
только в том, что он не вешает soffice, и его 
можно убить по желанию), можно запускать 
валидацию для уже существующих файлов. 
Исправлена пара багов.

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

Original comment by LRN1...@gmail.com on 26 May 2011 at 6:43

Attachments:

GoogleCodeExporter commented 9 years ago 
Пробовал запускать под другим юзером, у 
которого стандартные права (NT 6.1.7601, юзер 
только что создан со стандартными правами) 
- всё работало исправно. Так что дело не в 
админских привилегиях (хотя не исключено, 
что более жестокие относительно 
стандартных политики могут негативно 
отражаться на работе).

Заодно выяснил, что quickstarter считается при 
перезапуске OpenOffice. Поэтому надо выключать 
его в том числе, когда перезапускаешь OO 
после установки экстэншна (а перезапускать 
надо - иначе будет медленно работать). Надо 
будет как-то это отразить в документации.

Original comment by LRN1...@gmail.com on 26 May 2011 at 6:56

GoogleCodeExporter commented 9 years ago 
Молодец!

Original comment by dik...@gmail.com on 27 May 2011 at 4:06

GoogleCodeExporter commented 9 years ago 
Добавил перевод множественных чисел (пока 
только в одном месте - кол-во 
экспортированных картинок).

Теперь make.py использует только GNU gettext. 
pygettext.py, как оказалось, не поддерживал 
множественные числа (либо я не догадался, 
как ею воспользоваться, наверное keyword 
неправильно указывал - при использовании 
xgettext я на те же грабли сначала наступил). 
Добавил соответствующий аргумент, чтобы 
легче было указывать местонахождение gettext. 
Поскольку GNU gettext теперь обязателен, make.py 
также самостоятельно обновляет все 
найденные .po-файлы из en_US.po.

Добавил строк для перевода. Обновил 
русский перевод и добавил его в 
репозиторий.

Сделал тэг 1_0_0_beta_1

Как обычно, три варианта в аттаче.

/me пошёл искать beta-тэстеров

Original comment by LRN1...@gmail.com on 28 May 2011 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил загружалку шаблона стилей (шаблон 
есть в репозитории в под-директории misc, это 
тот же самый шаблон, который поставляется в 
архиве с OOoFBTools). Обновил русский перевод. 
Сделал тэг 1_0_0_beta_2.

Original comment by LRN1...@gmail.com on 28 May 2011 at 7:06

Attachments:

GoogleCodeExporter commented 9 years ago 
Исправил несколько багов связанных с 
работой под *nix (тэстировал под Debian Sid). 
Сделал тэг 1_0_0_beta_3.

Original comment by LRN1...@gmail.com on 28 May 2011 at 8:54

Attachments:

GoogleCodeExporter commented 9 years ago 
Х-м-м...сделал вставлялку языков и жанров 
(служебные стили). Пока не закоммитил. В 
процессе работы над ней возник вопрос: а 
почему, собственно, не все поля 
информ.диалога можно задать с помощью 
служебных стилей?
Мне в LOPyFB2Tools проще сделать функцию, которая 
записывает всё записывабельное содержимое 
информ.дерева (т.е. исключая ID, дату 
создания FB2, и название ПО, наверное) с 
разметкой служебными стилями в документ, 
чем делать для этого отдельный диалог, как 
это реализовано в OOoFBTools.

Original comment by LRN1...@gmail.com on 29 May 2011 at 4:57

GoogleCodeExporter commented 9 years ago 
Сменил статус на "работа идёт".

Original comment by LRN1...@gmail.com on 29 May 2011 at 5:31

GoogleCodeExporter commented 9 years ago 
В новой версии Офиса можно добавлять любые 
свойства для документа. Как вариант — 
пользователь должен всю специфическую 
инфу задать в пропертях, что сохраняются с 
самим документом.

Original comment by Yegor.Chemisov on 29 May 2011 at 6:26

GoogleCodeExporter commented 9 years ago 
Согласен, у меня у самого была мысль 
воспользоваться внутренними переменными 
документа.
Вопрос лишь в наглядности. Переменные - они 
закопаны внутри Ctrl+F2, надо знать, где они 
находятся, чтобы их найти. Плюс, 
редактировать их не то чтобы очень удобно.
В дереве редактирование наиболее удобное, 
ИМХО.
Можно пытаться сохранять данные из дерева 
во внутренние переменные документа, вместо 
дампа их прямо в текст со спец. стилями, но 
опять же - некоторые пользователи могут не 
понять.
Поэтому и вопрос встал.

Original comment by LRN1...@gmail.com on 29 May 2011 at 6:32

GoogleCodeExporter commented 9 years ago 
Сделал дамп информации fb2 в user-defined properties. На 
данный момент содержимое текста, 
помеченного служебными стилями, и 
содержимое дампа частично дублируются при 
открытии диалога (если дамп есть). После 
обдумывания решил оставить как есть: 
нормальное действие со стороны юзверя - это 
открыть диалог, подгрузив данные от 
служебных стилей, сделать дамп, закрыть 
диалог и удалить весь служебный текст 
(кроме аннотации, если она есть). Можно было 
бы сделать сравнение подгружаемых полей и 
отброс дубликатов, но рано или поздно 
юзверь где-то что-то поменяет, и 
дублирование опять вылезет, так что лучше с 
этим разобраться сразу.

Добавил 'make install' - теперь можно собирать и 
устанавливать экстэншн в офис одной 
командой! Кстати, если делать это при 
работающем офисе, то экстэншн будет 
работыть в отдельном процессе uno.exe (причём 
кол-во этих процессов может расти по мере 
переустановки экстэншна на один и тот же 
работающий процесс офиса). Скорее всего 
замедление работы при использовании 
экстэншна без перезапуска офиса как раз 
связано с работой экстэншна в отдельном 
процессе - IPC там скорее всего делается 
через сокет или пайп, а I/O под виндой 
известен своей дикой тормознутостью.

Обновил и пополнил перевод.

Сделал тэг 1_0_0_beta_4.

К слову, после записи дампа LibreOffice думает 
(даже на моей адской машине!) несколько 
секунд при открытии вкладки с юзерскими 
параметрами. Почему - не ясно, не так уж и 
много информации там. Наверное рисует 
контролы.

Original comment by LRN1...@gmail.com on 30 May 2011 at 12:19

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил инструмент для очистки стиля 
абзаца.

Добавил стабы для половины инструментов 
OOoFBTools (чтобы потом не делать перестановок 
пунктов меню).

Добавил вывод stdout/stderr unopkg в случае ошибки в 
его работе

Исправил три бага:
* в ресайзе диалога (на нынешний код не 
влияет, влияет на ещё не закомиченный код)
* в вызове init.py из коммандлайна (работает ли 
он - хз, давно не пользовался)
* в чтении свойств документа (если был 
записан жанр без имени, но с match'ем, то такая 
запись теперь игнорируется, не приводя к 
вылету конвертэра)

Пока без тэга.

У меня такое ощущение, что версия с 
профилированием не особо популярна, 
поэтому пока буду выкладывать только 
обычную и отладочную версии.

Original comment by LRN1...@gmail.com on 31 May 2011 at 9:02

Attachments:

GoogleCodeExporter commented 9 years ago 
Исправил баг, связанный с получением 
расширения файла. В отличие от ConvertFromURL в 
бэйсике, питоновский эквивалент не 
работает с url'ами типа http: и прочими не-file:. К 
счастью, конверсия в локальное имя файла в 
принципе не требуется, поэтому я её убрал.

Original comment by LRN1...@gmail.com on 31 May 2011 at 9:29

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил корректор текста и корректор 
переносов. Практически не тестировались, 
ибо не на чем .У кого есть сканированные 
тексты или готовые документы с 
искусственно введёнными ошибками - 
пожертвуйте на тэсткейсы! :)

Сделал тэг 1_0_0_beta_5. Давно пора.

Original comment by LRN1...@gmail.com on 1 Jun 2011 at 8:26

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил скачку картинок по ссылкам (любые 
ссылки, поддерживающиеся urllib - скорее всего 
он поддерживает больше, чем OpenOffice).

Исправил логику экспорта встроенных 
картинок, теперь выходной fb2-файл для example-1 
полностью совпадает с созданным OOoFBTools (за 
исключением названия программы и даты; и 
UTF-8 у меня написано заглавными буквами :) )

В чесьт такого дела сделал тэг 1_0_0_beta_6

Original comment by LRN1...@gmail.com on 1 Jun 2011 at 12:02

Attachments:

GoogleCodeExporter commented 9 years ago 
Исправил баг в геренации сложного ID.
Исправил дубликацию автора fb2, когда 
загружается дефолтный автор, и загружается 
автор из файла (в отличие от OOoFBTools, LOPyFB2Tools 
сохраняет и автора документа тоже).

Пока что без тэга.

Original comment by LRN1...@gmail.com on 2 Jun 2011 at 3:10

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил корректор OCR.

1_0_0_beta_7

Original comment by LRN1...@gmail.com on 2 Jun 2011 at 6:40

Attachments:

GoogleCodeExporter commented 9 years ago 
Чёрт, забыл сделал тэг, а исправить баг с 
подзаголовками забыл!
Версия с исправленным багом. Теперь - без 
тэга.

Original comment by LRN1...@gmail.com on 2 Jun 2011 at 7:01

Attachments:

GoogleCodeExporter commented 9 years ago 
Очень хотел спать, не доисправлял баг с 
подзаголовками. Теперь исправил.

Original comment by LRN1...@gmail.com on 3 Jun 2011 at 5:10

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил ручную коррекцию абзацев.
Кстати, она работает лучше оригинальной, 
поскольку умеет пропускать нетекстовые 
куски. Это позволяет обрабатывать 
выделения, содержащие таблицы, картинки и 
прочие OLE (в частности - обрабатывать весь 
текст полностью, если ничего не выделено).

Сделал тэг 1_0_0_beta_8

Original comment by LRN1...@gmail.com on 3 Jun 2011 at 3:54

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил переключатель раскладки. Пока 
довольно убогий, но с прицелом на будущее. 
Открыт к критике относительно структуры 
меню и UI (в расчёте на конвертацию между 
любыми двумя раскладками из большого 
множества). Кроме того, он сохраняет 
форматирование при переключении (в отличие 
от OOoFBTools). За это приходится расплачиваться 
скоростью работы. Большие куски текста 
обрабатывает долго, одну страницу - за 20 
секунд (на моей машине). В принципе, можно 
сделать две версии - быструю (без 
сохранения стилей) и медленную (с 
сохранением). Да, сохранение стилей делает 
практически невозможной отмену 
преобразования (стэк undo забивается до 
отказа даже на небольшом отрывке).

Тэг 1_0_0_beta_9

Original comment by LRN1...@gmail.com on 4 Jun 2011 at 12:37

Attachments:

GoogleCodeExporter commented 9 years ago 
Добавил инструмент для создания 
маркированных списков. В отличие от 
оригинального, этот не имеет диалога - 
выбор варианта работы (маркировка всех 
абзацев, или только уже являющихся 
элементами списка) осуществляется через 
соответствующий пункт меню.

Пока без тэга.

Кстати, вопрос: зачем этот инструмент нужен 
вообще? OpenOffice и сам вполне неплохо 
справляется с созданием списков, и 
экспортируются в fb2 они тоже хорошо.

Попутный вопрос: а не запихать ли 
инструменты в под-меню? Вместо 
использования одного длинного меню с 
разделителями.

Original comment by LRN1...@gmail.com on 5 Jun 2011 at 7:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Да, я тут почитал литературку попутно. Там 
упоминается, что createEnumeration() работает 
довольно медленно, и что использование 
курсоров для перебора абзацев позволяет 
значительно убыстрить работу. Правда, это 
было сказано для pre-2.x, а у нас уже 3.4 на дворе 
(кстати, в 3.4 экстэншн работает, 
разрабатываю сейчас под ним). Это к 
комментарию номер 16 - 
http://code.google.com/p/ooofbtools/issues/detail?id=58#c16.

Original comment by LRN1...@gmail.com on 5 Jun 2011 at 7:55

GoogleCodeExporter commented 9 years ago 
Исправил баг с именами файлов, содержащими 
не-латинские символы. Теперь имена файлов, 
которые скармливаются subprocess.Popen(), 
кодируются в локальную кодировку файловой 
системы.

Original comment by LRN1...@gmail.com on 5 Jun 2011 at 10:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Вопрос из #39 также относится к инструментам 
для работы с гиперссылками и разными 
видами сносок: зачем они нужны? Какие 
use-case'ы? Есть ли преимущества по сравнению 
со встроенными в OOo/LO инструментами?

Original comment by LRN1...@gmail.com on 6 Jun 2011 at 8:33

GoogleCodeExporter commented 9 years ago 
Насчет подменю. Я делал так (без подменю), 
чтобы было легче и быстрее user'у добраться 
до инструментов. Тем более, если вставку 
маркеров надо делать сотни раз...
Зачем этот инструмент нужен? Я заметил, что 
многие стандартные маркеры после OCR 
конвертер конвертирует, но читалки их не 
видят - отображается знак "?". Проблема не в 
конвертере - он тупо считывает симол и 
записывает его в нужной кодировке (если 
есть маркеры - то автоматом при вкл. опции - 
используется UTF-8). Чтобы в читалках 
нормально отображались маркеры (не все так 
криво отображаются) я и сделал инструмент 
замены маркеро на заведомо "хороший". 
Подробнее по инструментам см. Справку.

Original comment by dik...@gmail.com on 6 Jun 2011 at 3:58

GoogleCodeExporter commented 9 years ago 
Инструменты генерации сносок - это автомат. 
Есть несколько видов списков сносок - в 
конце главы, в конце книги и т.д. При 
установке соответствующих закладок 
Генератор сносок по заданному шаблону 
автоматически генерирует сноску для 
определенного текста сноски из Списка 
сносок. То же самое - и для генерации 
гиперссылок, только вместо сносок 
генерируются ссылки. Попробуй - легче будет 
понять суть инструмента.
Я очень подробно с примерами и картинками 
расписал его в Справке.

Original comment by dik...@gmail.com on 6 Jun 2011 at 4:01

GoogleCodeExporter commented 9 years ago 
Насчёт подменю: есть такая вещь как 
шорткаты. Если делать 100 раз, то гораздо 
удобнее в первый раз запомнить, что 
конверсия текста с английской в русскую 
раскладку вызывается через Alt+l-k-e-r, а в 
обратном направлении - через Alt+l-k-r-e. Тот же 
самый принцип применён к корректору ошибок 
OCR: вместо того, чтобы мышкой клацать то по 
одной, то по другой кнопке, достаточно 
запомнить, что кнопка "Найти" жмётся через 
Alt+h, режимы работы переключаются через Alt+f, 
а 5 кнопок справа активируются через 
Alt+u,j,i,k,l соответственно своему положению в 
диалоге.

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

Насчёт генератора ссылок: почитал help. В 
целом понятно, но как-то сложно и муторно. 
Должен быть способ попроще.

Original comment by LRN1...@gmail.com on 6 Jun 2011 at 4:28

GoogleCodeExporter commented 9 years ago 
Насчет шорткатов - ты прав - это проще. Но 
вот не всякий user сообразит, КАК повесить 
тот или иной мсакрос на быстрые клавиши. 
Поэтому я и пошел по выбранному пути (себе 
то я наделал шорткатов).

Маркеры: Конечно, сожно вставлять именно 
маркер, но - не помню уже - давно это было - не 
все "стандартные" маркеры OOo отображали 
нормально читалки, а я устал объяснять useram, 
что коныертер не виноват. Вот и сделал 
заведомо отображающийся в читалкаъ маркер 
с пробелом. Кому надо - заменили 
инструментом маркеры на этот - и все 
читается.
Я понимаю - это - костыль. Но - за неимением 
лучшего...

Original comment by dik...@gmail.com on 6 Jun 2011 at 4:48

GoogleCodeExporter commented 9 years ago 
Генератор сносок: Есть еще задумки его 
расширить - обработывать после OCR 
постраничные сноски (цифра с текстом после 
нескольких абзацев), обрабатывать 
звездочки, как идентификаторы сносок - и 
ряд друних видом сносок. Но - там масса 
сложностей, и скорее всего если сделаю - это 
будет уже не автомат, а интерактивный 
инструмент, т.к. после OCR номера сносок 
часто распознаны неверно, и без 
вмешательства пользователя - не понять, 
какой текст привязать к какой сноске...

Original comment by dik...@gmail.com on 6 Jun 2011 at 4:51

GoogleCodeExporter commented 9 years ago 
Не надо ничего вешать на макросы, 
соответствующие пункты меню уже помечены 
акселераторами, офис всё сделает сам. Это 
так же просто, как вызвать "Вставка->Сноска" 
через Alt+а-р. Разница только в том, что в 
отличие от локализаторов офиса я решил 
сделать унифицированные шорткаты для всех 
локалей - поэтому конверсия раскладки 
будет Alt+l-k-e-r и Alt+l-k-r-e вне зависимости от 
локали, в то время как в офисе, допустим, 
Файл->Выход в русской локали вызывается 
через Alt+ф-ы, а в английской - Alt+f-x.

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

Насчёт сносок: я склоняюсь не к 
автоматической обработке, а к "помощнику" 
при ручной обработке. Помощник будет иметь 
вид окна, которое висит рядом и позволяет 
искать возможных кандидатов в сноски. 
Найденные ссылки на сноски (т.е. не сам 
текст сносок, а ссылки на них, типа числа в 
верхнем регистре) пользователь будет 
выделять и жать кнопку "это ссылка на 
сноску". И искать дальше. Текст, являющийся 
текстом сноски, пользователь будет 
выделять, и жать уже кнопку "это текст 
сноски". Для ссылок тоже будут свои 
варианты, я думаю. Все эти действия 
помощник будет запоминать (происходит 
независимо от офиса; сохранять это добро 
придётся скорее всего в отдельном файле). 
Когда весь текст просмотрен, можно будет 
открыть специальный диалог работы со 
сносками, в котором ссылки на сноски можно 
будет сопоставлять с текстами сносок 
(думаю, будут всякие кнопки и 
интеллектуальные сопоставители, чтобы 
руками много не тыкать). Как это будет 
выглядеть - я пока не придумал. Можно будет 
управлять типом сносок (страничные, 
конечные, поглавные). После того, как всё 
сопоставлено, можно будет ткнуть кнопку, и 
текст будет приведён в кошерный вид - будут 
вставлены ссылки, сноски, гиперссылки и т.д.
Дело в том, что:
1) То, что есть в OOoFBTools выглядит, ИМХО, 
сложным (вообще, то, что я предлагаю, тоже 
сложное, но поскольку опираться на 
закладки в тексте не придётся, наверное 
будет проще)
2) Я так понял, что мотивация этого 
инструмента - избежать прыжков по тексту в 
поисках сносок. В данном же случае весь 
просмотр идёт линейно. То есть, конечно, это 
не автоматика, но автоматическая вычитка 
OCR'нутых документов - это из области научной 
фантастики; читать текст человеку придётся 
так или иначе, и запоминать (с помощью 
программы), где там - ссылки на примечания, а 
где - текст примечаний, можно по ходу чтения 
(читал не одну OCR'нутую книгу и, я думаю, 
примерно представляю, как выглядят 
неправильно распознанные сноски и 
примечания: ссылки - как левые числа в 
тексте, текст примечаний - как неожиданно 
вклинивающийся в основную массу текст, 
также неожиданно из неё потом 
выклинивающийся). Я бы даже пожалуй функцию 
для поиска возможных ссылок на примечания 
убрал, чтобы не искушать пользователей 
автоматикой там, где нужна ручная работа. 
Тогда можно вообще на этапе вычитки 
отказаться от окна - добавлять ссылки и их 
текст через меню и/или шорткаты и/или 
акселераторы.

Original comment by LRN1...@gmail.com on 6 Jun 2011 at 5:20

GoogleCodeExporter commented 9 years ago 
Насчет "помошника" по работе со сносками. У 
меня он запланирован, только немного в 
другом ракурсе - интерактивный диалог для 
остальных вариантов сносок (я писал о них 
выше), но найденные символы номеров сносок 
(в верхнем ли регистре, звездочки ли и т.д.) 
при подтверждении юзером помечаются 
автоматом спец. закладкой прямо в тексте. в 
параллельном окне диалога помошника - 
сразу ищется ближайщий текст для этой 
сноски, и тоже при подтверждении юзером 
помечаются автоматом спец. закладкой прямо 
в тексте. Это позволяет избежать 
сохранения в массу файлов, ускоряет 
работу... Надо еще учесть, что номера сносок 
могут быть неверно распознаны - часто 
вместо 3 FR распознает 4, вместо 6 - (0) или 
что-то в этом роде.
После прогона в интерактивном режиме 
помошник по таблице соответствия закладок 
номеров сносок и их текста вставляет 
сноски, удаляя при этом и эти закладки, и 
текст и номера.
Что-то в этом роде.

Original comment by dik...@gmail.com on 9 Jun 2011 at 4:58

GoogleCodeExporter commented 9 years ago 
Исправил некорректные аргументы в вызове 
Save_close_section() - в порыве редакторского рвения 
я зачем-то передал туда два последних 
аргумента повторно :-/

Original comment by LRN1...@gmail.com on 15 Jun 2011 at 2:13

Attachments: