Comments 74
Микрософт совершила большую ошибку в своё время, что для выбрала закрытый формат. В конце 90х я имел дело с LaTex — отличная вещь наподобие того же HTML, только сильно мощнее для формул и для подготовки книг и статей для печати. Но главный плюс в том, что формат читаемый, можно руками набирать. А майкрософт офис много крови всем попил. С закрытыми форматами была проблема и с генерацией документов и с их отображением.
У Google Docs те же грабли. В прошлом году делал там параметризацию документов, их API — сущий ад. Нет чтобы взять открытый формат и дать всем возможность редактировать документы в исходниках.
Я давно работал с word, но только поверхностно, в глубь не лез.
Если мне будет под силу разобрать его - то напишу статью
Микрософт совершила большую ошибку в своё время, что для выбрала закрытый формат.Это для кого ошибка? Чем тяжелее для альтернатив открывать файлы Офиса, тем больше будет куплено Офисов.
Отдельное спасибо авторам таких документов.
docx, xlsx и pptx всегда были открытыми форматами. Закрытыми долгое время были doc, xls и ppt.
Точнее, вот правильная ссылка на стандарт. (Ниже @sumbooody её тоже запостил.)
Так как я занимался рассмотрением и сравнением двух форматов Office Open XML и OpenDocument Format, могу сказать и уверить в том, что в первом случае часть фичь и тем более фунций + дефолтных значений и некоторых стилей - скрыты под капотом. Вроде и есть свободный формат, вроде и есть дока (сущий ад на мой взгляд), но не всё так прозаично как может казаться)
Даже если дока -- сущий ад, это всё же не повод отказывать формату в том, чтобы называться открытым. Язык C++, к примеру, тоже по одному только тексту стандарта изучить или реализовать практически невозможно. А вот если в документации формата отсутствует какая-то конкретная важная информация, то об этом было бы интересно узнать. Именно на максимально конкретных примерах.
Ошибка как раз для Микрософта. Народ использовал другие форматы. Например, мы используем HTML для многих документов. Потому что его сильно проще и быстрее обновить.
И если бы формат офиса был открытым, то продукт типа гугл.докс появился бы сильно раньше, и не только он один. Майкрософт бы такой продукт либо купил либо сам бы сделал. Майкрософт потерял практически этот рынок сейчас. Все перешли на гуглюдокс. Собственно у Майкрософта есть шанс, запустить аналог гуглюдокс, но с простым открытым форматом, который будет легко генерить программно и ручками. Тогда будет смысл перейти всем на этот формат и генерить документы в нём.
LaTeX не должен был допустить появления MSWord-а. На деле сколько-нибудь сложное форматирование в Google Docs сделать невозможно.
Так и не нужно. Сила в простоте. Зачем сложное форматирование, которое потом едет даже в том же Майкрософт Офис?
Мы у нас в компании последние годы используем Гугл.Докс, да и народ вокруг тоже его использует. Для формул LaTex скорее всего лучше. А для обычной офисной жизни и для написания статей, исковых полностью его хватает. Главное в нём очень удобно организована совместная работа.
В таблицах всё же хотелось бы испольовать больше четырёх арифметических действий, но Г.Д даже кубического корня нет.
А Г.Д удобен совместной работой. Мелкомягких на эту тему с 9х годов пинают.
Правда с появлением Google.docs офис почти умер.
Ну да, как же. Оформите мне хоть один документ по ЕСКД (2.105, 2.610) в гугл.доке. Ну такой, чтобы с полями, рамками, колонтитулами.
Если у вас чего-то нет, это не означает, что в остальном мире этого нет, у вас просто выборка не репрезентативная.
То же касается и "специфичности" задачи. Практически любое производство в РФ, которое готовит документацию, сталкивается с проблемой оформления по ЕСКД. И даже не смотря на робкие статьи прикрутить ASCIIDOC к ЕСКД, проще найти человека знающего word, отсыпать ему шаблонов, макросов и отправить работать с миром.
Я уж не говорю про требования заказчиков о предоставлении документов в "редактируемом формате" для передачи в электронный архив и прочие секретности, да NDA'шности.
Мелкому бизнесу и физлицам, по моему мнению, гуглдокс не нужен. Им не нужны плюшки совместного редактирования, им не надо пересылать кипу документов с гуглоаккаунтов. Их устраивает... встроенный в винду офис. Как максимум видел Либре.
На моей памяти из всех клиентов что я обслуживаю, а это более трех сотен фирм - никто не перешел в на гуглодокс, потому что простенькая выгрузка от поставщика на десяток страниц тормозит в браузере безбожно даже на i5. Кроме этого накладывается зависимость от постоянного онлайна, что с ценами на интернет для юрлиц (в моем регионе это сильно дороже чем физикам) убирает с конкурентного рынка гуглодоки вовсе.
А в ВУЗах и всяких министерствах все еще 2003 не могут до конца убрать. вижу это постоянно в рабочей переписке с ведущими вузами страны, по характерным косякам при перегоне docx->doc в возвращенном письме.
Сколько у нас в России производства и сколько у всего остального, где никакого ЕСКД нет. Этого ЕСКД нет в ВУЗах в рабочей документации, в тендерах, в судах.
В судах? Вы серьезно? Как вы предлагаете с гугло-доком соблюдать 152 ФЗ?
Как пользоваться гугло-доком в закрытых периметрах? Как пользоваться гугло-доком там где интернета или нет или он медленный (привет сёлам и всей инфраструктуре между городами).
Я не знаю сколько всего остального, но не видел ни одного предприятия\организации\ИП которое использовало бы гугло-док в продакшене, как основную систему ведения и разработки документации. Энерго-вырабатывающая промышленность, которая на секундочку местами является градообразующим предприятием, вся сидит на офисе - см. кучу тендеров. То же касается нефтянки и всего прочего.
Даже в шутке "Вся мировая экономика держится на Excel", есть доля шутки.
У нас в компании я уже давно не вижу документов в ворде и екселе. Всё в гугле.
Так что можете и вы теперь говорить, что знаете как минимум одну организацию.
Так что можете и вы теперь говорить, что знаете как минимум одну организацию.
Пилите пост, как ваш отдел кадров, бухгалтерия и прочие отделы (уж не знаю сколько их) соблюдают 152ФЗ. Заодно, как протащили все это через безопасников.
Яб с удовольствием почитал.
У меня уже пять лет есть специфичная задача: фабрика мебели шлёт жене пару сотен xlsx, в которых надо поменять ячейку, пересчитать формулы и конвертнуть в pdf. За пять лет вышло немало свежих версий либреофиса и опенофиса, но ни одна из них не может нормально конвертнуть в пдф ячейки с картинками, ну хоть ты тресни. Ну и правка файла в либреофисе портит его для экселя, и картинки остаются такими же кривыми в экспорте в либреофисе. То есть либреофис тупо не вариант. В итоге, учитывая нежелание покупать мс офис ради такой фигни пару раз в год, мое решение свелось к следующему: в яве через apache poi правим ячейки и пересчитываем формулы, потом вызываем скрипт autoit, который запускает ms excel viewer для нужного файла и отправляет его на печать на пдф принтер. Дёшево и сердито, но доступно только тем, кто успел обзавестись ms excel viewer-ом, ибо ms его выпилило, как Канада свой перехватчик Avro Arrow - с концами.
Можно долго рассуждать, что аналоги экселя корректно работают в 99%-ах случаев, но мне вот повезло попасть в не тот процент.
Ещё есть смысл из массы pdf-принтеров попробовать подобрать подходящий, в котором можно будет настроить качество экспорта, т.к. сохранение в pdf необязательно работает оптимальным образом.
Можно увеличить количество используемой памяти и поиграться с настройкой формата и качества изображений.
А МС да, выпиливает все свои полезные плюшки.
В 2000 писал диплом в QuarkXpress. Не было никаких проблем с рамочками, полями, колонтитулами, расползания и шрифтами. Не знаю почему до сих пор все мучаются с MS Wordом. Работает под Windows 3.11 или 95/98. Под NT не проверял.
QuarkXpress это про верстку для печати. Т.е. чтобы картинка на экране 100% соответствовало тому что вылезет из принтера\печатной станции.
Прямой аналог QuarkXpress это Microsoft Publisher
Цена. 470 евро (~40 000\год) за Кварк и 9 000-12 000\год за офис 365. Или ~17к за фиксированную (не подписочную) версию с word, excel, PP и outlook. Выбор очевиден.
Документы можно хоть в Автокаде оформлять, вопрос лишь в том где меньше боли.
Если сравнивать с QuarkXpress, то тогда стоит учитывать и LibreOffice с ценою (без поддержки) ₽0. Но тут же проблема в том, что все вокруг сидят именно на MS.
Не стоит, Кварк это приложение для публикаций (верстка, печать), Word и Writer это текстовые процессоры. Не смотря на кажущуюся одинаковость и, местами пересекающийся функционал, у этих приложений разное назначение.
QuarkXPress is a desktop publishing software for creating & editing complex page layouts in a WYSIWYG
Writer - A word processor with similar functionality and file support to Microsoft Word or WordPerfect. It has extensive WYSIWYG word processing capabilities, but can also be used as a basic text editor.
Правда с появлением Google.docs офис почти умер.
Спасибо за поднятие настроения, поржал с этой фразы.
Вы, судя по нику, разработчик из it-конторы, а во всём остальном мире есть, к примеру, x5 retail, которому надо заполнить таблицу с макросами в excel не ниже 2013. И сотрудники, быстро работающие в google docs (если это вообще возможно), на дороге не валяются.
Всё точно так. В финансовых конторах, включая очень большие, типа JP, у всех предустановлен офис с экселем и дофига кода на VBA (исторически и не очень). А у большинства малого бизнеса в Европе есть умный айтишник на подхвате, который понимает, что трахаться с опенсорсом гораздо проблематичнее, чем установить офис и решать проблемы через поддержку мелко-мягких.
Так что офис живее всех живых, несмотря ни на что.
Вы в каком мире живете?) аналог гуглдокс уже давно существует, и называется office 365 в платных редакциях, и как бесплатные веб-приложения в бесплатном onedrive. Насчёт форматов - начиная с момента внедрения форматов office open xml, генерация файлов документов сильно упростилась, по крайней мере что для php, что для python, что для других языков. А так, смотря что вам нужно при генерации документов, кому-то md достаточно, а кто-то из ворда последнее выжимает и после ищет альтернативы - лично для дипломного проекта матрицы тензорных уравнений писал на LaTEX 17 лет назад, потому как ms equations та еще поделка и падала при малейшем дыхании в ее сторону
WordPad такое умеет. Является частью Windows до сих пор, хотя в 10 и 11 дали возможность его удалять.
У меня Excel как‐то умудрился сохранить файл с большинством формул в локализованном виде. А потом при открытии эти формулы просто выкидывал (правда, не молча, а утверждая, что файл повреждён). LibreOffice при этом ничего не выкидывал, но и формулы не считал. Проблема решилась нахождением последней рабочей версии в СКВ, сравнении текущей с ней в распакованном виде (после LibreOffice мне стало только понятно, что формулы там есть, а не что с ними не так) и делокализацией скриптами на VimL с последующей запаковкой обратно.
И я не помню, чтобы я обновлял в это время Office, или трогал связанные с локализацей настройки.
Забавно, но пару раз (довольно давно) сталкивался со следующей ситуацией:
Excel отказывается открывать последнюю сохранённую копию файла (без объяснения причин);
Открываю файл в OpenOffice или LibreOffice;
Пересохраняю его, как *.xlsx;
Вуаля - Excel открывает файл как родной.
Но главный плюс в том, что формат читаемый, можно руками набирать.
В этом и плюс, и минус. В то время скорость записи на носители данных были очень низкие, и в случае выбора plain text формата вставка фрагмента в начале файла привела бы к необходимости перезаписывать весь файл (несколько мегабайт), что могло занимать минуты. Поэтому они заморочились с бинарным форматом, который позволял при редактировании в середине документа дописывать данные в конце файла.
Микрософт совершила большую ошибку в своё время, что для выбрала закрытый формат.
По-моему здесь же на хабре была статья об экселе, вкратце формат был придуман скорее для быстродействия на тогдашних слабых машинках.
«Формат файлов запутан в нужных местах для ускорения типичных операций. К примеру, у Excel 95 и 97 была функция «простого сохранения», которая использовалась в качестве ускоренного варианта документа OLE, полная версия которого была не слишком быстрой для повсеместного использования. У Word было нечто подобное под названием „быстрое сохранение“. Для быстрого сохранения длинных документов 14 раз из 15 все изменения просто добавлялись в конец файла, а весь файл не перезаписывался с нуля. Для жёстких дисков того времени это означало, что можно было успеть сохранить документ, допустим, за 1 секунду вместо 30. Также это означало, что удалённые части документа всё ещё хранились в файле – а людям, как оказалось, это не было нужно.»
Хорошая статья. Спасибо.
Если вам также будет интересно - напишу статью, как манипулировать с файлами excel посредством PHP/Java/Ruby
На PHP бы посмотрел. Особенно формулы и стили.
Хорошо, я постараюсь написать в скором об этом
Так альтернатив особо и нет - наследник phpexcel
https://phpspreadsheet.readthedocs.io/en/latest/
Проблема только, что реализация в ООП стиле приводит к падению по памяти на не самых больших документах.
Поэтому да, если файлы тяжелые, приходится работать непосредственно с xml
Я сделал так, что все манипуляции и данные записываются в массивы, а в конце перебором записываются в файлы обычным текстом без дополнительных библиотек, типа работы с xml и прочих дополнительных классов. Мне кажется, за счёт этого я сильно ускорил работу и облегчил по использованию памяти этой задачи.
У меня есть 2 класса: в первом записываются данные, во втором - запись xml и архивация .xlsx файла
Возможно, я изобрёл велосипед, но это, прежде всего, опыт и я хорошо разобрался в устройстве excel
Падение по памяти и производительности скрипта можно исправить рефакторингом кода и уменьшением сложности алгоритмов, чем я сейчас занимаюсь
Спс, я в курсе про PHPExcel, но это такой комбайн, а мне любопытна лишь часть его функционала - рендер в PDF (а точнее в картинку). А ещё PhpSpreadsheet рендерит путем сборки html c css, вдруг есть способ пооптимальнее. Для винды с установленным Excel все очень элегантно решается через Win32 API и буфер обмена, вот хотелось бы и под никсы что-нибудь компактное. И, если со стилями что-то можно придумать, то вот что делать с формулами...
У меня самый большой вопрос по Excel - как вести разработку макросов? И я сейчас не про встроенную IDE и Rubberduck, а про методологию.
Вопросы - где макросы хранятся? В каком формате? Можно ли прикрутить к этому нормальную систему контроля версий? Желательно, не используя импорт\экспорт модулей.
Хороший вопрос
В ближайшее время попробую разобраться с этим, и, если тема будет побеждена - напишу об этом
Я что‐то подобное делал для Word. Там макросы хранятся в бинарном файле, имитирующем файловую систему (OLE2), который много кто умеет разбирать, но мало кто умеет создавать. Я в итоге просто решил хранить документ без макросов в распакованном виде в VCS, отдельно там же хранить макросы и скриптом запаковывать файл обратно с последующим добавлением файлов с макросами посредством API Word.
https://www.ecma-international.org/publications-and-standards/standards/ecma-376/. вот официальная документация
Документация на английском - не каждый сможет разобраться, она очень большая и потребуется много времени для поиска нужной информации
Но все равно, спасибо за ссылку, кому-нибудь она точно пригодится
да, с этим согласен. сам в свое время штудировал это все неделями. кстати есть ещё OpenXml productivity tool. она позволяет просматривать содержимое office документов, word , excel, ppt, а также генерирует код, правда на C#. https://github.com/OfficeDev/Open-XML-SDK/releases/tag/v2.5
Спасибо за клад, думаю, мне это поможет в разборе word, и, может, дополнительных аспектах excel, которые я в этой статье не разобрал
На самом деле спецификация довольно понятная и позволяет быстро сделать то, что нужно. Но базовые концепции, типа абзацев, ранов, нумераторов — нужно в голову один раз загрузить.
подскажите, вы планируете делать и поддерживать собственный PhpSpreadsheet?
Есть еще такое "колесо" на PEAR. В свое время выручило. https://pear.php.net/manual/en/package.fileformats.spreadsheet-excel-writer.intro.php
Ну, это уже готовое решение, описание документации. По сути, тот же phpspreadsheet, только работает по своему. Да, такое же колесо, но я решил рассказать не о своей библиотеке, а об устройстве excel.
За ссылку спасибо
Извините, просто обзор "гвоздя", без обзора "молотка", которым гвоздь можно забить мне показался неполным. Вы же начали статью с идеи "разработки библиотеки".
Хотелось бы от вас увидеть аналитический обзор ("молотков") решений для эффективной работы с форматом на каких либо языках, раз уж вы на столько погрузились в данный вопрос.
Возможно это кому-то сохранит время и нервы в дальнейшем.
Стояла такая же проблема на проекте, но сложнее: нужен экспорт в xls и pptx с графиками и куртизанками из проекта на питоне. Готовых решений нет. Пришлось городить библиотеку на C# с OpenXML SDK и подвязывать ее к питону через pythonnet.
OpenXML SDK - та еще сдк, спроектировано по принципу: "одна строка в ХМЛ - одна строка кода на C#", вообщем пришлось знатно намучаться. Но сильно выручали генераторы кода из ХМЛ в C#.
О, да, openXML SDK - это штука, с которой люди встречаются единожды. (Благо, мне пришлось с ней встретиться только в виде документации)
Возможно, эта статья бы помогла избежать этого хотя бы с excel файлом
Тем более в скором я напишу про дополнительные функции excel - графики, фигуры, макросы и прочее. Пока собираю информацию и изучаю
В итоге случайно получилось поменять шрифт, размер шрифта и его начертание для символов нумерации столбцов и строк, причем работало это только в ms excel, страшно представить какие еще там есть недокументированные возможности.
"О сколько нам открытий чудных готовит Office Microsoft".
Пытаюсь делать то же самое на Swift, но постоянно ругается Excel что документ некорректный. Кто-то делал подобное под iOS ?
.xlsx изнутри. Разбор структуры файлов. Разбор каждого .xml файла