Když já s těmihle prohlížečkami PDF v prohlížečích (ať už Firefox nebo Chrome) nemám moc dobré zkušenosti a vždycky raději PDFka otvírám v dedikovaném prohlížeči specializovaném na PDF (na Windows třeba ten Adobe Reader, ale i FoxIt Reader byl fajn), na Linuxu obvykle Evince, ale dřív třeba i xpdf, nebo někdy jsem zkoušel i kpdf...
A co mi v těch webových prohlížečích nefungovalo? No PDF někdy prostě vypadala jinak. Jak kdyby se použil jiný font (neuměly snad ty prohlížeče použít font, který byl případně přibalen rovnou v PDF?). Někdy se špatně zobrazovaly znaky s diakritikou. Někdy se sice zobrazovaly dobře, ale problém byl pak při tisku takového PDF, tam najednou místo znaků s diakritikou rozsypaný čaj...
Takže po těchto zkušenostech si všude na počítačích kde pracuji nastavuji ve Firefoxu (dá se to najít v někde v about:config a v nastavení asociací) otevírání přímo v Evince. A v práci to často nastavuji i kolegům, když mají nějaký souvisejicí problém (někdy i když zrovna s PDF problémy nemají a řeším u nich něco jiného).
Chápu, že tvůrci webových prohlížečů asi na té funkcionalitě související s prohlížením PDF pořád pracují a že třeba tyto mnou uvedené problémy někdy zmizí (nebo už zmizely?)... Ale já zatím volím předběžnou obezřetnost.
Vestavěné prohlížeče PDF ve webových prohlížečích se postupně zlepšují. Z počátku to byla úplná tragédie, dnes už je to podstatně lepší, ale stále pokaždé s napětím čekám, co uvidím.
Ale je fakt, že moje nároky na plugin pro prohlížení PDF v prohlížeči jsou poněkud extrémní. Poměřuju to tím, co uměl plugin Adobe Readeru pro prohlížeče. S ním jsem kdysi implementoval to, že když uživatel v prohlížeči zvolil tisk webové stránky, ten se zrušil a místo toho se vyvolal tisk PDF dokumentu zobrazeného ve stránce. (Tedy to, co všechny ty dnešní prohlížeče PDF v prohlížeči řeší tím, že se nad zobrazeným PDF zobrazí nástrojová lišta, kde je i tisk. Zmáčknout to správné tlačítko už většina uživatelů zvládne.)
Vždycky jsem považoval PDF za takový WYSIWYG formát, naprosto blbuvzdorný - dokud se toho nechopily webové prohlížeče.
Nádavkem to je celé nějaké pomalé a na paměť žravé. A když to pošlu na tiskárnu, vyleze občas něco úplně jiného, než bylo na obrazovce.
Kdyby tahle funkcionalita z webových prohlížečů vypadla - třebas ve prospěch nějakého proprietálního plug-inu - určitě by se mi dost ulevilo.
Ten prohlížeč, co je ve Firefoxu, je napsaný v JavaScriptu. Mozilla tenkrát pod svá křídla vzala projekt, který už tou dobou existoval, a dál ho rozvíjí. PDFium (prohlížeč z Chrome) používá pro čtení PDF knihovnu Foxit PDF, pro vykreslování PDF pak je nějaká podpora v knihovně Skia (grafický engine používaný i Blinkem).
Vzhledem k tomu, že i webový prohlížeč je renderer, dává docela smysl nějak to s PDF prohlížečem integrovat, aby to nebyly úplně oddělené světy. Aby se třeba nestávalo, že se stejný font vykreslí jinak na webu a jinak v PDF. Je otázka, jak pracné by bylo přizpůsobit tomu jiný renderer, aby třeba renderoval také skrze Skia.
Třeba klasický problém, který býval v těch rendererech zpočátku, je práce s vloženými fonty. Normálně se o vykreslování fontů stará operační systém nebo grafická knihovna. Jakmile chcete začít vykreslovat správně fonty vložené v PDF, je potřeba si začít řešit vykreslování fontů do značné míry sám. Je potřeba podporovat potřebné formáty fontů, něco z toho jsou myslím licencované technologie. Navíc jsou tam takové radosti, že v PDF si můžete vymyslet vlastní znakovou sadu, ta je nějak namapovaná na vložený font, nebo může být namapovaná na systémový font – a když má správně fungovat o vyhledávání a kopírování textu, je tam zase mapování té vlastní znakové sady na Unicode (nebo na nějakou jinou univerzální sadu, nejsem si teď jistý). Takže jenom tohle je dost komplikovaná věc, se kterou se jinak potkáte jen v OS nebo grafických toolkitech, a i tam to bývá jednodušší.
No a anglicky psaná PDF se vám většinou zobrazí správně i bez tohohle všeho, protože si vystačí se znaky, které budou zobrazené správně, i když se nahradí nějakým písmem ze systému. Takže vlastně není potřeba mít to implementované hned od začátku – akorát že když ten váš prohlížeč bude používat někdo se znaky mimo anglickou latinku, bude narážet na problémy se zobrazením. Navíc i to PDF s „cizími“ znaky se dá vyrobit tak, aby bylo i se systémovým fontem zobrazené plus mínus správně. Jenže to je zase komplikovanější na generování a ne každý software pro vytváření PDF to zvládne. Takže uživatel pak vlastně ani neví, v čem je problém – některá PDF se zobrazí dobře, některá ne, je to chyba prohlížeče nebo autora PDF?
Ten JavaScript vysvětluje paměťovou a procesorovou žravost zobrazování PDF - alespoň ve Firefoxu.
Ale stejně si myslím, že webový prohlížeč by měl mít s PDF jediný společný bod: jak poslat do PDF zobrazenou stránku. Rozhodně by to neměl dělat naopak (zobrazovat PDF), protože jde o úplně jiný svět.
Zobrazování HTML stránky je do značné míry v režii prohlížeče - ten fakticky na základě předpisu (v HTML, CSS, ovládáním DOM objektů...) sestaví a zobrazí stránku, v principu nekonečnou. Za pozornost stojí, že obvykle scrollujeme
, neotáčíme stránky (jako ve čtečce knih). Převod takového dokumentu do tisknutelné podoby, na jednotlivé stránky, je samostatný úkol - a prohlížeče v něm často selhávají. (Za něco může pachatel stránky, ale za mnohé nikoliv.)
Zobrazení PDF dokumentu je ale úplně opačný problém. Může to vypadat jednoduše: prostě vykreslit stránky pod sebe. Ale není. Zobrazování PDF se věnují samostatné aplikace a i ty sotva stíhají držet krok. Představa, že to zvládne i webový prohlížeč, notabene JavaScriptem, je poněkud příliš optimistická.
Mě třeba FF jako prohlížeč PDF plně vyhovuje. Jen výjimečně potřebuji otevřít nějaké divné PDF v něčem "plnohodnotnějším", ale to plyne z toho, že jsem z tohoto hlediska běžný uživatel. Jako 99,999% uživatelů Firefoxu či Chrome. Mám spíš tu zkušenost, že když v nějakém PDF vyplňuji položky, tak se na Linuxu uloží/vytisknou blbě. Protože kódování je tam nastaveno "windowsové" - namátkou to dělávalo PDF s podacími lístky ČP.