Почему форматы Microsoft Office такие сложные?

> CCl4

Особенно порадовала

> RTF полностью поддерживается и сейчас.

и

>В первых версиях Excel для Windows, 1 мегабайт ОЗУ был обычным объёмом памяти, и 80386 с 20 мегагерцами мог с комфортом гонять Excel.

Если "это" работа, то что же тогда глюкалово и тормоза?

И ещё про обратную совместимость порадовало весьма. Тем более, что она в МСО очень-очень дерьмовая и её никто не тестирует и не патчит.

дядько дело пишет.

// wbr

нда ... нафига городить какие-то невообразимые костыли ?) ну в теории оно быстрее работало, но только в теории, как мне помнится - ворд на P200 MMX довольно долго писал doc файлы ...

да и сами MS отказались от своих огородов в пользу XML, что еще раз подтверждает ненужность и убогость формата ....

статейка - бред чистой воды. Поется песня про большой труд и обратную совместимость, а на практике совместимости даже рядом не было и нет. Или с 9х-го года все нормальные разработчики разбежались и вшивые индусы за еду дописывают костыли т.е. создают видимость развития?

Баян, на английском статья тут проскакивала.

Вот это убило:

> Да, я обещал обходные пути. <...> Заставить Office делать грязную работу за вас.

Да, конечно... особенно не под оффтопиком.

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

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

плодами творчества этого фен-боя пользуются десятки [сотни?] миллионов пользователей по всему миру уже более десятка лет. боюсь, экслерам и вотбинам до него как пешком до Китая, а про онанимусов и вовсе история не ведает.

// wbr

>Почему форматы Microsoft Office такие сложные?

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

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

> плодами творчества этого фен-боя пользуются десятки [сотни?] 
> миллионов пользователей по всему миру уже более десятка лет. боюсь, 
> экслерам и вотбинам до него как пешком до Китая, а про онанимусов и 
> вовсе история не ведает. 

У вас, дядя, с пониманием русского письменного проблемы? Где сказано,
про качество его "творчества"? Ась? Милок, лучше не пиши, но постарайся
понимать написанное. Если  же ты думаешь, что каждый, подобно тебе, должен с
открытым ртом внимать перцам, которые когда-то там-что-то-и-"миииллиардам
пользователей-по-всей-галактике", то обломись, родной. Тебе голова дана не
для того, чтобы туда есть.

> У вас, дядя, с пониманием русского письменного проблемы? Где сказано,
про качество его "творчества"? Ась? Милок, лучше не пиши, но постарайся
понимать написанное. Если же ты думаешь, что каждый, подобно тебе, должен с открытым ртом внимать перцам, которые когда-то там-что-то-и-"миииллиардам пользователей-по-всей-галактике", то обломись, родной. Тебе голова дана не для того, чтобы туда есть.

обычно белые люди стыдятся неуместного хамства.

anyway. в отличие от по-мальчишески хамоватого онанимуса, который, готов биться об заклад, не прочитал и страницы из открытой намедни документации по форматам MSO, Джоел в указанном вопросе разбирается отнюдь не по наслышке бо сам в своё время принимал в разработке весьма активное участие. внимание, знатоки, вопрос: к чьему мнению стоит прислушиваться - онанимуса или Джоела?

// wbr

> к чьему мнению стоит прислушиваться - онанимуса или Джоела?

своему ?)

>обычно белые люди стыдятся неуместного хамства.
>
>anyway. в отличие от по-мальчишески хамоватого онанимуса, который, 
>готов биться об заклад, не прочитал и страницы из открытой намедни 
>документации по форматам MSO, Джоел в указанном вопросе разбирается 
>отнюдь не по наслышке бо сам в своё время принимал в разработке весьма 
>активное участие. внимание, знатоки, вопрос: к чьему мнению стоит 
>прислушиваться - онанимуса или Джоела? 

Да ты, я смотрю, никак не угомонишься. Ты знаешь, дружок, я и говна 
никогда не ел. И чтобы такой знаток копрофагии не говорил, никогда не
буду его пробовать. Тут ты первый - без вопросов.

> Да ты, я смотрю, никак не угомонишься. Ты знаешь, дружок, я и говна
никогда не ел. И чтобы такой знаток копрофагии не говорил, никогда не
буду его пробовать. Тут ты первый - без вопросов.

хорошо. честное признание "я ничего не смыслю в обсуждаемом вопросе" принимается. по крайней мере честно.

// wbr

Жуть. МС сама себе выкопала яму. Преклоняюсь перед разработчиками опеноффиса, который его импортит на удивление хорошо.

В общем кардинальный выход один — забыть про этот формат в ближайшие 10 лет.

> Жуть. МС сама себе выкопала яму. Преклоняюсь перед разработчиками опеноффиса, который его импортит на удивление хорошо.

да уж, не так то просто порой избавиться от удивления от того, как OO умудряется импортировать MSO doc-и ;)

ну а по поводу ямы.. хм. я бы ещё понял, если бы MSO действительно плёлся где-то там далеко-далеко в хвосте за OO, KO, Abiword и всей этой блистательной братией и, в силу своих кривых технических решений физически за ней не поспевал. действительно, можно лишь пожалеть ребят и посоветовать основательно обновить персонал. если бы. но ведь это не так и как раз в яму MSO с грохотом рухнул именно OO завязнув там по самые помидоры и именно OO тиму приходится в ускоренном темпе штудировать что они там наоткрывали, чтобы стать хоть как-то конкурентоспособным на фоне гигантской базы документов в формате doc. в свою очередь, пока конкуренты копаются в старье, тратя на это свои бесценные и без того немногочисленные ресурсы, MS может спокойно работать над новым форматом документов :)

// wbr

эмм, Вы что-то путаете ... MS впереди только засчет домохозяек и офисного планктона, который можно пересадить на OO и они ничего не заметят )

> эмм, Вы что-то путаете ... MS впереди только засчет домохозяек и офисного планктона, который можно пересадить на OO и они ничего не заметят )

нет, ну конечно же, если проводить опрос среди реально продвинутой молодёжи, то MSO сосёт по самые гланды и практически не существует. это если не брать в расчёт все то мелкое быдло, которое окружает эти две десятка небритых панков ;)

// wbr

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

экспортит в doc зато хуже. Попадался как-то файл с картинками в колонтитулах, вертикальными надписями в таблицах/фреймах, который, будучи сохранённым в ods читался нормально, сохраненный в doc -- терял эти надписи. А в Word'е другой файл с толстыми картинками в верхних колонтитулах приводил к тому, что страницы в нижних колонтилулах не нумеровались. Удаляем художества -- опа, пошла нумерация. Вставляем художества из gif -- нумерация идёт ОК. Похоже, что-то кривое было в свойствах абзаца с картинками.

> MS впереди только засчет домохозяек и офисного планктона, который можно пересадить на OO и они ничего не заметят )

Угу. У меня в конторе 5 компьютеров Р133 +16 Мб ОЗУ на которых стоит (не летает, но работает приемлемо) MSO ХР
А теперь рецепт, пожалуйста. Как этих людей перевести на ОО что б они этого не заметили..

> нет, ну конечно же, если проводить опрос среди реально продвинутой молодёжи, то MSO сосёт по самые гланды и практически не существует. это если не брать в расчёт все то мелкое быдло, которое окружает эти две десятка небритых панков ;)

хм, да лана, число пользователей альтернативных офисных пакетов растет ... и довольно быстрыми темпами, просто не многим уже нужен MS Word 2007, которые по сис. требованиям не уступает Quake 3 )

> А теперь рецепт, пожалуйста. Как этих людей перевести на ОО что б они этого не заметили..

поставить его им ?)

Еврей и гомосексуалист Спольски советует гордым линуксойдам: "То же самое, но хостинг на Linux. Купи сервер на Windows 2003, установи на него лицензионный Word и настрой веб-службу, которая будет делать всё это. Полдня работы на C# и ASP.NET." А добавлять поддержку форматов m$ офиса в свободные конкуренты - ни-ни, не смей!

> хм, да лана, число пользователей альтернативных офисных пакетов растет ... и довольно быстрыми темпами, просто не многим уже нужен MS Word 2007, которые по сис. требованиям не уступает Quake 3 )

я бы понял, если бы на дворе был 2001й год. но сегодня систребования к q3 смотрятся просто смешными.

// wbr

> поставить его им ?)

Да за нефик делать... А работать оно на этой конфигурации будет, или мне затем их работу самому выполнять?

> я бы понял, если бы на дворе был 2001й год. но сегодня систребования к q3 смотрятся просто смешными.

ну да, покупать печатную машинку, которая тянет кризис это сейчас нормально ) жаль в кроссфайере не ставят на них видюхи ...

> Да за нефик делать... А работать оно на этой конфигурации будет, или мне затем их работу самому выполнять?

у девушки родители нормально перешли ...

> у девушки родители нормально перешли ...

Хм. На тех компьютерах я, если честно. не пробовал. Но, боязно. Если оно на моем тормозило... И с совместимостью не все безобидно. Наш бланк в последней (2-какой-то) версии, которую я пробовал конкретно перекашивало...

ну doc скорее всего перекосит, можно в Googl'овском офисе попробовать экспортировать ...

> Почему форматы Microsoft Office такие сложные?

На это есть вполне логичные причины и индусы тут не при чем. MS характеризовала раньше, до всяких индусов, (не знаю как сейчас) "Базарный" стиль разработки под тотальным давлением менеджемента.

Когда MS купила ворд .doc формат не предполагал , по определению, использование его на какой то другой машине, чем та на которой ое был создан. Т.е набил - распечатал. Никакого "просмотрел на компе товарища/начальства".
По этому .doc это просто дамп памяти редактора. Это позволяет делать быстрое сохранение и загрузку, особенно в условиях тотальной ограничеснности ресурсов.

А потом появилось два фактора - пользователи и менеджмент микрософт. Они осознали что аттачить .doc к емылу это клево и удобно. Но возникали глюки. Угадайте что сделал микросоыфт - правильно, такая ситуация в подобном стиле разработки могла иметь только одно решение : быстро патчить глюки в формате/коде во время тестирования.

К идее того что формат нужно редизайнить они пришли только через 20 лет ......

>которые по сис. требованиям не уступает Quake 3 )

ага, а по размеру еще его и превосходят....;-)

Весьма интересная, статья, главное приоткрывает загадку почему когдато ворд работал под досом, а сейчас требует столько ресурсов, и в чем недостаток odt.

> Когда MS купила ворд .doc формат не предполагал , по определению, использование его

> К идее того что формат нужно редизайнить они пришли только через 20 лет ......

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

Вот Джоель пишет, что SQL лучше XML тем что не нужен парсинг, и для перехода к след. записи достаточно прибавить "смещение".

Во-первых, он лукавит -- в SQL базу точно так же, как "парсить XML" надо сначала загрузить данные, логически связать внешние ключи и т.п., то есть данные в SQL базе без схемы данных -- бесполезны. Получается, то что в XML делается в одном самодостаточном файле, в SQL должно сопровождаться отдельными метаданными+инфраструктурой вроде компилятора SQL, составления планов запроса, и т.п.

То есть, грузить файл в базу, или XML в память для DOM -- все равно надо.

для перехода к след. записи в XML надо "всего лишь добавить смещение" в текущему узлу в DOM.

во-вторых, существенным недостатком XML он называет, что его надо грузить "весь целиком", что отжирает память. Ну так есть поточный SAX, наконец и от XML можно отказаться в сторону чего-то более легкого вроде YAML и т.п. контекстно-свободной грамматикой, что не потребует просмотра вперед и загрузки всего файла целиком, только некоторого самодостаточного потока/контейнера.

Я не ратую за то чтобы всё завернуть в XML, но по крайней мере одну-две задачи он решает: самодостаточные метаданные "формата файла", которые сами описывают его структуру и "универсальность" для написания тех же конверторов, не NxM вариантов (входных N в M выходных), а N+M вариантов конверторов через один "универсальный" формат.

Отделяя метаданные от реализации формата "хранения" мы получим те самые исторические галочки в абзацах "не переностить со след. абзацем", про которые никто уже и не помнит. То есть нерасширяемость, недостаточную гибкость "семантики" данных.

> Когда MS купила ворд .doc формат не предполагал , по определению, использование его

> К идее того что формат нужно редизайнить они пришли только через 20 лет ......

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

Вот Джоель пишет, что SQL лучше XML тем что не нужен парсинг, и для перехода к след. записи достаточно прибавить "смещение".

Во-первых, он лукавит -- в SQL базу точно так же, как "парсить XML" надо сначала загрузить данные, логически связать внешние ключи и т.п., то есть данные в SQL базе без схемы данных -- бесполезны. Получается, то что в XML делается в одном самодостаточном файле, в SQL должно сопровождаться отдельными метаданными+инфраструктурой вроде компилятора SQL, составления планов запроса, и т.п.

То есть, грузить файл в базу, или XML в память для DOM -- все равно надо.

для перехода к след. записи в XML надо "всего лишь добавить смещение" в текущему узлу в DOM.

во-вторых, существенным недостатком XML он называет, что его надо грузить "весь целиком", что отжирает память. Ну так есть поточный SAX, наконец и от XML можно отказаться в сторону чего-то более легкого вроде YAML и т.п. контекстно-свободной грамматикой, что не потребует просмотра вперед и загрузки всего файла целиком, только некоторого самодостаточного потока/контейнера.

Я не ратую за то чтобы всё завернуть в XML, но по крайней мере одну-две задачи он решает: самодостаточные метаданные "формата файла", которые сами описывают его структуру и "универсальность" для написания тех же конверторов, не NxM вариантов (входных N в M выходных), а N+M вариантов конверторов через один "универсальный" формат.

Отделяя метаданные от реализации формата "хранения" мы получим те самые исторические галочки в абзацах "не переностить со след. абзацем", про которые никто уже и не помнит. То есть нерасширяемость, недостаточную гибкость "семантики" данных.

блин, Опера 9.26, дублируются посты. Прибейте дубли, если что.

>Я не ратую за то чтобы всё завернуть в XML, но по крайней мере одну-две задачи он решает: самодостаточные метаданные "формата файла", которые сами описывают его структуру и "универсальность" для написания тех же конверторов, не NxM вариантов (входных N в M выходных), а N+M вариантов конверторов через один "универсальный" формат.

Засуньте в xml гигабайт данных, и радуйтесь. XML хорош но не для всего.

>Засуньте в xml гигабайт данных, и радуйтесь. XML хорош но не для всего.

если конкретно, то этот гигабайт в виде UUE :) в CDATA-секции "сплошного блоба" XML -- это и есть неправильный дизайн. Раньше были двоичные блобы, теперь их стали "заворачивать в XML".

Вместо этого надо оставить этот гигабайт в двоичном виде как есть, но добавить к нему XML(YAML,Sexpr, ...)-подобную аннотацию-метаданные, описание что это и зачем. И отдавать файл-блоб только вместе с такой аннотацией, или всей целиком или ссылкой на "схему данных", в каком-то контейнере (сойдёт и tar для начала).

Тогда и расширяемость останется, и данные будут описываемые, а не непонятно что окаменевшее.

SQL язык запросов, XML - язык разметки ... вы о чем ?)

>SQL язык запросов, XML - язык разметки ... вы о чем ?)

Вы о чем ? я про SQL ни слова не сказал.

я о всех выше идущих постах и гигабайте в XML ..

>я о всех выше идущих постах и гигабайте в XML ..

Гигабайт в xml - это божество призванное продемонстрировать неприменимость затыкания всех дыр XML. Правда человек предложил использовать XML в качестве метаинформации к гигабайту (если я верно понял), но по мне это способ наплодить лишних сущностей.

ну гигабайт в доке еще хуже )

>>Вот Джоель пишет, что SQL лучше XML тем что не нужен парсинг, и для перехода к след. записи достаточно прибавить "смещение".

это я об этом: http://www.joelonsoftware.com/articles/fog0000000319.html

How does a relational database implement SELECT author FROM books? In a relational database, every row in a table (e.g. the books table) is exactly the same length in bytes, <...> etc. What is the code to move to the next record in the result of this query? Basically, it's this:

pointer += 100;

> но по мне это способ наплодить лишних сущностей.

каких именно "лишних"? Я про то, что это формат данных должен оставаться расширяемым, а без метаинформации вообще становится окаменелым гавном мамонта :(

>каких именно "лишних"? Я про то, что это формат данных должен оставаться расширяемым, а без метаинформации вообще становится окаменелым гавном мамонта :(

Посмотрите на TIFF - расширяемый? да. XML есть? нет. Вы сейчас спорите зря, пихать расширяемость и метаинформацию во все дыры, занятие чреватое.

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

хм, SQL так же парсит то, что лежит в БД ... только структура другая, тут уже все будет зависить от реализации идеа, а не от того - парсить или не парсить )

> Вы, как я понимаю, однозначно скажете "да"?

да, да и еще раз да ) сейчас мне приходится городить такие костыли и собирать данные из 3-4х таблиц БД, что бы вывести 2-3 строчки ...

> То же самое, но хостинг на Linux. Купи сервер на Windows 2003, установи на него лицензионный Word и настрой веб-службу, которая будет делать всё это. Полдня работы на C# и ASP.NET.

)))))

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

:-))) Формат rtf тоже был придуман в Микрософте. Он универсальный, расширяемый и текстовый. Короче - Латех вид в профиль. Вероятно им (Микрософту) что-то другое нужно. В смысле не удобство пользователя и уж тем более не совместимость.

>:-))) Формат rtf тоже был придуман в Микрософте. Он универсальный, расширяемый и текстовый. Короче - Латех вид в профиль. Вероятно им (Микрософту) что-то другое нужно. В смысле не удобство пользователя и уж тем более не совместимость.

если бы они юзали нормальный TeX-совместимый формат, то m$office не юзали бы в таких количествах.