Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Používám openoffice už léta, nejvíce textový procesor. Mám ale problém, když uložím dokument v linuxu a pak ho otevřu ve stejné overzi ooffice ve windows, tak je rozházené formátování, dokonce když otevřu dokument na jiném linuxovém systému ve stejné verzi openoffice, tak je problém s formátováním, pokud něco jednoduchého kreslím či vytvářím vzorce, občas se stane, že když znovu otevřu dokument na stejném systému ve stejné verzi ooffice, tak má rozházené formátování. Proto se ptám, opravdu je openffice takový "šmejd" nebo se dá někde nastavit nějaké zafixování či provést některé nastavení?
to mohu jen potvrdit, používám mnoho instalací 2x i 3x řady na počítačích s Windows i Linuxem a nikdy jsem se s takovým chováním nepotkal
O tomhle jsem kdysi slyšel u ms wordu, tak jsem do docu vkládal nastavení i fonty a přežilo to. S oo zatim bez problému.
mne sa stava cosi podobne s tym ze zvacsa su to dokumenty od microsoftu ktore takto rozhadzuje ... z 10 stran v .doc som videl ako oo spravil peknych rozhadzanych 13 :(
Tipoval bych buď jinej font, než jim to bylo vytvořené nebo okraje? Jak to vidíte vy?
No podívám se zda by něco nešlo nasdílet, většinou se jedná o důverná data. Pokud potřebuju dokument někde otevřít, tak ho radši exportuju do pdf, kde se formátování logicky nemění. CO se týče toho formátování, jedná se např. o to, že jsou posunuté obrázky, když využívám kreslící fce, tak pokud "spojuji" nějaké úsečky, tak jsou někdy rozpojené a o kousek posunuté(proto teď raději fixuju vše dohromady), po otevření dokumentu vytvořeného v linuxu ve windows je zpravidla více "roztáhlý text", takže je více stránek, přitom písmo je stejné. Zjistil jsem, že částečně pomůže nastavit ve windows nějaké jiné formátování, ale taky to neni ono.
A formátování to blbne hlavně v tabulkovém kalkulátoru, v textovém procesoru tolik ne.
No ale nejvíce mi asi vadí to, když v tabulkovym kalkulátoru něco nakreslím a pak dám náhled, tak se to někdy celý rozhází. Stávalo se to u starších verzí a u nejnovější taky.
No jestli se jedna o "duverna" data, tak mozna pracujes pro vetsi firmu - hadam spravne? Ja mel s OOo nejvetsi problemy s .doc dokumentama ktery vznikly z korporatni sablony. Tzn. pokud .doc dokument obsahuje sablonu, ktera obsahuje vlastni styly, fonty, hlavicky, paticky atd, ... tak OOo proste zmagori. Nespadne, ale neni schopny s temahle udajema pracovat.
OO pro Linux se chová na svých formátech korektně , nesetkal jsem se s problémy , jen , když jsem upravoval 90 stránkový projekt , který byl v MS-2003 , tam to trochu naáhlo , udělalo jinak osnovu a odrážky , ale dalo se to nějak vytiskout... Ale pokud se jedná o OO to OO pak vždy bez problémů. S OO verzí od Novellu s tím probléby nebývaly ... nepoužívám verzi z OO , ale verzi , kterou vydává Novell ... sice je o cca 200MB větší , ale pracuje jak má.
Možná formátování dle nastavené tiskárny - tam se to formátuje dle fontů a to je jasné , že se to může změnit.
Jak jsem již psal. Používám stejné fonty. V linuxu mám nainstalovaný Arial právě kvůli kompatibilitě s Windows.
Kde se to nastavuje?
Tak metriku tiskárny zaškrtlou nemám, ale našel jsem něco co může dělat problémy. Možná to používání systémového písma, kde mám nastavený v různých systémech různý hinting aj., pokud to nedělá tohle tak fakt nevím.
A přenášíš to mezi platformami jako odt? S doc to docela blbne, obzvláště pokud původní doc pochází ještě z wordu.
Jo, všechno v nativním formátu ooffice.
To souhlasí. V OO verzi 3.0.1 pod Llinuxem jsem měl dokument s vloženou tabulkou ve formátu .doc (a kdysi vytvořený ve Wordu), po provedení úpravy ta tabulka zmizela. Při práci se stejným dokumentem ve formátu .odt problém nebyl.
Nakonec když se člověk podívá, jakým způsobem bývají ty informace v docu naházené (stačí export do HTML), tak se ani nedivím, že s tím má OOffice problémy.
Ano, je :).
Tiskni
Sdílej: