PDF fájl optimalizálása [megoldva]

Szkriptek: Python, Perl, Bash, ...

Sziasztok.

Nagy méretű PDF optimalizálását szeretném megvalósítani, vagyis a nem használt elemeket törölni, a szürkeárnyalatos és fekete-fehér képeket 150-300 DPI-ben maximalizálni.
Külön kérdésem az, miként lehet parancssorban megoldani azt, hogy a képek
zip, jpeg vagy jbig2, esetleg ccitt-group4 tömörítést kapjanak.

Alapötletként meghagytam a képek eredeti felbontását szerkesztéskor, hogy eps-ként történő beillesztéskor még tudjam szabadon változtatni a képméretet túlzott jelveszteség nélkül. Miután rendesen kitaláltam a körbevágásokat és a méreteket, a pdf elkészült... Szép nagy lett, alig 200 MB úgy 30 helyett.

A cél nyomdakész pdf előállítása, a képminőségek megtartásával -- lehetőleg mindet vektorosan hagyva (vagyis jpeg tömörítés hanyagolva, ha jól érzem).
(A win és mac megoldásokat hanyagolnám.)

  • 658 megtekintés

( blr v | 2022. 02. 08., k – 17:17 )

A nyomdának nem mindegy, hogy mekkora?

Már miért kapna hülyét? 200 megás pdf nem nagy, főleg, ha valami nagyobb kiadvány, könyv, vagy sok oldalas anyag. Igazából 1 gigáig nem necces. Nehogy azt hidd ám, hogy a kínaiak elmaradottak. Ezt lehetne hinni a sok dzsunka szemétből, amit globálisan kiexportálnak, de igazából tudnak azok rendes technológiát is használni és gyártani, szerintem meglepődnél, hogy mennyivel egy magyar nyomda előtt járnak. De tegyük fel, hogy legrosszabb esetben hülyét kapnak, akkor én nem bíznék rájuk semmit, ha 2022-ben nem tudnak egy 200 megás anyagot kezelni.

Ennek ellenére, ha ez téged zavar, akkor ezt nem utólag kell a pdf-en optimalizálni, hanem megnézni milyen programmal állítod elő, az milyen pdf drivert használ, Ghostscript vagy dvipdf, esetleg kutyafüle, és ez utóbbiban kell beállítani, hogy a képeket jpg-ben tömörítse, a szöveget meg LZxx-szel nyomja össze, így optimalizálva méretre.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( numen v | 2022. 02. 08., k – 18:28 )

Meglesheted a ghostscriptet - a PDFSETTINGS-ben beállított presetet további opciókkal lehet finomhangolni:

gs -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -dCompatibilityLevel=1.5 -dNOPAUSE -dQUIET -dBATCH -sOutputFile=compressed.pdf orig.pdf

Szerintem minden opciót értelmez, amit a ps2pdf: https://web.mit.edu/ghostscript/www/Ps2pdf.htm#Options

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Aszem' ez működik. Még nem értem, a ghostscript összes paraméterezését, azt nekem folyamatosan kell tanulgatnom...
Most végre minden vektoros alkatrész megmaradt vektorosan, a raszteresek minősége sem romlott az aktuális méretre zsugorítva.
Köszi!

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

( batyu v | 2022. 02. 08., k – 20:37 )

150-300 dpi vs a cél nyomdakész pdf, itt azért van ellentmondás, nem is kicsi. Hacsak nem valami napilap szintű nyomat lesz, akkor minimum a 300, de inkább a 600 dpi. Igényes fotókhoz meg még több.

A képeket amennyiben bitképek, nyugodtan tömörítheted jpeg-be, bár ha CMYK színterűek, akkor az ilyen jpeg nem lesz igazán szabványos - igaz ma már kb minden valamire való nyomda tudja kezelni. Biztosabb (és talán elegánsabb is) lzw tiff-be rakni ha CMYK - igaz, ez kicsit nagyobb lesz, kb mint a 100%-os minőségű jpeg.

Kérdés, hogy mitől lett ilyen nagy a doksi? A vektorgrafikák és a fontok nem szoktak túl sokat foglalni, de ha teleraktad beágyazott bitképekkel, pláne ha a láthatónál nagyobb, maszkolt/vágott képekkel, akkor az okozhat gondot. Illetve simán lehet olyan is, hogy pdf generálásnál sikerült raszterizálni a vektoros komponenseket is, ez hiba, hacsak nincs rá nyomós ok. Mivel, hogyan készült?

A képek rajzok, nem fotók. Inkább amolyan fotóról készített illusztrációk.

Ennek oka van:

3 x 5 centis fekete-fehér fotókon semmi sem látszik, eltűnnek a részletek, nagyítóval kéne nézni. ezért azt a taktikát vettem fel, hogy fotó alapján elkészítettem néhány száz képet kézi rajzzal, majd próbanyomtatások után megállapítottam, szemüveg nélkül melyek azonnal felismerhetők és melyek nem. Ezután próbáltam megítélni, hogy a nagyfelbontású fotóból hogyan alkotom újra a képet illusztrációnak. Röviden ennyi...

CMYK majd a színes lapok fotóihoz kell, de előtte egy monitorkalibrálást is megejtek, vagy inkább ráhagyom egy fotóstúdióra azokat. (Elegem van már...)

A doksi attól lett ilyen jó nagy, hogy a néhány száz grafikámat eps-sé konvertálva kvázi vektorképként toltam a pdf-be. Valódi vektorizálást nem mertem megvalósítani, azzal nagyon elbarmolnám a képet. Az eps grafika a jpeg helyett a latex fordító miatt kellett, attól nem térek el.

Vektoros objektumokat a pdf generálásakor sosem raszterizáltam, az valódi gány lenne. Kérdésedre válaszolva 2020-as Texlive-val készült minden, latex fordítóval (és dvipdf-fel.)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

grafikámat eps-sé konvertálva kvázi vektorképként toltam a pdf-be

Ez ebben a formában hibás, kvázi eps-ként toltad be, a postscript önmagában egy leíró nyelv, ami képes többek között vektoros grafikát is leírni, de emellett képes bitképek beágyazására is. Amikor előállítottad ezeket a bitképes eps-eket, akkor eléggé megnőhettek a méretek attól függően, hogy miképp, milyen formátumba csomagolta át a raszter adatokat. Mivel, hogyan állítottad elő az eps-eket? Ide kapcsolódik, hogy a végső CMYK kimenet előállításakor majd nagyon nem lesz mindegy, hogy mit adsz oda a LaTeXnek. Nem lehetetlen imagemagick-el jól előállítani (bár igényel némi feketemágiát is emlékeim szerint :)), de pl a gimp eps exportja nem ide való.
A vektor raszterizálás önmagában nem gány ha oka van, csak kerülendő. Oka lehet pl hogy ha a vektoros grafika tartalmaz átlátszóságot, a szerkesztésére már nincs mód, a nyomda pedig átlátszóság nélküli, pl pdf X1a-t kér.

Azt nem tudom, hogy a LaTeX most hol tart a valódi nyomdakész színes PDF-ek generálásával, de tartok tőle, hogy ezzel lesz még gondod. Nekem elég sok időm elment arra is anno, hogy linuxon összerakjak egy olyan workflow-t ami átmegy a nyomdák preflight-jain és ebből nekem a latex ki kellett hogy maradjon - nem az alkalmatlansága miatt, addig nem volt türelmem vesződni vele, hogy azt megállapítsam vagy cáfoljam. Pár kiadvánnyal nekifutottam, de hamar rá kellett jönnöm, hogy nem értek hozzá eléggé ahhoz hogy belátható időn belül megoldjam vele a feladatot. Aztán persze utólag lehet, hogy mással sem ment olyan gyorsan :)

Szerk: Közben eszembe jutott, hogy az eps mindenképpen sokkal nagyobb lesz mint a kiindulási kép, mivel kódolva, karakterként kerül bele az adat, nem binárisként.

A bitképes grafikákat az imagemagick parancssori convert-je állította elő, nem paramétereztem. Ha igényesen akartam volna raszterből vektorképet előállítani, azt kézivezérelt inkscape alatt valósítottam volna meg (van ott erre egy remek algoritmus).

Az ábrák szürkeárnyalatúak, CMYK nem kell hozzá. A layeres képkezelést Texlive-on már xetex fordítóval oldom meg mondjuk könyvborítónál. Ott használok cmyk-t.
Az imagemagick convertje alapból persze tiltja az eps és pdf konverziót a Mint repóiból telepítve (miért, nemtom), de az /etc/-ben eme tiltást meg lehet szüntetni.

A Texlive alatt még nem volt olyan, amit ne tudtam volna megcsinálni. Néha azonban egyetemi docens is segített, ami felemelő, főleg, hogy tisztában kezdek lenni belemélyedésem fokáról.

(az eps persze, hogy nagyobb lesz minden esetben. Ha már bezier-adatokat tárol, főleg.)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Ebben az esetben nem bezier adatokat tárol. Ki lehet belőle nyerni az eredeti bitképet, annak az adattartalmát tárolja csak karakteresen kódolva. Akárcsak a pdf, csak az már streamként, és kompaktabb kódolással pakolja be a képeket. Ha belenézel egy ilyen eps-be szövegszerkesztővel, valahol viszonylag az elején van egy %%BeginData ha jól emlékszem ami után ott is van a kódolt képadat.

Ebben én nem vagyok teljesen biztos. De teszek majd egy próbát ha lesz időm, csinálok egy pdf-et ugyanabból a képből scribussal beágyazva, meg kép->eps->LaTeX->dvipdf úton, kíváncsi leszek. Nekem úgy rémlik, hogy az eps-t be lehet ágyazni pdf-be interpretálás-feldolgozás nélkül, de lehet, hogy nem jól emlékszem.

Ilyen fájlokkal dolgozom:

  1. http://seakayakargo.com/konyv/hup/2016-07-08-rajz.jpg
  2. http://seakayakargo.com/konyv/hup/2016-07-08.eps

Ezeket az

\includegraphics[width=0.5\columnwidth,height=20ex]{kep-neve-ide}

parancs szúrja be B5-ös lapmérethez igazítva (lásd: 0.5\columnwidth).

A rajzot egy gimp és egy krita alakította, meg a digitális táblám. (Szapulták már grafikusok, de nekem elmegy. Van ilyenből vagy 170, és mindet bezsúfolom...)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Mert a fotómasinám eleve jpeg-tömörítéssel tolta a képet.
Amúgy tif lenne -- ha rendelkeznék tükörreflexes kamerával.

Színes képek ilyen kis méretben nem néznek ki jól, még akkor sem, ha rendesen négyszínfelbontással megy.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Értem, de a fekete-fehéreket miért RGB JPEG-be mentetted, amit aztán egy szál grayscale fotót tartalmazó EPS-sé konvertálsz? Miért nem pl. grayscale TIFF-be, amit tud a Krita is, nem veszteséges tömörítés, és remélhetőleg a LaTeX-nek sem okoz gondot.

Kb. 20 évvel ezelőtt hallottam egy előadást, ahol már Evil Postscipt Stuff névvel illették az EPS-t, és mélységesen egyet is tudok vele érteni. Pixeles képekre a TIFF elég régi szabvány, vektorosra RGB esetén ott az SVG, ha nyomdai anyagot akarsz, akkor PDF. PDF-be lehet PDF-et illeszteni újraértelmezés nélkül, tehát elvileg bármilyen PDF-kimenetet előállító kódban illenék benne lennie, opensource világban ilyesmi machinációkra pl. pont ott a GS.

Az EPS mint formátum ezer sebből vérzik a mai világban (na jó, 30 éve is, csak akkor nem nagyon volt más).

Semmi köze a dolognak az upgade-ekhez.
A Texlive mindig a legfrissebb csomagokat tartalmazza, a rendszerhez járó fordítók fejlesztése azonban több szálon folyik -- és egymással sokszor nem kompatibilisek.
a fordítók mindegyikét más célra kell használni és kész.
(Amúgy már megoldódott a tárgyban felvetett probléma)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Nem dolgozol latex fordítóval (ezt tudom egy ideje) -- de EPS fájlokkal sem. PS-sel végképp nem.

Eredeti kérdésem másról szólt, nem akarom ezt a szálat feleslegesen túltolni.

Amúgy a hozzászólásodban látszik, hogy nem olvastad, amit fentebb írtam: a konverzió kétféle lehet: egy ún. beágyazott, amikor az eps raszteres képet tartalmaz -- ezt csinálja az imagemagick convert programja, vagy alapból a gimp. A másik lehetőség az nkscape egyik algoritmusa, amikor valóban megtörténik a vektorizálás. Jó nagy lesz a file, kisebb torzulások is előfordulhatnak, ezt hanyagoltam. Kicsinyítéskor az eredmény a nyomdának megfelelne.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

de EPS fájlokkal sem. PS-sel végképp nem.

Kb. 30 éve írtam az első Postscript kódomat, de te biztosan jobban tudod, mihez értek.

nem olvastad, amit fentebb írtam

De, olvastam. A kérdésem nem arra vonatkozott, hogy miért pixelesen hagytad (ilyen képet automatán nem lehet szépen vektorizálni), hanem, hogy a színes kép → szürkeárnyalatos „rajz” eredményét miért egy RGB JPEG-be mentetted.

A hozzászólásaid alapján félreértesz.

Nem azt írtam, hogy 30 éve exportáltam először PS kódot valamiből, hanem azt, hogy kb. akkor írtam az első kódjaimat PS-ben (és lassan 20 éve utoljára, mert a PDF világában nem sok létjogosultsága van a natív PS kódnak egy nyomtatón kívül – lassan ott sem).

Én ezt a két parancsot futtattam, és jelentősen csökkent a képek mérete.

 eps2eps 2016-07-08.eps 2016-07-08out.eps 
 epstopdf 2016-07-08out.eps 

Méretek bájtban:

7882205 2016-07-08.eps
2549419 2016-07-08out.eps
 682000 2016-07-08out.pdf

Nem tudom, hogy a minőség elég jó-e. Szemrevételezéssel nem látok romlást.
 

Ja, ez meg a másik, hogy ha nyomda, akkor nem kis felbontásban fognak nyomtatni. Plusz mindegy mennyire optimalizálja ki a kolléga a fájlt, akár csak 5 megásra 200-ról, amikor a nyomdagép a legvégén nyomja kifelé, akkor mindenképp kitömörít mindent memóriába, mert ugye tömörített anyagot nem tud semmi nyomtatni. Már pedig egy min. 600 dpi-s sok száz oldalas anyag mindenképp sok gigás méretre fog rúgni nyers formában, ahogy a gép nyomja, akkor is, ha 1 megásra lett csodatömörítve.

Az ilyen pdf méretoptimalizálásnak utoljára a kora 2000-es években volt értelme, mikor még nem mindenkinek volt szélessávú nete, meg gyengébbek voltak a hardverek. Mostanra már csak annyi haszna van, ha valaki ECDL Mancika szintű usernek e-mailben kell áttolni mellékletként, mert a túl nagy mellékletet a legtöbb mailserver eldobja.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Meg fogja kapni a nyomda háromféle verzióban.

Egyik a legnagyobb fájlméret, amiben minden beágyazott kép tömörítés nélkül lesz a latex által kitolva.

Másik az, amikor ezt az egészet utólag optimalizálom.

Harmadik egy olyan módszer, amikor a latex a képeket pdf-ként kapja meg, amiben a képek eleve tömörítve vannak. (Ezt állítom elő a leggyorsabban.)

Az, hogy a rajzolt képnem még melyik konverzióját fogom választani, még kérdéses, egyeztetés után majd eldől. a kínai nyomdák verik az európaiakat, a papírárak szintén. Csak a szállítás árát nyomták kétszeresére, és az eu még vámol is. De még így is jól járok.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.