Жил-был на свете один перевод (как процесс, а не как результат). Существовал он таким образом: из pdf-ки с оригинальным текстом вырезались кусочки, вставлялись прямо в Word и снизу посредством значительных мысленных усилий появлялся русский текст, и, как правило, пара-другая сносок. А если в оригинале были сноски, то в сносках тоже появлялись картинки. Перевод шёл, и файл разрастался — в 16-страничном файле было 51 изображение, и Word стал работать так медленно, что перевод никак не мог стать результатом.
Встроенная функция компрессии изображений почему-то совсем не помогала, поэтому было решено произвести вмешательство хирургическим путём.
Файл выглядит вот так (узкие колонки — не текст, а картинки):
![](https://habrastorage.org/r/w1560/storage2/8fa/8e1/b4b/8fa8e1b4b917a0278997a203733c2ded.png)
Во внутренности doc-файла залезть тоже можно, но гораздо проще сделать это в .docx. Пересохраняем. Видим, что само по себе пересохранение ничего не дало — как весил файл 12 мегабайт, так и весит.
![](https://habrastorage.org/r/w1560/storage2/96d/7f4/6f6/96d7f46f617aee2832694271618a57aa.png)
Как известно, .docx-файл представляет собой zip-архив с особой внутренней структурой — поэтому без всякого труда заглянуть ему в кишки, а там…
![](https://habrastorage.org/r/w1560/storage2/9ee/853/8a9/9ee8538a9d249aab6cb3778a78d24923.png)
в распакованном виде директория
Конечно, главный виновник — изображения, каждое из которых занимает порядка десяти мегабайт:
![](https://habrastorage.org/r/w1560/storage2/172/268/4a5/1722684a5424a8bd34a54d3b1a190478.png)
Интересно, почему явно растровые изображения Word хранит в EMF — векторном формате? Вероятно, этому есть какое-то глубинное объяснение, которое будет задействовать аргумент о PDF-источнике («ведь PDF — тоже векторный формат!»), но сейчас нас волнует не это. Чтобы не заморчиваться редактированием файла document.xml при изменении формата рисунков, мы ограничимся всего лишь уменьшением их размера. К счастью, IrfanView среди всех прочих полезных функций умеет писать EMF (Photoshop, например, не умеет из коробки). А ещё он может уменьшать изображения пачками — этой функцией мы и воспользуемся. 800 пикселов по длинной стороне вполне достаточно.
![](https://habrastorage.org/r/w1560/storage2/d76/d19/9eb/d76d199ebb3891e182271bae30c009dc.png)
(на картинке сверху справа виден фрагмент буквы g — и это ещё уменьшенная по ширине экрана оригинальная версия).
После этого можно запаковать обратно изменённые файлы — весить они будут значительно меньше (в 15 раз):
.
Word совершенно спокойно съел этот файл. Правда, при сохранении обратно в .doc он несколько потолстел, но всё же совсем не настолько:
![](https://habrastorage.org/r/w1560/storage2/8cb/51e/142/8cb51e1428a9f76387ed45fe58904ab7.png)
Итого: файл сжат в 6,5 раз без уменьшения видимого качества (для печати файл не предназначен, но даже и в этом случае выглядел бы он неплохо), процесс перевода пошёл гораздо быстрее (и с меньшим количеством ругательств), а дома стало несколько спокойнее, что, без сомнения, является главным достижением.
UPD:
Обсуждение в комментариях, по какой именно причине Word вставляет рисунки в EMF
Встроенная функция компрессии изображений почему-то совсем не помогала, поэтому было решено произвести вмешательство хирургическим путём.
Файл выглядит вот так (узкие колонки — не текст, а картинки):
![](https://habrastorage.org/storage2/8fa/8e1/b4b/8fa8e1b4b917a0278997a203733c2ded.png)
Во внутренности doc-файла залезть тоже можно, но гораздо проще сделать это в .docx. Пересохраняем. Видим, что само по себе пересохранение ничего не дало — как весил файл 12 мегабайт, так и весит.
![](https://habrastorage.org/storage2/96d/7f4/6f6/96d7f46f617aee2832694271618a57aa.png)
Как известно, .docx-файл представляет собой zip-архив с особой внутренней структурой — поэтому без всякого труда заглянуть ему в кишки, а там…
![](https://habrastorage.org/storage2/9ee/853/8a9/9ee8538a9d249aab6cb3778a78d24923.png)
в распакованном виде директория
word
весила бы почти семьсот мегабайт! Неудивительно, что Word отказывается работать…Конечно, главный виновник — изображения, каждое из которых занимает порядка десяти мегабайт:
![](https://habrastorage.org/storage2/172/268/4a5/1722684a5424a8bd34a54d3b1a190478.png)
Интересно, почему явно растровые изображения Word хранит в EMF — векторном формате? Вероятно, этому есть какое-то глубинное объяснение, которое будет задействовать аргумент о PDF-источнике («ведь PDF — тоже векторный формат!»), но сейчас нас волнует не это. Чтобы не заморчиваться редактированием файла document.xml при изменении формата рисунков, мы ограничимся всего лишь уменьшением их размера. К счастью, IrfanView среди всех прочих полезных функций умеет писать EMF (Photoshop, например, не умеет из коробки). А ещё он может уменьшать изображения пачками — этой функцией мы и воспользуемся. 800 пикселов по длинной стороне вполне достаточно.
![](https://habrastorage.org/storage2/d76/d19/9eb/d76d199ebb3891e182271bae30c009dc.png)
(на картинке сверху справа виден фрагмент буквы g — и это ещё уменьшенная по ширине экрана оригинальная версия).
После этого можно запаковать обратно изменённые файлы — весить они будут значительно меньше (в 15 раз):
![](https://habrastorage.org/storage2/c73/38f/72a/c7338f72a5b94d7afc30f324542a2b67.png)
Word совершенно спокойно съел этот файл. Правда, при сохранении обратно в .doc он несколько потолстел, но всё же совсем не настолько:
![](https://habrastorage.org/storage2/8cb/51e/142/8cb51e1428a9f76387ed45fe58904ab7.png)
Итого: файл сжат в 6,5 раз без уменьшения видимого качества (для печати файл не предназначен, но даже и в этом случае выглядел бы он неплохо), процесс перевода пошёл гораздо быстрее (и с меньшим количеством ругательств), а дома стало несколько спокойнее, что, без сомнения, является главным достижением.
UPD:
Обсуждение в комментариях, по какой именно причине Word вставляет рисунки в EMF