T-Mobile od 15. září zpřístupňuje RCS (Rich Communication Services) zprávy i pro iPhone.
Společnost ARM představila platformu Arm Lumex s Arm C1 CPU Cluster a Arm Mali G1-Ultra GPU pro vlajkové chytré telefony a počítače nové generace.
Unicode Consortium, nezisková organizace koordinující rozvoj standardu Unicode, oznámila vydání Unicode 17.0. Přidáno bylo 4 803 nových znaků. Celkově jich je 159 801. Přibylo 7 nových Emoji.
Apple představil (YouTube) telefony iPhone 17 Pro a iPhone 17 Pro Max, iPhone 17 a iPhone Air, sluchátka AirPods Pro 3 a hodinky Watch Series 11, Watch SE 3 a Watch Ultra 3.
Realtimová strategie Warzone 2100 (Wikipedie) byla vydána ve verzi 4.6.0. Podrobný přehled novinek, změn a oprav v ChangeLogu na GitHubu. Nejnovější verzi Warzone 2100 lze již instalovat také ze Snapcraftu a Flathubu.
Polské vývojářské studio CD Projekt Red publikovalo na Printables.com 3D modely z počítačové hry Cyberpunk 2077.
Organizátoři konference LinuxDays 2025 vydali program a zároveň otevřeli registrace. Akce se uskuteční 4. a 5. října na FIT ČVUT v pražských Dejvicích, kde vás čekají přednášky, workshopy, stánky a spousta šikovných lidí. Vstup na akci je zdarma.
Uživatelé komunikátoru Signal si mohou svá data přímo v Signalu bezpečně zálohovat a v případě rozbití nebo ztráty telefonu následně na novém telefonu obnovit. Zálohování posledních 45 dnů je zdarma. Nad 45 dnů je zpoplatněno částkou 1,99 dolaru měsíčně.
Server Groklaw, zaměřený na kauzy jako právní spory SCO týkající se Linuxu, skončil před 12 lety, resp. doména stále existuje, ale web obsahuje spam propagující hazardní hry. LWN.net proto v úvodníku připomíná důležitost zachovávání komunitních zdrojů a upozorňuje, že Internet Archive je také jen jeden.
Jakub Vrána vydal Adminer ve verzi 5.4.0: "Delší dobu se v Admineru neobjevila žádná závažná chyba, tak jsem nemusel vydávat novou verzi, až počet změn hodně nabobtnal."
Správce nástroje curl Daniel Stenberg na GitHubu průběžně vytváří svou novou knihu Uncurled, v níž shrnuje své dlouhodobé zkušenosti s údržbou open-source projektu: od odpozorovaných pouček po vtipné a ne až tak vtipné příklady e-mailů od uživatelů.
Tiskni
Sdílej:
Takze radeji koukat na neergonomicke halabala fonty s mizernym kerningemMně 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.
pdf je dobré na fakturyNení, protože z toho nejde extrahovat informace a musí se platit miliardy firmám co to dělají.
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
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).
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
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.
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čilAno, 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í.
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.
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...
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.
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.
- 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.
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.)
Samozrejme se tady nebavime o beletrii ale primarne o vedeckych clancichZprá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 sazecBy mě zajímalo kolik třeba těch článků sází mistr sazeč a není to default co vyplivl latex.
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