Na Epic Games Storu lze do 15. června získat zdarma počítačovou hru PAYDAY 2 (ProtonDB, Wikipedie). Linuxový port přestal být ve čtvrtek 8. června podporován.
Ezoterický programovací jazyk Brainfuck (Wikipedie) slaví 30 let. Urban Müller nahrál první implementaci tohoto jazyka na Aminet 9. června 1993.
Společnost Apple na konferenci WWDC23 představila Game Porting Toolkit. Společnost CodeWeavers informuje, tento toolkit vychází ze zdrojových kódů jejího CrossOveru, tj. komerčního Wine.
Byla vydána květnová aktualizace aneb nová verze 1.79 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.79 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Jak to bude s podporou rastrového grafického formátu JPEG XL ve webových prohlížečích? Google ji nedávno z Chrome a Chromia odstranil (#1178058#c84). Jednou z novinek beta verze Safari 17 je ale právě podpora JPEG XL. Vráti se JPEG XL do Chrome a Chromia (#1451807)? Dění kolem JPEG XL lze sledovat například na r/jpegxl.
Byla vydána nová stabilní verze 6.1 (aktuálně 6.1.3035.51) webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 114. Přehled novinek i s náhledy v příspěvku na blogu. Nový Vivaldi se pro Bing tváří jako Microsoft Edge (upravený User-Agent) a díky tomu v něm funguje Bing Chat. Vylepšeny byly Pracovní prostory (Workspaces). Podrobný přehled v Changelogu.
Linuxová distribuce ArchLabs Linux po šesti letech vývoje končí. Dobbie to zabalil.
David Tschumperlé v obšírném článku se spoustou náhledů shrnuje vývoj multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie) za poslední rok a půl.
Vývojáři postmarketOS vydali verzi 23.06 tohoto před šesti lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, Plasma a Sxmo. Aktuálně podporovaných zařízení je 30.
Byla vydána distribuce openSUSE Leap verze 15.5 (poznámky k vydání). Jde o konzervativní distribuci odpovídající komerčnímu SUSE Linux Enterprise 15, nyní Service Pack 5. Mělo jít o poslední aktualizaci Leap v současné podobě před přechodem na Adaptable Linux Platform s „neměnným“ základem, ale padlo rozhodnutí, že v roce 2024 ještě vyjde Leap 15.6 s podporou do konce roku 2025.
V programu Gimp jsem si vytvořil obrázek a uložil ho do PNG. Potom jsem ho příkazem <pre> convert obraz.png soubor.pdf </pre> převedl do PDF. Výsledek byl v pořádku, pokud jsem předtím v tom Gimpu u obrázku nastavil velikost obrázku 595px krát 842px a velikost tisku 210mm krát 297mm. Pokud však v tom Gimpu u obrázku nastavím méně pixelů než 595 krát 842 (což u jednodužších obrázků potřebuji, abych ušetřil velikost souboru) a velikost tisku 210mm krát 297mm a uložím, tak potom se mi ten PNG blbě převádí do PDF - obrázek v tom PDF vznikne necelý a to ikdyž jsem zkontroloval, že PNG má pěkně celý obraz. Čím to je, že vznikají tyto zmetky? Měl bych ten příkaz upravit, a jak?
convert
se tím při převodu patrně řídí (nebo je tahle informace možná u bitmapových obrázků uložena i v tom PDF). Takže je potřeba velikost obrázku v pixelech a DPI nastavit tak, aby se vám obrázek na tu plochu papíru vešel.
V Open office by se to dalo, to už jsem taky dělal, ale nerad to pomocí toho dělám, protože když těch obrázků mám hodně, je to rychlejší dělat convertem.
Kde má png nastavené počet bodů na palec? Znamená to velikost obrázku a velikost tisku? Když jsem v Gimpu u toho obrázku nastavil velikost obrázku 595px krát 842px a velikost tisku 210mm krát 297mm, není potom problém png pomocí příkazu convert převést na PDF. Ale u jednodužších obrázků mi stačí v Gimpu nastavit méně pixelů, abych potom ušetřil kilobajtama. Když v tom Gimpu ale dám měně těch pixelů a velikost tisku zvolím zase 210mm krát 297mm, je potom ten problém, že při převodu na PDF pomocí příkazu convert, obrázek v PDF není celý. Aby byl celý, musel bych v tom Gimpu po ubrání pixelů nastavit i menší velikost tisku. To potom když z toho png udělám pomocí příkazu convert PDF, je obraz v PDF celý, ale je na pytel jiná věc - PDF je vzhledově malé; když potom budu jednotlivé PDF spojovat, je každý list jinak velký a to blbě vypadá. Já potřebuji obvyklou velikost PDF ikdyž ten png má jiný počet pixelů. Já vidím chybu někde jinde: Do toho příkazu convert asi potřebuji přidat nějaký přepínač nebo něco, což jsem neudělal. Jaký přepínač nebo něco, do toho příkazu mám přidat? Pokud je ještě jinde chyba, tak v čem?
convert
u nějaký parametr, který mu řekne, že výsledný „obrázek“ (PDF) má být větší, než ten, který konvertujete. Podívejte se na parametry -geometry
, -page
nebo -repage
. Pokud byste ponechal rozměry tisku v Gimpu na formát A4, pokusí se na tuhle velikost convert
obrázek zvětšit nebo zmenšit – a protože se zřejmě pokouší zachovat poměr stran (tj. čtvercový pixel, pochybuju o tom, že PDF umí obdélníkový pixel), musí se obrázek někde oříznout. Proto potřebujete správně přizpůsobit rozměry v cm i v pixelech (aby DPI zůstalo stejné).
Já ty poměry šířka k výšce v tom Gimpu přizpůsobuji dobře: Například udělám obrázek png, který má velikost obrazu 595px krát 842px a velikost tisku 210mm krát 297mm; ten se mi příkazem convert dobře převede do PDF. Když v tom stejném obrazu v Gimpu zmenším velikost obrazu na méně pixelů než předtím, a velikost tisku znovu nastavím 210mm krát 297mm; tak potom, když z toho chci pomocí příkazu convert vyrobit PDF, obraz na tom PDF je ořezaný a to hodně a dokonce z obou stran - z boku i z vrchu. Navíc v tom Gimpu, když jsem u toho obrazu před tím ubíral pixelů, ubral jsem schválně tak, aby poměr šířka v px k výšce v px se zachovala, počítal jsem to, takže to PDF jsem tím pádem do žádných obdélníkových pixelů nutit nemohl. Takže nevím, co to PDF pořád ořezává a ještě dokonce z obou stran - i do šířky i do výšky.
-density
convert
u. Ovšem zmenšovat či zvětšovat ty obrázky tak, aby se vždycky vešly právě na A4 podle mne není moc dobré, zvlášť jestli jsou to menší obrázky a budou se na A4 roztahovat, budou vypadat divně.
Parametr -density mi nefunguje: V Konzoli mám: <pre>[david@localhost pokusi]$ convert -density -resize 595x842 pokus210.png pokus210.pdf
convert: invalid argument for option `-resize': -density.
[david@localhost pokusi]$
</pre>
-density
hodnota.
Density je rozlišení? Tím pádem bych například mohl použit <pre>convert -density 72x72 puvodni.png cil.pdf</pre> Rozumím tomu dobře? Jinak - proč mi nefunguje formátování textu v této diskuzi? Já například správně napíšu značky pre a mezi ně něco napíšu a ve výsledku písmo nereaguje, jenom jsou vidět značky. Dříve mi formátování fungovalo.
Density je rozlišení? Tím pádem bych například mohl použitAno, je to tak.convert -density 72x72 puvodni.png cil.pdfRozumím tomu dobře?
Jinak - proč mi nefunguje formátování textu v této diskuzi? Já například správně napíšu značky pre a mezi ně něco napíšu a ve výsledku písmo nereaguje, jenom jsou vidět značky. Dříve mi formátování fungovalo.Protože jako nepřihlášený uživatel máte zapnutý WYSIWYG editor, ten by měl mít na kód atd. nějaké tlačítko v liště. Nezobrazuje tedy HTML tagy, ale rovnou výsledek. Zpět na editor zdrojového kódu mohou trvale přepnout jenom přihlášení uživatelé (nevím, zda je možné WYSIWYG editor přepnout do editace zdrojáku dočasně).
Tiskni
Sdílej: