Какво реално се случва, когато компресирате PDF
PDF123 Compress прекомпресира потоци и пакетира обекти с qpdf, но не намалява разделителната способност на изображенията, не прекодира растра в JPEG със загуби и не прави подмножество на шрифтовете. Линеаризацията почти не променя размера на файла.
Два PDF файла могат да изглеждат еднакво на екрана и да се различават с три порядъка: 50 KB срещу 50 MB. Разликата почти никога не е в текстовите оператори. В договор от двадесет страници тези оператори обикновено заемат няколко десетки килобайта, а всичко останало са извадки от изображения, изцяло вграден шрифт и степента, до която потоците и обектите са сбити.
Оттук следва извод, който си струва да се каже веднага: „компресията на PDF“ не е едно действие, а четири. Те свиват различни неща и имат различна цена, а ако се смесят в едно, опитът излиза противоречив: файлът е компресиран, но не е намалял, или е намалял, но страниците са замъглени.
Размерът идва от изображенията, шрифтовете и опаковането
Повечето случаи на „защо този PDF е толкова голям?“ започват със сканиране или снимка с висока разделителна способност, вградени в първоначалния си размер. Сметката си струва да се направи веднъж: страница с формат Letter 8,5 × 11 инча при 300 DPI е около 2550 × 3300 пиксела, а при три байта на пиксел това е приблизително 25 MB без компресия. Двадесет такива страници често достигат 60–80 MB, преди някой изобщо да се заеме с компресия.
Вторият източник са шрифтовете. PDF може да вгради цяла шрифтова програма, така че текстът да се изобразява еднакво на всяка машина, а цената се определя от размера на таблиците с глифове, не от това колко текст реално се чете. Затова подмножеството на шрифтовете е отделен лост за размера.
Третият е самото опаковане. Едно и също съдържание може да се съхранява с разточителни настройки за компресия, а обектите му да са разпръснати из файла, всеки със собствени служебни разходи. Това не променя нито един пиксел или глиф и точно до тази част достига прекомпресията на потоците.
„Компресията“ е четири различни лоста
Върху размера действат четири лоста; те работят на различни нива, а цената им почти не се припокрива. Изборът на грешния е най-честата причина компресията да изглежда, че не прави нищо.
| Лост | Какво засяга | Печалба в размер | Цена |
|---|---|---|---|
| Прекомпресия на потоци и обектни потоци | Как са компресирани потоците със съдържание, как се съхраняват и пакетират обектите | Зависи колко разхлабен е бил оригиналът | Изгледът на страниците не се променя |
| Намаляване на разделителната способност | Броят пиксели, тоест разделителната способност | Голяма | Разделителната способност намалява безвъзвратно |
| Прекодиране на изображения със загуби | Байтовото представяне на растра | Голяма | Качеството на изображението намалява |
| Подмножество на шрифтовете | Вградените таблици с глифове | Умерена | Неизползваните глифове вече не са редактируеми |
| Линеаризация | Редът на обектите | Почти нулева | В замяна дава време за зареждане на първата страница |
Първите четири реда се наричат „компресия“ общо, но само първият не пипа съдържанието. При него пък най-лесно се подценява ефектът: при сканиране, чийто размер е предимно сурови извадки от изображението, той почти няма какво да премахне, а значително биха го свили намаляването на разделителната способност и прекодирането със загуби, с цената на безвъзвратно изгубена разделителна способност и качество.
Кой от четирите лоста използва PDF123 Compress
Компресиране на PDF (POST /api/v1/misc/compress-pdf) прави само първия ред. Той изпълнява qpdf с компресия на некомпресираните потоци (--compress-streams=y), втори проход върху вече компресираните с Flate потоци (--recompress-flate) и пакетиране на обектите в обектни потоци (--object-streams=generate).
Той не намалява разделителната способност на изображенията, не прекодира растера към JPEG с по-ниско качество и не прави подмножество на шрифтовете. Страниците трябва да изглеждат също, а икономията идва от прекомпресията с Flate и пакетирането на обекти.
Условието за провал заслужава същата яснота. Когато размерът на файла е предимно вече компресирани JPEG данни, Flate няма какво да свие, защото тези байтове стоят извън обхвата на трите ключа по-горе. Затова пакет от сканирания може да се върне само с няколко процента по-малък, докато PDF с предимно текст и подобен размер печели забележимо повече.
Обратният път е Декомпресиране на PDF: той разгъва потоците за преглед (--qdf, обектните потоци са изключени) и също не променя изгледа на страниците.
Кога е нужен друг път, а не Compress
| Какво ви трябва | Кой път да изберете |
|---|---|
| Идентичен изглед, само премахване на разходите по опаковането | Compress |
| Пакет от сканирания е наистина твърде голям и загубата на качество е приемлива | Намаляване на разделителната способност или прекодиране със загуби, но не този Compress |
| Трябва да остане редактируем, но следващият символ не се изписва | Други настройки за експорт или изходен файл, вижте подмножество на шрифтовете |
| Браузърът трябва да види първата страница по-рано | Линеаризацията решава първото изчертаване, не размера |
| Файлът изобщо не се отваря | Repair, това е структурен проблем, а не проблем с размера |
В последния ред има капан: Линеаризиране на PDF тук не е отделна реализация, а псевдоним на Compress. Двете сочат към една и съща операция, каноничният id е misc/compress-pdf, а linearize-pdf е само псевдоним; порталът за този инструмент винаги изпраща linearize=true и optimizeLevel=1, сървърът не чете нито едно от двете полета, а на qpdf никога не се подава --linearize. Операцията, която наистина линеаризира файла, е Protect, когато го криптира.
Така че ако искате същия изглед в по-малък файл, Compress е целият отговор. Ако искате свиване на изображения със загуби или подмножество на шрифтовете, този път не е правилният лост. Файлът се връща веднага, без акаунт. А за да видите къде всъщност живеят обектите, потоците и таблицата с кръстосани препратки, продължете с Какво има вътре в PDF.