Здравствуйте!

Всем нам знаком Microsoft Office и OpenOffice. У Microsoft форматы документов кривые и закрытые, а у OpenOffice -- OpenDocument, который открыт и т.п.

Одно "но", мешающее сохранять файлы в odf форматах: нет нормальных конверторов.

Есть определенное желание профинансировать создание
одного из двух:

• Плугина для ms office 10/11, чтобы офис нормально (обычным образом) создавал, открывал созданные и изменял с odf (достаточно ODT и ODS (doc и xls);
• Конвертора, который бы без установки запускался, сворачивался в трей, и при попытке открыть ODT/ODS файл там, где нет OpenOffice, но есть Microsoft Office, сконвертировал файл в офисный формат, запустил офис с открытием этого файла, отследил закрытие этого файла в офисе и сконвертировал бы уже измененный файл в ODF.

Общие требования:

• автоматическое обновление при запуске, если опубликована новая версия
• возможность начать искать все офисные файлы на компьютере с автоматической их конвертацией в odf
• Продукт должен быть OpenSource (и SVNненный, само собой) и хорошо документированный.
• Само собой, можно и нужно заимствовать наработки в http://sourceforge.net/projects/odf-converter (где уже реализована работа с ODF форматом).
• Потребуется разорабаться с OpenOffice на предмет того, как он открывает и конвертирует ms office и odf файлы, и хорошо бы не начинать с нуля, а "извлечь" из OpenOffice
• должно быть два варианта программы: без инсталляции и с инсталляцией в систему. Автообновление должно работать в любом случае.

Есть ли такой монстр/группа монстров, которые бы опубликовали смету, были бы уверены в том, что получится готовый безглючный продукт, и которые бы оценили стоимость такой работы и её конечные сроки?

Т.к. скриптовый язык у MS Office и Open Office различаются, то переносимость скриптов отпадает сама собой.
Т.е. необходимо конвертировать только данные в документах ...

У меня появились некоторые мысли:

1. Необходимо уточнить ТЗ, определить то, что необходимо сделать, выявить ограничения реализации и т.п...
2. Место ли этому топику именно в этом разделе?
3. Предполагаемый бюджет проекта? Т.е. на что вы готовы? Миллион рублей? Полмиллиона?   



Это сообщение отредактировал(а) mihanik - 16.6.2007, 09:21

Участвую

Смотрю, команда уже подбирается...
  

По большей части, скрипты в документах у обычных пользователей отсутствуют.
Однако, формулы в ms excel обычно присутствуют. Т.о., требуется обеспечить перенос формул.

• Да, но я же сам этого не уточню. Господа, если требуется, создадим рабочую группу? Тогда нам потребуется эффективно общаться друг с другом. Но это, например, в e-groupware. А предварительно можно и здесь договориться.
• Не знаю. А куда нужно поместить топик?
• Ну, не думаю, что это полмиллиона рублей. Если растянуть по времени, то возможен квартал с финансированием штуку зеленки/месяц. В конечном итоге, код на C++/Java по работе с ODF и Office 97/XP/2003 уже есть, а для 2007 предоставляет исходник сам Microsoft (OpenXML to ODF convertor на sourceforge). Т.е. ведь нужно просто объединить весь код в единую программу. В идеале, наверное, все-таки писать на Java, чтобы было переносимо на другие платформы. Понятно, что проект условно-бесплатный: если бы я был миллионером, я бы нашел программистов и посадил бы их на решение исключительно таких задач (электронный документооборот и стандартизация). Но, господа, это же ведь реальная нужда для многих контор. И такой продукт нужен. И он должен быть бесплатным и opensource, чтобы им пользовались.

А это еще зачем???
Мелкомягкий офис есть только на оси мелкомягких. Следовательно про переносимость речь не может идти.

Предлагаю сделать плагин для офиса, который просто будет позволять читать/писать ОДФ формат.

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

Хотя, конечно, это не обязательно.
Но нужно вспомнить про то, что Офис есть под Макинтошем.



А это возможно, да?
Но ведь нужно понимать, что у кого-то Office XP (2002), у кого-то Office 2003. Кстати, это не прихоть: в XP есть много из того, что было удалено по лицензионным ограничениям из Office 2003. Вот, например, у odf-converter.sourceforge.net нет поддержки Excel XP, PowerPoint XP. А поддержка Word XP у меня не работает.. По-этому, тут вопрос в том, всегда ли это будет работать. Если не всегда, то уж лучше конвертор.

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

А в идеале и то, и другое.

Создание плугина --  дело долгое?

Это сообщение отредактировал(а) itcar - 17.6.2007, 13:34

2ALL
http://odf-converter.sourceforge.net/ 

Правда, не тестил.

Что, умный самый, да?

1. Во-первых, это OpenXML <--> ODF конвертор. Т.е. только для форматов, которые есть в msOffice 2007 (конвертировать обычный XML/DOC/PPT нельзя -- нужно их сохранить с помощью "пакета совместимости" в OpenXML, а потом сконвертировать);
2. Во-вторых, он не предназначен для downgrade версий (Office 2003, Office 2002). Т.е. 2003/2002 сможет открывать OpenXML, но не ODF файлы. Потом нужно будет сконвертировать получившийся OpenXML в ODF отдельным пунктом меню.
3. Excel && PowerPoint -- только для Office 2003.
4. У меня в ms Word XP (2002) не работает: т.е., модуль есть в списке COM-объектов, могу сохранить в OpenXML (Word2007), но сохранить в ODT не могу.

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

Это сообщение отредактировал(а) itcar - 17.6.2007, 13:31

Модератор: 

itcar, по поводу вашего выссказывания



Неблагопристойно выражаетесь... Негоже в светской беседе высказываться вызывающе ...

Теперь по сути.

Если вы хотите полной переносимости, то java, конечно, - это хорошо.
Однако в этом разделе обычно общаются программисты VB, VBS, VBA.
Поэтому Вам как организатору и спонсору требуется определиться, будем ли мы охватывать макинтоши или ограничимся только ibm-совместимыми компьютерами.
Если маки не брать в расчёт, то мы можем справиться с поставленной задачей .
В противном случае нам придётся подключать программистов из соседних разделов, например С, С++ или Java.

Ваше мнение?

Оригинальный ответ, что тут сказать  И это говорит потенциальный руководитель проекта...
Ладно, не суть важно. "Каждому - своё".

Моё скромное и ни к чему не обязывающее мнение.
1. 
Не существует "необычных" и "обычных" пользователей. Если пишете подобный продукт, то придется реализовывать и учитывать ВСЕ варианты использования для ВСЕХ пользователей. Попытка делить на тех или иных - это, как минимум, элементарное неуважение.
2. В виде плагина его реализовывать не стоит.
3. Платформа.. Лично я - против джавы и использования виртуальных машин в принципе. Пишите 3 версии продукта в идеале - Win, Mac, *Nix. Язык - С++. MacOS для PC уже выпущен и успешно использован. Сам видел и диск в руках держал.

Благодарю за внимание и на этом топик покидаю. Желаю всем удачи.

Во-первых, я не поставил смайлик, а надо было.
Дело в том, что ссылка на этот ресурс есть в исходном сообщении (просьба прочесть внимательно).
Я сказал это без зла.
Прошу прощения у тех, кому это показалось недружелюбным.

Во-вторых, по языку:

Во-первых, Java -- действительно кросс-платформенный язык. Все, кто писали на VC++, к примеру, согласятся, что перенести такой код достаточно сложная задача, особенно, если использовать MFC.
Во-вторых, Java язык совершеннее C++: он не отягощен совместимостью с C.
Другое дело -- вопрос производительности. Но он решается в рамках прекомпилирования.

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

Что же по поводу Apple MacOS for PC, недавно я читал официальный релиз Apple по данному вопросу, где сообщалось, что у компании нет планов по переносу ОС на x86 PC-совместимые компьютеры.
Я, признаться, был очень огорчен этим сообщением, т.к. MacOS -- по моим понятиям, идеальная система: Юникс в человеческом обличии с гениальной структурой библиотек и прогрессивной ООП средой (не сравнимо с WinAPI).
Я думаю, что диск, который Вы держали -- это ОС на VMWare или аналогов.


Эти языки, по причине абсолютной непереносимости, я не рассматривал как возможные.
Этот продукт должен быть опен сорс, и интеграция существующих C++ исходников будет усложнена. К тому же, Unixовые программисты не знают VB. Думаю, нужно подключать C++/Java.
Не хочу обижать VBшников -- для программиста язык не главное, а главное структурное мышление. Но все-таки я себе это слабо представляю.


Более того, господа, раз уж пошла такая пьянка, то зачем ограничивать программу только офисными стандартами?
Ведь есть много областей, где конвертирование необходимо. Возьмем элементарный RAR vs ZIP. ZIP является стандартом, а RAR -- нет.
ZIP можно открыть где угодно, а RAR -- покупая отдельно программу.
ВАЖНО, я здесь не хочу сравнивать возможности RAR и возможности ZIP. Понятно, что RAR совершеннее (но, конвертор здесь будет хорошим инструментом популяризации формата, освобождая выкладывающих свои файлы в нестандартных форматах от опасений за возможность пользователей такие форматы прочесть).

А изображения? Ведь все это, возможно, будет можно со временем конвертировать.




Лично я не представляю, как малыми финансовыми возможностями реализовать скриптовый перенос.
Да и не очень уверен, нужно ли это. Конечно, я не против таких возможностей. Просто у меня нет уверенности в том, что эта работа решится быстро.
Я на проблему смотрю с точки зрения корпоративных пользователей и "электронного государства". У корпоративных пользователей есть желание сползти с Офиса, но нет возможности переделывать все остальное. Наличие такого конвертора даст возможность компаниям не покупать Ms Office. Что обезопасит и их от гонений ОБЭПа, и ускорит внедрение эффективного документообоота. Конечно, многие используют скрипты в таких документах, но большая часть -- не использует.




Согласен.


Это сообщение отредактировал(а) itcar - 17.6.2007, 23:32

Переместил из  Программирование, связанное с MS Office  по просьбе itcar.

Тема интересная...
Готов взяться за реализацию на VB6...

Как вообще предполагается читать/писать документы MS Office учитывая, что формат закрытый и спецификаций на него нет? Та же Jakarta POI давно заброшена.

По поводу конвертера RAR <--> ZIP, если из RAR в ZIP еще можно (хотя и смысла в этом не много), то обратное преобразование невозможно.

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


С помощью написанного Java OpenDocument Convertor http://www.artofsolving.com/opensource/jodconverter.
По-сути, нужно только дописать JOD под указанные требования.