Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Dokonce i s matematikou si docela poradí a není to povětšinou nijak tragické.Nic moc. MathJax to umí lépe.
Mathjax má zabalený nějakých 17 MB
OMG. A i bez toho mi přijde lepší generovat ty vzorečky offline – vyrobit z nich jednorázově nějakým generátorem HTML+CSS+JS+SVG a ne to renderovat všechno až na klientovi.
<span class="cmti-10">regul</span><span class="cmti-10">á</span><span class="cmti-10">rn</span><span class="cmti-10">í</span>tenhle problém řeším v make4ht s pomocí filtrů
Tohle je určitě zajímavý postup.
Zajímavý je a rád jsem si to přečetl. Ale vyrobit PDF a z něj pak vytáhnout zase prostý text, mi nepřijde jako moc čisté řešení.
Dílem proto, že konverze z TeXu není v principu možná bez stejné interpretace textu, jakou provádí TeX samotný: TeX si totiž pomocí přečtených maker sám určuje, jakým způsobem bude číst další řádky zdrojového textu a jak je bude interpretovat.Ano, musi to delat nejaky TeX backend, ktery ma informaci jak interpretovat co chtel autor textu rici.
Pomocí pdfTeXu vytvořím PDF soubor, který obsahuje kompletní HTML kód. Pak stačí pomocí příkazu ... z něj udělat HTML soubor.Tohle sice funguje, v mezich mozneho je to i elegantni, nicmene je to stale drbani se levou nohou za pravym uchem.
Podotknul bych pouze, že řešení, které ze skoro každého vzorečku vygeneruje pro HTML stránku obrázek, mi připadá poněkud humpolácké: textové písmo pak ve www prohlížeči vizuálně nenavazuje na písmo ve vzorečku. Konverze do MathML nebo něčeho podobného je tedy žádoucí. Bohužel ani 15 let po vzniku MathML není tento jazyk implementován ve všech běžných webových prohlížečích, což odrazuje od dalších aktivit.
Ačkoli jsem matematik, osobně se vyhýbám vzorečkům v HTML stránkách jako čert kříži. Takže ani v následující ukázce tento problém neřeším. Důvody byly řečeny před chvílí.
Hlavu do písku samozřejmě strkat můžeme, ale popularita malých čteček podporujících EPUB a současně nevhodných pro prohlížení PDF je prostě fakt. Vzhledem k nepodpoře MathML ve WebKitu a velikosti/náročnosti skriptů jsou obrázky celkem jasná volba.
Už jsem se na to ptal minule: šlo by udělat SAX parser pro TeX? Který by četl zdrojový soubor TeXu a emitoval události typu:
Takže ze zdroje:
\sec Nadpis text
by vylezlo např.
<command name="sec">Nadpis</command> <paragraph>text</paragraph>nebo lépe
<sec>Nadpis</sec> <paragraph>text</paragraph>
(samozřejmě ne jako textový výstup ale jako SAXové události)
Nemuselo by se jít nijak do hloubky, dovnitř maker – stačilo by zpracovat značkování, které je přímo ve zdrojovém dokumentu. Případně by se nějak definovala makra, která se ještě mají interpretovat (např. makro, které vypisuje název firmy, ano, zatímco jiná makra ne).
Kdyby existoval takovýhle obecný nástroj, tak by se daleko lépe daly psát další konvertory, které by tyhle jednoduché události zpracovaly a generovaly různé další formáty.
Ale přijde mi to celkem složité, protože to není jen \něco
, ale i \něco[…]{…}
, \něco[a=1, b=2, …]{…}
nebo třeba \verb|…|
případně \scalebox{-1}[1]{F}
atd.
Jde mi o tu myšlenku generování různých výstupů z jednoho vstupního formátu – proto se taky ptám pod tímhle článkem. I když musím říct, že se čím dál víc taky uchyluji myšlence: DocBook nebo nějaký vlastní XML formát jako obecný zdroj + generování různých výstupů (z nichž jeden je TeX/LaTeX a následně PDF).
Akorát je pak trochu potíž, když napíšeš třeba diplomku, vygeneruješ si z ní ten LaTeX a PDF a zjistíš, že by tady ještě chtěla typografie nějak doladit, manuálně zasáhnout do vygenerovaného .tex
souboru. U té diplomky to ještě jde, tu vydáš jednou a hotovo, ale třeba taková firemní dokumentace – tu je potřeba aktualizovat, vydávat nové a nové verze. Tam pro manuální zásahy není prostor, to by člověka umořilo a stejně by na to občas zapomněl.
Tohle by mělo jít řešit pomocí něčeho jako instrukce pro zpracování (nebo přímo pomocí nich), kde byl uvedl příkazy/kód pro ten který výstupní formát a při generování ostatních by se to ignorovalo – takže by šlo do zdrojového formátu vložit kus i TeXu nebo kus XHTML, pokud by to bylo potřeba. A ručním změnám generovaného výstupu by se šlo teoreticky úplně vyhnout.
git diff
je v pohodě čitelný. Výstup do PDF je v podstatě čistý LaTeX (a můžeš vkládat přímo kusy LaTeXu v editoru). Výstup do HTML skrz (na začátku diskuse zmíněný) eLyxer je docela pěkný (včetně obrázků), asi by to jen chtělo přidat "firemní" CSS. Ale krom toho má LyX i nativní export do HTML, který je mnohem zajímavější, pokud to s ním myslíš vážně. V LyXu totiž je k layoutu (odstavec, nadpis, seznam,…) definováno, jak bude vypadat v LyXu (WYSIWYG editoru), jak v LaTeXu a jak v HTML (a možná i v něčem dalším). Takže můžeš přidávat vlastní konstrukce (styly) do dokumentu a přitom nepřijdeš o možnosti exportu.
Druhou možností na psaní dokumentace, o které uvažuju, je Markdown. Je docela rozšířený a pokud jde o text přiložený přímo k programu a zobrazovaný v něm (nápověda), je nepraktické vyžadovat LyX či podobné "velké" nástroje. Ale zas Markdown není rozšiřitelný a kdo si má pamatovat, jak se co vlastně formátuje.
Druhou možností na psaní dokumentace, o které uvažuju, je Markdown.Zmineny reStructuredText a Sphinx.
zjistíš, že by tady ještě chtěla typografie nějak doladit
Tvoje starosti a Rothschildovy prachy...
Jde mi o tu myšlenku generování různých výstupů z jednoho vstupního formátu – proto se taky ptám pod tímhle článkem.Protože XSLT je ještě o něco méně čitelné, než TeXová makra?I když musím říct, že se čím dál víc taky uchyluji myšlence: DocBook nebo nějaký vlastní XML.
<xsl:template match="a[ starts-with(@href, 'http://') or starts-with(@href, 'https://') or starts-with(@href, 'ftp://') or starts-with(@href, 'mailto:') ]"> … </xsl:template>a ostatní se zpracují buď jinou šablonou nebo se přeskočí nebo z nich zbude jen text. Jde tohle udělat pomocí TeXového makra? Nebo bych musel předefinovat celý příkaz (bez ohledu na jeho parametry/obsah) např.
\url
a dovnitř nacpat nějaké IFy?
V tomhle má obrovskou výhodu XML a XHTML (případně i olomítkované HTML5), kde nemusíš rozumět významu značek a přitom to můžeš zpracovat.Hahaha!
Jenže co když se mi v tom PDF objeví třeba poznámky pod čarou nebo po straně nebo něco jiného, s čím jsem při tvorbě HTML maker nepočítal? To mi pak úplně rozbije ten výstup, který vznikne převodem PDF na prostý text.
Ten SAX parser by právě umožňoval ty věci, kterým navazující nástroj nerozumí (nebo nechce rozumět) prostě přeskočit, ignorovat a odchytávat si jen ty značky/příkazy, které mě zajímají a které umím v tom kterém výstupním formátu vykreslit.
Poznamky pod carou by se daly nechavat v pameti
Jenže na se právě musím připravit předem – nejde to použít na obecný TeXový dokument.
Ještě mne napadla jedna věc: z TeXu se přece dají volat shellovské skripty nebo obecně příkazy, ne? Tak bych mohl předefinovat jen vybraná makra (která chci generovat v tom výstupním formátu) a na nich vždycky zavolat příkaz operačního systému, který by nějak obalená data poslal do souboru nebo nějaké roury – nezajímal by mě pak výstup pdflatexu, ale výstup těch příkazů postupně volaných z maker. Akorát by to znamenalo postupně spustit spoustu procesů (pro každý TeXový příkaz/makro, pro každý odstavec…).
Pak by tomu šlo podstrčit libovolný dokument v TeXu a filtrem by prolezlo jen to, co bych předem definoval – ostatní formátování by se zahodilo/přeskočilo.
Já měl vždycky poznámky pod čarou na konci dané stránky, ale i bez toho, bys tam měl1, což by ti pak zaplevelilo to HTML, které bys chtěl získat převodem PDF na text, a vlastně i ty poznámky na konci knihy by tam dělaly bordel.
[1] to číslo v textu, které odkazuje na poznámku
Moc jsme to nezkoumal, ale ConTeXt umí XML...
http://tex.stackexchange.com/questions/43052/converting-context-document-to-html
% Hlavička HTML: \def\html{{\everypar={}\parskip=0pt\Blue {\typoscale[700/700] <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/1998/REC-html40-19980424/strict.dtd" >\endgraf \tag{html lang="cs"}\endgraf \tag{head} <meta http-equiv="Content-Type" content="text/html; charset=UTF8">\endgraf \noindent\tag{title}Mathjax test\tag{/title}\endgraf \tag{script type="text/x-mathjax-config"} % MathJax \mjcode\endgraf \tag{/script} \tag{script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML\string_HTMLorMML"} \tag{/script} \tag{/head}\endgraf} \tag{body}\endgraf\Black}\bigskip\bigskip} % Inicializační kód MathJaxu \def\readmeaning#1->#2\end{#2} \def\mjcode{\bgroup\catcode`\#=12 \mjcodeA} \def\mjcodeA#1{\def\mjcode{#1}% \xdef\mjcode{\expandafter\readmeaning\meaning\mjcode\end}\egroup} % de-tokenizace \mjcode{ MathJax.Hub.Config({tex2jax: {inlineMath: [["\\$","\\$"]]}}); MathJax.Hub.Config({ TeX: { Macros: { "\(": "\\left(", "\)": "\\right)", bold: ["{\\bf #1}",1] } } }); } % Použití MathJaxu: \mj$...matika...$ nebo \mj$$...display matika...$$ \def\mj$#1${\if^#1^\expandafter\displaymj \else \printmj{\string\$}{#1}\fi} \def\displaymj#1$${\endgraf \notagindent\printmj{\string$\string$}{#1}} {\catcode`&=12 \gdef\printmj#1#2{\def\tmpb{#2}% \edef\tmpb{\expandafter\readmeaning\meaning\tmpb\end}% de-tokenizace \replacestrings{&}{&}% citlivé HTML znaky nahradím entitami \replacestrings{<}{<}\replacestrings{>}{>}% {\tt#1\tmpb#1}} }Makra předpokládají, že před každým vzorečkem ve zdrojovém textu je napsáno \mj, tedy \mj$...matika...$ nebo \mj$$...matika...$$. Mohl bych to sice dát do \everymath a \everydisplay, ale někdy je lepší to mít pod vlastní kontrolou. Do html stánky přepíše makro doslova stejný vzoerec obalený \$...\$ nebo $$...$$. Je to jiné, než v TeXu, protože v html potřebuji, aby se samotný $ choval normálně. Návrh v dokumentaci MathJaxu použít \(...\) jsem nevyužil, protože tyto sekvence používám na zvětšovací závorky.
Tiskni
Sdílej: