Комментарии 171
давайте исходить из задачи, которую должна решать любая стандартизация.
Стандартизация - это выделение некоторых параметров системы или услуг в качестве эталонных.
Стандартизация - это сужение многообразия. Зачем?
Чем более разнообразные стандарты придется поддерживать завтра программистам, тем больше глюков вы получите в софте (софт будет сложней). Это закономерность.
Стандартизация - это диктатура, некоторое ограничение свободы, но делаемое во благо всем, а не отдельным участникам сообщества.
Задачами стандартизации является НЕ предоставление более выгодных условий для кого-то из производителей, а простота совместимости и повышение качества и надежности ПО, а значит выгода всех пользователей.
А принятие второго стандарта, потом третьего, потом сотого - это процесс противоречит понятию стандартизации в принципе.
Позиция Майкрософт предельно ясна - компания старается получить более выгодные условия в конкурентной борьбе. Но этот подход противоречит принципу любых открытых стандартов, которые делаются на пользу сообщества а не одного игрока.
Давайте не заменять тему дискуссии сравнением кто лучше OOXML или ODF. Обе спецификации находятся в самом начале пути. Пока не время считать цыплят ;)
PS
На сегодняшний день форматы Microsoft уже являются стандартом де-факто. Никто не мешает Майкрософт впредь использовать OOXML в качестве собственного формата. Но чтобы иметь будущее, компания должна играть по правилам сообщества, а не по своим собственным)
Стандартизация - это выделение некоторых параметров системы или услуг в качестве эталонных.
Стандартизация - это сужение многообразия. Зачем?
Чем более разнообразные стандарты придется поддерживать завтра программистам, тем больше глюков вы получите в софте (софт будет сложней). Это закономерность.
Стандартизация - это диктатура, некоторое ограничение свободы, но делаемое во благо всем, а не отдельным участникам сообщества.
Задачами стандартизации является НЕ предоставление более выгодных условий для кого-то из производителей, а простота совместимости и повышение качества и надежности ПО, а значит выгода всех пользователей.
А принятие второго стандарта, потом третьего, потом сотого - это процесс противоречит понятию стандартизации в принципе.
Позиция Майкрософт предельно ясна - компания старается получить более выгодные условия в конкурентной борьбе. Но этот подход противоречит принципу любых открытых стандартов, которые делаются на пользу сообщества а не одного игрока.
Давайте не заменять тему дискуссии сравнением кто лучше OOXML или ODF. Обе спецификации находятся в самом начале пути. Пока не время считать цыплят ;)
PS
На сегодняшний день форматы Microsoft уже являются стандартом де-факто. Никто не мешает Майкрософт впредь использовать OOXML в качестве собственного формата. Но чтобы иметь будущее, компания должна играть по правилам сообщества, а не по своим собственным)
Я абсолютно согласен! Только почему-то сейчас есть сообщества людей, которые пытаются эту борьбу стандартов задушить в зародыше. И хотят бить по голове тем, что ODF ISO получил, а вот OOXML - мы не дадим его получить.
я думаю, что эта борьба обойдется и без участия сообществ.
Есть факт, что ODF стал международным стандартом. Он развивается.
Теперь ISO решать, зачем нужен второй стандарт на формат офисных документов?
С точки зрения целей стандартизации - чем меньше стандартов, тем лучше. Я именно эту мысль и расписал в своем посте. Именно это блокирует OOXML, а не любовь или ненависть миллионов пользователей.
А большую часть программистов выступающих против OOXML легко понять - им надо будет ручками программировать все эти 6000 страниц спецификации OOXML если вдруг ее примут ;)
На месте программистов я бы тоже не радовался такой перспективе:)
А простому пользователю будет по барабану, как устроен внутри документ, который он отправляет на принтер или по почте. Ему важно, чтобы на том конце провода его без проблем открыли.
Есть факт, что ODF стал международным стандартом. Он развивается.
Теперь ISO решать, зачем нужен второй стандарт на формат офисных документов?
С точки зрения целей стандартизации - чем меньше стандартов, тем лучше. Я именно эту мысль и расписал в своем посте. Именно это блокирует OOXML, а не любовь или ненависть миллионов пользователей.
А большую часть программистов выступающих против OOXML легко понять - им надо будет ручками программировать все эти 6000 страниц спецификации OOXML если вдруг ее примут ;)
На месте программистов я бы тоже не радовался такой перспективе:)
А простому пользователю будет по барабану, как устроен внутри документ, который он отправляет на принтер или по почте. Ему важно, чтобы на том конце провода его без проблем открыли.
Так для выгоды всех пользователей, как мне кажется, было бы логично предусмотреть возможность использования таблиц, макросов и не только Java, или я не прав?
А программисты... Им за то и платят ;)
А программисты... Им за то и платят ;)
- программистам за это не платят, если это не программисты Майкрософт. Не забывайте про сообщества волонтеров, которых в тысячи раз больше чем сотрудников МС. И их интересы гораздо важней чем интересы одной компании.
- Стандарт не подразумевает окончательной и неизменной формы. Это платформа, на которой будет достроено все необходимое. Если надо - предусмотрят.
- А вам кто-то запрещает пользоваться OXML? Нет. Но это ведь не значит, что ваше личное предпочтение должно стать стандартом для миллионов других людей? В этом смысл спора. Пользуйтесь OOXML. Просто ODF - это международный стандарт. Вот и вся разница. И его будут развивать не в том направлении, которое видит МС для своих продуктов, а в том, которое необходимо пользователям
- Стандарт не подразумевает окончательной и неизменной формы. Это платформа, на которой будет достроено все необходимое. Если надо - предусмотрят.
- А вам кто-то запрещает пользоваться OXML? Нет. Но это ведь не значит, что ваше личное предпочтение должно стать стандартом для миллионов других людей? В этом смысл спора. Пользуйтесь OOXML. Просто ODF - это международный стандарт. Вот и вся разница. И его будут развивать не в том направлении, которое видит МС для своих продуктов, а в том, которое необходимо пользователям
программистам за это не платят, если это не программисты Майкрософт. Не забывайте про сообщества волонтеров, которых в тысячи раз больше чем сотрудников МС. И их интересы гораздо важней чем интересы одной компании.
Это как это?! То есть, интерес тех, кто пишет так, не на уровне готового продукта важнее, чем интерес тех, кто за деньги, но пишет готовые продукты?! Получается, надо принимать те форматы, которые будут удобнее ребятам под свободной лицензией?!
А вам кто-то запрещает пользоваться OXML? Нет. Но это ведь не значит, что ваше личное предпочтение должно стать стандартом для миллионов других людей? В этом смысл спора. Пользуйтесь OOXML. Просто ODF - это международный стандарт. Вот и вся разница. И его будут развивать не в том направлении, которое видит МС для своих продуктов, а в том, которое необходимо пользователям
Да, его будут развивать в том направлении, которое видит Sun. Только и всего :)
Это как это?! То есть, интерес тех, кто пишет так, не на уровне готового продукта важнее, чем интерес тех, кто за деньги, но пишет готовые продукты?! Получается, надо принимать те форматы, которые будут удобнее ребятам под свободной лицензией?!
А вам кто-то запрещает пользоваться OXML? Нет. Но это ведь не значит, что ваше личное предпочтение должно стать стандартом для миллионов других людей? В этом смысл спора. Пользуйтесь OOXML. Просто ODF - это международный стандарт. Вот и вся разница. И его будут развивать не в том направлении, которое видит МС для своих продуктов, а в том, которое необходимо пользователям
Да, его будут развивать в том направлении, которое видит Sun. Только и всего :)
важнее интересы тех, кто пишет программы по любой причине, а не только ради денег. Важнее интерес программиста, который хочет встроить поддержку офисного формата в свою программу и не важно под какой лицензией он работает. Важно чтобы для этого не надо было вскрывать себе мозг.
Именно поэтому на любом большом проекте интерфейсной частью занимаются самые опытные и высококвалифицированные специалисты, а все остальные кодят все наполнение модулей. Именно поэтому стандарты разрабатывают люди которые способны отличить платформу, от конкретной реализации и предусмотреть, возможно ли эффективное развитие этой платформы.
Пока обязанности распределяются таким образом - все будет развиваться
А вы уверены, что знаете, кто входит в OASIS? :)
http://www.oasis-open.org/about/foundati…
Это только спонсоры-основатели.
Так что Sun там не в гордом одиночестве
Именно поэтому на любом большом проекте интерфейсной частью занимаются самые опытные и высококвалифицированные специалисты, а все остальные кодят все наполнение модулей. Именно поэтому стандарты разрабатывают люди которые способны отличить платформу, от конкретной реализации и предусмотреть, возможно ли эффективное развитие этой платформы.
Пока обязанности распределяются таким образом - все будет развиваться
А вы уверены, что знаете, кто входит в OASIS? :)
http://www.oasis-open.org/about/foundati…
Это только спонсоры-основатели.
Так что Sun там не в гордом одиночестве
Sun в основном и занималась разработкой, IBM больше присоседилась из чувства "мы тоже за альтернативу" :)
не все так просто. "Присоседившаяся" IBM замечена в том, что обеспечивает "патентную амнистию" множеству начинаний Open Source. И не просто из-за любви к альтернативе. Не будем принижать и ее роль в процессах стандартизации. Кроме того, не забываем, что IBM - прямой конкурент Sun (как в сфере операционных систем, так и серверного оборудования). В таких ситуациях просто так не присосеживаются.
Так в том и вопрос: что лучше, MS или IBM + Sun? ;)
вы забыли приобщить к списку еще 4 титульных спонсора.
Еще раз повторюсь - мы не знаем точного состава команды которая работает над ODF, насколько я знаю в команду входят люди из Нувел, Oracal. Если у вас есть ссылка на то, какие компании разрабатывают ODF - приведите их. Будет любопытно.
Резюмируя написанное мною в предыдущих постах,
при разработке общих стандартов команда, состоящая из сотрудничающих компаний конкурентов - лучше, чем команда из одной компании.
Неужели это не очевидно?
Когда конкуренты работают над одним стандартом, это лучше, поскольку исключает реализацию монопольных интересов в общих стандартах и технологиях.
Это просто очевидно...
Майкрософт может легко разрешить ситуацию, включив своих людей в разработку ODF. Они выбирают другой путь. А зря, потому что поезд может уйти совсем без них. И такой исход очень вероятен, очень. И тогда им придется следовать стандарту, чтобы оставаться в обойме
Еще раз повторюсь - мы не знаем точного состава команды которая работает над ODF, насколько я знаю в команду входят люди из Нувел, Oracal. Если у вас есть ссылка на то, какие компании разрабатывают ODF - приведите их. Будет любопытно.
Резюмируя написанное мною в предыдущих постах,
при разработке общих стандартов команда, состоящая из сотрудничающих компаний конкурентов - лучше, чем команда из одной компании.
Неужели это не очевидно?
Когда конкуренты работают над одним стандартом, это лучше, поскольку исключает реализацию монопольных интересов в общих стандартах и технологиях.
Это просто очевидно...
Майкрософт может легко разрешить ситуацию, включив своих людей в разработку ODF. Они выбирают другой путь. А зря, потому что поезд может уйти совсем без них. И такой исход очень вероятен, очень. И тогда им придется следовать стандарту, чтобы оставаться в обойме
Ну если не учесть что в этих 6 тысячах страниц далеко не все и есть отсылки на закрытые форматы MS, то встает вопрос а нафига это надо?
А можно пример ссылки на закрытый формат?
wmf
А ссылку на пункт спецификации где он приводится как неотъемлемый элемент спецификации а не пример?
Даже примера достаточно. Если wmf там допускается, значит его необходимо реализовывать всем "читателям" формата.
Больной на голову аргумент. Вы не программист.
Программист :) Опишите, почему я не прав.
Да что тут описывать? Вы наверняка писали что-то, что работает с базой данных и, соотвественно, может читать данные получаемые от БД. Вы при этом реализоваывали полностью все типы данных которые могут быть от БД получены (включая custom type)?
Да таких примеров куча. У вас есть задача, вы ей реализуете таким образом как вам удобно минимальной функциональность, если вам нужно быстро вывести набор XML элементов то вы можете их вывести вообще без использования DOM либо ещё чего просто составляя нужные строки в цикле. Вас при этом никто не обязывает реализовавать XPath.
Да таких примеров куча. У вас есть задача, вы ей реализуете таким образом как вам удобно минимальной функциональность, если вам нужно быстро вывести набор XML элементов то вы можете их вывести вообще без использования DOM либо ещё чего просто составляя нужные строки в цикле. Вас при этом никто не обязывает реализовавать XPath.
Отлично :) Рисую картину:
Вы пишете конкурента MSOffice-у (а что? формат файлов у них открыт!).
Чтобы клиенты смогли безболезненно перейти, вы читаете и реализуете весь ooxml, пропуская примеры и невнятные ".. ну или в любом другом формате". Продаете продукт под слоганом "NewOffice! Совместим c MSOffice на 100% ! За половину цены!"
И что дальше? Клиент покупает, приносит домой, открывает свой документ и (сюрприз!), а картинка не показывается. Звонит вам:
В чем дело?
Вы открываете документ и видите там wmf:
Ну вы понимаете, там это был только пример. Мы его отбросили ...
Меня не волнует! Ждите иск!
Клиент подает в суд за то, что вы солгали в рекламе и скорее всего выигрывает.
Я конечно приукрасил, но смысл должен быть понятен: Когда делаешь "читателя" формата, нужно реализовывать обработку всех возможных вариантов. Когда делаешь "писателя", можешь выбрать тот вариант, который больше нравится.
Вы пишете конкурента MSOffice-у (а что? формат файлов у них открыт!).
Чтобы клиенты смогли безболезненно перейти, вы читаете и реализуете весь ooxml, пропуская примеры и невнятные ".. ну или в любом другом формате". Продаете продукт под слоганом "NewOffice! Совместим c MSOffice на 100% ! За половину цены!"
И что дальше? Клиент покупает, приносит домой, открывает свой документ и (сюрприз!), а картинка не показывается. Звонит вам:
В чем дело?
Вы открываете документ и видите там wmf:
Ну вы понимаете, там это был только пример. Мы его отбросили ...
Меня не волнует! Ждите иск!
Клиент подает в суд за то, что вы солгали в рекламе и скорее всего выигрывает.
Я конечно приукрасил, но смысл должен быть понятен: Когда делаешь "читателя" формата, нужно реализовывать обработку всех возможных вариантов. Когда делаешь "писателя", можешь выбрать тот вариант, который больше нравится.
Можно привести кучу примеров, когда нужно прочитать не всё а только необходимую часть. По этому ваш пример безоснователен. Никто не мешает вставлять в ooxml тот же ogg, совершенно открытый формат. И даже Microsoft Office его прочитать не сможет, на совершенно законных основаниях в соответствии со спецификацией. В чём проблема-то? Если у вас цель написать совместимый со всем документ - используйте популярные типа, если нет - не используйте. Делайте так как вам удобно.
Этот аргумент был бы "больным на голову" если бы мы говорили не об OOXML, а о нормальном стандарте. Множество вещей в OOXML описаны только в примерах, так что опускать их никак нельзя (иначе MS Office 2007 файл не признает - проверно). А если можно опускать часть примеров, но не все, то кто решает - какие важны, какие - нет ?
ну так почитайте 6000 страничек ;)
Или вы полагаете что для включенной в документ векторной графики МС использовал что-то кроме своего родного WMF?
А кстати, поделитесь ссылкой, где OOXML-спецификация лежит?
Родной сайт http://www.microsoft.com про это ничего не слышал ваапсче.
Или это слишком открытая информация? ;)
Или вы полагаете что для включенной в документ векторной графики МС использовал что-то кроме своего родного WMF?
А кстати, поделитесь ссылкой, где OOXML-спецификация лежит?
Родной сайт http://www.microsoft.com про это ничего не слышал ваапсче.
Или это слишком открытая информация? ;)
> А ссылку на пункт спецификации где он приводится как неотъемлемый
> элемент спецификации а не пример?
итак в спецификации, том первый (Fundamentals), упоминание включенного WMF-документа имеется, на странице 99. В разделе PresentationML. Если есть желание сканировать дальше - сканируйте.
По указанной ниже ссылке можете скачать всю спецификацию.
> элемент спецификации а не пример?
итак в спецификации, том первый (Fundamentals), упоминание включенного WMF-документа имеется, на странице 99. В разделе PresentationML. Если есть желание сканировать дальше - сканируйте.
По указанной ниже ссылке можете скачать всю спецификацию.
интересно, и что теперь? Ну есть у нас подтверждение для использования WMF внутри открытого документа, и что дальше? Нам стало легче или наоборот труднее? :)
Ладно, пока рассмотрение идет своим чередом и все изменится если МС по своей традиции сможет подкупить экспертов.
Ладно, пока рассмотрение идет своим чередом и все изменится если МС по своей традиции сможет подкупить экспертов.
Посмотрел, там есть возможность (нет ограничения) на использование видео, аудио и картинок любого формата, в частрости WMF. Это плохо? JPEG защищён патентами, его нужно исплючить? А если мне нужно работать с документами которые содержат WMF, JPEG или там TPP, мне что делать? Конвертировать их во что-то? А если это TPP не может быть сконвертировано во что-то ещё? Мне что делать прикажете? Допустим, таких документов у меня миллион. Ваше решение.
вам знакомо слово thumbnail?
А теперь гляньте на структуру пакета и обратите внимание на присутствие в ней файла thumbnail.wmf
Так вот wmf - не возможная а обязательная часть любого пакета, потому что именно в этом формате сохраняются уменьшенные копии страниц презентации в пакете. Обратите внимание - wmf является обязательной частью любого пакета (презентации). Не JPG, не SVG, а именно WMF.
Закрытый формат не может стать частью открытой спецификации, потому что GNU-системы могут не иметь средств для отображения такого документа. Это одна из сотен претензий, которые скорее всего (вероятность наверное 80%) не пропустят ECMA-376 (или просто OOXML) в открытые стандарты.
Это слишком очевидная цитата чтобы дальше дальше об этом спорить ;)
А теперь гляньте на структуру пакета и обратите внимание на присутствие в ней файла thumbnail.wmf
Так вот wmf - не возможная а обязательная часть любого пакета, потому что именно в этом формате сохраняются уменьшенные копии страниц презентации в пакете. Обратите внимание - wmf является обязательной частью любого пакета (презентации). Не JPG, не SVG, а именно WMF.
Закрытый формат не может стать частью открытой спецификации, потому что GNU-системы могут не иметь средств для отображения такого документа. Это одна из сотен претензий, которые скорее всего (вероятность наверное 80%) не пропустят ECMA-376 (или просто OOXML) в открытые стандарты.
Это слишком очевидная цитата чтобы дальше дальше об этом спорить ;)
15.2.15 Thumbnail Part
Content Type: Any supported image type.
Далее примеры:
[Note: Some example content types are:
image/gif http://www.w3.org/Graphics/GIF/spec-gif89a.txt
image/png ISO/IEC 15948:2003 http://www.libpng.org/pub/png/spec/
image/tiff http://partners.adobe.com/public/developer/tiff/index.html#spec
image/pict http://developer.apple.com/documentation/mac/QuickDraw/QuickDraw-
2.html
image/jpeg http://www.w3.org/Graphics/JPEG/
Ниже там текст и ещё примеры. В качестве одного из примеров приведён, действительно, thumbnail.wmf. В качестве одного из примеров. Из Any supported image type.
Видимо да, дальше спорить бесполезно.
Content Type: Any supported image type.
Далее примеры:
[Note: Some example content types are:
image/gif http://www.w3.org/Graphics/GIF/spec-gif89a.txt
image/png ISO/IEC 15948:2003 http://www.libpng.org/pub/png/spec/
image/tiff http://partners.adobe.com/public/developer/tiff/index.html#spec
image/pict http://developer.apple.com/documentation/mac/QuickDraw/QuickDraw-
2.html
image/jpeg http://www.w3.org/Graphics/JPEG/
Ниже там текст и ещё примеры. В качестве одного из примеров приведён, действительно, thumbnail.wmf. В качестве одного из примеров. Из Any supported image type.
Видимо да, дальше спорить бесполезно.
ну, и теперь, ситуация - мой комп не знает WMF, и чего? Адьос амигос? Спецификация ДОЛЖНА обеспечить 100% совместимость СТАНДАРТА на ВСЕХ реализациях.
Не "Any supported image type", а опен форматс онли.
Не "Any supported image type", а опен форматс онли.
Чем вам WMF не открытый формат? Вы спецификацию на него не можете найти? Вы уже придираетесь. Вы отказываетесь от своих слов, что там может быть только и исключительно WMF?
блин)))
потому что не открытый. Мало ли Билушка сетует на патентные нарушения в стане линукс? )))
См.выше. GNU-системы не поддерживают WMV, WMF, WMA и не обязательно будут (это их ПРАВО). А спецификация открытого формата обязана быть открытой и не допускать вариаций в пресловутой папке /docProps/ - все превьюхи в /docProps/ должны однозначно конверироваться в единый формат. Иначе целостность документа будет нарушена.
Заметьте, мы с вами нашли самый простой случай, мы не изучали особенности XML-разметки. Просто лень тратить на это время) Интуиция (она мне редко изменяет) подсказывает мне что можно найти и другие несуразности
потому что не открытый. Мало ли Билушка сетует на патентные нарушения в стане линукс? )))
См.выше. GNU-системы не поддерживают WMV, WMF, WMA и не обязательно будут (это их ПРАВО). А спецификация открытого формата обязана быть открытой и не допускать вариаций в пресловутой папке /docProps/ - все превьюхи в /docProps/ должны однозначно конверироваться в единый формат. Иначе целостность документа будет нарушена.
Заметьте, мы с вами нашли самый простой случай, мы не изучали особенности XML-разметки. Просто лень тратить на это время) Интуиция (она мне редко изменяет) подсказывает мне что можно найти и другие несуразности
Вы отказыаетесь от своих слов, что может быть использован только и исключительно WMF? Да или нет?
уважаемый dmach,
я доказал что OOXML использует проприетарные форматы в составе служебных частей пакета. Именно поэтому он врядли будет принят в качестве открытого формата.
И своих слов я не забираю, потому что сверх-задача выполнена, и как говорят
"что требовалось доказать"
я доказал что OOXML использует проприетарные форматы в составе служебных частей пакета. Именно поэтому он врядли будет принят в качестве открытого формата.
И своих слов я не забираю, потому что сверх-задача выполнена, и как говорят
"что требовалось доказать"
Уважаемый manuscriptum, вы писали: "Так вот wmf - не возможная а обязательная часть любого пакета", это можно посмотреть чуть выше. Я вам привёл кусок спецификации, который показывает, что ваши слова - неправда. Вы отказываетесь это признавать. Вероятно вы не способны признавать свои ошибки.
Вы либо некомпетентны либо врёте, что наглядно показано на этом примере.
Что и требовалось доказать.
Вы либо некомпетентны либо врёте, что наглядно показано на этом примере.
Что и требовалось доказать.
уважаемый dmach - в порыве спора вы сами нашли еще одну дыру (лазейку) в спецификации ooxml,
к сожалению вы пока этого не поняли)))) Защищая ooxml вы же его случайно и похоронили)
Огромное вам спасибо!
Поскольку я рассуждаю как специалист с академическим образованием,
просматривая спецификацию OOXML я обратил внимание только на папку /docProps/
и явно служебный thumbnail.wmf который там лежал. И ограничился беглым взглядом. Я же логик.
Я же понимаю, что создание превью - автоматическая операция, которую программа должна выполнить сама,
без какого-то участия пользователя.
Но вам же надо было докопаться до истины! И докопались - так что вы молодец)
Уж точно говорят "Нет никого внимательней, чем твой оппонент" )))
Естественно, поскольку речь идет о здравом смысле и стандарте
(повторюсь, стандарт - это ограничение разнообразия, а не наоборот),
программист, который реализует многоформатность для такой ерунды как файлы уменьшенных копий страниц (!!!)
такой программер либо дурак, либо пройдоха)))
Заметьте, я никогда не говорил что МС - дураки. Это далеко не так.
МС, понимая, что для такой незначительной операции,
как автоматическое создание уменьшенной копии страниц, пользователь врядли
будет лезть в настройки и выбирать формат превьюх (а будут ли такие настройки в программе вообще?),
то при генерации превью будет использоваться формат по умолчанию! Догадаетесь какой?
Да тот, который приведен в примере!
К чему приведет хаос в использовании форматов в пакете презентации, это вы уж сами пофантазируйте;)
Не надо громких фраз "про ложь" и прочее. Это звучит несколько наивно.
Приведенный вами фрагмент спецификации уточняет, но не противоречит сказанному мной.
В конце концов, для подтверждения моих слов попросите любого у кого есть MSOffice 2007
прислать вам файл презентации, любой.
Переименуйте его в zip и откройте в пакете папку /docProps/ и сами посмотрите, какой формат
будет использоваться в качестве превью ))) И кто будет прав, если там стоит WMF?
В желании выиграть битву вы случайно проиграли войну.
Но в данном случае, речь конечно же не о войне.
к сожалению вы пока этого не поняли)))) Защищая ooxml вы же его случайно и похоронили)
Огромное вам спасибо!
Поскольку я рассуждаю как специалист с академическим образованием,
просматривая спецификацию OOXML я обратил внимание только на папку /docProps/
и явно служебный thumbnail.wmf который там лежал. И ограничился беглым взглядом. Я же логик.
Я же понимаю, что создание превью - автоматическая операция, которую программа должна выполнить сама,
без какого-то участия пользователя.
Но вам же надо было докопаться до истины! И докопались - так что вы молодец)
Уж точно говорят "Нет никого внимательней, чем твой оппонент" )))
Естественно, поскольку речь идет о здравом смысле и стандарте
(повторюсь, стандарт - это ограничение разнообразия, а не наоборот),
программист, который реализует многоформатность для такой ерунды как файлы уменьшенных копий страниц (!!!)
такой программер либо дурак, либо пройдоха)))
Заметьте, я никогда не говорил что МС - дураки. Это далеко не так.
МС, понимая, что для такой незначительной операции,
как автоматическое создание уменьшенной копии страниц, пользователь врядли
будет лезть в настройки и выбирать формат превьюх (а будут ли такие настройки в программе вообще?),
то при генерации превью будет использоваться формат по умолчанию! Догадаетесь какой?
Да тот, который приведен в примере!
К чему приведет хаос в использовании форматов в пакете презентации, это вы уж сами пофантазируйте;)
Не надо громких фраз "про ложь" и прочее. Это звучит несколько наивно.
Приведенный вами фрагмент спецификации уточняет, но не противоречит сказанному мной.
В конце концов, для подтверждения моих слов попросите любого у кого есть MSOffice 2007
прислать вам файл презентации, любой.
Переименуйте его в zip и откройте в пакете папку /docProps/ и сами посмотрите, какой формат
будет использоваться в качестве превью ))) И кто будет прав, если там стоит WMF?
В желании выиграть битву вы случайно проиграли войну.
Но в данном случае, речь конечно же не о войне.
Кстати, просвятите (я правда не знаю), какие image-типы поддерживает ODF?
вы сами можете почитать спецификацию, она даже переведена на русский язык
http://www.i-rs.ru/odf/translation
http://www.i-rs.ru/odf/translation
И ведь действительно бесполезно. К вам пришел документ в котором превьюшка и вообще все картинки в WMF, а у вас, какая жалость, нечем раскодировать эту бодягу. Спор тут совершенно неуместен.
А в ODF-документ вставить WMF нельзя?
Пока нельзя. Просто потому что в IANA не зарегистрировано. Но зато можно вставить image/vnd.adobe.photoshop, image/vnd.djvu или image/vnd.microsoft.icon, так что хрен редьки не слаще. Хотя нет - слаще. На самую капельку. По крайней мере есть точка отсчёта куда можно посылать пользователя, который встретил в документе "неведому зверушку" и быть уверенным, что мы под "форматом XYZ" понимаем именно "формат XYZ" и ничто другое (так что можно создать plugin для поддержки формата). В случае с OOXML вполне может статься что под .abracadabra один вендор понимает один формат, а второй вендор - какой-нибудь совсем другой формат ибо никакой регистрации, как я понимаю, не предусмотрено...
В общем и здесь ODF, как обычно, обходит OOXML - но не очень значительно: даже списка форматов, которые рекомендуется поддерживать в стандарте нет!
В общем и здесь ODF, как обычно, обходит OOXML - но не очень значительно: даже списка форматов, которые рекомендуется поддерживать в стандарте нет!
технически вы можете "вставить" любой формат, но автор программы должен обеспечить импорт формата в формат для внутреннего хранения.
Не думаю, что WMF будет разрешен в качестве одного из форматов для внутреннего хранения.
Просто при вставке, файл wmf (b(или бой другой проприетарный формат) должен быть транскодирован в один из форматов внутрненнего хранения.
Не думаю, что WMF будет разрешен в качестве одного из форматов для внутреннего хранения.
Просто при вставке, файл wmf (b(или бой другой проприетарный формат) должен быть транскодирован в один из форматов внутрненнего хранения.
Отличная идея. Т.е. если у меня есть библиотека клипарта в WMF, то при переходе на ODF она идет лесом?
не забывайте, что речь идет о международном стандарте. Документ должен одинаково выглядеть, что на вашем компе, что на бамбуковом сервере в Гандурасе.
Не ожидайте, что для внутреннего хранения в ODF кто-то встроит что-то кроме открытого стандарта. Почитайте перевод спецификации в разделе дополнений, Найдите его по ключевому слову MIME. Вас ждет искреннее удивление) Все форматы, используемые для внутреннего хранения специфицированы внутри стандарта ODF.
Не ожидайте, что для внутреннего хранения в ODF кто-то встроит что-то кроме открытого стандарта. Почитайте перевод спецификации в разделе дополнений, Найдите его по ключевому слову MIME. Вас ждет искреннее удивление) Все форматы, используемые для внутреннего хранения специфицированы внутри стандарта ODF.
Совершенно верно, судя по ответам. Хотя на самом деле может быть другой вариант, если прочитать спецификацию =)
К сожалению, лагерь сторонников ODF категорически отрицает идею обратной совместимости. Увы.
К сожалению, лагерь сторонников ODF категорически отрицает идею обратной совместимости. Увы.
Ответ ниже (чтобы не тесниться %)
Вы развели бардак - вы его и ливидируйте. Но мне, пожалуйста, не присылайте документы пока не изведёте проприетарные форматы, Ok ?
Для того чтобы работать с документами в пределах одной организации и одной программы международный стандарт не нужен.
Для того чтобы работать с документами в пределах одной организации и одной программы международный стандарт не нужен.
так а кто кричал что формат DOCX надо убить?
У меня уже неоднократно возникала ситуация, с присылкой срочных документов в этом модном у секретарш формате. И ничего - отправил письмо "открыть не могу, пришлите в DOC". Сроки к черту, но это не моя проблема. А внутри офиса мы завсегда договоримся))
У меня уже неоднократно возникала ситуация, с присылкой срочных документов в этом модном у секретарш формате. И ничего - отправил письмо "открыть не могу, пришлите в DOC". Сроки к черту, но это не моя проблема. А внутри офиса мы завсегда договоримся))
Стандарт DOCX надо убивать постепенно - прежде всего запретить выпускать официальные документы в этом формате, потом - запретить использовать его для посылки писем в разные инстанции (они должны подшиваться в архив, а для этого лучше использовать стандартные форматы). Ну и так далее. Конечно "вставать в позу" и отказываться его открывать если от этого зависит существование вашей фирмы не стоит. Нам тут недавно в и .cdr файлы присылали, а они и близко ни к какому стандарту не лежали...
да ладно вам, скоро пользователям Open Office будет проще открыть DOCX чем самим пользователям MSOffice. В ОО фильтр будет встроенный, а на МС версий до 2007 потребуется конвертер)))
Так что будет глубоко все равно в каком формате пришлют документик)
Так что будет глубоко все равно в каком формате пришлют документик)
фильтр в ОО встроится волшебным образом? или мне мне придётся купить/скачать последнюю версию?
он скорее всего войдет в новые версии ООо.
Над ним сейчас работает Novel, потом он будет доступен для всех дистрибутивов и конечно будет входить в поставку ООо
Над ним сейчас работает Novel, потом он будет доступен для всех дистрибутивов и конечно будет входить в поставку ООо
но старые версии ООо как не понимали, так и не будут понимать docx.
я это к тому, что многие ваши замечания в этом топике просто нелогичны, хотя в целом ваша позиция понятна
я это к тому, что многие ваши замечания в этом топике просто нелогичны, хотя в целом ваша позиция понятна
хм. Логично. Что-то видимо сделать придется)
Раскрою маленький секрет
меню "справка/наличие обновлений"
Эта волшебная кнопочка рано или поздно поможет
Раскрою маленький секрет
меню "справка/наличие обновлений"
Эта волшебная кнопочка рано или поздно поможет
а владельцы "Старых версий ООо" - это простите, кто? Если у человекаесть возможность скачать 100мб чтобы установить старую версию, однажды ее также можно и обновить.
а кто мешает владельцу MS Office скачать конвертер?
теперь по порядку, чтобы стала понятна логика моего пред.поста.
100 миллионов пользоватлей ОО получают версии, просто обновляя свои дистрибутивы. Им по барабану что есть такой формат docx. Они даже не заметят того, что однажды получат обновленный офис с нативным открытием docx (многие даже знать об этом не будут).
А вот мне как пользователю MSOffice надо потратить 10 минут на то чтобы найти FileFormatConverters.exe
на сайте microsoft.com потом сгрузить его и инсталлировать.
Иначе говоря, линуксоиды получат все патчи в одном флаконе.
Разницу чувствуете?
Если вы не видите в тексте логики, это вовсе не значит что ее там нет ;)
100 миллионов пользоватлей ОО получают версии, просто обновляя свои дистрибутивы. Им по барабану что есть такой формат docx. Они даже не заметят того, что однажды получат обновленный офис с нативным открытием docx (многие даже знать об этом не будут).
А вот мне как пользователю MSOffice надо потратить 10 минут на то чтобы найти FileFormatConverters.exe
на сайте microsoft.com потом сгрузить его и инсталлировать.
Иначе говоря, линуксоиды получат все патчи в одном флаконе.
Разницу чувствуете?
Если вы не видите в тексте логики, это вовсе не значит что ее там нет ;)
Это все справедливо только для пользователей Linux, которые регулярно обновляют свои дистрибутивы.
Пользователи ООо != Пользователи Линукса, так ведь?
Пользователи ООо != Пользователи Линукса, так ведь?
100 миллионов пользоватлей ОО получают версии, просто обновляя свои дистрибутивы
70 миллионов пользователей MS Office уже имеют версию 2007 :)
90% пользователей PC имеют возможность получать обновления Windows автоматически. что мешает фирме Microsoft включить (если это ещё не сделано) конвертер в одно из обновлений?
ваша логика мне понятна и позиция в чём-то близка
А данные о количестве пользователей МСО2007 публикует сама МС?
Ну мы-то знаем как они любят преувеличивать)))
http://www.rtcomputer.ru/index.php?pid=7…
Я не поставлю денег на статистику, публикуемую МС.
Плохому танцору знаем что мешает.
Посмотрим, что помешает Майкрософт)
Я просто опишу вам ситуацию, которая произошла со мной.
Однажды мне прислали горящий документ в формате DOCX.
Разумеется, я не смог его открыть, и у меня не было времени на поиски заплаток.
И не было возможности скачивать 30 (!!!) мегов конвертера,
(весь ОО весит 100 МБ для справки).
В этой ситуации это была не моя проблема - поплатился тот человек.
Что мешало Майкрософту выдавать предупреждение при сохранении в формате DOCX
о возможной несоместимости? Тогда такого сообщения не было.
Вот это была уже тупость МС. И она периодически всплывает в разных местах)
Ну мы-то знаем как они любят преувеличивать)))
http://www.rtcomputer.ru/index.php?pid=7…
Я не поставлю денег на статистику, публикуемую МС.
Плохому танцору знаем что мешает.
Посмотрим, что помешает Майкрософт)
Я просто опишу вам ситуацию, которая произошла со мной.
Однажды мне прислали горящий документ в формате DOCX.
Разумеется, я не смог его открыть, и у меня не было времени на поиски заплаток.
И не было возможности скачивать 30 (!!!) мегов конвертера,
(весь ОО весит 100 МБ для справки).
В этой ситуации это была не моя проблема - поплатился тот человек.
Что мешало Майкрософту выдавать предупреждение при сохранении в формате DOCX
о возможной несоместимости? Тогда такого сообщения не было.
Вот это была уже тупость МС. И она периодически всплывает в разных местах)
выдаёт ли ООо предупреждение при сохранении, что ODF-формат может не прочитаться в MS Office (на данный момент стандарт де-факто) или в старых версиях OOo?
вот тут уже чистая подмена понятий уважаемый, в духе MS )))
Не в кассу сравнивать убогую несовместимость "MSWord vs MSWord 2007"
с односторонней несовместимостью "OOWriter vs MSWord"
Это вещи из разных логических категорий. Через годик вы это увидите. Застолбите ссылочку на этот пост))
Со стороны OO Writer совместимость обеспечена. И пользователь может поставить формат doc по умолчанию.
OO Writer выдает правильное предупреждение при попытке сохранить в формате doc)))
а по поводу "пользователей старых версий ОО" может сказать только тот, кто не пользуется ОО вООбще))
В open source это выражение звучит как-то глупо ))
Не в кассу сравнивать убогую несовместимость "MSWord vs MSWord 2007"
с односторонней несовместимостью "OOWriter vs MSWord"
Это вещи из разных логических категорий. Через годик вы это увидите. Застолбите ссылочку на этот пост))
Со стороны OO Writer совместимость обеспечена. И пользователь может поставить формат doc по умолчанию.
OO Writer выдает правильное предупреждение при попытке сохранить в формате doc)))
а по поводу "пользователей старых версий ОО" может сказать только тот, кто не пользуется ОО вООбще))
В open source это выражение звучит как-то глупо ))
мой OpenOffice не понмал ODF, пришлось обновить. для меня скачать сотню мб - не проблема, но есть же и пользователи с дорогим трафиком или вовсе без интернета
Но он не выдаёт никакого предупреждения при попытке сохранить в формате ODF, а следовало бы, так как это малораспространённый формат. И у моей мамы, имеющей лицензионный StarOffice, пару раз были проблемы, пока я не научил её сохранять документы в doc.
пользователь может поставить формат doc по умолчанию. OO Writer выдает правильное предупреждение при попытке сохранить в формате doc
Но он не выдаёт никакого предупреждения при попытке сохранить в формате ODF, а следовало бы, так как это малораспространённый формат. И у моей мамы, имеющей лицензионный StarOffice, пару раз были проблемы, пока я не научил её сохранять документы в doc.
Тогда может заодно пожалеем тех, кто не сможет сгрузить заплатку или обновление для MS?
Ну чисто для симметричности условий сравнения))))
те люди, которые имеют проблемы с обновлением через интернет, могут раздобыть
(и это делается) новый дистрибутив у счастливых обладателей выделенки.
Не рассказывайте мне про несчастных. И меня только год назад появилась выделенка.
До тех пор много лет довольствовался диал-апом. И ОО у меня был свежий всегда. Так что отпадает.
А по поводу предупреждения, повторюсь - вы допустили логическую ошибку.
Может тогда перечислим 15000 программ, включая CorelDraw, в которых не откроется ODF? )))
Вы в курсе, сколько на свете текстовых редакторов? А офисных пакетов? Уверены что только два?
в линуксах штук пять. Платных несколько десятков... а может сотня.... кто их считал? ))
MS не удосужился предупредить тех, кто платит ему деньги. Это fuck-up.
А по поводу "пары раз с ODF" добавлю - при переходе на Unicode с вордовскими файлами у меня такая жопа
случалась пару раз в неделю. MS не удосужился придумать мягкий переход на новую кодировку.
А между прочим мог.
Ладно, на все вопросы вроде ответил.
Если вам просто нужно чтобы за вами было последнее слово, и дискуссия затянулась по этой причине,
то "пардоне муа". Замолкаю)
Ну чисто для симметричности условий сравнения))))
те люди, которые имеют проблемы с обновлением через интернет, могут раздобыть
(и это делается) новый дистрибутив у счастливых обладателей выделенки.
Не рассказывайте мне про несчастных. И меня только год назад появилась выделенка.
До тех пор много лет довольствовался диал-апом. И ОО у меня был свежий всегда. Так что отпадает.
А по поводу предупреждения, повторюсь - вы допустили логическую ошибку.
Может тогда перечислим 15000 программ, включая CorelDraw, в которых не откроется ODF? )))
Вы в курсе, сколько на свете текстовых редакторов? А офисных пакетов? Уверены что только два?
в линуксах штук пять. Платных несколько десятков... а может сотня.... кто их считал? ))
MS не удосужился предупредить тех, кто платит ему деньги. Это fuck-up.
А по поводу "пары раз с ODF" добавлю - при переходе на Unicode с вордовскими файлами у меня такая жопа
случалась пару раз в неделю. MS не удосужился придумать мягкий переход на новую кодировку.
А между прочим мог.
Ладно, на все вопросы вроде ответил.
Если вам просто нужно чтобы за вами было последнее слово, и дискуссия затянулась по этой причине,
то "пардоне муа". Замолкаю)
тогда вам стоило высказаться корректнее, а именно:
"В отдалённом будущем владельцам будущих версий OOo открыть файлы в формате DOCX будет проще, чем владельцам устаревших версий MS Office в прошлом".
"В отдалённом будущем владельцам будущих версий OOo открыть файлы в формате DOCX будет проще, чем владельцам устаревших версий MS Office в прошлом".
Если дело не в принципе, а в невозможности открыть docx, то это возможно поможет.
http://soft.oszone.net/program/3341/
http://soft.oszone.net/program/3341/
Уже приведенный WMF. Куча спецификаций вида текст выглядит как в вон в той версии ворда, это надо обрабатывать как в том ворде и т.п.
Хорошая статья, спасибо!
Немного ошибок заметил:
наверно должно быть: есть одно но...
наверно должно быть: Если тот формат...
Немного ошибок заметил:
...OpenFormula, но тут ест одно но...
наверно должно быть: есть одно но...
...Есть тот формат что есть меня не устраивает...
наверно должно быть: Если тот формат...
Википедиа говорит нам:
1. Название Office Open XML слишком похоже на OpenOffice.org, что приводит к путанице. Некоторые считают, что оно было выбрано намеренно.
2. Несмотря на то, что информация о формате открыта, он защищён патентами Microsoft, и любая программа для чтения Open XML нарушит законы США. [8][9]
3. Документация к Open XML занимает более 6000 страниц, что является излишне большим и существенно усложняет попытку создания программы с поддержкой Open XML.[10]
4. Из
1. Название Office Open XML слишком похоже на OpenOffice.org, что приводит к путанице. Некоторые считают, что оно было выбрано намеренно.
2. Несмотря на то, что информация о формате открыта, он защищён патентами Microsoft, и любая программа для чтения Open XML нарушит законы США. [8][9]
3. Документация к Open XML занимает более 6000 страниц, что является излишне большим и существенно усложняет попытку создания программы с поддержкой Open XML.[10]
4. Из
Ну вобщем вот что она говорит: http://ru.wikipedia.org/wiki/Microsoft_O… ^^
Если коротко, то:
1. Название Office Open XML слишком похоже на OpenOffice.org, что приводит к путанице. Некоторые считают, что оно было выбрано намеренно.
Про название - считаю бредом. Честно. OOXML перепутать с OpenOffice вообще сложно. А KOffice?
2. Несмотря на то, что информация о формате открыта, он защищён патентами Microsoft, и любая программа для чтения Open XML нарушит законы США.
А вот это уже передергивание фактов. Sun Microsystems точно также защитила патентами части стандарта ODF. И ничего, нормально, только бумажку выпустила разрешающую. Но как выпустила, так и отзовет.
А чтобы точно знать, что нарушит патент, нужно его целиком прочитать. Я пока не читал, поэтому спорить в этом вопросе не буду. Но почитаю ;)
3. Документация к Open XML занимает более 6000 страниц, что является излишне большим и существенно усложняет попытку создания программы с поддержкой Open XML.
Правильно! Даешь стандарты на 1 страницу 14 кеглем. Чтобы читать было просто. RFC почитайте (любой), поймете, что стандарт не описывается легко. А как легко описать более 10 лет эволюции офисного формата?
Конечно, я согласен с тем, что попытка создания "портика для инвалидов", типа, мол, "мы заботимся о пользователях Word 97" - полная ерунда. Поэтому тут частично соглашусь, но частично - нет.
4. Из-за широкого использования в Open XML битовых масок невозможно провести формальную проверку XML-файла с помощью DTD
В чем проблема? Проверить - можно. Не факт, что содержание будет совпадать, но формально - проверить можно.
5. Open XML является, по сути, переводом в XML бинарных форматов Microsoft Office. Как ручное редактирование, так и поддержка Open XML в других программах серьёзно затруднены. Размеры бумаги перенумерованы числами от 1 до 68, вместо имён A4, B5 и т. д; аналогично сделано с кодами языков. Некоторые имена цветов отличаются от стандартных.
А в каком виде хранить графику? Не в бинарном? А в каком, простите?
Думаю, что эти мелочи, в виде имен цветов и прочего - поправят. Тут согласен, опять же, что это недочет, а не критическая проблема.
6. Формат поддерживает вставку двоичных данных, что в будущем может привести к несовместимости.
См. пред. пункт.
7. Отсутствие поддержки языков с начертанием справа налево, и как результат, невозможность написания документов на арабском языке и иврите.
Это не проблема стандарта, а проблема программы. Есть Unicode, поддерживайте его в программе и будет Вас счастье.
8. Формат времени, доставшийся Open XML по наследству от Microsoft Excel, а тому от Lotus 1-2-3, отсчитывает годы начиная с 1900. При этом сам 1900 год неправильно трактуется как високосный, вследствие чего все даты до 28 февраля 1900 года включительно имеют неправильное соответствие с днём недели. Также в формате времени не задан часовой пояс, и временные расчёты не учитывают переходов на летнее время.
Это не проблема стандарта, а проблема программы. Во многих странах переход на летнее время устанавливается каждый год особым законом (Израиль, к примеру). Мне что, в формате предугадать действия израильского парламента?
9. Использование специального формата математических формул, который имеет альтернативу в виде MathML, и вдобавок был отвергнут консорциумом W3C ещё в 1997 году. В других местах также используются собственные форматы Microsoft — например, для векторной графики применяется внутренний формат Windows WMF, а не стандартизированный SVG.
Да, тут полностью согласен, это минус. Если есть стандарт, ему надо стараться следовать. Но на то и есть бинарные включения, чтобы можно было туда SVG засунуть.
10. Отсутствие поддержки выходных дней недели кроме субботы-воскресенья, в частности, пятницы-субботы (в Израиле) и четверга-пятницы (в странах Ближнего Востока).
Это не проблема стандарта, а проблема программы. Конкретные особенности страны должны пониматься программой, а не стандартом.
Опять же, подводя итоги, получается так: тот, кто писал это в Wiki, достаточно далек от программирования и разработки вообще.
1. Название Office Open XML слишком похоже на OpenOffice.org, что приводит к путанице. Некоторые считают, что оно было выбрано намеренно.
Про название - считаю бредом. Честно. OOXML перепутать с OpenOffice вообще сложно. А KOffice?
2. Несмотря на то, что информация о формате открыта, он защищён патентами Microsoft, и любая программа для чтения Open XML нарушит законы США.
А вот это уже передергивание фактов. Sun Microsystems точно также защитила патентами части стандарта ODF. И ничего, нормально, только бумажку выпустила разрешающую. Но как выпустила, так и отзовет.
А чтобы точно знать, что нарушит патент, нужно его целиком прочитать. Я пока не читал, поэтому спорить в этом вопросе не буду. Но почитаю ;)
3. Документация к Open XML занимает более 6000 страниц, что является излишне большим и существенно усложняет попытку создания программы с поддержкой Open XML.
Правильно! Даешь стандарты на 1 страницу 14 кеглем. Чтобы читать было просто. RFC почитайте (любой), поймете, что стандарт не описывается легко. А как легко описать более 10 лет эволюции офисного формата?
Конечно, я согласен с тем, что попытка создания "портика для инвалидов", типа, мол, "мы заботимся о пользователях Word 97" - полная ерунда. Поэтому тут частично соглашусь, но частично - нет.
4. Из-за широкого использования в Open XML битовых масок невозможно провести формальную проверку XML-файла с помощью DTD
В чем проблема? Проверить - можно. Не факт, что содержание будет совпадать, но формально - проверить можно.
5. Open XML является, по сути, переводом в XML бинарных форматов Microsoft Office. Как ручное редактирование, так и поддержка Open XML в других программах серьёзно затруднены. Размеры бумаги перенумерованы числами от 1 до 68, вместо имён A4, B5 и т. д; аналогично сделано с кодами языков. Некоторые имена цветов отличаются от стандартных.
А в каком виде хранить графику? Не в бинарном? А в каком, простите?
Думаю, что эти мелочи, в виде имен цветов и прочего - поправят. Тут согласен, опять же, что это недочет, а не критическая проблема.
6. Формат поддерживает вставку двоичных данных, что в будущем может привести к несовместимости.
См. пред. пункт.
7. Отсутствие поддержки языков с начертанием справа налево, и как результат, невозможность написания документов на арабском языке и иврите.
Это не проблема стандарта, а проблема программы. Есть Unicode, поддерживайте его в программе и будет Вас счастье.
8. Формат времени, доставшийся Open XML по наследству от Microsoft Excel, а тому от Lotus 1-2-3, отсчитывает годы начиная с 1900. При этом сам 1900 год неправильно трактуется как високосный, вследствие чего все даты до 28 февраля 1900 года включительно имеют неправильное соответствие с днём недели. Также в формате времени не задан часовой пояс, и временные расчёты не учитывают переходов на летнее время.
Это не проблема стандарта, а проблема программы. Во многих странах переход на летнее время устанавливается каждый год особым законом (Израиль, к примеру). Мне что, в формате предугадать действия израильского парламента?
9. Использование специального формата математических формул, который имеет альтернативу в виде MathML, и вдобавок был отвергнут консорциумом W3C ещё в 1997 году. В других местах также используются собственные форматы Microsoft — например, для векторной графики применяется внутренний формат Windows WMF, а не стандартизированный SVG.
Да, тут полностью согласен, это минус. Если есть стандарт, ему надо стараться следовать. Но на то и есть бинарные включения, чтобы можно было туда SVG засунуть.
10. Отсутствие поддержки выходных дней недели кроме субботы-воскресенья, в частности, пятницы-субботы (в Израиле) и четверга-пятницы (в странах Ближнего Востока).
Это не проблема стандарта, а проблема программы. Конкретные особенности страны должны пониматься программой, а не стандартом.
Опять же, подводя итоги, получается так: тот, кто писал это в Wiki, достаточно далек от программирования и разработки вообще.
Насчет 10 вы не правы.
Объясняю. Есть функция NETWORKDAYS, которая возвращает количество выходных между двумя датами. Для Росии одно число, дла Израиля другое.
Объясните мне, как нужно писать программу, чтобы она:
- будучи запущенна в Израиле, считала по одному алгоритму.
- будучи запущенна в России, считала по другому.
- Чтобы в документе, пришедшем из Израиля в Россию, был показан израильский ответ
Объясняю. Есть функция NETWORKDAYS, которая возвращает количество выходных между двумя датами. Для Росии одно число, дла Израиля другое.
Объясните мне, как нужно писать программу, чтобы она:
- будучи запущенна в Израиле, считала по одному алгоритму.
- будучи запущенна в России, считала по другому.
- Чтобы в документе, пришедшем из Израиля в Россию, был показан израильский ответ
Аналогичную ситуацию можно придумать для ваших ответов на 7 и 8.
Ха, так тут есть простой ответ. Во-первых, у пользователя в настройках операционной системы указано его местоположение. Если выбрал неправильное - сам виноват.
Теперь программа может считать так, как надо.
А чтобы показан был израильский ответ, так пользователь (высылающий документ) должен знать об этой разнице и хранить ответ не в виде вычисляемой формулы, а в виде числа. Точка.
А если пользователь об этой разнице не знает, то ему неплохо было бы несколько лучше знать либо свою страну, либо ту страну, с которой он работает.
Теперь программа может считать так, как надо.
А чтобы показан был израильский ответ, так пользователь (высылающий документ) должен знать об этой разнице и хранить ответ не в виде вычисляемой формулы, а в виде числа. Точка.
А если пользователь об этой разнице не знает, то ему неплохо было бы несколько лучше знать либо свою страну, либо ту страну, с которой он работает.
Вы серъезно?
Вполне. Почему я знаю об этой разнице, а бухгалтерша тетя Лена с контрагентом из Израиля об этом знать не должна?
У Вас есть лучшее решение? Почитайте OldNewThing, поймете, сколько уже крови было пролито за интернационализацию приложений, и сколько ее еще прольется.
У Вас есть лучшее решение? Почитайте OldNewThing, поймете, сколько уже крови было пролито за интернационализацию приложений, и сколько ее еще прольется.
Есть функция. В данном случае NETWORKDAYS. То, о чем Вы говорите, означает, что программист должен сделать ветвление: если у нас стандартные выходные, берем функцию, иначе вычисляем ответ. Что сводится к тому, что функцию нельзя использовать, так как полностью корректного результата она не дает, а ветвление лишь наворачивает код. Такой функции не должно быть в стандарте.
насчет пункта 6 зря вы так лихо свели все к графике;) Те люди, которые занимаются вопросами стандартизации - не простые программеры. Они должны учитывать гораздо более отдаленные перспективы использования спецификаций и форматов. Если есть опасность несовместимости это не стандарт (пользователь вставит данные которые только ему известно чем открываются)
по поводу пункта 5 тоже забавно складывается;) Спецификация должна быть ОПТИМАЛЬНОЙ, максимально прозрачной и просто реализуемой. В противном случае это не общий стандарт. Стандарт стоит на страже пользователей и разработчиков, причем в равной степени, на страже всех.
по поводу пункта 5 тоже забавно складывается;) Спецификация должна быть ОПТИМАЛЬНОЙ, максимально прозрачной и просто реализуемой. В противном случае это не общий стандарт. Стандарт стоит на страже пользователей и разработчиков, причем в равной степени, на страже всех.
Не пойму, что толку учитывать перспективу, когда речь идет о конкретном, офисном стандарте? Если поменяются условия, он и сам поменяется! HTML 4 уже сколько живет, а он очень многого не предусматривал... Взять тот же тэг object - ну чем не вставка "бинарных" данных?
И оптимальность - очень сложное понятие. Очень. В этом случае, судить не могу; себя уж точно не считаю оптимальным.
И оптимальность - очень сложное понятие. Очень. В этом случае, судить не могу; себя уж точно не считаю оптимальным.
речь не идет о КОНКРЕТНОМ офисном стандарте.
Конкретный офисный стандарт представила МС в виде компиляции своих внутренних стандартов в XML-технологию. По сути именно таким подходом и объясняется безумный объем спецификаций в 6 тыс страниц.
Конкретный офисный стандарт представила МС в виде компиляции своих внутренних стандартов в XML-технологию. По сути именно таким подходом и объясняется безумный объем спецификаций в 6 тыс страниц.
ODF - это платформа, которая будет расширяться. Это ее задача. И согласно ее спецификации, ее можно расширить.
Тег object содержит ссылку,а не самые бинарные данные.
Насчет 9 вы не правы. SVG — он XML-based, бинарность ему не нужна особо.
Ваш ответ на 5.
> Думаю, что эти мелочи, в виде имен цветов и прочего - поправят. Тут согласен, опять же, что это недочет, а не критическая проблема.
Допустим, поправили в ooxml1.2. Итого, у нас есть гигабайты старых документов со старыми цветами, и новые документы с новыми. Как писать программу, читающую эти данные? Два варианта:
1. Делать две обработки для старого и нового формата.
2. Забить на данные старого формата. Они потеряны.
Это будет касаться каждой (!) программы, читающей эти данные: редакторы, въюверы, поисковики, анализаторы, библиотеки ...
Вывод: ошибка в формате гораздо тяжелее исправляется чем ошибка в программе. К проектированию формата такого уровня надо подходить как можно более тщательно.
И вот. Перед вами два подхода:
ODF не спешит с выпуском стандартов на некоторые части, пока они не отшлифованы до блеска.
OOXML взяли большое количество ошибок из старых форматов и перенесли в новый под ложным предлогом совместимости. Зато у них описаны все части! Но стоит ли этим хвастаться? ;)
> Думаю, что эти мелочи, в виде имен цветов и прочего - поправят. Тут согласен, опять же, что это недочет, а не критическая проблема.
Допустим, поправили в ooxml1.2. Итого, у нас есть гигабайты старых документов со старыми цветами, и новые документы с новыми. Как писать программу, читающую эти данные? Два варианта:
1. Делать две обработки для старого и нового формата.
2. Забить на данные старого формата. Они потеряны.
Это будет касаться каждой (!) программы, читающей эти данные: редакторы, въюверы, поисковики, анализаторы, библиотеки ...
Вывод: ошибка в формате гораздо тяжелее исправляется чем ошибка в программе. К проектированию формата такого уровня надо подходить как можно более тщательно.
И вот. Перед вами два подхода:
ODF не спешит с выпуском стандартов на некоторые части, пока они не отшлифованы до блеска.
OOXML взяли большое количество ошибок из старых форматов и перенесли в новый под ложным предлогом совместимости. Зато у них описаны все части! Но стоит ли этим хвастаться? ;)
Насчет 4. Нафига тогда там делать XML если его нельзя проверить любым штатным валидатором?
Насчет 5. XML подразумевает читаемость не только роботами. К тому же плохо, то что интерпретация значений может поменяться в другой версии. И если ПО не смотрит на версию формата в файле (если конечно она там есть) можно получить очень неоднозначные глюки.
Начет 6. Такое делать нельзя. Графику надо хранить отдельно. В документе должен быть только якорь. Это повышает гибкость формата. Это же не графический формат, а формат документов. Если же товарищи из MS не знают, что такое архиваторы, то это явно их проблемы.
Пункт 8. На дату есть стандарт. И это есть проблема стандарта.
Пункт 10. Если бы поддержки выходных небыло, я бы согласился. Но ее есть. Так что надо делать правильно.
Насчет 5. XML подразумевает читаемость не только роботами. К тому же плохо, то что интерпретация значений может поменяться в другой версии. И если ПО не смотрит на версию формата в файле (если конечно она там есть) можно получить очень неоднозначные глюки.
Начет 6. Такое делать нельзя. Графику надо хранить отдельно. В документе должен быть только якорь. Это повышает гибкость формата. Это же не графический формат, а формат документов. Если же товарищи из MS не знают, что такое архиваторы, то это явно их проблемы.
Пункт 8. На дату есть стандарт. И это есть проблема стандарта.
Пункт 10. Если бы поддержки выходных небыло, я бы согласился. Но ее есть. Так что надо делать правильно.
О, круто. Давайте я тоже буду тиражировать то что говорят другие!
3. Спецификация ooxml включает в себя полностью все используемые технологии, спецификация odf ссылается на другие документы. Если включить эти документы в спецификацию odf то её размер будет БОЛЬШЕ (включите, к примеру, спецификацию Java)
по остальному - http://blogs.gotdotnet.ru/personal/vgabriel/content/binary/V-Answers-to-IBM-CZ-2007-08-13-7.pdf
3. Спецификация ooxml включает в себя полностью все используемые технологии, спецификация odf ссылается на другие документы. Если включить эти документы в спецификацию odf то её размер будет БОЛЬШЕ (включите, к примеру, спецификацию Java)
по остальному - http://blogs.gotdotnet.ru/personal/vgabriel/content/binary/V-Answers-to-IBM-CZ-2007-08-13-7.pdf
Поддерживаю автора.
Обращаю внимание общественности, доменное имя свободно - https://www.nic.ru/whois/?query=noodf.org =)
"Никто не мешает Майкрософт впредь использовать OOXML в качестве собственного формата. Но чтобы иметь будущее, компания должна играть по правилам сообщества, а не по своим собственным)"
не должна, если в сообществе у нее большой вес
не должна, если в сообществе у нее большой вес
Java вам придется таскать чтоб хотя бы запустить OpenOffice. А чтоб запустить Microsoft Office надо таскать .net. Не вижу причин не таскать )
По поводу .NET Вы не правы. Очень не правы.
Я о последнем офисе. Разве нет?
Ну вот. Пока лишь частично, но требует
http://office.microsoft.com/ru-ru/projec…
http://office.microsoft.com/ru-ru/projec…
Ну, наверно, начинать нужно с того, что у ODF тоже есть основной источник критики его же описание в Wikipedia, которое вы и взяли за основу. И критикуются в основном, как и в случае со стандартом OOXML, часности. Но, нужно признать, что идеальных стандартов не так уж и много, если они вообще есть...
В чем же заключается основная проблема с OOXML, так это в том, что Microsoft намеренно старается развязать войну стандартов. Вопрос в том, зачем нужен еще один стандарт? В принципе, MS могло участвовать и в разработке ODF, но раньше она не была заинтересована в стандартизации, посколько владела де-факто стандартом.
PS. Кстати, утверждение на счет лицензий Sun как раз и есть передергивание: Sun обязалась не предъявлять по ним никаких требований и это обязательство не возможно отозвать.
В чем же заключается основная проблема с OOXML, так это в том, что Microsoft намеренно старается развязать войну стандартов. Вопрос в том, зачем нужен еще один стандарт? В принципе, MS могло участвовать и в разработке ODF, но раньше она не была заинтересована в стандартизации, посколько владела де-факто стандартом.
PS. Кстати, утверждение на счет лицензий Sun как раз и есть передергивание: Sun обязалась не предъявлять по ним никаких требований и это обязательство не возможно отозвать.
Да, разумеется, только за основу я брал и чтение самого стандарта, в Wiki это только смотрелось потом, дополнительно. Ибо про формулы и отсутствие скриптов я знал еще со времен, когда пытался попробовать в реальной работе OpenOffice.
А по поводу Sun - интересно, как это его невозможно отозвать? Не напомните ли мне норму права в США, согласно которому компания не может этого сделать, а то я как-то подзабыл :(
А по поводу Sun - интересно, как это его невозможно отозвать? Не напомните ли мне норму права в США, согласно которому компания не может этого сделать, а то я как-то подзабыл :(
Я не юрист, и про норму американского законодательства вам профессионально не расскажу (как, наверно, и вы мне). Мне достаточно прочитать это заявление: http://www.oasis-open.org/committees/office/ipr.php. Во всяком случае, его юридическая значимость для меня не менее и не более юридической значимости любой софтверной лицензии или патента (поскольку, точных формулировок и самих норм американского права, которые их подтверждают я так же не знаю. Как и вы, насколько я понимаю. Или я ошибаюсь? ;)
НЛО прилетело и опубликовало эту надпись здесь
Вы знаете, я не привык общаться в таком духе, так что либо снизойдите до нормального общения, либо мне незачем отвечать.
НЛО прилетело и опубликовало эту надпись здесь
Я не собираюсь слушать матюки от человека, который толком ничего не сказал. Еще раз повторяю, что речь идет о стандарте, а не о разнице OO и MS Office. Если не понимаете о чем речь, просто промолчите.
Зря вы с ним спорите... На карму гляньте. :)
to
piroJOKE
Остальным смотреть его карму и читать подпись. %)
to
piroJOKEОстальным смотреть его карму и читать подпись. %)
Впрочем, Вас я тоже не поддерживаю. Мнение pJ мне ближе, хоть оно и жутко хамское, и я ему друг, судя по его подписи. Я мог бы поговорить о чудесах того и другого формата, но это вам уже и до меня говорили. У M$, просто, чудес гораздо больше и это не эсть карашо.
Согласен с автором.
К сожалению не могу технически подтвердить премущества той или иной спецификации, но «охота на ведьм» неприемлима для меня, будь то Open source или Микрософт.
К сожалению не могу технически подтвердить премущества той или иной спецификации, но «охота на ведьм» неприемлима для меня, будь то Open source или Микрософт.
НЛО прилетело и опубликовало эту надпись здесь
Ваш хамский стиль общения порядком надоел. Почему бы персонажей с такой кармой вообще нахер не банить?
Технические проблемы есть у обоих стандартов. Проблема политическая, а не техническая. Между прочим негодование к OOXML идёт именно из-за политики Microsoft в отношении стандартов.
Например, про патенты. Конечно Sun имеет тоже запатентовала ряд технологий. Да и IBM тоже. Но в отличии от Microsoft они не мешают делать открытые реализации. Microsoft не говорила, что откроет свои патенты, которые пересекаются с OOXML.
Например, технология CardSpace (метод аутентификации типа OpenID). Несмотря на том, что Microsoft говорила, что это открытый стандарт создать свободную его реализацию так и не получилось, так как MS блокирует разработки угрозами патентов.
То же самое с .Net — разработчики Mono (свободной реализации .Net) постоянно вынуждены обходить патенты.
ODF лучше OOXML не технически. Технически, наверное, они равно. ODF лучше, потому что он будет действительно открыт для предложений и развития.
Например, про патенты. Конечно Sun имеет тоже запатентовала ряд технологий. Да и IBM тоже. Но в отличии от Microsoft они не мешают делать открытые реализации. Microsoft не говорила, что откроет свои патенты, которые пересекаются с OOXML.
Например, технология CardSpace (метод аутентификации типа OpenID). Несмотря на том, что Microsoft говорила, что это открытый стандарт создать свободную его реализацию так и не получилось, так как MS блокирует разработки угрозами патентов.
То же самое с .Net — разработчики Mono (свободной реализации .Net) постоянно вынуждены обходить патенты.
ODF лучше OOXML не технически. Технически, наверное, они равно. ODF лучше, потому что он будет действительно открыт для предложений и развития.
> В итоге, на сегодня получается следующее: в стандарте ODF, прошедшем ISO стандартизацию, нет формул. Проблему может решить ODF 1.2, но пока его нет.
> Опять же, проблему может решить ODF 1.2, но пока его нет. Пишут.
Будет ODF 1.2 - будут и эти компоненты. Не изобретать же ради них новый стандарт документа с нуля?
> Опять же, главный плюс Microsoft Office для многих - наличие стандартизованных макросов. ... А важность макросов как таковых, надеюсь, никто отрицать не будет?
Будут, ещё как. Эти "стандартизированные макросы", очередной новый "птичий язык", созданный для решения единственной проблемы в единственном приложении, были нужны исключительно в MS Office (как в проприетарном продукте с закрытым кодом и сложностью интеграции с другими приложениями) и исключительно для MS Office-овских файлов (как для бинарных файлов в закрытом формате, да ещё и меняющемся со временем по прихоти MS). В цивилизованном мире для задач наподобие "переноса большого количества данных из текстовых документов в целевой формат, их обработки и проверки на корректность и последующей выгрузки дальше", используется великое разнообразие скриптовых языков (Perl/Python/Ruby/shell/TCL/что-угодно-ещё-да-хоть-scheme - а не единый и с нуля созданный для единственной цели VBA) с либо модулями для генерации нужных форматов напрямую, либо биндингами к библиотекам.
Ага, библиотекам. Которые можно привязать к любому языку, уже не обязательно скриптовому, от того же Perl-а до C++ или Джавы, и использовать хоть на смартфонах-КПК, хоть внутри навороченных бизнес-процессах на мощных серверах. А не использовать для обработки данных единственный встроенный язык.
> Опять же, проблему может решить ODF 1.2, но пока его нет. Пишут.
Будет ODF 1.2 - будут и эти компоненты. Не изобретать же ради них новый стандарт документа с нуля?
> Опять же, главный плюс Microsoft Office для многих - наличие стандартизованных макросов. ... А важность макросов как таковых, надеюсь, никто отрицать не будет?
Будут, ещё как. Эти "стандартизированные макросы", очередной новый "птичий язык", созданный для решения единственной проблемы в единственном приложении, были нужны исключительно в MS Office (как в проприетарном продукте с закрытым кодом и сложностью интеграции с другими приложениями) и исключительно для MS Office-овских файлов (как для бинарных файлов в закрытом формате, да ещё и меняющемся со временем по прихоти MS). В цивилизованном мире для задач наподобие "переноса большого количества данных из текстовых документов в целевой формат, их обработки и проверки на корректность и последующей выгрузки дальше", используется великое разнообразие скриптовых языков (Perl/Python/Ruby/shell/TCL/что-угодно-ещё-да-хоть-scheme - а не единый и с нуля созданный для единственной цели VBA) с либо модулями для генерации нужных форматов напрямую, либо биндингами к библиотекам.
Ага, библиотекам. Которые можно привязать к любому языку, уже не обязательно скриптовому, от того же Perl-а до C++ или Джавы, и использовать хоть на смартфонах-КПК, хоть внутри навороченных бизнес-процессах на мощных серверах. А не использовать для обработки данных единственный встроенный язык.
Вообще, с 97 года у Office были библиотеки, позволявшие работать с ним почти на любом языке. И сейчас есть. Просто мне было проще писать это "внутри" документа, чтобы сразу видеть результат выполнения, ставить точки останова и т.д.
Когда это будет сделано, когда будет работать ODF 1.2, вот тогда и посмотрим. А пока - рановато.
Кроме того, про VBA Вы зря ;) У меня уже два года рюкзак с надписью Visual Studio 2005: Tools for the Microsoft Office System. И забудьте про VBA ;)
Когда это будет сделано, когда будет работать ODF 1.2, вот тогда и посмотрим. А пока - рановато.
Кроме того, про VBA Вы зря ;) У меня уже два года рюкзак с надписью Visual Studio 2005: Tools for the Microsoft Office System. И забудьте про VBA ;)
> Вообще, с 97 года у Office были библиотеки, позволявшие работать с ним
Уточните. "У MS Office были библиотеки, позволяющие работать с ним", или "у формата документов MS Office" были такие библиотеки? Проприетарщики почти всегда делают первый вариант (что в офисе, что в том же скайпе, в котором для скайп-звонков надо иметь установленный скайп-клиент). В то время как для interoperability серьёзно необходим именно второй вариант. А в случае с MS (который библиотеки первого типа наверняка выпустит в закрытых исходниках и под единственную платформу), первый вариант дополнительно ограничит возможности взаимодействия.
> почти на любом языке.
(Задумчиво) Perl/Python? Не представляю себе использование других языков для обработки текстовых данных (а ворд-документы и таблички - это в первую очередь обычно именно текст).
Уточните. "У MS Office были библиотеки, позволяющие работать с ним", или "у формата документов MS Office" были такие библиотеки? Проприетарщики почти всегда делают первый вариант (что в офисе, что в том же скайпе, в котором для скайп-звонков надо иметь установленный скайп-клиент). В то время как для interoperability серьёзно необходим именно второй вариант. А в случае с MS (который библиотеки первого типа наверняка выпустит в закрытых исходниках и под единственную платформу), первый вариант дополнительно ограничит возможности взаимодействия.
> почти на любом языке.
(Задумчиво) Perl/Python? Не представляю себе использование других языков для обработки текстовых данных (а ворд-документы и таблички - это в первую очередь обычно именно текст).
У MS Office, разумеется, не у формата, конечно ;)
> Perl/Python
Так в чем проблема? Зачем Perl на платформе Windows, к примеру, где можно взять тот же C#?
> Perl/Python
Так в чем проблема? Зачем Perl на платформе Windows, к примеру, где можно взять тот же C#?
НЛО прилетело и опубликовало эту надпись здесь
Продолжай пользоваться Перлом.
Может товарищи не будут путать теплое с мягким? Я имею в виду язык для программирования всего чего угодно, к тому же компилируемы заранее, с языком для написания скриптов, компилируемым непосредственно перед выполнением? Разве тот же IronPyton случайным ветром в студию задуло? Например в программе, в разработке которой я участвую как тестировщик, динамически подгружаемая с базы логика обработки документов имено на АйронПитоне и написана, а вся программа на C#.
Так что C#-у совершенно нефиг делать в списке возможных языков для написания скриптов для документа, а вот Питон очень даже подходит.
Так что C#-у совершенно нефиг делать в списке возможных языков для написания скриптов для документа, а вот Питон очень даже подходит.
> Так в чем проблема?
Эээ, а как генерировать xls-документы из Perl/Python?
> Зачем Perl на платформе Windows,
А кто сказал про платформу Windows? Такого допущения не вводилось. Такое допущение является серьёзным ограничением interoperability.
> к примеру, где можно взять тот же C#?
Тут снизу piroJOKE, в общем-то, правильно сказал, хотя и с избыточной горячностью :)
Положим, мы уже имеем какую-нибудь мощную трейдинговую систему на Java, или какой-нибудь web20-ный сайт на RoR/Django. И хотим прикрутить туда генерацию таблички с котировками за нужный период (excel/oocalc), или печатную версию статьи (word/oowriter), или что-нибудь ещё. Извините, что, тогда исключительно для этой задачи выбирать, к уже имеющемуся решению на Java + Sun Fire 15k или Linux cluster + RoR/Django, дополнительно доставлять Делловскую машинку с виндой? Только чтобы иметь возможность заюзать Windows-only библиотеки MS Office, и возрадоваться модному C#?
Я уже не говорю про то, что для мелкого one-time скриптинга Perl/Python подходят существенно лучше, чем C# :)
Итак, на чём мы остановились. На кой же ляд нам стандартизировать макросы и макроязык?
Для упрощения генерации/конвертации документов ("вот тебе прайсы 10 контор - сделай мне сводку цен на материнки на базе Socket 939")? - Perl/Python + библиотеки чтения/записи формата (которые мы получаем благодаря открытости формата). Снаружи, а не внутри. Плюс не надо изучать новый язык для единственной задачи.
Чтобы делать "активные документы" ("любой офисменеджер может сделать простейшее приложение")? Знаем, проходили, половина DailyWTF-а посвящена великолепным базам данных, разработанным в Excel или Access и неожиданно ставшим использоваться не десятком пользователей, а несколькими сотнями. К тому же, если "офисменеджер" не умеет писать на Perl, то кто сказал, что он умеет писать на VBA (или другом макроязыке)? Что то, что то изучать.
Тогда зачем ещё какие-то жёсткие единичные макросы в самом формате?
Эээ, а как генерировать xls-документы из Perl/Python?
> Зачем Perl на платформе Windows,
А кто сказал про платформу Windows? Такого допущения не вводилось. Такое допущение является серьёзным ограничением interoperability.
> к примеру, где можно взять тот же C#?
Тут снизу piroJOKE, в общем-то, правильно сказал, хотя и с избыточной горячностью :)
Положим, мы уже имеем какую-нибудь мощную трейдинговую систему на Java, или какой-нибудь web20-ный сайт на RoR/Django. И хотим прикрутить туда генерацию таблички с котировками за нужный период (excel/oocalc), или печатную версию статьи (word/oowriter), или что-нибудь ещё. Извините, что, тогда исключительно для этой задачи выбирать, к уже имеющемуся решению на Java + Sun Fire 15k или Linux cluster + RoR/Django, дополнительно доставлять Делловскую машинку с виндой? Только чтобы иметь возможность заюзать Windows-only библиотеки MS Office, и возрадоваться модному C#?
Я уже не говорю про то, что для мелкого one-time скриптинга Perl/Python подходят существенно лучше, чем C# :)
Итак, на чём мы остановились. На кой же ляд нам стандартизировать макросы и макроязык?
Для упрощения генерации/конвертации документов ("вот тебе прайсы 10 контор - сделай мне сводку цен на материнки на базе Socket 939")? - Perl/Python + библиотеки чтения/записи формата (которые мы получаем благодаря открытости формата). Снаружи, а не внутри. Плюс не надо изучать новый язык для единственной задачи.
Чтобы делать "активные документы" ("любой офисменеджер может сделать простейшее приложение")? Знаем, проходили, половина DailyWTF-а посвящена великолепным базам данных, разработанным в Excel или Access и неожиданно ставшим использоваться не десятком пользователей, а несколькими сотнями. К тому же, если "офисменеджер" не умеет писать на Perl, то кто сказал, что он умеет писать на VBA (или другом макроязыке)? Что то, что то изучать.
Тогда зачем ещё какие-то жёсткие единичные макросы в самом формате?
Интересно что вы тут повторяете доводы Microsoft'а, которыми он руководствовался выбрасывая из MS Office 2008 for Mac "родные" VBA'шные макросы и всовывая туда AppleScript.
IMO совместимые макросы - штука хорошая (интерактивные документы, etc), но во-первых вторичная, а во-вторых уж точно не довод в пользу OOXML где их нет (и даже внутри MS Office совместимости нет!)...
IMO совместимые макросы - штука хорошая (интерактивные документы, etc), но во-первых вторичная, а во-вторых уж точно не довод в пользу OOXML где их нет (и даже внутри MS Office совместимости нет!)...
> Интересно что вы тут повторяете доводы Microsoft'а, которыми он руководствовался выбрасывая из MS Office 2008 for Mac "родные" VBA'шные макросы и всовывая туда AppleScript.
...и допустило еще большую ошибку, так как документ с такими макросами будет работать только на маках. Великолепное интероперабилити, МС, как всегда, на коне. Или они таки притащат потом AppleScript на РС? Впрочем, лучше от этого уже точно не станет...
...и допустило еще большую ошибку, так как документ с такими макросами будет работать только на маках. Великолепное интероперабилити, МС, как всегда, на коне. Или они таки притащат потом AppleScript на РС? Впрочем, лучше от этого уже точно не станет...
Между прочим, существенно более разумный ход Майкрософта - это создание Windows Scripting Host инфраструктуры, в которую могут биндиться любые языки. Что привело к появлению ActivePerl, ActivePython и ActiveTCL.
Но опять же, это хоть и удобная инфраструктура, но опять же инфраструктура уровня приложения (мы можем дёргать некоторую функциональность закрытого приложения). А макросы - это функциональность уровня формата файла. Самому файлу нужная... непонятно для чего. Разве что если мы горим желанием уметь делать "реферат с кнопкой". Или "книгу с попап-баннерной рекламой".
Для Word-а/OOWriter-а и OODraw (аналога в MS Office нет ;) ) встроенные макросы нужны... как газете коленвал. Для PowerPoint/OO Impress - тем более. Я могу понять надобность использования внешних функций в Excel/OOCalc ("рассчитать текущее состояние накоплений, получив с сайта FOREX текущую стоимость доллара и евро" и т.п.), но в текущем виде оно как раз реализуется достаточно сложно; и опять же, в идеале, эти функции должны писаться не на "том языке, который является частью формата", а на "том языке, который человек уже знает".
Т.е., опять же, внешними механизмами. Отлаженными и самостоятельными. Для Perl-а модуль наподобие "ForexCurrency.pm" может уже валяться на CPAN-е, а для VBA/ActionScript/чего-то-там-нововводимого его поищешь ещё.
Но опять же, это хоть и удобная инфраструктура, но опять же инфраструктура уровня приложения (мы можем дёргать некоторую функциональность закрытого приложения). А макросы - это функциональность уровня формата файла. Самому файлу нужная... непонятно для чего. Разве что если мы горим желанием уметь делать "реферат с кнопкой". Или "книгу с попап-баннерной рекламой".
Для Word-а/OOWriter-а и OODraw (аналога в MS Office нет ;) ) встроенные макросы нужны... как газете коленвал. Для PowerPoint/OO Impress - тем более. Я могу понять надобность использования внешних функций в Excel/OOCalc ("рассчитать текущее состояние накоплений, получив с сайта FOREX текущую стоимость доллара и евро" и т.п.), но в текущем виде оно как раз реализуется достаточно сложно; и опять же, в идеале, эти функции должны писаться не на "том языке, который является частью формата", а на "том языке, который человек уже знает".
Т.е., опять же, внешними механизмами. Отлаженными и самостоятельными. Для Perl-а модуль наподобие "ForexCurrency.pm" может уже валяться на CPAN-е, а для VBA/ActionScript/чего-то-там-нововводимого его поищешь ещё.
Документы бывают разные. И задачи бывают разные. Например может быть документ со списком задач и кнопкой "показать решение". Почему нет ? Для этого сильно продвинутого языка не надо. В PDF можно делать интерактивные документы, а в ODF/OOXML нельзя - где логика. Но эта задача - сильно вторична по сравнению с первостепенной задачей: реализовать переносимую поддержку неинтерактивных документов. И многим эти интерактивные документы и даром не сдались. Так что вынести их в отдельный стандарт - разумное решение IMNSHO.
по поводу таскать с собой яву. там где есть ОпенОфис, ява есть по умолчанию. Чего же боле?
А причем здесь ОпенОфис, если ODF стандарт. Он не должен быть привязан к конкретной программе.
согласен, да. но что может потребовать выполнения макросов вне програмной оболочке? я могу ошибаться, но макросы не работают без Ёфиса, нет?
я с макросами знаком только на уровне студенческих лабораторных работ и поэтому ничего не могу сказать точно.
Но, как я понимаю, макрос содержится в документе и программа уже сама его выполняет. Здесь нет никакой зависимости. Можно написать свой собственный редактор, в котором макросы будут выполняться особым образом.
Но, как я понимаю, макрос содержится в документе и программа уже сама его выполняет. Здесь нет никакой зависимости. Можно написать свой собственный редактор, в котором макросы будут выполняться особым образом.
Три аргумента, указывающие на недостатки статьи:
1. OOXML кросплатформенен ? Если нет то это не стандарт
2. Формулы - чем вам плох MathML ? И вообще, зачем в стандарт, позволяющий внедрять сторонние объекты совать что то похожее, но свое ? Национальная, тьфу, крпоративная идея ?
3. Прежде чем "идти" вв ISO стандарт должен быть УЖЕ открытым, а что мы имеем ? Сколько продуктов "держат" ODF, а сколько OOXML ?
P.S. Вы не в Майкрософт работаете - а то по постам смотрю - клуб благородных девиц Дядюшки Билла :)
1. OOXML кросплатформенен ? Если нет то это не стандарт
2. Формулы - чем вам плох MathML ? И вообще, зачем в стандарт, позволяющий внедрять сторонние объекты совать что то похожее, но свое ? Национальная, тьфу, крпоративная идея ?
3. Прежде чем "идти" вв ISO стандарт должен быть УЖЕ открытым, а что мы имеем ? Сколько продуктов "держат" ODF, а сколько OOXML ?
P.S. Вы не в Майкрософт работаете - а то по постам смотрю - клуб благородных девиц Дядюшки Билла :)
1. OOXML - кросплатформенен (плюс-минус), макросы (который так нравятся автору статьи) - ни в коем разе. Вплоть до того, что макросы одной 12й версии MS Office для разных OS (Windows и MacOS) несовместимы между собой.
2. Он говорил про формулы в таблицах. Выкидывать ODF вместо его дополнения необходимыми частями - бред. Это всё равно как выкидывать машину и покупать новую из-за того, что у старой колесо спустило.
3. Ну это не есть формальное требование. Хотя да, при прочих равных...
P.S. Сейчас напишу, пожалуй статью по поводу макросов - чтобы раз и навсегда закрыть этот вопрос...
2. Он говорил про формулы в таблицах. Выкидывать ODF вместо его дополнения необходимыми частями - бред. Это всё равно как выкидывать машину и покупать новую из-за того, что у старой колесо спустило.
3. Ну это не есть формальное требование. Хотя да, при прочих равных...
P.S. Сейчас напишу, пожалуй статью по поводу макросов - чтобы раз и навсегда закрыть этот вопрос...
НЛО прилетело и опубликовало эту надпись здесь
Вы забыли про третью категорию: те, кто с ним работал используя библиотеки, которые предоставляет Microsoft. Да, такой подход вполне возможен и осмысленен, но, опять-таки, к качеству стандарта прямого отношения не имеет. Мне же было нужно работать с ним напрямую (ну так вот получилось). Причём не писать новый OOXML "с нуля" (это тоже не бог весть как сложно), не читать и показывать его (что уже сложнее, но не смертельно), а преобразовывать его. И вот это таки сделать весьма непросто: простейшие правки могут потребовать согласованных неочевидных изменений в нескольких файлах... Грр...
В ODF таких проблем гораздо меньше (но их там тоже далеко на ноль)...
В общем моя оценка: ODF - еле-еле троечка (удовлетворительно), OOXML - где-то между единицей (плохо) и двойкой (неудовлетворительно). Вопрос: почему в ISO практически единогласно был принят откровенно посредственный стандарт ODF остаётся открытым, но это не повод ставить печать на ещё худший стандарт OOXML!
В ODF таких проблем гораздо меньше (но их там тоже далеко на ноль)...
В общем моя оценка: ODF - еле-еле троечка (удовлетворительно), OOXML - где-то между единицей (плохо) и двойкой (неудовлетворительно). Вопрос: почему в ISO практически единогласно был принят откровенно посредственный стандарт ODF остаётся открытым, но это не повод ставить печать на ещё худший стандарт OOXML!
Кстати, уже прошло пилотное внедрение ODF в Гос. органах РФ, судя по всему удачное и этот опыт будет переносится и на другие регионы:
http://www.altlinux.ru/government_news/odf_in_russia.html
http://www.altlinux.ru/government_news/odf_in_russia.html
Кстати в OpenXML макросы тоже не специфицированы :).
А с другой стороны, мне кажется, что ODF в общем полезный формат, т.к. есть хоть какая-то возможность написать конвертор к OpenOffice.org не занимаясь реверс инженирингом (хотя полностью этого избежать не получится) а изучая спецификацию. Правда оо.о поддерживает несколько свою версию ODF, а не совсем стандарт.Ну да что-то лучше чем ничто.
Т.е. я согласен, что ODF не панацея, но я считаю, что его наличие стоит приветствовать.
А с другой стороны, мне кажется, что ODF в общем полезный формат, т.к. есть хоть какая-то возможность написать конвертор к OpenOffice.org не занимаясь реверс инженирингом (хотя полностью этого избежать не получится) а изучая спецификацию. Правда оо.о поддерживает несколько свою версию ODF, а не совсем стандарт.Ну да что-то лучше чем ничто.
Т.е. я согласен, что ODF не панацея, но я считаю, что его наличие стоит приветствовать.
Про макросы я написал отдельно. Там всё гораздо хуже: мало того что в OOXML макросы не специфицированы, мало того что проблемы с макросами - это просто бич MS Office (их совместимость при переходе с версии на версию таки хромает), но в Office 12 (в котором как раз и появился OOXML) на совместимость Microsoft просто-напросто "поклал с прибором": MS Office 2007 for Windows и MS Office 2008 for Mac используют совершенно разные макросы (VBA в одном случае и AppleScript в другом).
уважаемые Хабраграждане!
Здесь уже многое написано про ODF, но у меня сложилось впечатление, что во многих случаях мы просто цитируем чужие цитаты, которые цитируют чьи-то мнения.
По адресу http://www.i-rs.ru/odf/translation лежит перевод на русский спецификации ODF.
Из замеченного на скорый взгляд в самой спецификации, она НЕ исключает использование таблиц в презентациях. Видимо, здесь мы путаем спецификацию и программу ОО.
Читаем сначала п. 2.3.3 "Модель содержимого документа презентации" предусматривает список графических изображений (п 2.3.2), которые в свою очередь (п. 2.3.4) могут содержать "элементы, реализующие расширенные табличные свойства".
Здесь уже многое написано про ODF, но у меня сложилось впечатление, что во многих случаях мы просто цитируем чужие цитаты, которые цитируют чьи-то мнения.
По адресу http://www.i-rs.ru/odf/translation лежит перевод на русский спецификации ODF.
Из замеченного на скорый взгляд в самой спецификации, она НЕ исключает использование таблиц в презентациях. Видимо, здесь мы путаем спецификацию и программу ОО.
Читаем сначала п. 2.3.3 "Модель содержимого документа презентации" предусматривает список графических изображений (п 2.3.2), которые в свою очередь (п. 2.3.4) могут содержать "элементы, реализующие расширенные табличные свойства".
Ответ на: пост dmach-a
> К сожалению, лагерь сторонников ODF категорически отрицает идею обратной совместимости.
Объясни, пожалуйста, подробнее про идею обратной совместимости, которую отрицает лагерь сторонников ODF и поддерживает, как я понял, лагерь сторонников OOXML. Я пропустил похоже этот момент :)
> К сожалению, лагерь сторонников ODF категорически отрицает идею обратной совместимости.
Объясни, пожалуйста, подробнее про идею обратной совместимости, которую отрицает лагерь сторонников ODF и поддерживает, как я понял, лагерь сторонников OOXML. Я пропустил похоже этот момент :)
Ну как два примера, нападки на
1. возможность включения в документ данныех в произвольных форматах (видео, графика и картинки)
2. наличие специального раздела спецификации описывающего ограничение поведения разлиыных прошлых программных продуктов (не только от Microsoft а вообще)
1. возможность включения в документ данныех в произвольных форматах (видео, графика и картинки)
2. наличие специального раздела спецификации описывающего ограничение поведения разлиыных прошлых программных продуктов (не только от Microsoft а вообще)
Ну про первый пункт мы уже поговорили %)
Во втором пункте имеются в виду те самые флаги ПробелыКакВОфисе98 и тому подобные в теге compact?
И общий вопрос: как эти два пункта обеспечивают обратную совместимость?
PS: Под обратной совместимостью формата я понимаю возможность без переконвертации читать данные в старом формате в программе, которая реализовала поддержку только нового формата. Например, если после полной реализации ooxml можно будет читать старые doc-и без дополнительный ухищрений, то это можно назвать обратной совместимостью :)
Во втором пункте имеются в виду те самые флаги ПробелыКакВОфисе98 и тому подобные в теге compact?
И общий вопрос: как эти два пункта обеспечивают обратную совместимость?
PS: Под обратной совместимостью формата я понимаю возможность без переконвертации читать данные в старом формате в программе, которая реализовала поддержку только нового формата. Например, если после полной реализации ooxml можно будет читать старые doc-и без дополнительный ухищрений, то это можно назвать обратной совместимостью :)
Под обратной совместимостью со старыми форматами документов я понимаю возможность конвертации старых документов в новый формат без потерь данных и возможность работать со старыми документами в рамках нового формата используя все его преимущества.
Хорошо :) Можно, пожалуйста, пример старого и нового формата, где обратной совместимости (по твоему определению) нет?
Возможно я покажусь вам банальным, но вот тупо Microsoft Word -> ODF.
Ааа :) А ODF -> OOXML тоже? (у последнего, насколько я помню, нет таких стилей страницы как у первого)
У него много чего нет. Таких стилей как в ODF, такого форматирования как у WordPerfect 12, нет поддержки формата PCX и т.д. и т.п.
Вообще он обратно совместим только с MS Office предыдущих версий - и только при использовании MS Office последних версий (только они могут знать как правильно расставлять переносы при указании соответствующих флагов).
Спрашивается: почему международный стандарт ISO должен поддерживаться другим стандартом ISO хуже, чем приватный стандарт MS Office ?
Вообще он обратно совместим только с MS Office предыдущих версий - и только при использовании MS Office последних версий (только они могут знать как правильно расставлять переносы при указании соответствующих флагов).
Спрашивается: почему международный стандарт ISO должен поддерживаться другим стандартом ISO хуже, чем приватный стандарт MS Office ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ODF — про бревно в глазу