Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Máme faktury a faktury mívají přílohy. Proces importu faktur do DMS je následovný :
PDF jde k záznamu v DMS párovat i ručně, nebo načíst z PC. Celý proces vypadá docela složitě, ale na druhou stranu je mnohem jednodušší, jak kdyby vše kolovalo v papírové formě a je to rozhodně přehledné. Taktéž se do DMS ukládají dokumenty, které jsou v SAPu, nebo v našem IS. DMS tedy spíš nefunguje jako takový SharePoint, ale jako čistě backend pro uložiště dokumentů. Ona firma i konečně dodává plugin do MS Office, aby šlo dokumenty upravovat přímo z DMS (něco jako má SharePoint), prostě ťuknu ve web ksichtu na dokument, otevře se word, upravím ho a dám "commit to dms" a je tam včetně nové revize. Nojo, za toto chce ta firma asi 40kkč :), takže zatím fakt ne a nelze tedy DMS uživatelsky takovým způsobem používat, což je docela škoda :-/.
Největší problém tohoto řešení je skenování dokumentů, resp. QuickScan. Tento sw dělá tři nemilé věci :
(program se spouští jako baťák s parametry : IF EXIST C:\scan-qs-dms\*.tif. ("C:\Program Files (x86)\EMC Captiva\QuickScan\QuickScn.exe" /scan profile=01-BW,overwrite=overwriteall))
Jinými slovy, QuickScan nám kazí celý proces. Náš dodavatel tvrdí, že se supportem není kloudná řeč, že to nehodlají opravovat a možná už se QuickScan nebude dál vyvíjet. Znají OCR sw, který toto umí, ale stojí třeba 40kkč i více.
Nabízí se tedy otázka, zda někdo nezná lepší způsob, jak toto řešit. Nebo zda někdo nezná "levnou" náhradu za QuickScan, popř. i opensourcovou? :). Já to vidím tak, že nám firma dodala nefunkční řešení (QuickScan), tudíž to je na jejich bedrech. Osobně ale neznám pozadí (smlouvy apod. věci), takže jelikož jsem byl požádán o návrh řešení (samozřejmě jsem reagoval ve stylu, že to by měla navrhnout ona firma), tak sonduji. Nevadí, když to bude placený pro win, nebo pro lin, hlavní je funkčnost a cena :). Samozřejmě bych dal přednost nějakému OSS řešení.
Požadavky tedy jsou :
- schopnost číst čárový kód (třeba i pootočený)
- na základě čárového kódu vyjmout z tiff souboru všechny stránky tak, jak jdou za sebou a převést je do pdf do té doby, než narazí na další čárový kód, poté vytvořit nový soubory zase do něj nasypat všechny stránky, co jsou za ním atd.
- umožnit filtrování čárových kódů (nejlépe tedy podle začátku - prefixu a podle délky, prostě tak, aby nedocházelo k neřešitelným kolizím)
Pro zajímavost, přemýšlelo se jednu dobu i nad Alfresco DMS, který má SAP connector, ale jednak by to vyšlo ve výsledku asi i dráž, ale hlavně se hledělo na to, aby nám to byla schopna rozchodit nějaká firma, co s podobnými procesy má zkušenosti a má ověřené funkční řešení, tedy nic, co by někdo řešil za pochodu. Pokud by měl někdo dotazy v podobnéch duchu, tak věřte, že budou nezodpovězeny, jelikož já jsem malý červ a výběr řešení a další věci připadli někomu jinému, takže ani nevím, co vše bylo ve hře, z čeho všeho se vybíralo atd.
Zdar Max
Tiskni
Sdílej:
Už jsem podobné řešení viděl jinde, takže mne to ani moc nepřekvapuje, ale neodpustím si komentář: myslím, že tohle pěkně ukazuje, jak jde současný svět do prdele – máme rychlé připojení k Internetu resp. propojení skoro všech počítačů na planetě, máme rychlé mnohajádrové procesory, terabajtové disky, spousty GB operační paměti… a co s tím děláme? Tiskneme a posíláme si papírové faktury, zaměstnáváme člověka, který je strká do skeneru, OCRkujeme, rozpoznáváme čárový kód (který jsme předtím vytiskli a nalepili) a pak to stejně asi někdo opisuje z bitmapy do formuláře nebo minimálně kontroluje jestli se to OCRkovalo správně… Místo aby jedna firma poslala druhé třeba jednoduché XMLko opatřené elektronickým podpisem, na druhé straně se to automaticky spárovalo s objednávkou a automaticky nebo ručně schválilo a zadal se automaticky příkaz k proplacení. Tohle se mohlo dělat už v devadesátých letech na 486kách nebo dřív, kdyby lidi nebyli blbci a nepoužívali počítače jako psací stroje.
Místo aby jedna firma poslala druhé třeba jednoduché XMLkoNekdo uz zminil ten EDIFACT, tedy presne to co pisete. Je to bohuzel nezaplatitelne a kdo to nekdy zavadel vi, jak komplikovana zalezitost to je. Bezna praxe dnes je, ze mala firma posila i nadale papirovou fakturu a 'specializovany prostrednik' ma lidi, kteri to prectou a vytvori ta strukturovana data a ty pak posilaji dal. To samozrejme take neco stoji a zazil jsem pripady, kdy firma obchod s nejakym zakaznikem radeji vzdala, nez by platila tu 'infrastrukturu' pri zasilani faktury.
na druhé straně se to automaticky spárovalo s objednávkoutohle vyzaduje umelou inteligenci - to je proste v praxi u vetsiny firem nemozne. Jeste tak v pripadech, kdy je predmetem obchodu jedna polozka.
tohle vyzaduje umelou inteligenci - to je proste v praxi u vetsiny firem nemozne. Jeste tak v pripadech, kdy je predmetem obchodu jedna polozka.
Co mi chodí faktury (i od celkem malých obchodů) tak tam bývá kromě čísla faktury i číslo objednávky1, takže bych si to v pohodě spárovat mohl. A v ISDOCu je taky políčko pro odkaz na objednávku – příklad:
<OrderReferences> <!--Nepovinná hlavičková kolekce objednávek pro případnou vazbu --> <OrderReference> <!--Objednávka #1--> <SalesOrderID>OP-111222/2008</SalesOrderID> <!--Vlastní ident. objednávky přijaté u dodavatele--> <ExternalOrderID>OV-123111/2008</ExternalOrderID> <!--Ext.č.obj.přijaté, typicky obj.vydaná odběratele--> <IssueDate>2008-01-03</IssueDate> <!--Datum vystavení objednávky přijaté u dodavatele--> </OrderReference> <OrderReference> <!--Objednávka #2--> <SalesOrderID>OP-111223/2008</SalesOrderID> <ExternalOrderID>OV-123112/2008</ExternalOrderID> <IssueDate>2008-01-20</IssueDate> </OrderReference> </OrderReferences>
A pak jsou případy, kdy chodí faktury bez objednávky2 – např. pravidelné účty za elektřinu nebo telefon – a tam zase stačí nastavit pravidlo, že pokud se částka vejde do nějakého měsíčního limitu, tak se faktura automaticky schválí a zaplatí, jinak to dostane někdo k ručnímu schválení/revizi.
Tragikomické na tom je, že všechny potřebné údaje v těch počítačích máme, často i ve strojově čitelné formě v nějaké databázi, jen se pak cestou ta informace ztratí, převede na strojově nečitelnou – a pak se to na druhé straně musí zase pracně převádět zpět, aby tomu druhý informační systém rozuměl.
[1] které znám, protože jsem to objednával, akorát ho nemám zanesené v žádném systému, protože toho je málo a řeším vše ručně
[2] resp. tam zase může být číslo smlouvy, podle kterého se to spáruje
Otázka je jak bude vypadat trh práce, když zničehonic příjdou o práci stovky opisovačů
zbar - http://zbar.sourceforge.net/ - čtení čárových kódů mnoha typů. Umí číst jak ze souboru, tak ze zařízení (webkamera). Jednou dobou jsem webkamerou scanoval QR kódy z Androidu a funguje to na jedničku. Má to GUI, ale může běžet i v konzoli. Buď se ukončí po přečtení prvního kódu, nebo čte kontinuálně (natočím webkameru na další kód a ten se vypíše na konzoli).
Konkrétně QR kód jsem zkoušel vytisknout, naskenovat a předat obrázek programu. Pod 200dpi byly občas problémy se čtením, při 300dpi fungovalo čtení na jedničku i když jsem QR kód přečmáral propiskou. Myslím že by stálo za pokus zařadit do cesty imagemagick a skenovat jen výřez místa, kde by měl být kód - zbaru chvilku trvalo, než se tím obřím souborem prokousal.
K požadavkům:
- zbar, volitelně imagemagick
- imagemagick
- grep, wc, možná sed
....a všechno samozřejmě poslepovat pořádným lepidlem - BASH.
a nešlo by ty dokumenty dělit prostě jen podle toho prefixu. To OCR by mohlo rozeznávat znaky lépe než čárový kód, píšete, že jste omezili identifikační oblast, takže by mělo jít jen o dostatečně exotický prefix.
Jinak, to dělení dokumentu je fakt dobrá finta.