LibreOffice 4.0

Автор ape, 29 июля 2012, 22:06

0 Пользователи и 2 гостей просматривают эту тему.

frob

Ответ видел. Примерно тоже самое, но другими словами я вроде бы уже писал.

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

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

В случае PUB в основном проблемы с API во фреймворке и на стороне LO.
Над API Фридрих работает, в LO кого надо пинает.

Кстати, он начал добавлять поддержку VDX и VSDX (формат MSO2013) в libvisio. Места для реверс-инжиниринга там нет, т.ч. каков прогресс не знаю.

ape

Цитата: frob от 30 сентября 2012, 16:52Ответ видел...
Спасибо.
Цитата: frob от 30 сентября 2012, 16:52В случае PUB в основном проблемы с API во фреймворке и на стороне LO.Над API Фридрих работает, в LO кого надо пинает.Кстати, он начал добавлять поддержку VDX и VSDX (формат MSO2013) в libvisio. Места для реверс-инжиниринга там нет, т.ч. каков прогресс не знаю.
Посмотрев "хронологию" фильтров, это и предполагал: если работа над фильтром имеет "видимый тормоз", жди больших перемен к лучшему.

ape

#92
@frob:
Valek! Если это возможно, "наябедничайте" Фридриху по моменту, который отбивает какое-либо желание смотреть ежедневные сборки.
Причина: Сборки Win_x86 осуществляются в 3-х разных средах MinGW, MSVCR-2008sp1 и MSVCR-2008 с 3-мя вариантами Явы: Ява-5, Ява-7 и без Явы.
Следствие: множество ошибок, специфичных только для этой сборочной ветки, например,
- /daily/Win-x86@7-MinGW/..  как правило не запускаются, сообщая об отсутствии той или иной библиотеки (2012-10-03_23.18.04; 2012-10-05_23.11.11);
- /daily/W2008R2@16-minimal_build/master/2012-10-07_00.46.56/.. собрана с правильной MSVCR-2008, но без Явы, т.е. по сути без LibO_Base;
- /daily/W2008R2@20-With-Symbol-Bytemark-Hosting/master/2012-10-01_05.02.30/.. собрана с MSVCR-2008sp1 и имеет Bug_55437 + ошибки в Base (сообщения программы об использовании неправильной Явы) из-за
Цитироватьchecking the installed JDK... checked (JDK 1.7.0_04)
- вот эта ветка /daily/Win-x86@6/master/.. , давно, с 24.09, не обновлялась, хотя использует самую правильную сборочную среду, с одной оговоркой
Цитироватьchecking the installed JDK... checked (JDK 1.5.0_22)
checking for target Java bytecode version... 1.5
надо использовать JDK 1.6.0_22~33.
--
Результат:
- ошибки со статусом NEEDINFO
- возможен пропуск действительно критичных багов, которые всплывут регрессией официального релиза
- потеря тестеров (мне, например, уже не хочется даже смотреть в сторону "альфы")
--
По возможным ошибкам Base - скорее всего, они вылезут уже сейчас в Федоре и OpenSUSE, т.к. последние /daily/Linux-Fedora17-x86_64@4-gcc-4.7-dbgutil/.. используют в качестве допустимой JDK-1.7.0_06
Цитироватьchecking for java... /bin/java
checking the installed JDK... checked (JDK 1.7.0_06-icedtea)
checking for target Java bytecode version... 1.7
checking for javac... /bin/javac
checking for javadoc... /bin/javadoc
checking if javac works... javac works
checking if gij knows its java.home... /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6.x86_64
Здесь лежит пример MDB-файла, к таблицам которого не могут подключиться (Windows_OS) LibO-3.6.2; W2008R2@16-minimal_build; W2008R2@20-With-Symbol-Bytemark-Hosting
LibO-3.5.7rc2 подключается к этой базе без проблем.
Думаю, что не стоит выносить эксперименты-экскрименты на публичный обзор. Замечу, что при сборке LibO-3.5.7 используются JRE-1.6.0.22 и MS_VCR-2008 (9.0.21022.8_х86), которые, как мне кажется, следует пока использовать в качестве эталонной сборочной среды.

frob

Я попробую.
Возможно эти сборки производятся на разных машинах.

ape

Цитата: frob от  8 октября 2012, 01:30
Я попробую. Возможно эти сборки производятся на разных машинах.
@frob: для сборки LibO-3.6.3.0 продолжают использовать MS_VCR-2008sp1
Цитироватьchecking the Microsoft C/C++ Compiler... found (/cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin/cl.exe)
checking the Version of Microsoft C/C++ Compiler... found compiler version 001500003072 (MSVS 2008).
Боюсь, что люди будут терять время, пытаясь найти причину регрессий, например, по Bug_55437. Если найдёте время, посмотрите, пожалуйста, сообщения об отсутствии этой ошибки в версиях LibO-3.7.0.0 (и LibO-3.5.7.2 - !), для сборки которых использовался MS_VCR-2008
Цитироватьchecking the Microsoft C/C++ Compiler... found (/cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin/cl.exe)
checking the Version of Microsoft C/C++ Compiler... found compiler version 001500002102 (MSVS 2008).
Фридрих один из немногих разработчиков, кто предельно внимателен к Win_x86. Он смог бы подтянуть и Тора, чьи дистрибутивы собирались и на version 001500002102 (MSVS 2008) и с Явой-6(26, если не ошибаюсь).

ape

Таблицы базы данных невозможно подключить. При первом подключении - сообщение, что используется неправильная Ява (1.7.0_u06, как в сборочном логе). Сборка - 3.7.0.0.alpha0+ (Build ID: 6cad15d)_Win_x86. Боюсь, что и в /daily/Linux-Fedora17-x86_64@4-gcc-4.7-dbgutil будет всё тоже самое, т.к. и здесь указана только Ява-7 в качестве допустимой.

Yakov

Цитата: ape от 16 октября 2012, 13:28Сборка - 3.7.0.0.alpha0+ (Build ID: 6cad15d)_Win_x86.
А в этой сборке есть расширение "Построитель отчётов"?

ape

#97
Win_x86
Цитироватьchecking whether to build the Presentation Minimizer extension... yes
checking whether to build the Presenter Console extension... yes
checking whether to build the PDF Import extension... yes
checking which pdf backend to use... internal
checking whether to build the Wiki Publisher extension... no
checking whether to build the Report Builder extension... yes
Fedora ... x64
Цитироватьchecking whether to build the Presentation Minimizer extension... yes
checking whether to build the Presenter Console extension... yes
checking whether to build the PDF Import extension... yes
checking which pdf backend to use... internal
checking whether to build the Wiki Publisher extension... no
checking whether to build the Report Builder extension... yes
checking which jfreereport libs to use... internal
checking which Apache commons-* libs to use... internal
checking whether to build support for scripts in BeanShell... yes
checking which beanshell to use... internal
checking whether to build support for scripts in JavaScript... yes
checking which rhino to use... internal

ape

Цитировать1. Открыть вложенный файл.
2. Файл сохранить как FODT.
3. Файл перезагрузить и сохранить.
4. Сохранить файл как ODT.
5. Файл перезагрузить.
6. Файл сохранить как DOCX.
7. Перезагрузить файл.
Файл-первоисточник имел формулы версии MCO-2003/XP. Эти формулы (действия 2, 3, 4) конвертировались в OLE-объекты "Формулы". Такие формулы теряются при реэкспорте в DOCX.

[вложение удалено Администратором]

Yakov

Цитата: ape от 22 октября 2012, 07:01Такие формулы теряются при реэкспорте в DOCX.
Подтверждаю.
Только потеря формул происходит уже на шаге 3 (когда открываем сохранённый FODT).

ape

#100
В 3.7.0.0 и 3.6.х - да; в 3.5.7.2 - всё так, как написано.
--
P.S. Добавлю коммент в описание ошибки.
p.p.s. Подключение к таблицам БД Access всё также вызыват зависание - смотрел по последней сборке "/daily/Win-x86@6/master/2012-10-20_14.21.35" (Ява-6, MSVCR-2008).

ape

#101
Эта сборка содержит исправления нескольких критичных регрессивных ошибок (Base, RTF..). Пока вопросов со стабильностью работы не больше, чем в LibO-dev_3.6.4.0, и меньше, чем в 3.6.3.2 (официальный релиз). Локализацию (подойдёт на 95%) можно использовать от любого пакета (RPM-DEB; x86-amd64) 3.6.4.0.
ЦитироватьQ; Зачем это надо?
А: Я им пользуюсь из-за поддержки MS_Publisher

ape

Изменил название темы - перенумерация согласно Release Plan.

Yakov

Когда стоит ожидать появления первой локализованной версии 4.0 (с русской локализацией)?
В начале декабря?

ape

#104
Цитата: Yakov от 12 ноября 2012, 14:51
Когда стоит ожидать появления первой локализованной версии 4.0 (с русской локализацией)?
В начале декабря?
Не знаю. Использую локализацию DEB-3.6.4.0. Совпадает ~95%. Можно просто распаковать архив (вложение).
Пока 2 неприятных регрессии - потеря формул формата МСО-2000\2003 в DOCX-файлах и дублированная нумерация страниц (слева и справа) в тех же DOCX. Тестовый файл - Proekt_MU.docx - размещён на форуме. 1-я регрессия появилась после устранения автозапуска Редактора формул МСО в фоновом режиме, что привело к потере OLE-формул, даже в случае кросс-конвертации через FlatXML. Теперь такие файлы приходится сразу, за один прогон, редактировать, заменяя OLE-формулы LibreMath на формулы.
--
Вернулись бы к варианту 3.5.7.2:
- МСО не у всех
- Редактор формул легко добавляется и удаляется из состава установленных компонентов
- При конвертации в
ODT\FODT нет необходимости редактировать за один прогон


[вложение удалено Администратором]