Vodafone, Evince, Acrobat, kde je chyba?

7.7.2008 12:53 | Přečteno: 1290× | Ani zbla | poslední úprava: 7.7.2008 13:53

Mým mobilním operátorem je již řadu let Vodafone. Většinou si nemám na co ztěžovat, pořádně mě naštvali jen dvakrát - jednou jsem se své novém mobilu zkoušel brouzdat po netu a ti hajzli mi to naúčtovali jako WAP (tedy myslím o dva řády dráž). Podruhé mi zavolali, že jsem u nich už dlouho a mám dobrou platební morálku a jestli bych jim nesehnal nové zákazníky! (Samozřejmě začali s tím, že poskytnou nějaké úžasné slevy, i když jen pro ty nové dušicky.)

Ale to jsem trochu odbočil. Zkrátka, každý měsíc se koukám na své vyúčtování, což je takový PDF dokument. Roky to fungovalo, na všech platformách. Najednou to ale fungovat přestalo, písmenka v tom dokumentu nějak divně rozházená, vizte obrázek. Nejelo to ani v Evince ani v Okularu. Verze dokumentu je 1.3 (tedy Acrobat 4), ale používají se nějaká speciální vodafouňácká písma a to bude asi kámen úrazu.

Tak jsem napsal na péči o zákazníky, že to rozbili. Odpověděli mi, že si mám stáhnout Acrobat Readera, prej je zadarmo i pro mou platformu

Ano, v Akrobatu to funguje. Sice mě štve, že nemůžu používat svůj svobodný Evince a že rozbili něco co fungovalo (a nechci vědět, kolik peněz za to rozbití dostal dodavatel). Na druhou stranu musím Acrobat Reader 8 pro Linux pochválit. Jednak mi dodali balíček pro mou distribuci (Ubuntu), rozhraní je GTK a nepůsobí jako vetřelec a celé to startuje i funguje velmi rychle.

       

Obrázky

Komentáře

[freshmouse]

Vždyť to není rozbité! Je to tzv. cool style nebo crazy style. Pokrok nezastavíš!

[Vinicius]

Na vině možná bude Mr. Poppler.

[otula]

Nevím, jestli to spolu nějak souvisí, ale KPDF se mi před nějakou dobou odnaučilo číst PDF vytvořená v Acrobat Distilleru. A potvrdili mi to i další, když jsem se ptal na fóru Archu.

[Jan Drábek]

Můj mobilní operátor - nešikovné, použil bych spíše Mým mobilním operátorem je

[alblaho]

Dobrá. Thx.

[Ladicek]

On se dneska toleruje i ten nominativ. Lidi jsou líný mrchy a v delších větách to na většinu obyvatelstva působí poněkud nesrozumitelně

[disorder]

skus aj xpdf

[otula]

nebo kghostview

[alblaho]

xpdf - stejně rozbité, kghostview zobrazil jen čistou stránku.

Ono je to jedno. Mám pocit že Evince i Okular (kpdf) používají vevnitř nějakou sjednocenou implementaci, možná odvozenou od xpdf.

Krom toho, xpdf má natolik humpolácké předpotopní rozhraní, že bych ho používal jen s odporem

[Vinicius]

To vevnitř je právě knihovna poppler a tam asi bude zakopaný pes. Zkusil bych poslat dané pdf autorům knihovny do bugzilly, třeba v nové verzi něco opraví. Sami vyzývají k takovému postupu. http://poppler.freedesktop.org/

[alblaho]

Nu dobrá. Ale že bych chtěl zveřejňovat všechny své údaje a telefonní čísla mých přátel a rodiny, to se mi tedy moc nechce :-\

[Michal Čihař]

Většinou stačí poslat jednomu vývojáři...

[disorder]

vidis, to je pravda. xpdf moze zavisiet na poppler-utils alebo na xpdf-reader a xpdf-utils -- mas tie?

[Michal Čihař]

No jo, taky to vidím rozbitý .

[Michal Fecko]

Holt, PDF je teda iné ISO

[Aleš Kapica]

PDF není samospasitelné a na podobné věci jako faktury apod. - je naprosto nevhodné.

[alblaho]

A jaký formát bys na ty faktury použil? Nic mě nenapadá.

[Filip Jirsák]

Já bych nejraději použil XML odpovídající nějakému schématu. Ještě lépe něco-jako-XML ale určené pro strukturovaná data, ale žádný takový rozšířený formát není, většinou se místo něj používá právě XML. V horším případě pak tabulka z kancelářského dokumentu. Pokud by nešlo ani to, zvolil už bych raději PDF než HTML, protože faktura bývá většinou interpretována především podle vzhledu a HTML nemá prostředky pro to, jak v něm sémanticky reprezentovat fakturu (a použití obecných prvků typu tabulka by mohlo být nejednoznačné).

[Luboš Doležel (Doli)]

Nedovedu si představit, že bych zákazníkovi poslal nějaké XML, ať si s ním pohraje.

[Filip Jirsák]

Myslel jsem to jako nějaký standardizovaný formát, kterému by rozuměl kdejaký program. Takže by si zákazník tu fakturu zobrazil v OOo nebo by si jí rovnou naimportoval do svého účetního softwaru. O snad dokonce na faktury nějaký standardní formát v rámci EU existuje… Když někomu pošlu ODF, to mu taky posílám XML, které splňuje určité schéma (a pár dalších věcí).

[thingie]

Hašišmarjá, už je to tu zas.

[Michal Vyskočil]

No tak XML jako univerzální jazyk pro popis strukturovaných dat vcelku funguje. Než tu za chvíli začne někdo strašit s XSLT, tak do té jsou faktury v XML vcelku fajn. Rozhodně více fajn, než třeba build.xml

[Ondrej 'SanTiago' Zajicek]

Co treba plain text (ci nanejvys s elementarnimi HTML znackami) se vsemi potrebnymi udaji?

[Filip Jirsák]

V plain textu (i tom HTML) se těžko budou vyjadřovat vztahy mezi jednotlivými údaji – třeba souvislost mezi názvem výrobku, jednotkovou cenou, množstvím, cenou bez DPH, sazbou a částkou DPH, cenou s DPH, slevou a třeba ještě poplatkem. Že to umístíte vedle sebe na řádek ještě neznamená, že to patří k sobě, a že to každý pochopí (když si to někdo třeba nechá přečíst hlasovou čtečkou).

[Aleš Kapica]

Osobně bych použil djvu. Opensource implementace existuje, ba řekl bych že v mnoha směrech lepší než pro PDF. Proč je však vhodnější pro výše uvedený účel?

• To co je vidět nelze žádným způsobem dodatečně pozměnit. Faktura není formulář, který by měl někdo vyplňovat, takže použít XML nebo HTML je naprostá ptákovina
• Používá wavelet kompresi, která má lepší výsledku než JPEG 2000 takže výsledný "obrázek" je mnohem menší než u PDF a přitom se renderuje rychleji
• Djvu umožňuje mít skrytou textovou vrstvu, jejíž obsah lze digitálně podepsat. Takže je technicky možné, aby do ní informace z faktury byly uloženy jako vhodně strukturovaný XML dokument.

[Filip Jirsák]

Proč by měla být faktura v PDF uložená jako obrázek? Normální je snad uložit ji tam jako text. PDF lze podepsat jako celek (podepsání skryté textové vrstvy je vám k ničemu, před českým zákonem to neobstojí – a je to tak správně, uživatel musí vědět, co podepsal). Podle mne faktura jsou zejména strukturovaná data, takže XML je docela rozumný formát. Zabezpečení proti změnám zajistí elektronický podpis.

[Aleš Kapica]

Především proto, že neexistuje jednotný typ faktury. Faktury obsahují podpisy, razítka a jsou i faktury psané ručně. Pokud chci mít kompletně elektronickou evidenci, pak nezbývá, než tyto faktury skenovat. Zároveň je pak nutno řešit otázku - jak zajistit aby se v těchto elektronických dokumentech dalo vyhledávat také podle obsahu? S djvu to lze. Přes djvused lze naimportovat libovolný textový obsah.

Asi jste pořádně nečetl, poněvadž pak by vám nemohl uniknout poslední bod a totiž že skrytá textová vrstva může obsahovat právě strukturovaný XML dokument. Ovšem vzhledem k tomu že je tato vrstva skrytá, není vůbec nutné, aby tento XML dokument byl nějak navázán na nějaký css styl, resp. xsl šablonu.

Pokud jde o podpis. Poněkud jste nepochopil účel elektronického podpisu. Podpis je určen především k ověření dat. Nejde o to co uživatel podepsal. On totiž nepodepisuje nic. On pouze obdrží fakturu za jejíž správnost někdo ručí a tím je vystavovatel faktury. Uživatel potřebuje pouze ověřit zda vložená textová data v dokumentu někdo nepozměnil. U djvu navíc může ihned případně nějakou nesrovnalost vizuálně ověřit.

Djvu dokument obsahuje také tzv. metadata, v nich mohou klidně být el. podpisy všech vrstev, tj. nejenom textové. Djvu je navíc formát který byl přímo navržen pro archivaci dokumentů. PDF, pokud vím mělo zajistit především přenositelnost.

[Filip Jirsák]

Díval jsem se na to z pozice toho, kdo fakturu vytváří. Tj. žádné skenování, žádné různé typy faktur, naopak je potřeba podpis toho, kdo ručí za správnost údajů. Pro elektronické zpracování faktur by pak samozřejmě byl výhodný jediný strukturovaný formát, který by obě strany mohly použít jak v účetnictví, tak např. v elektronické komunikaci s bankou. Oba formáty (jak djvu tak PDF) tohle neumožňují, protože tam musí zobrazenou fakturu interpretovat člověk – a třeba opsat údaje z ní do účetnictví. XML data uložená v textové vrstvě vedle „obrazové“ reprezentace faktury jsou mi k ničemu, protože nikde nemám zaručeno, že XML obsahuje to samé, co je na obrázku.

[Aleš Kapica]

Díval jsem se na to z pozice toho, kdo fakturu vytváří. Tj. žádné skenování, žádné různé typy faktur, naopak je potřeba podpis toho, kdo ručí za správnost údajů.

Tak na tohle existuje gsdjvu - který umožňuje rovnou tisk do djvu formátu. Stejně tak není problému do djvu převést již existující pdf utilitou pdf2djvu.

Pro elektronické zpracování faktur by pak samozřejmě byl výhodný jediný strukturovaný formát, který by obě strany mohly použít jak v účetnictví, tak např. v elektronické komunikaci s bankou. Oba formáty (jak djvu tak PDF) tohle neumožňují, protože tam musí zobrazenou fakturu interpretovat člověk – a třeba opsat údaje z ní do účetnictví.

Tak tohle zrovna u djvu s textovou vrstvou nemusí být pravda. Protože tuto textovou vrstvu strukturovaných dat lze bez nejmenších problémů vytáhnout a dále zpracovat. A protože nástroje pro zpracování djvu (djvulibre) jsou k dispozici jako opensource a to jak pro linux, tak pro windows, není problém vytvořit libovolnou aplikaci která by ty data sežvýkla tak jak by bylo třeba.

XML data uložená v textové vrstvě vedle „obrazové“ reprezentace faktury jsou mi k ničemu, protože nikde nemám zaručeno, že XML obsahuje to samé, co je na obrázku.

Od toho je právě ten ten podpis. Pokud sedí podpisy pro jednotlivé vrstvy (tj. jak obrazové tak textové). Je na 100% jisté že je autorem tvůrce dokumentu a ten tímto také ručí za správnost dat. Navíc, pokud by byla obrazová část faktury generovaná přes nějaký stylesheet z dat uložených v textové vrstvě, tak je prakticky vyloučeno že by se mohla lišit.

[Filip Jirsák]

Od toho je právě ten ten podpis. Pokud sedí podpisy pro jednotlivé vrstvy (tj. jak obrazové tak textové). Je na 100% jisté že je autorem tvůrce dokumentu a ten tímto také ručí za správnost dat. Navíc, pokud by byla obrazová část faktury generovaná přes nějaký stylesheet z dat uložených v textové vrstvě, tak je prakticky vyloučeno že by se mohla lišit.

Tohle bych dělal raději tak, že budu mít podepsaná zdrojová data (v přenositelném formátu) a ta si nechám zobrazit svým programem, kterému důvěřuju. Nerad bych řešil, že na faktuře bylo vidět 10 Kč a v datech bylo 1000 Kč, obojí bylo podepsáno, a já pak musel řešit, který údaj vlastně platí a co si vezmu na tom, kdo tohle podepsal. Nehledě na to, že bych ten rozdíl nejprve musel zjistit. Takže pokud s tím chci dělat něco rozumného, potřebuju ta strukturovaná data – a nějaký obrázek ukazující, jak ta strukturovaná data zobrazuje software dodavatele, je mi k ničemu a nepotřebuju ho.

[Aleš Kapica]

Takže pokud s tím chci dělat něco rozumného, potřebuju ta strukturovaná data – a nějaký obrázek ukazující, jak ta strukturovaná data zobrazuje software dodavatele, je mi k ničemu a nepotřebuju ho.

Bohužel svět už je takový. Drtivá většina faktur v elektronické formě není a nebude. Nehledě na to, že onen "obrázek", stejně tak jako v praxi cár papíru plní stejný úkol - dává možnost vizuální kontroly. Naopak - rozhodně víc bych věřil datům z takto vytaženého dokumentu, než těm, co přeťukává nějaký účetní z PDF.

[Filip Jirsák]

Jedna naklonovaná špatná implementace snad ještě neznamená problém celého formátu.

[otula]

Právě se mi poppler aktualizoval na verzi 0.8.4, a problém, který jsem měl, už je vyřešen. Možná to s ním nebude zlobit už ani tobě.

[alblaho]

Fíha. Já mám Ubuntu Gutsy, v Hardym je 0.6.4, teprve v Intrepidu je 0.8.4. Nevím jestli tak rychle vyvíjejí, nebo jenom číslují . Někdy to zkusím v tom Intrepidu.

[kotyz]

0.8.4 bys mel mit i v Hardym, zapnes-li si repozitar backports.

[DjAARA]

podle packages.ubuntu.com jaksi v backports pro hadyho ještě není…

[jbohac]

mám stejnej problém s Vodafoním vyúčtováním. Poppler 0.8.4 to u mne nespravil. Právě jsem to nahlásil do Bugzilly: https://bugs.freedesktop.org/show_bug.cgi?id=16861

[jbohac]

vyvojar poppleru zjistil, ze za spatne vykreslovani muze uz freetype. Vyvojar freetypu tvrdi, ze je to blby font, ktery neni podle standardu. Prave probiha diskuse mezi vyvojari freetype, kteri se dohaduji, zda takovyhle spatny font podporovat, nebo ne.

Viz thread na tf-devel mailinglistu.