Ещё бы запретили распространять все офисные пакеты, поддерживающие odt, совсем было бы хорошо, это была бы победа разума над энтропией. Дрочеры, фапающие на этот говноформат только потому, что он открытый и свободный, идите в лес. Более идиотского решения, чем зипованный эксемель тяжело придумать! В сравнении с этим даже закрытый бинарный формат мелкомягких доков выглядит гораздо предпочтительнее. Даже ублюдочный pdf (при условии, что средства создания и редактирования будут столь же распрстранены и доступны, как щас для doc).
Ровно то же самое, что и подвигло меня вспомнить про одт. Правда, мне всё это время недосуг уточнить, сжатый это эксемель, или нет. Я, кажется, ни разу не видел вживую документ в docx. Но, если он не сжатый, то это значит, что он, при всех своих недостатках, гораздо лучше, чем открытый odt/
У меня есть несколько идефиксов, которые я периодически продвигаю на ЛОРе. Говённость odt среди них, как и ненужность (на 99% от текущего состояния) формата pdf. Сейчас я маю вильный час та натхнення.
Он тоже сжатый. А теперь поведай, почему ты так ненавидишь сжатие? Зажаты они обычным ZIPом. Ты же знаешь, что почти в любом мобильнике есть поддержа zip дабы распаковать jar?
> В сравнении с этим даже закрытый бинарный формат мелкомягких доков выглядит гораздо предпочтительнее. Даже ублюдочный pdf (при условии, что средства создания и редактирования будут столь же распрстранены и доступны, как щас для doc).
аргументация, кроме достойной лужи, будет?
безотносительно этих конкретных форматов интересует:
1). агрументация того, что бинарный формат лучше текстового xml + бинарных файлов
2). агрументация того,что закрытый формат лучше открытого
>Это завышенная требовательность к ресурсам при обработке таких доков.
С чего бы? Распаковка чего-то LZW-образного обычно быстрее чем IO. На практике можно даже получить ~5-10% *рост перформанса* при чтении сжатых данных по сравнению с несжатыми. Особенно если мы имеем такой избыточный формат данных как XML.
Потому, что знаю, как удобно бывает работать с несжатыми документами. Вот тебе пример: представь, что кому-то пришла в голову идея хранить в сжатом виде юниксовые конфиги. Прикинь, сколько сразу теряется отработанных десятилетями возможностей и приёмов в работе с текстовыми конфигами.
На практике для офисных документов сжатие делает невозможным режим, аналогичный имеющемуся в меловорде режиму инкрементных сохранений. Который позволяет БЫСТРО сохранять БОЛЬШИЕ документы. Очень быстро, за доли секунды даже на слабых машинах очень большие, во много мегабайт, документы. Достигается это записью в файл диффов к предыдущему состоянию. Дописывания их в конец файла. Производительнсть труда повышает некисло. Однократное сохранение с отключённым этим режимом приводит размер и состояние файла к нормальному.
> 1). агрументация того, что бинарный формат лучше текстового xml + бинарных файлов
Бинарные файлы гораздо компактнее, что просто устраняет надобность внешнего сжатия.
2). агрументация того,что закрытый формат лучше открытого
Нет. Открытый формат лучше закрытого. Более того, открытый формат в общем случае гораздо лучше, чем открытый код. Но отрицательные качества избыточного и сжатого формата таковы, что открытость на их фоне уже не является преимуществом.
А хрен их знает. Кому-то нужны. При нормальном формате проблемы несущественны. Зачем самим себе строить искуственные ограничения, ограничивать возможности? Когда ты МОЖЕШЬ работать с такими документами, это по любому лучше, чем когда возможности этой ты лишён. Никто же не заставит тебя лепить именно огромные доки, если не захочешь. Да, ещё есть слабые машины. Да хотя бы девайсы типа смартфонов. Для них и стокилобайтный док можно считать большим.
>А хрен их знает. Кому-то нужны. При нормальном формате проблемы несущественны.
До, несущественны, поставил абзац в начале документа, форматирование 500 страниц слетело, сиди опять все выравнивай. Отличный редактор, отличный формат.
ОЗУ у тя сколько? Гига два, а может четыре? Что, уже дошли до стадии, когда для обработки килобайта данных необходим мегабайт свободной памяти? Я помню времена, когда ситуация была несколько другой, когда можно было комфортно работать с документами, едва влезающими в память. А теперь - рискнёшь открыть четырёхгиговый документ?
Хотя вот что. Разработчикам самого быстрого редактора таблиц «Gnumeric» XML жутко не нравится, если поискать на их сайте, то можно найти статью почему конкретно не нравится.
> поставил абзац в начале документа, форматирование 500 страниц слетело, сиди опять все выравнивай
Гы-гы-гы!! Никому больше так не говори. Если руки из жопы, то, конечно, слетит, даже если в конце текста добавишь. Для того, чтобы не слетало, нужно научиться правильно документы создавать и оформлять. В текстпроцессорах есть все средства для этого.
Ты рискнёшь открыть в ОО двухгиговый документ? Представляешь, каким колом встанет система? А когда-то я спокойно открывал двухмегабайтный текст на 286 с мегабайтом памяти.
> Бинарные файлы гораздо компактнее, что просто устраняет надобность внешнего сжатия.
текстовые форматы обычно более расширяемые, напр. в xml можно добавить новый namespace и встраивать новые возможности. Плюс текст хранится текстом, данные данными, что даёт возможность редактирования бинарного контента внешними программами.
Соответственно в тех задачах, где это надо (например создание текстового документа с возможностью включения произвольных внешних данных) это может сыграть в пользу xml.
Правда там, где это не нужно бинарный формат, конечно, выигрывает.
некоторые архивы поддерживают инкрементальное сохранение, но это лирика.
Используй стили, Люк! При грамотном применении стилей вёрстка не летит и не сыпется. Запрет висячих строк, «не отрывать от предыдущего», «всегда в начале странцы» и ты пы. Вообще не проблема.
Я бы тебе поверил, если бы не знал, что на свете существует формат tiff. Но, поскольку я с ним знаком, это высказывание для меня не более, чем некомпетентный бред.
Плюс текст хранится текстом
Никто не мешает хранить текст текстом и при бинарной структуре самого файла. Как минимум, вордовские доки вполне читаемы простым просмотрщиком текста.
некоторые архивы поддерживают инкрементальное сохранение, но это лирика.
Угу. Если бы такой формат архива применялся в данном случае, у меня было бы меньше аргументов для срача.