Uncurled: zkušenosti s dlouhodobou správou open-source projektu (curl) (diskuse)

[Pavel Křivánek]

epub verze: https://daniel.haxx.se/uncurled/uncurled.epub

[kosmo]

Proč to musí někdo dát do idiotského epub formátu když všude je standard pdf? Ten ti otevře jakýkoliv prohlížeč.

[Jendа]

Protože v PDF nejde (obecně, bez příšerných problémů vzniklých heuristikami na rewrap) měnit velikost písma, font, barva, šířka řádku…

[kralyk z abclinuxu]

Jo, ta šířka řádku je IMO hlavní problém. PDFko víceméně nejde vytvořit tak, aby bylo dobře zobrazitelné na všem od velkých desktopových displayů po telefony nebo čtečky.

Epub se oproti tomu přizpůsobí šířce displaye.

[Se uklidnime]

Takze radeji koukat na neergonomicke halabala fonty s mizernym kerningem v osekane ctecce jen kvuli zmene velikosti pisma? Vzdy si to v pdf zoomnu ne? Nebo snad to koukate na mobilu ci nejake 6" parodii na eknihu? A4 nebo 10"+ je zaklad, cokoliv pod je o kompromisu a ergonomicke bide. Takze az vam nekdo nabizi zarizeni na pdf pod 400$ ani na to nekoukejte, bude to pomala neergonomicka parodie na frasku. iPad je naproste minimum ale nema e-ink. Takze kvalita zacina nekde u treba Onyx Boox Note, nebo rovnou Max Lumi 2, taky reMarkable2 je skvely kousek. A na ePUB si jiz v zivote nevzpomenete

[Jendа]

Takze radeji koukat na neergonomicke halabala fonty s mizernym kerningem

Mně přijdou normální počítačové fonty s automatickou sazbou naprosto v pohodě. A pak jsou různí blázni co používají věci jako bionic reading a tak.

Vzdy si to v pdf zoomnu ne?

Nezoomneš, když to má pevnou šířku řádku. Buď se ti to tam nevejde, nebo budou po stranách pruhy. A neexistuje "jedna správná" čtečka PDFek, protože PDF jsou v padesáti různých typech - různé standardní knihy různých velikostí (A5, A4, a takové ty Bněco mezi tím), ale taky třeba dvojsloupcový formát ve kterém často vychází vědecké články.

Nebo snad to koukate na mobilu ci nejake 6" parodii na eknihu?

Ano třeba také. Nebo na notebooku, který je ale zrovna landscape, takže se tam ta stránka poněkud nevejde a současně jsou po stranách pruhy.

[|🇵🇸]

různí blázni co používají věci jako bionic reading a tak

Označení „blázni“ je potenciálně docela trefné.

Jsou nějaké solidní studie, které by ukazovaly, že ten „bionic reading“ je [čtenáři] k něčemu dobrý? Protože s jinými formami „rychločtení“ je to dost bída.

[Jendа]

To je přece i o individuální preferenci. Ty bys snad chtěl studii i na to, že někomu chutná koprovka víc než rajská.

[|🇵🇸]

Tím jsi mě navedl přímo k souvisejícímu příkladu, tzv. „styly učení“. Že prý se někdo učí lépe z obrázků a jiný z textu. Ukazuje se však, že žádné takové rozdíly se v praxi nepodařilo průkazně identifikovat. Přesto mnoho lidí, zvláště vyučujících, v tenhle koncept věří, a to i na škodu výuky.

A ano, studie chuťových vjemů nejsou od věci. Např. díky nim víme, že různí lidé vnímají různě různé potraviny (typicky kapustu), příp. se chutě s věkem mění (zvláště během dospívání, ergo viz např. trýznění dětí, když jim některá zelenina nechutná, potažmo kecy o tom, jak je to časem přejde – ano, protože se změní jejich tělo). Používá se to také pro plošné genetické testy.

[kralyk z abclinuxu]

Pochopil jsem správně, že "Bionic Reading" není in-vivo čip, který člověku dodá DMA do e-booků, nýbrž služba, která v textu boldem zvýrazní první půlku každého slova? :D

[BoneFlute]

Samozřejmě, že si to čtu i na mobilu, proč by ne? Mám Kindle, mám iPad, mám zkušenosti. Můj závěr - pdf je dobré na faktury. Na knihy v žádném případě.

[Jendа]

pdf je dobré na faktury

Není, protože z toho nejde extrahovat informace a musí se platit miliardy firmám co to dělají.

[BoneFlute]

To co píšeš z mnoha důvodů tak nějak není pravda.

- Parsování faktur se nedělá proto, že se faktury posílají v PDF, ale protože se posílají v jpegu (v PDF).

- Parsování faktur se nedělá proto, že se posílají v PDF, ale protože neexistuje specifikace jak je strojově posílat - jestli je pošleš jako PDF, text, nebo DOCX, to máš stejně blbě.

- Na posílání faktury se dá celkem s úspěchem použít platba-QRcode. Takže by bohatě stačilo, když by se řeklo (nebo uzákonilo), že se s tou fakturou musí posílat i ten QRcode, a hned to extrahování informací bude snadné (furt by to šlo líp, ale alespoň něco).

- Samozřejmě dokonalé by bylo, když by se definovala struktura faktury.

Což říkám jako člověk, který zrovna to parsování PDF dělal, a tak mám nějakou představu, v čem je problém.

Každopádně téma bylo o neužitečnosti PDF pro literaturu. To, že pdf je dobré na faktury byla jen taková výplň.

[xkucf03]

Parsování faktur se nedělá proto, že se faktury posílají v PDF, ale protože se posílají v jpegu (v PDF).

To mi moc běžné nepřijde. Ale ono i když je to jako text (dokonce ani nemusí být převedený na křivky), tak není triviální z toho vydolovat strukturovaná data – člověk sice vidí tabulku atd. ale počítač se v tom snadno ztratí (resp. potřebuje různé heuristiky nebo i AI).

Parsování faktur se nedělá proto, že se posílají v PDF, ale protože neexistuje specifikace jak je strojově posílat

Existuje ISDOC, EDI a další.

Na posílání faktury se dá celkem s úspěchem použít platba-QRcode.

Přijatou fakturu neeviduješ jen proto, abys ji proplatil – nezajímá tě jen celková částka, ale jednotlivé položky, jejich ceny a množství.

Nicméně pokud se strany neshodnou na žádném strojově čitelném formátu, tak to sklouzává k ekvivalentu papírové faktury (akorát posílaného e-mailem), a pak těžko najdeme něco vhodnějšího než PDF(/A).

[trekker.dk]

nezajímá tě jen celková částka, ale jednotlivé položky, jejich ceny a množství.

... a taky tam musí být odběratel a dodavatel. Prostě hromada informací, které se do QR kódu nevejdou

[kralyk z abclinuxu]

Můj dojem z QR kódu na fakturách je, že to je užitečný tak maximálně pro bankovnictví v telefonu.

Existuje software pro přečtení QR platby na desktopu?

[Jendа]

Existuje software pro přečtení QR platby na desktopu?

Přímo extrakce platby a třeba vyplnění do nějakého internetového bankovnictví nevím (s tím souvisí že banky mají náhodná vlastní API a některá vůbec nebo jsou obtížně použitelná -- např. Fio má API velmi dobré, ale neumí to připravit formulář v internetbankingu k odkliknutí, musí se to řešit kompletně po vlastní ose), ale když na to pustíš zbarimg, tak samozřejmě dostaneš ta data a čísla účtu apod. z nich lze vykoukat/zkopírovat.

[BoneFlute]

> To mi moc běžné nepřijde...

No, já se na tom právě zasekl. Dokavad tam byl text, tak byl problém jen v tom, že každá faktura má svůj vlastní formát. To se ještě nějak řešit dalo. Ale pak přišli jpegy, a mě se fakt nechtělo to ještě proháně OCRkem.

> Přijatou fakturu neeviduješ jen proto, abys ji proplatil...

Jsem si toho vědom. Uvedl jsem to jako rychlé a nikoliv ideální řešení. Základní problém ale zůstává.

O ISDOC a EDI jsem neslyšel (taky jsem po tom zase tak zvláštně nepátral). Setkal se s tím někdo v praxi? Jde to nějak adoptovat? Pošlu klientovi emailem fakturu. Co tam přidat, aby se to dalo zpracovat strojově? Musí se někde začít, že.

[xxxs]

kludne si daj vyhladat edi format a pozri. v praxi je to trosku bordel a obe strany fakturacie musia zamakat, aby sa to vyladilo do pozadovanej funkcnosti.

[kralyk z abclinuxu]

Takže by bohatě stačilo, když by se řeklo (nebo uzákonilo), že se s tou fakturou musí posílat i ten QRcode, a hned to extrahování informací bude snadné (furt by to šlo líp, ale alespoň něco).

QRCode by rozhodně nestačil, ale IMO by stačilo do toho PDFka přidat strojově čitelnou přílohu s ekvivalentními daty. Například by to mohlo bejt ve formátu BSON (protože podporuje typ decimal128).

No nicméně jak už to tak bejvá u těhle problémů, ten hlavní problém je stejně společenskej - ať už vymyslíme jakýkoli tehcnický řešení, je otázka, jak ho dostat do širokého používání...

[_]

QRCode by rozhodně nestačil

Ano, QR kód samozřejmě nestačí.

IMO by stačilo do toho PDFka přidat strojově čitelnou přílohu s ekvivalentními daty. Například by to mohlo bejt ve formátu BSON (protože podporuje typ decimal128). No nicméně jak už to tak bejvá u těhle problémů, ten hlavní problém je stejně společenskej - ať už vymyslíme jakýkoli tehcnický řešení, je otázka, jak ho dostat do širokého používání...

Chápu to správně, že se snažíš znovuvynalézat kolo, které u nás existuje někdy od roku 2009 (a v zahraničí ještě mnohem déle)? A následně tvrdíš, že není možné něco, co se v praxi běžně používá? (stačí se podívat do celkem libovolného účetního programu na možnosti importu)

P.S. BSON opravdu není formát pro předávání faktur. Teoreticky by sice použít šel, ale to by šla prakticky libovolná podobná technologie. Nicméně ta řeší asi tak 0.00001 % daného problému. Podstata je, že navrhneš logický model těch dat a domluvíš se s ostatními na jeho používání.

[Jendа]

A následně tvrdíš, že není možné něco, co se v praxi běžně používá?

Asi se to nepoužívá dost často na to, aby nebyly potřeba Rossumy. Nikdo přece netvrdil, že neexistují i faktury, které jsou ve vhodném automaticky zpracovatelném formátu.

[kralyk z abclinuxu]

Chápu to správně, že se snažíš znovuvynalézat kolo, které u nás existuje někdy od roku 2009 (a v zahraničí ještě mnohem déle)? A následně tvrdíš, že není možné něco, co se v praxi běžně používá?

Že by něco nebylo možného jsem netvrdil, pouze jaksi pozoruju, že prakticky žádná faktura, kterou obdržim, strojově čitelná není (ať už v jakémkoli formátu)... No takže na možnosti importu v učetním programu se sice podívat můžu, ale jaksi nebudu mít co do něj naimportovat... Nevím o tom, že by mi někdy někdo poslal ISDOC data...

[_]

Nemá cenu dumat nad tím, jestli stavět něco nad BSONem... V tomhle problém není, ty formáty existují, účetní programy je umí importovat. Problém je spíš v tom, že data v těchto formátech málokdo posílá. Souvisí to i s tím, že málokdo ti odmítne proplatit fakturu kvůli tomu, že jsi ji poslal jen v PDF a ne ve strojově čitelném formátu. Ve skutečnosti to ty účetní programy umí v těch formátech i exportovat (u různých jednoúčelových generátorů faktur to může být horší), takže je to primárně o lenosti/neznalosti lidí.

Napadá mne jedna cesta, jak tomu trochu pomocí -- ty účetní programy by mohly při generování faktury do PDF automaticky přiložit i ISDOC, tudíž by to od uživatele nevyžadovalo žádnou explicitní akci, dělal by vše tak jako dřív. A na straně importu by to chtělo přidat vstupní filtr, který načte celé PDF a vezme si z něj tu přílohu (nevím, jestli to nějaký program už má, ale nebylo by to těžké). Pak už stačí jen do těch generovaných PDF přidat větičku: "tento soubor obsahuje i data ve strojově čitelném formátu ISDOC"... a zbytek je už jen na těch účetních, zda si budou chtít ušetřit práci nebo rádi opisují čísla z jednoho okna do druhého (případně jejich zaměstnavatelé vyhazují peníze za různé Rossumy).

[plostenka]

A na straně importu by to chtělo přidat vstupní filtr, který načte celé PDF a vezme si z něj tu přílohu (nevím, jestli to nějaký program už má, ale nebylo by to těžké). Pak už stačí jen do těch generovaných PDF přidat větičku: "tento soubor obsahuje i data ve strojově čitelném formátu ISDOC"...

ISDOC je mala domu nekoho z vlady -> uplne nepouzitelne. On 16 October 2008, 14 companies and the Czech government signed a declaration to use this format within one year in their products.

Akorat pridavas slozitost, protoze nekdo musi zvalidovat, ze vsechna data v binarnim blobu odpovidaji viditelnym udajum na fakture. Takze ses Rossumu nezbavil a navic mas novy vektor pro nekonzistence/chyby/utoky.

[kralyk z abclinuxu]

Akorat pridavas slozitost, protoze nekdo musi zvalidovat, ze vsechna data v binarnim blobu odpovidaji viditelnym udajum na fakture. Takze ses Rossumu nezbavil a navic mas novy vektor pro nekonzistence/chyby/utoky.

Ano, to je další problém... Podíval jsem se na dokumentaci isdocu a celkem chápu, proč se to nepoužívá. Ale on by se dost možná nepoužíval ani jednodušší formát. Ono to nejspíš dopadne tak, že různé Rossumy apod. se postupně zlepší, zlevní a zkomoditizují, a prostě se bude na tyhle věci používat EjÁj, protože to je ve výsledku realističtější cesta. Důvody jsou podobné jako popsáno v Doctorow: Metacrap.

[Jendа]

- Parsování faktur se nedělá proto, že se faktury posílají v PDF, ale protože se posílají v jpegu (v PDF).

Ne. I faktury co mají písmenka jako text se musejí zpracovávat tou Rossum věcí/heuristikami/ručně.

- Parsování faktur se nedělá proto, že se posílají v PDF, ale protože neexistuje specifikace jak je strojově posílat - jestli je pošleš jako PDF, text, nebo DOCX, to máš stejně blbě.

Samozřejmě. Nemyslím si, že bych tvrdil opak.

[Dirka]

Tos zabil, na faktury? Diky, ne!

[trekker.dk]

Máte lepší nápad, který bude splňovat požadavky dané zákonem, tj. elektronický podpis?

[|🇵🇸]

Jo, co třeba změnit zákon?

[kralyk z abclinuxu]

A4 nebo 10"+ je zaklad, cokoliv pod je o kompromisu a ergonomicke bide.

No tak to ani náhodou. Pokud jde o knihy obsaující pouze nebo téměř pouze text, což je případ zprávičky, těch 10" mi přijde jako cca maximum, A4 už bych považoval za silně nepohodlné.

(Samozřejmě něco jinýho jsou třeba články nebo učebnice obsahující diagramy/vzorce/grafy/fotky/whatever, pro to je fakt lepší větší tablet a PDF formát, ale to je jiná kategorie.)

[Se uklidnime]

Samozrejme se tady nebavime o beletrii ale primarne o vedeckych clancich, magazinech nebo komixech pdf je nutnost a i takova beletrie se cte lepe kdyz to dela mistr sazec a ne nejaky epub algoritmus.

[kralyk z abclinuxu]

Aha, tak to je ale diskuse o voze a o koze... Na články a už vůbec komixy samozřejmě PDF ano a stejnětak větší formát zařízení. Beletrie a literatura, kde >95% je rozsáhlý souvislý text, je ale úplně jiná kategorie s jinými parametry. Něteří lidi mají třeba z toho důvodu např. iPad na PDFka a <10" čtečku na knížky...

[kosmo]

Na komixy bych spíš preferoval cbz/cbr formát který je na to určený.

[dezavu]

Kefaline to je jsou jen jpegy v zipu nebo rarku Kdyz uz tak djvu - skvely na archivovani casopisu.

[Jendа]

Samozrejme se tady nebavime o beletrii ale primarne o vedeckych clancich

Zprávička je o jednom konkrétním textu, který má mnohem blíž k té beletrii než k paperu.

a i takova beletrie se cte lepe kdyz to dela mistr sazec

By mě zajímalo kolik třeba těch článků sází mistr sazeč a není to default co vyplivl latex.

[_]

knihy se ctou ve ctecce, a tam je pdf na hovno

pdf je urceno primarne pro tisk

[plostenka]

Protoze narozdil od EPUBu PDF neni standard, ale opatentovany bastl.

[xkucf03]

PDF/A:

PDF/A is an ISO-standardized version of the Portable Document Format (PDF) specialized for use in the archiving and long-term preservation of electronic documents.

Initial release October 1, 2005; 16 years ago

[Štangľa]

Kokotina. Epub nehovori vobec nic o tom ako to ma vyzerat, je to horsi format nez html

[|🇵🇸]

Vždyť uvnitř je právě HTML (dříve XHTML), CSS,…