Byla vydána Java 26 / JDK 26. Nových vlastností (JEP - JDK Enhancement Proposal) je 10. Odstraněno bylo Applet API.
Byla vydána nová verze 260 správce systému a služeb systemd (Wikipedie, GitHub). Odstraněna byla podpora skriptů System V. Aktualizovány byly závislosti. Minimální verze Linuxu z 5.4 na 5.10, OpenSSL z 1.1.0 na 3.0.0, Pythonu z 3.7.0 na 3.9.0…
Byla vydána nová verze 5.1 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v poznámkách k vydání. Videopředstavení na YouTube.
Bylo oznámeno vydání nové verze 8.1 "Hoare" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Doprovodný příspěvek na blogu Khronosu rozebírá kódování a dekódování videa pomocí Vulkan Compute Shaders v FFmpeg.
Byl představen open-source a open-hardware prototyp nízkonákladového raketometu kategorie MANPADS, který byl sestaven z běžně dostupné elektroniky a komponent vytištěných na 3D tiskárně. Raketa využívá skládací stabilizační křidélka a canardovou stabilizaci aktivně řízenou palubním letovým počítačem ESP32, vybaveným inerciální měřicí jednotkou MPU6050 (gyroskop a akcelerometr). Přenosné odpalovací zařízení obsahuje GPS,
… více »Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.
SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
Odesíláte e-maily v HTML?
| ano |
|
19% (297) |
| ne |
|
77% (1190) |
| nevím |
|
4% (61) |
Celkem 1548 hlasů
Vytvořeno: 30.3.2008 19:07
Tiskni
Sdílej:
chybí mi "jak kdy",To spadá pod "ano", ne?
Já když svým partnerům odpovím v čistém textu, tak nadávají, že tohleto a támhleto nemají podtržené a zase tohle by chtělo zdůraznit a napsat velkým písmem ...majitelka firmy - největší zákazník má špatné oči ... takže jasná volba. Téměř vždy HTML
má špatné očiTak ať si zvětší písmo ve svém klientovi... Jinak když mám poslat formátovaný dokument, tak RTF nebo PDF

Výjimečně.
Ne, proti HTML e-mailům nic nemám, pokud je to vhodné (ceníky s obrázky), ale když mi někdo pošle mail s obrázkem dopisního papíru na pozadí a jako font použije nějaký Comic Sans (či podobné), tak mi to už vadí.
ti nekdo zaskrtne "
), byly tam 3 věty bez jakéhokoliv formátování. Jinak BFU běžně posílají fotky v 2MB doc (!), i když je jasné, že třeba z jejich foťáku vypadne jpg.
Snad si to paní na druhém konci drátu příště rozmyslí.
> To nic není, mně přišel o víkendu spam (od české firmy) s 4 MB docem.To nič nie je. Najväčšou perlou, ktorú som dostail mailom, je "Return Receipt" s veľkosťou 242kB. Ministerstvo zdravotníctva SR zjavne používa Lotus Notes, ktoré potrebujú takmer štvrť megabajtu, aby povedali "Vaša správa bola prečítaná".
Nebylo by asi na škodu vytvořit navazující anktetu, která mě v souvislosti s maily hned napadla: Používáte diakritiku v mailu? Já osobně jen když mi příjde mail od osoby, která ji použila nebo v případě, kdy je zcela jasné, že nebude příjemci činit problém.
Return-Path: X-Original-To: Delivered-To: Received: To: Subject: =?UTF-8?B?Tm92w6kgcMWZaWhsYcWhb3ZhY8OtIGl uZm9ybWFjZSBwcm8gRnJhbnRhIG5hIE4=?= =?UTF-8?B?ZW9maWNpw6FsbsOtIGtsdWIgcMWZw6F0ZWwgZUJhbmt5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BitDopis pak obsahuje text v UTF-8. Na tom vidíš, kde je dvakrát deklarováno kódování (dvě úrovně). A pak je tam ještě jednou - v předmětu (u jména odesílatele a příjemce se to dělá stejně). Dnes není problém posílat (a přijímat) e-maily s diakritikou. A to nejen v těle zprávy, ale i v předmětu nebo ve jméně odesílatele/příjemce. Takže pišme s diakritikou, lépe se to čte.
Proto nic nezkazite mailem bez diakritiky.Zkazí - jednak obtěžuje příjemce tím, že musí číst hůře čitelný text a jednak pomáhá udržovat ten mizerný stav softwaru - když se lidem budou špatně zobrazovat maily, časem jim dojde, že by si měli pořídit lepší software (postfix, KMail, Thunderbird...) nebo si ho aspoň správně nastavit.
(nabízí se např. XML)Dalo by se použít XHTML a jeho < blockquote > a tam, kde sémantické značky nejsou (asi patička) by stačilo dohodnout nějakou CSS třídu pro označení daného blokového elementu. S tím rozbalováním a sbalováním by se mi to taky líbilo.
Dalo by se použít XHTML a jeho < blockquote > a tam, kde sémantické značky nejsou (asi patička) by stačilo dohodnout nějakou CSS třídu pro označení daného blokového elementu.Ale tady vůbec nejde o vzhled! To už si zařídí klient (tedy poštovní klient) sám. Jde o to, aby věděl, kde ty části zprávy jsou -- jejich formátování je druhá věc, na té první nezávislá. A nejde jen o citaci, jde třeba i o záhlaví vložených zpráv. Takhle vidím ta záhlaví, která mi tam pošle odesílatel, ale co když chci vidět jen některá?
S tím rozbalováním a sbalováním by se mi to taky líbilo.Jsou klienty, co to umí. Ale podle mě se to (to = jakákoli práce se zprávou formátovanou v ASCII-artu) příliš složitě implementuje (regulární výrazy, mnoho úprav řetězců atd.), a tak se do toho nikdo moc nehrne, protože z toho vždycky koukají problémy (nestandardní formátování, např. jiné značky než "> " atp.). Kdyby to bylo třeba v tom XML, tak zpracovatele XML má ve standarních knihovnách kdejaký jazyk, takže by se vývojář klienta staral jen o práci s obsahem uzlů -- a nikoli o samotné uzly (potažmo formátování ASCII-artem).
Ale tady vůbec nejde o vzhled! To už si zařídí klient (tedy poštovní klient) sám. Jde o to, aby věděl, kde ty části zprávy jsou -- jejich formátování je druhá věc, na té první nezávislá.Však v XHTML definuješ jen význam a o formátování se postará až CSS. Pokud styl není, použije se výchozí styl prohlížeče/klienta. To je jako když uděláš jednoduchou HTML stránku s H1, STRONG, UL, OL... tam si to taky prohlížeč naformátuje po svém a ty uvádíš jen význam elementů. Zavádět XML formát zpráv by bylo fajn, ale to bychom rovnou mohli přepsat protokol SMTP, aby pracoval s XML požadavky a odpověďmi místo těch zastaralých
klíč: hodnota asi by to za to stálo, ale je to spousta práce.
BTW: co máž proti přiložení celé MIME zprávy? Aspoň se k tobě dostanou všechny hlavičky.
Zavádět XML formát zpráv by bylo fajn, ale to bychom rovnou mohli přepsat protokol SMTP, aby pracoval s XML požadavky a odpověďmi místo těch zastaralých klíč: hodnota asi by to za to stálo, ale je to spousta práce.Nevím, já ty protokoly neznám, jsem jen uživatel (a jako uživatel navrhuju to, co jsem navrhl výše), ale myslím si, že by celá zpráva nemusela hned být v XML. Hlavičky by mohly zůstat, typ zprávy by se nastavil na XML a text zprávy by už byl v XML (jako se to teď dělá s HTML). Nicméně nechci spekulovat, nevidím do toho tolik.
BTW: co máž proti přiložení celé MIME zprávy? Aspoň se k tobě dostanou všechny hlavičky.Nelíbí se mi to; často někdo přiloží nějaký divný formát zprávy, plus se mi moc nelíbí, když mám víc v sobě vložených zpráv, přijde mi nepohodlné s tím pracovat.
Nevím, já ty protokoly neznám, jsem jen uživatel (a jako uživatel navrhuju to, co jsem navrhl výše), ale myslím si, že by celá zpráva nemusela hned být v XML. Hlavičky by mohly zůstat, typ zprávy by se nastavil na XML a text zprávy by už byl v XML (jako se to teď dělá s HTML). Nicméně nechci spekulovat, nevidím do toho tolik.Když už, tak by bylo přínosné do XML nacpat celou komunikaci, včetně všech hlaviček. Ale k tomu se jen tak nedohrabeme, protože současné SMTP a MIME funguje relativně dobře a bylo by to spousta práce.
Nelíbí se mi to; často někdo přiloží nějaký divný formát zprávy, plus se mi moc nelíbí, když mám víc v sobě vložených zpráv, přijde mi nepohodlné s tím pracovat.V současnosti to má pro (kompletní zpráva včetně hlaviček) i proti (vloženou zprávu si musíš rozkliknout v novém okně*). Ale ty nevýhody jsou čistě věcí klientů - šlo by to udělat tak, aby i vložené MIME zprávy zobrazovaly jako vložený text. *) Alespoň v klientech, které používám.
Když už by se to (XML) dělalo, tak by stejně umělo formátování. Takže XHTML se přímo nabízí. Dělal bys tak vlastní XML schéma, které by obsahovalo většinou značky, které už existují v XHTML. A pak bys třeba zjistil, že vyvíjíš ten nový formát jen kvůli tomu, abys přidal jednu značku pro patičky.Jenže XHTML nabízí spoustu zbytečností. Např. dělení dokumentu na HEAD a BODY -- to vůbec není třeba.
Když už, tak by bylo přínosné do XML nacpat celou komunikaci, včetně všech hlaviček. Ale k tomu se jen tak nedohrabeme, protože současné SMTP a MIME funguje relativně dobře a bylo by to spousta práce.Souhlasím, ale výměna formátu hlaviček nejde udělat ze dne na den...
Jak už jsem psal: většina diskutujících (ostatně včetně zadavatele ankety) by měla upřesnit, jestli myslí HTML only maily nebo multipart/alternative s jednou text/html a jednou text/plain alternativou. Za to první bych schvaloval použití tělesných trestů, to druhé je sice neefektivní, ale akceptovatelné.
P.S.: odkdy na odrážky potřebujete HTML?
http-equiv meta-element je jen berlička pro případ chybějící hlavičky HTTP odpovědi. V praxi to má na svědomí akorát zmatené stížnosti lidí, kteří si čertvíproč myslí, že má http-equiv mít přednost před hlavičkou HTTP odpovědi, případně o její existenci vůbec netuší.
Tak na Outlookáře mám jednoduchý, i když zdlouhavý recept: otravuji je tak dlouho dokud mi nezačnou posílat maily v prostém textu. 