Преобразование и сжатие документов в цифрах в случае OpenXML и OpenDocument
В продолжение темы сжатия документов используя новые форматы OOXML и OpenDocument перейду к конкретным цифрам, по возможности, нейтрально по отношению к любому из форматов.
Для начала приведу цифры по преобразованию документов в случае OpenXML — в одном из следующих постов попробую описать ту же процедуру для OpenDocument. Попробую, поскольку создание стенда для OpenDocument сложнее, но возможно.
Для начала как и что проверялось.
Проверялись 4 датасета документов из архива Енота Поискуна:
- 318 документов OpenDocument (.odt) — 14 482 368 байт
- 620 документов OOXML (.docx и .xlsx) — 24 451 860 байт
- 419 документов MS Office 2000/XP/2003 (.doc, .xls) — 58 669 568 байт
- 39 документов MS Powerpoint 2000/XP/2003 (.ppt) — 74 423 296 байт
Датасеты не подбирались специально, был просто общий архив документов, а далее документы разного типа были сгруппированы. Отдельно отмечу что архив документов не синтетический, а такой какими документы встречаются в «дикой природе», в данном случае размещаются госзаказчиками на сайтах закупок.
Причем с датасетами проверялось следующее:
- для документов OOXML и OpenDocument проверялась пригодность для «дожатия» документов. Техника которую я ранее описывал в заметке практическое сжатие электронных документов.
- для документов MS Office проверялось их сжатие после преобразование в OpenXML с последующим «дожатием».
Проверка «дожатия» документов
Дожатие документов проводилось по принципу пережатия ZIP контейнера улучшенным deflate алгоритмом (см. статью выше) и пережатием изображений в документах алгоритмами без потери качества.
Для датасета документов OpenDocument документы были дожаты до совокупного объёма в 12 364 803 байт или, иначе, до 85,37% от начального объёма.
Для датасета документов OOXML документы были дожаты до совокупного объёма в 17 113 886 байт или, иначе, до 70% от начального объёма.
Итого можно заметить что документы OOXML сжимаются лучше. Но это не единственное что их отличает, кроме того документы OOXML в среднем меньше чем документы OpenDocument.
Для датасета OpenDocument средний размер документа равен: 14 482 368 / 318 = 45 562 байт до дожатия и 12 364 803 / 318 =38 883 байт после дожатия.
Для датасета OOXML средний размер документа дожатия равен: 24 451 860 / 620 = 39 438 байт до дожатия и 17 113 886 /620 = 27 603 байт после дожатия.
Разница между двумя форматами почти на треть так что я решил покопаться в причинах этого чуть по глубже. Чтобы понять это надо заглянуть в не только в форматы файлов, но и в то как с ними работают прикладные программы.
В чем особенность, например, формата OpenDocument и работы OpenOffice?
Если распаковать любой ODT документ и заглянуть в его внутренности то там можно обнаружить:
- папку Thumbnails содержащую файл thumbnail.png размером от 900 байт до 10 000 байт, в среднем же около 5400 байт
- папку Configurations2 содержащую ряд (обычно) пустых поддиректорий и конфигурацию OpenOffice
- файл двоичный файл layout-cache размером от 18 до 881 байта (по тем данным что есть) или, в среднем, 121 байт
- а также перечисление всех этих файлов в файле META-INF/manifest.xml
Обо всей этой информации можно сказать с уверенностью лишь одно — к содержанию документа она отношения не имеет. Это «полезный мусор» и некоторые удобства при работе в виде thumbnail’а, но не более.
Проверять вычистку ODT документов автоматически задача довольно трудоёмкая, поэтому произвольным образом была сделана проверка «дожатия» на примере одного документа размером в 30 836 байт в оригинальном виде и в 30 328 байт в «дожатом виде» (пережат контейнер и картинки). В итоге после удаления Thumbnails, Configurations2, layout-cache и чистки манифеста файла, и последующего сжатия в контейнер размер документа составил 18 007 байт, или 58% от оригинального файла. Что гораздо лучше чем просто сжатие документов OpenDocument и лучше даже чем сжатие OOXML. Итого, за счёт ряда ухищрений и доработки OpenOffice, в том что касается долгосрочного хранения докуменов и небольшого их объёма OpenDocument не уступит OOXML.
Сжатие докуметов MS Office преобразованием в OpenXML
Впрочем задача дожимать документы возникает сравнительно редко, чаще возникает вопрос выигрыша при переводе документов из устаревших форматов в новые. Но инструментов преобразования документов немного — фактически для перевода офисных документов в OpenDocument мало вариантов кроме как воспользоваться API OpenOffice, а для перевода документов в OOXML есть варианты в виде API MS Office и B2XTranslator (http://b2xtranslator.sourceforge.net/) — бесплатный движок на работающий на .NET и Mono.
В данном случае тестирование проводилось именно с помощью B2xtranslator которые более чем другие способы заточен под потоковое преобразование документов.
С его помощью два датасета — датасет документов MS Office (.doc, .xls) и датасет презентаций MS Powerpoint были преобразованы в формат OpenXML, а далее уже имеющимся у меня движком «дожаты» в части ZIP контейнера и изображений.
В итоге получились следующие результаты.
Преобразованием в OpenXML датасет документов MS Office (.doc, .xls) был уменьшен до 16,78% от начального объёма (от 58 669 568 байт до 9 848 436 байт), а то есть в 6 раз.
После дожатия документов их объём составил 9 401 414 байт или 16,02%. Можно обратить внимание что дожатие документов принесло всего около 0,76% выигрыша объёма и связано это с несколькими факторами:
- файлы .doc и .xls из выборки почти не содержали изображений
- b2xtranslator использует более эффективный Deflate алгоритм для создания ZIP файлов и дожатие помогает несильно.
Преобразованием в OpenXML датасет презентаций MS Powerpoint был уменьшен до 84% от начального объёма (от 74 423 296 байт до 62 634 326 байт), а то есть на 15%.
После дожатия документов их объём составил 55 137 124 байт или 74%.
В данном случае можно увидеть что презентации при преобразовании изначально значительно меньше сжимаются в объёме, но гораздо лучше дожимаются в основном из-за рекомпрессии изображений которые и составляют основной их объём.
При этом, сжатие презентаций может быть существенно улучшено при использовании дожатия с потерями, например, преобразованием векторной графики и внедренных OLE объектов картинок Adobe Photoshop и Corel Draw в растровые изображения.
Неохваченное и нюансы
1. Неохваченным осталось преобразование документов из форматов MS Office в OpenDocument, но для того чтобы его организовать на поток надо соответствующим образом собирать стенд с OpenOffice’ом. Если кто-нибудь хочет это проделать самостоятельно — могу передать все вышеперечисленные датасеты для экспериментов.
2. b2xtranslator всё ещё ОЧЕНЬ сырой продукт. Несмотря на то что разработчики в нём очень оперативно реагируют на каждый отправленный им баг (а я им отправил уже с 5 штук), тем не менее в некоторых случаях он производит нечитаемые OpenXML документы, а в некоторых просто виснет.
3. Преобразование документов, разумеется, фатально с точки зрения эталонности документов, наличия у них ЭЦП и так далее. Преобразованный документ по объёму существенно отличается от оригинала.
Зачем всё это нужно?
Когда файлов сравнительно немного, то их сжатие и преобразование нужно нечасто. Чаще всего уменьшить размер презентации чтобы отправить по почте или же уменьшить размеры документов когда сайт хостится на платном хостинге и дешевле пережать документы за сутки чем докупать лишнее дисковое пространство и каждый месяц за него платить.
В моём случае вопрос упирается в то что документов накопилось уже несколько сотен тысяч и в общей совокупности это более 48 гигабайт.
С одной стороны это немного, но с другой стороны когда для хранения документов используется Amazon S3, это оказывается более чем актуально.
Поделиться в соц. сетях
Microsoft Translate
Рубрики
- BI (3)
- CEP (1)
- IBM (13)
- Novell (6)
- WTF (1)
- apple (3)
- blogging (61)
- couchdb (3)
- data.gov.ru (250)
- datasets (104)
- diagramming (11)
- e-Government (927)
- eGov (946)
- google (33)
- gtd (5)
- links (65)
- linux (19)
- microsoft (47)
- not so wtf yet (3)
- opengovdata.ru (198)
- opensource (56)
- productivity (2)
- saas (4)
- second life (2)
- security (6)
- semweb (15)
- sun (13)
- virtualization (16)
- vista (2)
- web (223)
- web 2.0 (108)
- wikileaks (1)
- yahoo (11)
- Без рубрики (4)
- Енот Поискун (17)
- Общественное благо (12)
- алгоритмы (73)
- алгоритмы (51)
- аналитика (19)
- антисео (5)
- бывает и такое (8)
- виртуализация (21)
- вопросы (20)
- госзаказ (172)
- идеи (29)
- из жизни (95)
- инновации (27)
- интересные проекты (7)
- информация (108)
- книги (2)
- метапост (1)
- открытое государство (51)
- открытые данные (10)
- поиск (93)
- почти несерьёзно (16)
- размышления (127)
- расшифровка реальности (10)
- робототехника (1)
- руководство проектами (3)
- скиур (19)
- социальные сети (45)
- социоранк (9)
- стандарты (22)
- стоит почитать (21)
- футуристика (1)
- электронное государство (945)
- юзабилити (25)
- юмор (14)
Метки
антиспам госзакупки гослюди госуслуги датасеты дебаты извлечение информации инновации кузьминов метаданные навальный открытое государство открытые данные поиск почти без иронии публичность раскрытие информации расшифровка реальности систематизация социоранг социоранк стартапы форматы файлов футуристика #belyh #rucamp #socamp 94-ФЗ antispam apps4russia icamp icamp2009 md5 ogp open government searchme semweb sha1 ssl usability






