Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované GIFy.
Nejnovější X.Org X server 21.1.18 a Xwayland 24.1.8 řeší další bezpečnostní chybu.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 210. sraz, který proběhne 20. června od 18:00 v Red Hat Labu na Fakultě informatiky Masarykovy univerzity na adrese Botanická 68A nebo také online.
Byla vydána nová verze 17 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.05.0. Přehled novinek v poznámkách k vydání. Nově je implementováno standardizované simulační rozhraní ROS (Robot Operating System) 2.
Nejnovější X.Org X server 21.1.17 a Xwayland 24.1.7 řeší 6 bezpečnostních chyb: CVE-2025-49175, CVE-2025-49176, CVE-2025-49177, CVE-2025-49178, CVE-2025-49179 a CVE-2025-49180. Nils Emmerich je nalezl koncem března a dnes publikoval detaily.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.4 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
UN Open Source Week 2025 probíhá tento týden v sídle Organizace spojených národů v New Yorku. Středeční a čtvrteční jednání bude možné sledovat na UN Web TV.
Byla vydána nová verze 2.50.0 distribuovaného systému správy verzí Git. Přispělo 98 vývojářů, z toho 35 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Infrastrukturu pro chatovací aplikaci Telegram provozuje člověk s vazbami na ruské zpravodajské služby. Upozorňují na to investigativní novináři z redakce iStories. „Vedneev dodává služby ruskému státu včetně jeho jaderného institutu nebo zpravodajské službě FSB,“ říká v podcastu Antivirus novinář Jan Cibulka. Uživatelům, kteří si chtějí své informace chránit, doporučuje Telegram vůbec nepoužívat, a raději zvolit jednu z alternativ, WhatsApp nebo Signal.
Český AI startup Rossum.ai, který má kořeny v české open source komunitě, otevřel veřejnou verzi svého HTTP API pro univerzální vyčítání údajů z faktur. V omezeném objemu je vyčítání faktur pro všechny zdarma, dokumentace je k dispozici na Apiary.
Tiskni
Sdílej:
Nejkomičtější na tom je, že dodavatel často pošle do jednoho cloudu strojově čitelná data, aby mu to z nich vyrobilo fakturu v PDF. A jeho zákazník pak toto PDF1 pošle do jiného cloudu, aby mu to z něj vyrobilo strojově čitelná data. To je panečku pokrok a smysluplné využití moderních technologií!
[1] Další úroveň je vložit do toho ještě tiskárnu a skener.
UNA:+.? ' UNB+IATB:1+6XPPC:ZZ+LHPPC:ZZ+940101:0950+1' UNH+1+PAORES:93:1:IA' MSG+1:45' IFT+3+XYZCOMPANY AVAILABILITY' ERC+A7V:1:AMD' IFT+3+NO MORE FLIGHTS' ODI' TVL+240493:1000::1220+FRA+JFK+DL+400+C' PDI++C:3+Y::3+F::1' APD+74C:0:::6++++++6X' TVL+240493:1740::2030+JFK+MIA+DL+081+C' PDI++C:4' APD+EM2:0:1630::6+++++++DA' UNT+13+1' UNZ+1+1'To vzniklo někde na sálových počítačích, ne?
Existuje i XML varianta nebo pak ten ISDOC. Nicméně pointa je v tom, že je to nějak definovaný formát, jsou pro něj napsané knihovny a stačí je použít. Zrovna ten ISDOC podporují snad všechny účetní programy, které se tu používají.
Chápu ten byznys model (už před lety jsem viděl průzkumy, kolik peněz velké firmy vyhazují za přepisování faktur) a možná je to i lepší než aby spousta lidí seděla u počítače a opisovala čísla z obrázku do formuláře… ale stejně je mi trochu smutno z toho, k čemu se potenciál technologií používá. Když se to to člověk podívá trochu s odstupem třeba jako nějaký mimozemšťan, tak z toho lidstvo vychází opravdu hloupě – část lidí generuje problém a část lidí se ho pokouší řešit – vyplýtvají na to obrovské množství prostředků, místo aby se dohodli. A jak jsem psal ve vedlejší diskusi, mám trochu obavu, aby technologie tohoto typu nezafixovala současný špatný stav a neudělal z něj normu (protože lepší a čistější řešení nebude už tak akutně potřeba). Tak snad to bude aspoň k něčemu a časem najdete smysluplnější využití pro to, co se naučíte na fakturách.
Ano, máme EDI, UBL, ISDOC, ... a to už desítky let, ale přesto si stále vyměňujeme PDFka. Je potřeba přemluvit mnoho článků v hodně konzervativním procesu, a změna většina článkům řetězce nepřinese moc výhod.Chápu, že je složité, přehodit se z „defaultně lidsky čitelného“ PDFka na nějaký úplně jiný formát. Fascinuje mě ale, že lidstvo nedokáže dát do rohu toho PDFka malý QR code. Faktura by vypadala a šla zpracovávat (člověkem) pořád stejně, ale současně by to šlo strojově.
Dalsi zadrhel, ktery komplikuje spoustu "strojove citelnych" dat na fakturach, je adversarialni dodavatel, ktery vygeneruje fakturu, kde bude neco jineho v QR kodu nez lidsky citelne.No, ne, že by zrovna dnes používané neuronky byly nějak odolné třeba proti adversariálním pixelům ;)
121655448894
kus čísla účtu, nebo variabilní symbol? Nebo číslo zakázky?Variabilní symbol (uvádějte při platbě): 2111800075 Konst.symbol: | 308 Stranač. 1 Faktura - daňový doklad č.: FVCN-75/2018 Dodavatel: Odběratel: Zákaznické číslo: Brmlab z.s. CM PROPERTY, s.r.o. K Žižkovu 282/9 19000 Praha 9 Brmlab z.s. IČ: 05778042 Bubenská 1477/1 DIČ: CZ05778042 170 00 Praha 7 Česká republika Doprava: Úhrada: © Na bankovní účet x Banka: Česká Spořitelna a.s. IČ: 22860657 Číslo účtu: 500026012/0800 Datum vystavení dokladu: 9.4.2018 Datum splatnosti: IBAN: © CZ4308000000000500026012 Datum zdanitelného plnění: 25.3.2018 SWIFT: GIBACZPX Místo plnění: CZ 29.4.201 8 Předmět zdanitelného plnění Množství /j. © rozk koz DH a vš Cena UBez koukání do rejstříku a bez googlení z toho demangluj, kdo kde sídlí a jaké má IČ.