PDF szöveg kicserélése képre

Iroda

A tárgyban található műveletre keresek alkalmas szoftvert.

Use case:
Felhasználó megnyit egy pdf-et, tetszőlegesen rajzol négyszögeket az oldalra, a "Crop to image" jellegű funkció pedig a téglalapok alatt lévő területből bittérképet készít, a kijelölt szöveginformációkat eltávolítja a pdf állományból, és a képet nanométer pontosan ugyanoda igazítja.

Erre miért van szükség:
Sok egyenletet, vektorgrafikát tartalmazó academic paperöket szeretnék kindle-n olvasni, az egyenleteket viszont még egy konvertáló programmal sem sikerült okosan átvinnem a készülékre.

Opcionális lehetőség:
Ha nagyon nincs ilyen, írjunk egyet. Ez esetben vállalkozó kedvű személyek jelentkezését várom, libpoppler, pdftohtml, pdftk, Qt, C++ ismeretek bármelyikével.

  • 3964 megtekintés

( batyu v | 2011. 08. 11., cs – 12:35 )

Ha a méret nem számít, akkor ghostscript -> jpgwrite backend -> jpg-k összefűzése pdf-be (erre n+1 megoldás van, imagemagick talán a legkézenfekvőbb). Hátrány, hogy a teljes tartalom bitképbe kerül.
Amúgy meg esetleg pdfedit lehet erre jó: http://pdfedit.cz/en/index.html de nem biztos, hogy egyszerűen működik a dolog vele.

A JPEG-es megoldáshoz:

Más indíttatásból, de egyszer én is csináltam valami hasonlót (pdf doksi pixelesítése). Nekem jobban bejött a kevés színt tartalmazó PNG. Ha tudja az ember, hogy fekete-fehéret fog nézni, akkor 8 vagy 16 színű indexelt PNG tömörebb tud lenni egy doksi megjelenítésében, mint az olyan minőségű JPEG, hogy a betűk szárait ne torzítsa bántóan a JPEG. Persze, ha sok a fotó, sokszínű felület, akkor ez nem jó, bár 256 színű PNG-vel is elég elfogadható eredményeket kaptam. (Nincs Kindle-m, de talán a kijelzője nem is bír sok árnyalatot. Nem tudom.)

Egy jó kis PNG optimalizálóval igen szép eredmény lesz, és még ha torzít is, éles kontúrúak maradnak a vékony vonalak. Nekem úgy 200 DPI felbontás vált be a generáláskor.

Az eredeti problémafelvetéshez:

Nem vagyok igazán hozzáértő (a max. eredményem a téren pár PS-turkáló és módosító szkript írása), de azt sejtem, hogy igen nehéz lesz pontosan detektálni, mi is kép, képlet, pontosan meddig tart, stb., mert ahány forrás annyiféle a belső megoldása ezeknek. Még az is különbség, ha LaTeX->DVI->PDF vagy közvetlen LaTeX->PDF útvonalon keletkezik a dokumentum, de ha másból generálják, egész más dolgok lehetnek benn. Félek, hogy a kitűzött célt csak a PDF-et generáló teljes lánc ismeretében lehet elérni, tehát egy megoldás jó lehet pl. a PDFLaTeX kimenetéhez, de Word-ből Acrobat-tal generált doksihoz nem.

A pixelesítés viszont működik minden forrásra.

> igen nehéz lesz pontosan detektálni, mi is kép, képlet, pontosan meddig tart, stb.

A témaindító hozzászólásban leírt use case nem automatikus felismerésre vonatkozik:
> Felhasználó megnyit egy pdf-et, tetszőlegesen rajzol négyszögeket az oldalra

A felvázolt működésre volna szükség tehát.

Egyébként köszönöm az építő hozzászólást.

"A témaindító hozzászólásban leírt use case nem automatikus felismerésre vonatkozik:"

OK! Bocs, figyelmetlen voltam.

Így viszont baromi nagy munka egy doksit így átalakítani. Amiket én olvasok, azokban oldalanként 10-20 képlet van... A PNG-s megoldás meg szkriptelhető és egész elfogadható méreteket eredményez. (Én 20-50 kB/oldalt kaptam, amikor csináltam, és a kimenet képernyőn tökéletesen olvasható lett.)

OK, megnyugodtam. :-)

Közben eszembe jutott, hogy nekem a legjobban a következő jött be képernyőre konverziókor:

Ha csak fekete-fehér a doksi:
a) Az odalakat mondjuk 400 DPI-s fekete-fehér (1 bites!) képekre alakítom
b) Pontosan 0.5-tel leskálázom, de már grayscale-ben
c) Ezt konvertálom indexelt png-re

Ez egy józan eszes antialiasing, viszont kézben tartom, csak 5 árnyalat jöhet szóba, így előírhatom, hogy csak ennyi szín legyen a palettán. Ez baromi jól tömöríthető lesz és nem keni el nagyon a vékony vonalakat sem.

A mindenféle konverterek hipi-szupi antialiasingja olyan sok árnyalatot hoz be, hogy az rontja a tömöríthetőséget.

Színesnél persze ez nem jön be, ott azt szoktam csinálni, hogy ismét a végeredmény dupla felbontásával generálok először mindent, de antialiasing nélkül és én skálázom pontosan 0.5-ös faktorral le, ami megcsinál egyfajta antialiasingot, de az árnyalatok számát azért kordában tartja. Itt persze nem elég néhány árnyalat, de 64 vagy 256 elemű paletta már jó képminőséget és mellette kis méretet szokott hozni.

A végeredmény png-ket aztán könnyű összefűzni pdf-fé. (Én annak idején html-lé fűztem össze, pontosabban oldalanként 1 html, ami navigációt + ezt a png-t tartalmazta. Képernyőn szépen olvasható volt a végtermék.)

Az a baj, hogy most nem találom a szkriptjeimet, mert marha régen írtam őket. Nagyrészt a pngutils tagjaival csináltam, bash-ban összefogva. De biztos meg tudod írni, nem nagy ügy.

Most poén kedvéért csináltam egy pdfből ilyen átkonvertált dolgot. Ez csak paraméterezés kérdése (méretet lehet csökkenteni, ha ügyesen optimalizálja az ember a kimeneti jpg-t vagy png-t), nálam szokott működni plakátok jpg-vé tételénél.

Alap sorok:
1. convert akarmi.pdf akarmi.jpg
2. convert *.jpg akarmi-uj.pdf

Én is ezt tudnám javasolni, talán a legegyszerűbb megoldás.

Ötlet algoritmushoz:
a képleteket gyanítom, más fontkészlettel írod fel, ami tudja a szépséges gyökalatt és szumma jeleket, stb.
Ha a pdf-ben valahogy erre tudsz rákeresni, akkor automatizálható válna, hogy ezeket alakítsa képéppé. Mondjuk ilyen stringek esetén, amit ezzel a különböző fontkészlettel ír le a dokumentum, kap egy 5px margint-t, s akkor tuti nem lóg ki semmi belőle.
No persze, hogy ezt a gyakorlatban qt alatt hogyan lehet kivitelezni, jó kérdés :D

szerk.: kicsit maradva a convert-nél. Nem releváns megoldás a -resize kapcsoló?

Szerintem kár ezzel szenvedni.

Pl van, hogy folyószövegben is beágyazva, lineárisan leírható képlet található, mondjuk egy polinom és azt a sor végén eltörik egy műveleti jelnél és a köv. sorban folytatják. Ilyenkor mi lesz? Vagy mi van a képlettel, ami általában középre van igazítva meg a sorszámával, ami mondjuk jobbra? Egy lap-átméretezésekor ez mind gondot jelent.

Ha mindenképp Kindlen akarod olvasni a cuccokat, szerintem még mindig a png-s megoldás a legjobb. Nem illeszkedik a méretarányokhoz, de lehet görgetni.

Egy régi megoldást láttam hasonlóra, de nem volt jó, leírom, hátha mégis hasznosnak találod:

Pixelesítették az oldalt, majd szétvágták több száz kis részre, először vízszintes vonalakkal, melyek fehér területen haladtak, majd ezeket függőlegesen szintén fehér területek mentén. Így durván szó-méretű kis grafikákat kaptak. Ezt tették be, mintha karakterek lennének és ez átrendeződött, ha az oldalméret változott. De ez is könnyen szétcsúszott. Nem az igazi...

( calamari | 2011. 08. 11., cs – 18:18 )

A cups tud pdf-be nyomtatni. Bár a szöveget megtartja úgy nézem, de hátha ez pont átalakít benne valamit úgy, hogy neked jó lesz.
Esetleg Windows alatt ugyanilyen pdf-be nyomtatós: http://sourceforge.net/projects/pdfcreator/
Nem tudom működik-e és tudom, hogy nem pont az, de hátha. :)

( Aadaam v | 2011. 08. 11., cs – 19:20 )

Erre van egy hardveres megoldas, iPadnek hivjak.

Kulon szoktam sajnalni azokat az embereket, akik azt hiszik, a kindle alkalmas tudomanyos vagy szakmai anyagok olvasasara. (Nem.)

En meg azokat az ugyfeleket, akiknek olyan programozojuk van, aki nem olvassa el a funkcionalis specifikacio kontextusat.

Neked az a problemad hogy cikkekben sok a keplet. Van egy masik problemad is, hogy a kepernyo keptelen a4-es megjelenitesre. Harom megoldasod van:
- vagy talalsz valami szoftvert ami ugy konvertal ahogy neked kell (de ettol meg a sima kindle nem lesz alkalmasabb szakcikk olvasasra, tapasztalat)
- vagy megirod magadnak
- vagy mas technologiai platformra allsz at.

Mivel szerintem a kindle - a dx se - alkalmas arra, ami miatt neked kell ez a funkcio, es ezzel a velemenyemmel nem vagyok egyedul, ezert en a harmadik megoldast javasoltam.

De mivel te felvetetted, hogy tordelesi problemaid is vannak, valoszinuleg nem is dx-ed van, azt pedig sokezer ember neveben allitom, koztuk lelkes kindle userek neveben, hogy a kindle kizarolag szepirodalomra alkalmas. Ezt jopar kindle-s ismeros szomoruan vette tudomasul.

(pl. az oldal alapu, de szoveges hivatkozasok is be fognak halni, de ez csak egy bajod lesz a millio kozul.)

Egeszen addig, amig nem kell vizualis tervezessel is foglalkoznod, mert ott hirtelen szinek jelennek meg a szakkonyvekben. De legyen, bar nalam bukik, mert attol meg hogy nem en irok style guide-ot, van hogy at kell nezzem (komolyabb alkalmazasok, weboldalak eseten ez 60-100 oldalas doksi siman)

( bikmakk | 2011. 08. 13., szo – 19:55 )

Csak ötletelek, de én első körben lehet, hogy nem vacakolnék a képek ugyanoda-illesztésével, inkább a dokumentum végére, külön oldalakba illeszteném a megfelelő ábrákat. Így elég lenne két pdf-doksit szimplán összefűzni.

Másik ötlet: azt próbáltad már, hogy a pdf-olvasó programból cupspdf-fel nyomtatsz egy másik pdf-et? Lehet, hogy úgy nem esnek szét az egyenletek.

Harmadik ötlet: A pdf-et képfájlok sorozatává konvertáló majd ezeket ismét pdf-fé fűző program nagyon necces? Így persze nem fogsz tudni szövegre keresni, ill. a copy-paste sem működik majd, viszont lehet, hogy megoldja minden gondod.

Szerk.: bocs, a harmadik ötletet már írták, csak read only voltam.
http://hup.hu/node/105803#comment-1330051