[OpenOffice] Проблемы OOO

а можно ссылку на спецификации?

Чтобы OOo доработать, его сначала нужно откопать

/thread

>почему не довели до ума, что мешает? непонятно.

если бы это было хоть кому-то по-настоящему нужно, давно бы уже всё сделали

> а можно ссылку на спецификации?

http://www.microsoft.com/interop/docs/officebinaryformats.mspx

>> если бы это было хоть кому-то по-настоящему нужно ++и этот кто-то обладал бы подобными возможностями++, давно бы уже всё сделали

Вон сколько лет народ мучился, писал html+css движки для браузеров, пока более-менее заработало. W3C так и до сих пор референсный браузер склепать не осилило. По своим собственным открытым спецификациям, ага.

С офисами та же фигня. А с МСО и еще хуже.

> если бы это было хоть кому-то по-настоящему нужно, давно бы уже всё сделали

По большому счету оно многим нужно (преимущественно конечно пользователям Windows), но я бы тоже не стал ставить поддержку форматов MSO в приоритет.

почему не довели до ума, что мешает? непонятно.

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

новость на opennet

http://www.opennet.ru/opennews/art.shtml?num=14318

> но я бы тоже не стал ставить поддержку форматов MSO в приоритет

а что ставить, интерфейс MSO, который воткнуть хотят? :)

ты сам то эти «открытые» спецификации видел? если они открыты - не зачит, что их очень просто реализовать.

>> а можно ссылку на спецификации?

http://www.microsoft.com/interop/docs/officebinaryformats.mspx

Не подскажете, а на какой странице там описано как отрисовывать и обрабатывать OLE объекты?

>спецификации doc и docx Ms открыты давно

Почитай 6000 листов спецификаций

>спецификации doc и docx Ms открыты давно

Спецификации ODF открыты ещё дольше, но такая серьёзная компания, как Microsoft, так и не смогла сделать полноценную поддержку этого стандарта.

>спецификации doc и docx Ms открыты давно

«Делать как ворд 97» и ко. Спецификации MS такие спецификации.

> не смогла сделать полноценную поддержку этого стандарта.

Мне тут пересохраняли мсофисом в одт вордовские файлы, которые опенофис открывал плоховато, мсофис неплохо с одт работает.

>почему не довели до ума, что мешает? непонятно.

Доведи, что мешает? непонятно.

>Умеет открывать простые документики

полноценную поддержку

Так и OOo работает :}

всем известно наверное, что кривая работа с майкрософтовскими форматами одна из самых больших бед MSO.
Исправил.

MSO 2007/2010 документы в форматах более ранних версий самого себя открывать нормально не умеет.

> Не подскажете, а на какой странице там описано как отрисовывать и обрабатывать OLE объекты?

OLE (за исключением Compound Document) разве каким-то образом должно иметь отношение к спецификации на данные форматы? Я подозреваю к чему был задан вопрос. Например некоторые детали реализации то ли алгоритма лэйаута висячих абзацев, то ли чего-то подобного не были открыты или описаны - и поэтому даже при следовании спецификации документы могут выглядеть по-разному в разных программах. Наверное спецификации не охватывают полностью все бинарные офисные форматы и объекты документов. Может в будущем майкрософт откроет спецификации еще на что-то (как например в мае месяце этого года на pst), может не откроет. Ну и фиг с ним, человек выше просто просил ссылку ))

> если бы это было хоть кому-то по-настоящему нужно, давно бы уже всё сделали

Странная логика. По-твоему 12309 тоже всех устраивает? (:

Фигня это все. МС это делают специально.
В МС ворде под мак такие же проблемы с форматированием как и в опенофисе.

Не открыты вообще-то, а показаны их кусочки. И, как ни странно, этим спецификациям MS Office не соответствует.

http://local.joelonsoftware.com/wiki/Почему_форматы_Microsoft_Office_такие_сл...

кстати это не самые полные спецификации - на MSDN лежат новые гораздо более подробные версии

>По-твоему 12309 тоже всех устраивает? (:

ну конечно, просто публике проще кушать кактус, чем поднять свою задницу и начать исправлять его;)

1. Спецификации кривые и неполные.
2. У Sun не было денег на какие-либо доработки.
3. Oracle'у вообще положить на OpenOffice.

> кстати это не самые полные спецификации - на MSDN лежат новые гораздо более подробные версии

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

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

> Oracle'у вообще положить на OpenOffice

Вот-вот скоро новая версия выходит. Откуда ты взял, что им положить на ООо?

> почему не довели до ума, что мешает? непонятно.

А вы знаете, что форматирование в MSOffice зависит от драйвера принтера? Предлагаете повторить эту полезную фичу?

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

djvu

PDF/A (похуже, чем djvu но тоже допустимо)

Если требуется совместное редактирование и неизменность форматирования - то:

tex

PageMaker (windows/MAC - не знаю, запускается ли он под wine)

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

>А вы знаете, что форматирование в MSOffice зависит от драйвера принтера?
мсье не задумывался, почему так?

Дык ODF же победил? Нужно

1. Чтобы победил ODF/PDF Hybrid

2. Поднапрячь МС перейти на этот формат

3. ...
4. PROFIT!!

>>А вы знаете, что форматирование в MSOffice зависит от драйвера принтера?

мсье не задумывался, почему так?

Задумывался, но так и не понял, что мешает использовать путь PageMaker. Низкая квалификация пользователей?

PageMaker тоже верстается под принтер - но можно выбрать некий «сферический в вакууме принтер Postscript 1200 dpi», сверстать все под него, а затем выводить на любой другой принтер. Информация об использованном драйвере принтера записывается в публикацию. Да - шрифты и объекты при растризации могут немного отличаться (например, если напечатаем на принтере 600 dpi) - но это будет практически незаметно. А абсолютное положение объектов на странице будет жестко задано.

>OLE (за исключением Compound Document) разве каким-то образом должно иметь отношение к спецификации на данные форматы?

А почему оно там упоминается, и не раз?

> [url=http://local.joelonsoftware.com/wiki/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83_%D1... форматы Microsoft Office такие сложные? (И как это обойти)[/url]

Спасибо - интересная статья. Отдельные мысли правильные, но есть и странные советы.

Например меня удивил вот этот совет:

«Если вам нужно переводить табличные данные в Excel, попробуйте CSV.»

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

Интересную ведь я нашел в пятницу

Вбиваем в Excel формулы

=1 - 0.8 - 0.2 получаем 0

=(1 - 0.8 - 0.2) получаем -5 * 10^-17

> А почему оно там упоминается, и не раз?

Специально сейчас посмотрел - чуть ли не все упоминания OLE идут в контексте потоков внутри Compound Document. Т.е. вопросы хранения объектов внутри составного документа. Мне казалось, что вопросами отрисовки подобного должна заниматься ОС - сегодня же любой новичок в Windows может отобразить word или excel в своем приложении с помощью какого-нибудь очередного ole-контейнера в своем любимом тулките.

Может растолкуете суть проблемы?