Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Sorry, ale pokud človíček není odborník na TeX nebo (blablaTeX) tak je to opruz jen rozběhatPromiňte, ale opravdu je obtížné nainstalovat v linuxové distribuci TeXlive a spustit
pdfcsplain dokument
?
bože to je bordel ...Máte pravdu. Ovšem v uzavřených systémech je ten nános historie taky, jenom je to schované. A v pseudootevřených systémech (LibreOffice) je zmatek ještě větší, jen se Vám nechce v těch statisících až miliónech řádků kódu to hledat. A uživatelům se zdá, jak to krásně funguje, neboť směrem k uživatelům se dbá na to, aby byla vytvořena líbivá slupka. My TeXisté hrajeme s otevřenými kartami. Vnímáte ten rozdíl?
"Umí číst OpenType fonty, UTF-8 na vstupu, interně Unicode" - myslím, že jedině takhle to dává smysl pro používání v tomto století.Naprosto souhlasím. Bohužel ale není možné zahodit z distribuce TeXu vše, co s tímto pravidlem nemá co dělat s tím, že to novým uživatelům akorát znepříjemňuje život. Kromě nových uživatelů tu jsou totiž konzervativní TeXisté se svými obskurními makry závislými na interním kódování TeXu, které v té době použili, se svými fonty, které si třeba kdysi koupili, se znalostmi, které si kdysi přečetli a ta dokumantace tam je pořád. U 8bitových fontů jsem v článku jasně napsal, že čeština v Unicode TeXu nepojede. Kvůli těmto lidem se budeme muset smířit s tím, že v TeXové distribuci ten nános historie pořád bude. Já jsem CSplain přizpůsobil Unicode TeXům a je možné jej tedy používat i v tomto století. Vytáhnul jsem jej tedy z popela jako bájného Fénixe a přidal k němu OPmac.
a to vsechno je jen kvuli tomu, ze Knuth neumoznil menit svuj program?Nemáte pravdu. Knuth umožní měnit ten program, jen tu změnu nesmíte nazvat TeX. A skutečně, když se podíváte do tabulky na konci článku: v roce 2005 přišel formát OpenType a v roce 2006 jej umí číst XeTeX. Nebo Unicode Math: s tím přišel Microsoft v roce 2007, první implementaci měli v tom svém programu tuším v roce 2009 a Jonathan Kew to implementoval do XeTeXu v roce 2010. Dnes, pokud se nemýlím, Unicode math umí jen Microsoftí produkt (nebudu uvádět jeho jméno) a dále XeTeX a Luatex. Nic víc. Tím chci naznačit, že TeXisté jdou s dobou a Knuth neklade překážky.
bože to je bordel ...Máte pravdu. Ovšem v uzavřených systémech je ten nános historie taky, jenom je to schované. A v pseudootevřených systémech (LibreOffice) je zmatek ještě větší, jen se Vám nechce v těch statisících až miliónech řádků kódu to hledat. A uživatelům se zdá, jak to krásně funguje, neboť směrem k uživatelům se dbá na to, aby byla vytvořena líbivá slupka.
My TeXisté hrajeme s otevřenými kartami. Vnímáte ten rozdíl?
Ono to ovšem není tak černobílé. Velké naděje jsem vkládal v Lout, který ale Unicode také neumí a IMHO balancuje na hraně existence.
Pokud se zvolí XeTeX, pak pokud font obsahuje ligaturu fl, není třeba dělat vůbec nic, provede se automaticky. A i v PDF to bude správně a dohledatelné.Přečtěte si, prosím, pozorně, čeho se týká toto diskusní vlánkno a pak sem teprve něco pište. Problém je v tom, že v Unicode neexistuje ligatura flcaron. O ligatuře fl zde není řeč, tu umí automaticky vkládat i klasický TeX z roku 1982. Pomocí TeXových bastlících metod ala Knuth neexistenci flcaron sice snadno vyřešíme, ale s vědomím problémů, které jsem popsal.
Ostatně pokrok v sazbě i fontech nedělali amatéři, a věděli co dělají.V tomto kontextu je dobré si položit otázku, proč tito profíci přišli na to, že je potřeba figatury automaticky nahrazovat v sázecím systému, až nyní, zatímco v TeXu je tato vlastnost implementována už třicet let.
Jediný kvalitní výsledek je, že ligatury, které používáte jsou přímo součastí fontů. Cokoli jiného je zhoršení kvality.Kdybyste si přečetl, co jsem psal na počátku vlákna:
Připlácnutí čárečky k ligatuře fl pomocí makrer TeXu je samozřejmě možné a je to ta nejjednodušší věc, ale vždy to bude jen kompromis.shledal byste, že máme na věc stejný názor, takže další debata je zbytečná.
Nicméně stále zde je potřeba prohledávatelných PDF, které vyžadují, aby použité ligatury byly v tabulkách Unicode.Je problém, aby se ligatura pro účely vyhledávání mapovala na řetězec místo jednoho Unicode kódu?
Předpokládám, že aby to fungovalo, musí to podporovat jak font, tak sázecí program.Tedy jestli tomu dobe rozumim, musi to podporovat predevsim sazeci program, a pokud chyby podpora ve fontu, je nutne to doplnit jinak. Na zaklade techto informaci sazeci program vygeneruje ToUnicode tabulku, ktera je soucasti PDF dokumentu. Musite mit jeste samozrejme PDF prohlizec, ktery to podporuje. Pak staci pouzit:
\input glyphtounicode \input glyphtounicode-cmr \pdfgentounicode=1a v prohlizeci zalozenem na poppleru mi pak vyhledavani pro Type1 fonty chodi.
A ToUnicode table can be associated with a font that does not normally have a way to determine the relationship between glyphs and Unicode characters (some do). The table maps strings of glyph identifiers into strings of Unicode characters, often just one to one, so that the proper character strings can be made from the glyph references in the file.
pdftex -ini **\relax *\hsize=10cm \vsize=10cm \pdfoutput=1 *\font\f=csr10 *\f Tady je příklad vyhledatelného textu, to je finta. *\font\fa=cmmi10 \fa \char12 *\endTy hvězdičky jsou prompt, budete si povídat s pdftexem. Nemáte-li po ruce ISO-2 terminál, můžete si řádek ,,\f Tady je příklad ...`` vložit do souboru, překódovat jej pomocí iconv do ISO-8859-2 a místo uvedeného řádku napsat \input soubor. Potom se podívejte do výsledného texput.pdf. Zkuste vykopírovat text včetně symbolu beta (přes clipboard nebo pomocí pdftotext). Dostanete ho v Unicode. Například symbol beta má v Knuthově fontu cmmi10 pozici 12, ale po vykopírování dostanete jeho správný UTF8 kód. Stejně tak v prohlížeči půjde vyhledat slovo ,,příklad``, přestože písmeno ř od svého vstupu do sázecího programu až po výstup do PDF nepoznalo, co to je Unicode. Příklad se záměrně opírá o ini verzi 8bitového pdfTeXu (přepínač -ini), tj. bez jakýchkoli dopředu načtených maker, bez jakéhokoli překódování. Není použito žádné \input glyphtounicode. Proto například symbol beta není možné tisknout pomocí $\beta$, protože to není v iniTeXu definováno. Proč to funguje: font má v PDF downloadovány nejen glyphy, ale i jejich názvy. Knihovna na čtení PDF (např. poppler) má vlastní tabulku ,,názvy to Unicode`` a s tou při vyhledávání nebo vykopírovávání textů pracuje. Ostatně jsem to popsal i v závěru nového dílu tohoto seriálu. Můžete se za domácí cvičení ještě zamyslet nad ligaturou ve slově finta. Po vykopírování textu máte Unicode ligatury fi, třebaže v době vzniku fontu csr10 byl Unicode teprve vzdálená budoucnost. Všimněte si, co dělají vyhledávače textů: napíšete finta (bez ligatury), vyhledávač ve Vašem slově najde dvojici f a i, promění ji ve fi (podle Unicode) a takové slovo vyhledá.
Díval jsem se do specifikace PDF 1.7. strings of glyph identifiers into strings of Unicode characters
je zavádějící, protože popisuje spíše implementaci než algoritmus. Pro úsporu místa je možné místo párování jednoho glyphu na jeden znak párovat rozsah glyphů na stejně dlouhý rozsah nebo seznam code pointů. Odsud asi ony strings. Navíc code pointy se zapisují v UTF-16BE, takže neBMP nebo složené znaky jsou z implementačního hlediska řetězec surrogates.
Nicméně pořád je to TeX. Rok od roku čím dál víc drhne, a čím dál víc zaostává za tím, co umí jiné sázecí programy.Jakou jinou alternativu ma tedy clovek k dispozici? U TeX a jeho pohrobku mi to stale prijde jako snaha hackovat neopravitelne.
luainputenc
je možné používat 8 bitové fonty s utf8 vstupem i v lualatexu
\documentclass{article} \usepackage[T1]{fontenc} \usepackage[utf8]{luainputenc} \usepackage[czech]{babel} \usepackage{tgschola} \begin{document} Ahoj světe! Jak se mají žlutí koňové? Příliš žluťoučký kůň úpěl ďábelské ódy \end{document}
S pomocí balíčku luainputenc
je možné ...
Ještě jsem o tom balíčku přemýšlel a chtěl bych upozornit, že se mi to jeví jako nedotažené řešení. Především to při zápisu do textových souborů pomocí \write nekóduje zpět do sprévného UTF-8. O tom, že v TeXu je prováděná i zpětná konverze jsem v článku psal. Autor balíčku na to nějak zapomněl.
Za druhé do LuaLaTeXu jsou nataženy vzory dělení slov v Unicode, takže po použití luainputenc tyto vzory dělení fungovat přestanou a jiné tam nejsou. Pouze CSplain umí načíst vzory dělení současně v IL2, T1 i Unicode.
TeX byl designovan pro sazbu na papir, medium fixni velikosti a rozliseni (ok, dvi ...), v podstate staticky layout, jenze v budoucnu se bude vetsina dokumentu zobrazovat na obrazovkach ruznych velikosti a ruznych rozliseni, a pak je potrebny urcity dynamicky scaling.Možná by to šlo vyřešit tím, že dokument by měl podobu TeXového zdrojáku. Při změně nastavení písma by čtečka spustila TeX, aby dokument znovu vysázel.
S luaTeXem je možné makrojazyk TeXu úplně obejítNic bych neobchazel, na vstup (frontend) bych moc nesahal, prave stabilita makrojazyka je silna stranka TeX a to co podle informaci z clanku dela treba XeTeX mi prijde jako rozumny smer. Klicem je IMHO backend, pokud bude k dispozici dobre integrovana implementace layout enginu schopneho generovat kvalitni epub3+ ci embeddable HTML5+CSS, s MathML, ma TeX opet na roky vyhrano, i kdyby se musely zatim pouzivat u prohlizecu obezlicky jako epub.js ci MathJax.
Energie se bude, IMHO, venovat spise nastrojum s rozumnym dynamickym vystupem do HTML5/CSS/MathML/SVG/JS, pripadne i s prevodem do PDF, typografie v teto oblasti se zlepsuje milovymi kroky, stejne jako souvisejici standardy. Bohuzel se mi zda, ze tady TeX pokulhava a veci jako latex2html ci latexml jsou spise k placi.Řekl bych, že to pokulhávání není problém TeXu, ale těch konvertorů (la)tex2html/latexml... Když už je něco v něčem dobré, proč to nevylepšit i do jiných oblastí? Z TeXu jde velice snadno vytvořit značkovací nástroj na úrovni txt2tags/asciidoc/markdown... proč na takovouto jeho podmnožinu nevytvořit nějakej konvertor do dynamických formátů? Měli bychom možnost tuto podmnožinu TeXu postupně rozšiřovat a přitom stále disponovat s nestárnoucím formátem a dokonalým výstupem do pdf/ps. Vytvářet vedle TeXu zase novej nástroj s případným převodem do PDF, mi přijde jako znovu vynalézání kola.
Řekl bych, že to pokulhávání není problém TeXu, ale těch konvertorů (la)tex2html/latexml...Dobre, ale existuje dobry konvertor? Zmineny tex4ht generuje taky pekny binec, testovano na verzi svn30088.0 (Fedora 19).
Dobre, ale existuje dobry konvertor? Zmineny tex4ht generuje taky pekny binec, testovano na verzi svn30088.0 (Fedora 19).to záleží na tom, jak vypadá konvertovaný soubor, žádný konvertor nefunguje stoprocentně. třeba tex4ht se snaží co nejvíc zachovat vizuální formátování, i za cenu divočejšího html kódu. ale dá se hodně konfigurovat, jen to není úplně trriviální
\chyph
se mi to zarazí...
This is XeTeX, Version 3.1415926-2.5-0.9999.3 (TeX Live 2013) restricted \write18 enabled. entering extended mode (./sbirkazakonu.tex (/usr/local/texlive/2013/texmf-dist/tex/csplain/base/ucode.tex Font encoding set to Unicode. WARNING: czech+slovak hyphenation patterns are not loaded in Unicode.) ! Undefined control sequence. l.2 \chyphMůžete mě někdo prosím nasměrovat k řešení? Když jsem si teď zkusil u trochu delšího textu přidávat u přetečených slov dělítka, daleko více oceňuji práci pánů Ševečka a Lhotky pro csplain
xetex dokument
spustí XeTeX s formátem eplain. Tento formát má nataženy vzory dělení podle souboru generic/config/language.def
a k jejich přepínání používá příkaz \uselanguage
, tedy v tomto případě \uselanguage{czech}
. Můžete tedy zkusit použít tento příkaz a zůstat u XeTeXu s eplainem. Osobně tuto cestu nemám moc prozkoušenou, takže netuším, k jakým to může vést v souvislosti s OPmac problémy. I když, samozřejmě, OPmac je udělaný tak, aby aspoň anglicky fungoval i nad plainTeXem (není nutný csplain).
Já bych spíš vygeneroval csplain pod XeTeXem a ten použil, pokud tedy potřebujete použít Unicode. Tedy:
xetex -jobname pdfcsplain -ini -etex csplain.ini xetex -fmt pdfcsplain dokumentSoubor pdfcsplain.fmt pak soukromě umístím mezi ostatní do
web2c/xetex/pdfcsplain.fmt
(následuje použití příkazu texhash
) a konečně místo xetex -fmt pdfcsplain
používám zkratku xeplain
udělanou pomocí skriptu. Příkaz \chyph funguje jen v csplainu.
\uselanguage{czech}
se akorát objevila chybička slovenských výrazů pro Tabulka/Obrázek, to druhé doporučenější řešení vypadá bezchybně.
Má nějaký smysl (kromě zpětné kompatibility starších textů) používat ještě encTeX místo XeTeXu?
Má nějaký smysl (kromě zpětné kompatibility starších textů) používat ještě encTeX místo XeTeXu?Vaše otázka mě přinutila k vážnějšímu zamyšlení, děkuji za ni. Je pravda, že začínající uživatel by se asi nemusel zabývat starobylostmi a měl by se zaměřit na XeTeX nebo LuaTeX. Ideální by též bylo, kdyby ty starobylosti (včetně staré dokumentace, která může vést jen ke zmatení) byly od začínajícího uživatele zcela odstíněny, aby se nemusel rozptylovat tím, co nepotřebuje. To bohužel jednoduše nejde. Mírné důvody ke konzervatismu encTeX+pdfTeX nicméně zůstávají:
ad A) Existuje modifikace vlna.tex zvaná xevlna.tex, která funguje v XeTeXu. Analogii v LuaTeXu neznám. Obě zmíněné věci by se daly udělat v Lua skriptu pro LuaTeX, ale nepřinutil jsem se tím zatím zabývat. Ani nikdo jiný to neudělal.Patrik Gundlach vytvořil callback pro lualatex, který toto řeší. Používá sice knihovny pro LuaLaTeX, ale ta funkce by měla fungovat i v plainu. Toto řešení je také obsaženo v balíčku impnattypo
\chyph % nebo \uselanguage{czech} pro čistý luatex \input opmac \input luaotfload.sty \input prevent-single \font\hello={Latin Modern Roman} at 12pt \hsize=3in \hello Příliš žluťoučký kůň úpěl ďábelské ódy. Text s krátkými souhláskami a samohláskami i dalšími jevy z nabídky možností v textu možnými. \bye
\input ucode \chyph \input lmfonts \font\hello={Latin Modern Roman} at 12pt \input prevent-single \hsize=3in \hello Příliš žluťoučký kůň úpěl ďábelské ódy. Text s krátkými souhláskami a samohláskami i dalšími jevy z nabídky možností (v textu možnými). \bye
\input ucode \chyph \input prevent-single \input luaotfload.sty \font\hello={name:Linux Libertine O:+rlig;+clig;+liga;+tlig} at 12pt \hsize=3in \hello Příliš žluťoučký kůň úpěl ďábelské ódy. Text s krátkými souhláskami a samohláskami i dalšími jevy z nabídky možností (v textu možnými). Grafika, ffinance -- pomlčka a tak. I začátek odstavce je třeba řešit, i když výskyt zalomení není pravděpodobný. Co třeba í znaky š diakritikou? Různé možnosti [v závorkách <a jiných znacích \bye
Pokusil jsem se o novou verzi, která funguje i se závorkamiVýborně, dejte to např. na CTAN, ať o tom vědí i TeXisté, kteří nečtou diskuse pod Olšákovými články.
Pokud jde o luaotfload, je pravda, že je to velký moloch, ale to je kvůli tomu, že fontloader v luatexu jenom načte veškeré informace z fontu do tabulky a veškeré úkoly jako je aplikace ligatur a ostatní opentype featury nechává na makrechNemáte pravdu. Veškerou inteligenci obstará font a dále Lua-kód, který modifikuje primitivní příkaz \font tak, že umí načíst OTF. Místo \input luaotfload.sty pište prosím \input luafonts. To csplainu sluší lépe. Pro srovnání: soubor luafonts.tex obsahuje jen 14 řádků maker a Lua kódu, zatímco luaotfload.sty načte 47 souborů a s tisíci řádky, aby nakonec dokázal totéž, co luafont.tex. Já mám rád jednoduchost, proto se mi vůbec nelíbí, že v ukázce pro csplain načítáte zbytečně komplikované makro.
Zatím jsem to umístil na Github, na CTAN dodám později.Pokusil jsem se o novou verzi, která funguje i se závorkamiVýborně, dejte to např. na CTAN, ať o tom vědí i TeXisté, kteří nečtou diskuse pod Olšákovými články.
O existenciPokud jde o luaotfload, je pravda, že je to velký moloch, ale to je kvůli tomu, že fontloader v luatexu jenom načte veškeré informace z fontu do tabulky a veškeré úkoly jako je aplikace ligatur a ostatní opentype featury nechává na makrechNemáte pravdu. Veškerou inteligenci obstará font a dále Lua-kód, který modifikuje primitivní příkaz \font tak, že umí načíst OTF. Místo \input luaotfload.sty pište prosím \input luafonts. To csplainu sluší lépe. Pro srovnání: soubor luafonts.tex obsahuje jen 14 řádků maker a Lua kódu, zatímco luaotfload.sty načte 47 souborů a s tisíci řádky, aby nakonec dokázal totéž, co luafont.tex. Já mám rád jednoduchost, proto se mi vůbec nelíbí, že v ukázce pro csplain načítáte zbytečně komplikované makro.
luafonts.tex
jsem neměl tušení, proto jsem použil luaotfload. Ale tím molochem jsem myslel především tu lua knihovnu. Ovšem když jsem se na to teď díval, zdá se, že luaotfload.sty
načítá knihovnu luatexbase.sty
docela zbytečně a luafonts.tex
poskytuje stejnou funkcionalitu s menším množstvím TeXového kódu.
Tiskni
Sdílej: