TeX – 3 (příklady autorského značkování) (diskuse)

[beginer]

Děkuji za výborný článek.

Čím to je, že se mi subjektivně více líbí text vysázený pomocí maker p.Olšáka ?

[jOHAN]

Mne sa tak isto viac páči. Sú tam isto také isté fonty? V LaTex a ConTeX výstupe vidím pri podrobnom priblížení rôzne veľkosti (výšky) písmen v slove. Text pôsobí rozhádzane. V TeX+OPmac výstupe je všetko pekné, vyrovnané.

[olsak]

Textové fonty jsou ve všech třech ukázkách stejné. Například pomocí příkazu pdffonts se můžete přesvědčit: TeXGyreSchola-Regular/Bold/Italic.

Já nevidím rozházený text ani různé velikosti písmen v jednotlivých ukázkách. To asi taky záleží na PDF prohlížeči...

[jOHAN]

Máte pravdu, bolo to prehliadačom PDF vo firefoxe. PDF prehliadač v systéme (Ubuntu 12.04, evince) to zobrazuje korektne.

[K>]

vice vertikalniho prostoru v tabulce se dela nastavenim registru na vetsi hodnotu nez 1, tedy pomoci: \renewcommand{\arraystretch}{1.3}

[K>]

Hm, ale to protinani dvojitych car nevim, takze jsem leda tak polovicni LaTeXovy expert :)

[wamba]

to se dá řešit pomocí balíčku hhline a pak místo příslušných \hline použít \hhline{||-|--||}

[olsak]

> to se dá řešit pomocí balíčku hhline ...

Ano, pana kolegu Krňávka tedy od této chvíle nazývám LaTeXovým expertem. Je zde také názorně vidět, co jsem psal v článku: pro skoro jakýkoli problém v LaTeXu existuje balíček, jen je třeba vědět jaký.

Nevyřešené problémy nicméně zůstávají: matematické fonty v XeLaTeXu ani ConTeXtu nejsou TXfonty (implicitní Computer Modern se k textovému písmu Schola vůbec nehodí), a dále v ConTeXtu jsme se zatím nevyrovnali s křížením čar v tabulce.

[vencas]

Existují opentype matematické fonty XITS, v XeLaTeXu jsou natáhnout pomocí \setmathfont{XITS}, viz např. zde.

[olsak]

> Existují opentype matematické fonty XITS ...

XITS jsem pro ukázku tohoto článku taky zkoušel, ale nějak se nedařilo. Chtělo by to tedy předvést funkční řešení: vyjít ze zdrojáku priklad-latex.tex, zabudovat do něj změny a poslat odkaz na zdroják a výsledné PDF.

[wamba]

Tak po trošce hledání a experimentů předkládám:

\documentclass[a4paper,11pt]{article} 
\usepackage{polyglossia}               % nastavení jazyka (náhrada za babel)
\setdefaultlanguage{czech}             % české vzory dělení, atd. 
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{fontspec}
\setmainfont{XITS}
\usepackage{unicode-math}
\setmathfont{XITS Math}
\usepackage{hhline}
\begin{document}
\begin{tabular}{||l|cc||} 
  \hline
  & \multicolumn{2}{c||}{počet \qquad\null}\\
  makro             & řádků kódu & stran dokumentace \\ 
  \hhline{||-|--||}
  &&\\ [-2ex]
  plain             &    1241 & 100 \\
  OPmac             &    1600 &  19 \\ 
 \hhline{||-|--||}
  &&\\ [-2ex]
  \LaTeX{} (jádro)  &    8000 & 240 \\
  hyperref          &   24773 & 423 \\
  color + graphics  &    2469 &  81 \\
 \hhline{||-|--||}
  &&\\ [-2ex]
  Ti\textit{k}Z     & 1\,634\,882 & 726 \\ 
 \hhline{||-|--||}
 &&\\ [-2ex]
  Con\TeX{}t        & 1\,155\,673 & 547 \\ 
  \hline
\end{tabular}

V řádku se píše matematika mezi dolary: $a^2+b^2=c^2$. Nebo je možno
sestavit samostatnou rovnici obklopenou dvojicí dolarů:

\begin{equation}
  \int x^\alpha \mathrm{d}x = 
  \begin{cases}
    \frac{x^{\alpha+1}}{\alpha+1} & \mbox{pro } \alpha\not=-1 \\
    \ln x                         & \mbox{pro } \alpha=-1 
  \end{cases}
  \label{rce}
\end{equation}
Vzorce se zapisují zhruba tak, jak bychom je anglicky přečetli.


\[
  \mathbb{A} = 
  \begin{pmatrix} 
    a & b & c \\
    d & e & f \\
    g & h & i 
  \end{pmatrix}
\]
Toť na úvod vše.

\end{document}

Nastavení math fontů:\usepackage{unicode-math} \setmathfont{XITS Math} (u mě funguje jen po přesunu amsmath a amsfont před)

dříve diskutované \hhline a za ním vložený "fake" řádek zmenčený &&\\ [-2ex] (no dobře to moc elegantní není :))

[olsak]

Děkuji za námět na vylepšení LaTeXové ukázky. Je vidět, že nemám ty správné LaTeXové návyky, tj. nenapadlo mě zkoušet přehazovat pořadí zavedení jednotlivých balíčků. V zadání ovšem bylo ponechat textový font Schola. Protože navíc nemám fonty instalované v systému (mám je jen jako .otf soubory v TeXové distribuci), byl jsem nucen upravit zavedení fontu nikoli podle názvu fontu, ale názvu jeho souboru. Takže hlavička vypadá takto:

\documentclass[a4paper,11pt]{article}  % V LaTeXu povinné
\usepackage{polyglossia}               % nastavení jazyka (náhrada za babel)
\setdefaultlanguage{czech}             % české vzory dělení, atd.
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{fontspec}                  % nastavení fontu
\setmainfont[Ligatures=TeX,
    Extension=.otf,
    UprightFont= *-regular,
    BoldFont=*-bold,
    ItalicFont=*-italic,
    BoldItalicFont=*-bolditalic
]{texgyreschola}                      % fontová rodina TeXGyre Schola
\usepackage{unicode-math}             % nastavení matematického fontu
\setmathfont{xits-math.otf}
\setmathfont[range=\mathit]{texgyreschola-italic.otf}

Kompletní výsledek je na priklad-latex-b.tex a priklad-latex-b.pdf. Je možné si všimnout, že to stále není úplně totéž, jako v OPmac ukázce. Například jednička není z fontu Schola ale z xits fontu, což nepůsobí dobře. A otázka, jak zavést do xelatexu matematický TXfont (který není unicode) taky není zodpovězena. Přitom XeTeX tomu technickou překážku neklade: za použití XeTeX+OPmac tam ten TXfont mám snadno. Nevylučuji, že problém je jen v tom, že LaTeXu příliš nerozumím, takže do něj neumím vpravit TXfont.

[wamba]

ta jednička by šla změnit pomocí \setmathfont[range=\mathup]{texgyreschola-regular.otf} popř. i nastavit další range=\mathbfup

[olsak]

Děkuji za částečné řešení toho vertikálního prostoru v LaTeXové tabulce pomocí \renewcommand{\arraystretch}{1.3}. Chápu to tedy tak, že potom mezi řádky, kde se nevyskytuje vodorovná linka a tudíž tak velký prostor není potřeba, je nutné vrazit něco jako \vspace se záporným argumentem.

[Jaroslav]

Příloha:

• latex.png (59083 bytů)

nevim, jestli nemam spatny firefox, ale priklad k OPmac ma nedokonceny znak integralu i zavorky kolem matice, v ostatnich prikladech to bylo dobre. kdyz to otevru externe, tak je vsechno dobre. nevite nekdo, proc?

[Jakub Lucký]

Protože pdf.js... Ten prohlížeč ve FF je taková fórová hračka...

[vencas]

Text "proč nerad používám LaTeX" jsem četl už asi před 10 lety a také i o něm stále myslím totéž: je to pohled autora-programátora v TeXu, který chce mít sazbu přesně podle svého gusta (je asi shodný s pohledem mnoha TeXařských elitářů).

Mně tedy většinou záleží primárně na obsahu, přijetí obsahu by měla sazba umožnit, tedy vypadat "přijatelně" a nerušit (což třeba Word, zvlášť s matematikou, ani náhodou nesplňuje), a taky pro mně jako autora proveditelná s vynaložením rozumného úsilí. A LaTeX mi v tom poskytuje akorát tu rovnováhu, která se mi líbí - většina věcí funguje, když něco zřídka chci jinak, dá se to přiohnout.

Při publikaci článků, mají vydavatelé styly pro LaTeX, které většinou potřebují jen malou úpravu zdrojáku, pokud je napsán "čistě". Argumenty, že autoři dokumentu v LaTeXu prasí (v článku p. Olšáka) jsou podobné, jako že c++ je špatný jazyk, protože v něm lze psát špinavě. Docela by mě zajímalo, jak by pan Olšák připravoval sborník v plainu (když uvádí jako příklad, jaké je to peklo s LaTeXem), kdyby se mu sešlo 40 příspěvků v plainu, přičemž každý by si nejdřív definoval všechny svoje věci (obsahy, obrázky, floaty, citace, nadpisy) vlastními makry?

Psát si vlastní makra na obsah, no, kdo chce tam, pomozme mu tam. Opravdu nemám čas na to, abych si psal makra na prezentace (jako beamer, který má těch skvělých vychytávek opravdu dost), číslování řádků textu (ve dvousloupcové sazbě na vnějším okraji a další drobnosti) a pokračovat by se dalo dlouho - stačilo by projít seznam balíčků, které v LaTeXu používám a každý z nich bych si nějak uprasil sám. Celkem mám představu, jak ty balíčky vevnitř vypadají, mnoho z toho bych v TeXu napsal (TeXbook naruby je super), ale proč...?

[olsak]

> Docela by mě zajímalo, jak by pan Olšák připravoval sborník v plainu (když uvádí jako příklad, jaké je to peklo s LaTeXem), kdyby se mu sešlo 40 příspěvků v plainu, přičemž každý by si nejdřív definoval všechny svoje věci (obsahy, obrázky, floaty, citace, nadpisy) vlastními makry?

Ano, připravoval jsem sborník v plainu, sešlo se 40 příspěvků, většina byla v LaTeXu, několik v plainu. Ty LaTeXové jsem prelovským skriptíkem přeznačkoval do mého značkování, u těch plainových jsem odříznul definice sazby, protože definice sazby měl sborník vlastní. Nikde nebyl žádný problém. Sborník jsem sestavil v pohodě.

[vencas]

Já jsem si právě představoval, že každý článek v plainu měl svoje definice kapitol, obrázků, citací apod - a ta makra se navíc nejmenovala stejně. Vy použijete \kap, někdo jiných \chap, další \secti atd.

Já když jsem jednou sborník v LaTeXu dělal, kde těch příspěvků taky bylo kolem 40, tak jsem věděl, že střeva článků - \section atd - se jmenují stejně, takže jsem uřezával preambule (ve kterých bylo plno ošklivých věcí jako 60 definic \def\bka{\mathbold{\kappa}}\def\bKa{\mathbold{\Kappa}} které si autor nosil nejspíš už od diplomky), ale na těch základních věcech panovala shoda a už jsem je upravovat nemusel.

A shodneme se na tom, že peklo byly příspěvky, které přišly ve Wordu a někdo je zkonvertoval čímsi do "LaTeXu" plného \vskipů, \hspace, \textbf atp.

[deda.jabko]

Psát si vlastní makra na obsah, no, kdo chce tam, pomozme mu tam

Trochu mi to pripada jako NIH syndrom.

[dad]

jsem tehoz nazoru, ale musim priznat, ze jsem to nechtel psat u clanku, ktery ma uroven, psat u nekoho , kdo ma uroven a sve praci rozumi.

Navic me pri cteni toho clanku napadlo, ze pan Olsak nabizi svetu 'sva' makra, ktera jsou 'lepsi' nez ta makra v tom LaTexu. To jsem musel ale nejak spatne pochopit, protoze to by odporovalo te jeho myslence, ze psat se ma v tom cistem TeXu a ne v nejakych predpripravenych a tim omezujicich subsystemech.

Musism rict, ze se v tom stale jeste nevyznam, protoze sem to pochopil tak, ze ja jako treba autor budu spolupracovat s nejakym expertem na TeX, s kterym si domluvim co ja v mem originale musim zapsat za 'kouzelna slovicka' a pak se to vytiskne optimalne. Je to tak spravne?

Tedy, kdyby to tak melo byt, tak to je z hlediska sazby jiste optimalni, ale zda se mi to neprakticke?

[nasson]

Osobně mám podobný názor (LaTeX vs plain TeX), prostě začnu psát hned a detaily řeším později. U plainu musím umět nejdříve vše (nebrat doslova) a pak začít psát...

Pan Olšák to třeba vysvětlí. Ale pokud to chápu dobře, tak neříká, že jsou lepší (měla by dělat více méně totéž), ale že jsou jednodušší ve smyslu snažšího přiohnutí do konkrétní podoby. Prostě si vezmu kus a použiju ho, zbytek smažu/změním. A to u LaTeXu neudělám takto snadno...

OPmac jsou makra pana Olšáka. Existuje něco podobného, světově rozšířeného? Nebo ještě jinak - jsou jednotlivé názvy maker používané v OPmac v souladu s těmi, co se obecně používají v TeX komunitě? A má vůbec TeX komunita běžně užívané názvy pro makra? (např. * jako odrážka, to je inovace jen v OPmac, nebo běžná praxe i u ostatních?)

Jinak názvy LaTeX a ConTeX jsou otřesné. V tu chvíli mě nezajímají slečny v těsných gaťkách a vyhledat informaci o contextu je přímo nemožné...

[olsak]

Pan Olšák to třeba vysvětlí...

Výhody OPmac jsou shrnuty na první a druhé stránce dokumentace. Vlastnosti, které má LaTeX rozprostřeny v desítkách balíčků s celkovým počtem stotisíců řádků kódu, jsou naprogramovány v jediném souboru s 1600 řádky. Chtěl jsem hlavně ukázat, že se věci dají dělat jednoduše.

A nemusíme jen srovnávat počty řádků kódu, ale též počet stran dokumentace. OPmac je na 19 stranách. Když ale chcete třeba použít beamer (typicky proto, aby člověk na slídu napsal: nadpis, * výkřik první, * výkřik druhý), musí se prokousat více než dvěma sty stránkami dokumentace.

jsou jednotlivé názvy maker používané v OPmac v souladu s těmi, co se obecně používají v TeX komunitě? A má vůbec TeX komunita běžně užívané názvy pro makra? (např. * jako odrážka, to je inovace jen v OPmac, nebo běžná praxe i u ostatních?)

TeXová komunita obecně používá (bohužel) LaTeXové značkování. OPmac jsem zveřejnil v prosinci 2012 na setkání uživatelů TeXu v Brně a pak v dubnu mi o tom vyšel podrobný článek v americkém TUGboatu. Je to tedy relativně nové, takže zatím asi málo užívané.

[vencas]

Já sice chápu, že obhajujete svoje makra, ale jestli tvrdíte, že byste i beamer napsal na 1.6k řádků a zdokumentoval na 19 stranách (nejde o přesné počty, ale o to, že je to řádově méně), tak tomu moc nevěřím (přechody, pauzování uprostřed slidu (včetně TikZ!) , obsah a ukazování postupu v rámci sekce, konfigurovatelnost sekcí, výstup na stránku s přehledem slidů).

Samozřejmě že když se píše monolitický systém, který má být spíš podkladem pro to, aby si ho věci znalý člověk přiohnul podle potřeby, může být úspornější, než balík maker, který má aspiraci pokrýt bezpočet použití a podporovat všemožná rozšíření.

[olsak]

Jsem přesvědčen, že 90 procentům uživatelů stačí jednoduché slídy, které jsou v OPmac-tricks zmíněny pod číslem 0017 a 0022. Tím těmto uživatelům ušetřím dlouhé studium dvousetstránkové dokumentace. A poměr jednoduchost OPmac / složitost Beameru je v tomto případě gigantický: implementace není na 1.6 k řádcích, ale slovy na 24 řádcích. Dokumentace včetně implementace se vejde na jednu obrazovku www prohlížeče.

A TikZ je další obluda, bez které se obejdu, viz článek Jednoduchá grafika PDF primitivně.

Můžete samozřejmě namítat, že v mém řešení není všechno, ale co tam chybí si šikovný uživatel dodělá. Stačí umět TeX (tj. přečíst řádově 100 stránek dokumentace) na rozdíl od stovek až tisíců stránek k jednotlivým balíčkům. Každý si může vybrat, co se mu jeví jednodušší.

[vencas]

Já si právě radši přečtu jednoduchý example k beameru a pak si v dokumentaci vždycky najdu to, co potřebuju. S TikZ udělám na pár řádek věci, které bych primitivy psal dlouho a kdybych na to měl století, udělal bych si vlastní TikZ, akorát horší.

Asi rozumíte rozdílu mezi "přečíst" si 100 stránek dokumentace k TeXu (a tím se začít učit programovat v jazyce, který je popsán na 100 stránkách, ale přečtení a porozumění stavebním blokům je tisícina úsilí, které musíte potom vynaložit) a "přečíst" si dokumentaci k Beameru, kterou si opravdu jen přečtu a některé části přímo použiju.

Úplně rozumím tomu, že pro Vás je snažší psát v TeXu; když ale argumentujete proti LaTeXu, snažíte se prezentovat Vaši osobní preferenci jako něco, co by měli všichni nahlédnout (a ještě s určitou zahořklostí, že se prosadilo něco podřadného). Už to, že většina žurnálů (aspoň těch matematicko/přírodovědecko/technických) bere příspěvky v LaTeXu, ukazuje, že LaTeX bude mít asi i nějaké výhody.

[nasson]

No, mate pravdu, ale asi jen castecne. Beamer moc neznam, nebudu komentovat. TikZ je bezva a bude fungovat i v plainu. Ale co se tyce LaTeX vs TeX. Tak v LaTeXu si sice prectu jednu kratkou knizku a muzu zacit psat, ale kdyz pak chci neco urciteho, tak je to vazne tvrdy boj. Pak mohu zacit hledat vhodny balicek a nejspise ho i najdu, ale opet musim cist dokumentaci (nekdy to mam za 10 minut hotove a je to bezva, jindy ctu 500 strankovou knizku). Obcas se pak balicky mezi sebou nemaji rady, zalezi treba i na poradi, atd. On by to byl boj i v plainu. Ale otazkou je, proc LaTeX? Proc radsi nebyla v historii vystavena jen makra nad plainem, ale stale se drzici tech zakladu, tak jako to dela OPmac? Bylo by to lepsi? Pokud by byl vysledek stejny, tak si myslim, ze bylo. LaTeX ma jednu obri vyhodu, kterou hrave porazi plain i Context. Rozsirenost. Proste dokumentaci, ruzna rozsireni, jak co udelat, aniz bych musel znat cokoliv ze strev, atd.

Ja napr. zkousel context. Je lepsi? Nepochybne. Ale jsem zpatky u LaTeXu, protoze pouzivam rozsireni, ktera v contextu nejsou. A hlavne, veci z dokumentace pak v MKIV nefunguji. Zkratka chybi dobra dokumentace a ucit se zaklady z mail listu... navic z nevyhledatelnym nazvem context...

[olsak]

Abych ukázal, v jakém poměru je zhruba jednoduchost OPmac proti složitosti LaTeXu, rozhodl jsem se spočítat soubory a řádky, které XeLaTeX potřeboval na vyprodukování ukázky z tohoto článku a srovnat to s počtem souborů a řádků, které ke stejnému výsledku potřeboval CSplain.

XeLaTeX při zpracování priklad-latex-b.tex načetl 89 dalších souborů s celkem 69843 řádky. Skoro se divím, že to všechno drží pohromadě a jakým zázrakem to vlastně funguje.

CSplain při zpracování priklad-opmac.tex načetl 5 dalších souborů s celkem 2999 řádky a vytvořil víceméně totéž.

Při generování formátů byly síly obou variant daleko vyrovnanější: XeLaTeX potřeboval pro vygenerování sebe sama 33 souborů a 42709 řádků a CSplain potřeboval 23 souborů a 20000 řádků. Zde jsem nezapočítal soubory při generování XeLaTeXu s jinými vzory dělení, než je čeština, slovenština a angličtina, protože vzory dělení zabírají nejvíce místa. Pravda, XeLaTeX má během generování načteno cca 50 vzorů dělení. To umí CSplain taky (dokonce vzory dělení načte v různých kódováních, což zas LaTeX neumí), ale v implicitní konfiguraci má CSplain načtenu jen češtinu, slovenštinu a angličtinu. Tak, abychom měli porovnání, ostatní jazyky XeLaTeXu jsem nepočítal.

Pro zajímavost můžete spočítat, kolik řádků externích souborů potřeboval k vytvoření ukázky ConTeXt. Shledáte, že jich je ještě více, než v případe XeLaTeXu.

[Josef Kufner]

I ten LaTeX vyžaduje docela hodně úsilí. a v něm kdysi psával také, ale postupem času jsem plně přešel na LyX, který za mne vyřeší prakticky všechny technické detaily a já mám více času na zkoumání zajímavějśích věcí, abych pak měl o čem psát. Na druhou stranu je pořád dobré vědět, jak to funguje pod pokličkou, neboť je pak snažší řešit neobvyklé situace.

[vencas]

Pro vyřešení "soutěžních" otázek (i všemožných dalších problémů s *TeXem) doporučuji tex.stackexchange.com.

[dgvdtfdsffx]

p.olsak je naprosta legenda jenz vse programuje v texu jako kdysi emacsari delali jen emacsu. ja se jen divim ze mame freebsd, netbsd, gnu linux a hafo c kompileru i c libek pribyva, tak sazeci system je furt jen jeden tex a nadstavby. interesantni!!!

[Josef Kufner]

Scribus

[Hudry]

Scribus? Vtip? zkousel sem si v tom vysazet knizku cca 200 stran... nemel sem dost casu abych mel se Scribem trpelivost. Kdo mi napise ze na nizkonakladove casopisy s malym poctem stran je to vyborne, tak at si to rovnou odpusti.

[fxf]

Děkuju za tento seriál. Rád se poučím o tom, kam se TeX ubírá. Používám TeX a především LaTeX už dlouhá léta, především pro psaní odborných textů. Bohužel musím říct, že to používání není tak úplně dobrovolné. Spíš je to tak, že prostě není nic lepšího k dispozici, jinak mám občas pocit, že se vracím někam do počítačového pravěku. Vpodstatě souhlasím se všemi stížnostmi na LaTeX uvedenými zde. Vím, že mnoho z toho jsou stížnosti na LaTeX, ale samotný TeX mi příjde příliš nízkoúrovňový.

Neudál se v této oblasti nějaký pokrok k modernějšímu systému, který by stál za otestování? Ať už se jedná o nějakou nadstavbu TeXu (skriptování v Lua místo v TeXu mi zní nadějně), nebo o nějakou modernější alternativu?

[ghibulo]

Přišla mi jako poměrně dobrá myšlenka používat asciidoc asciidoc - ty značky se snadno osvojí a na rozdíl od konkurence to má tolik konstrukcí, že by to mělo bez problémů stačit od diplomky po dopis babičce. Ovšem nejen dle mých zkušeností ten export funguje spolehlivě jen do html - nicméně dost slušně, včetně matiky. Trochu si teď pohrávám s myšlenkou, udělat z toho export do TEXu pana Olšáka. Člověk by pak mohl psát všechno jedním způsobem a měl by super výsledky v html/pdf/elknihyDOC. Do různejch wysiwyg editorů by se to zatím dalo dostat přes import htmlka. Zdá se mi, že by tomuto řešení v současné nabídce těžko něco obdobného konkurovalo, ale možná se mýlím...? Domnívám se, že budoucnost zveřejňování textů musí vést přes nějaké takovéhle esperanto, které bude každej server schopnej překlopit dle požadavků do jakéhokoliv formátu v co nejlepší kvalitě - otázka je, jestli je vhodné za toto 'esperanto' pasovat právě asciidoc. Asi by tyto věci stály za diskuzi odborníků, aby se vytyčilo k čemu směřovat. Mnoho kostiček už máme připraveno a plainTEX nebo asciidoc by mohla být jedna z nich.

[Fluttershy, yay!]

pandoc rozšiřitelný Haskellem. ^_^

[ghibulo]

Díky za upozornění, pěkná kostička do naší stavby, ale přímá odpověď na to, co pasovat na "esperanto", ve kterém by šlo psát co nejvýhodněji většinu textů, to není. Dle mého, by toto "esperanto" mělo splňovat toto:

žádné rapidní změny, co jednou napíšu, už nechci nikdy přepisovat nebo přeznačkovávat (IMHO např. Latex toto ve svém vývoji popřel, možná ještě popře?)

snadnost zápisu - žádnej XML hybrid, kterej by prudil pamatováním na zbytečné ukončovací značky atd. (DocBook se tím zřejmě vylučuje)

poměrně rozsáhlé možnosti, každý uživatel si to nastuduje do takové hloubky, jakou bude potřebovat a co nejméně požadavků by mělo být řešeno spešl v exportních souborech (markdown nebo textile nejsou příliš vhodné pro svou omezující jednoduchost)

Možná mám jen omezenej pohled, ale stále mi zatím připadá AsciiDoc jako nejlepší kandidát z možných.

[lolo]

založený na xml... http://tbookdtd.sourceforge.net/

a trochu lehčí varianta k AsciiDoc - http://txt2tags.org/

Kdosi tu psal, že moderní latex je ConTeXt...

[vencas]

Já jsem se (pro dokumentaci programů) přiklonil ke Sphinx - rozšířený je, rozšiřitelný taky; syntaxi má celkem jednoduchou, byť na diplomku podle mě nestačí (nějaké složitější tabulky asi moc nepůjdou), lze vkládat rovnice, obrázky, grafy. Občas trochu těžkopádné, ale jde si na to zvyknout a výstup do HTML, pdf a mnoha dalších je přesně to, co mi sedne.

[olsak]

Dříve, než začneme uvádět odkazy na jednotlivá konvertítka mezi formáty, je třeba učinit zásadní rozhodnutí: jaký formát je ten výchozí, ze kterého se ostatní formáty generují, se kterým pracuje uživatel, píše v něm dokument a který je ukládán pro potřebu archivace. Můj názor je, že výchozí formát musí být pro autora poměrně přítulný, ale navíc v něm musí jít udělat vše bez kompromisů. A dokument bez kompromisů je dle mého názoru jedině v TeXu s výstupem do PDF. Všechny ostatní formáty (html, ePub, reStructuredText atd.) obsahují nějaký kompromis a tedy po konverzi představují ztrátu informace.

Ačkoli po autorech žádáme čisté značkování, nakonec při zcela závěrečné úpravě sazby my sazeči do zdrojového dokumentu vložíme občas nějakou prasárnu typu \kern0.5mm, \looseness-1 atd. Například makro sice umístí obrázek s nanometrovou přesností na střed, ale obrázek má své subjektivní těžiště někde jinde a je potřeba jej podle toho mírně posunout. Nebo je třeba přesvědčit formátovač o speciálním formátování některých odstavců, abychom docílili balancování dvoustrany. Tyto značky jsou tedy vloženy dodatečně sazečem do zdrojového dokumentu TeXu. Je možné je označit například pomocí \pdfout{značka}. Zdrojový dokument TeXu by se tedy měl stát výchozím (pro archivaci, pro konverze). Jedině ve zdrojovém dokumentu TeXu lze dělat takovéto úpravy, jedině tam nejsme my sazeči omezeni žádnými kompromisy. Máme totiž v ruce Turingův stroj.

Jestliže např. pandoc na www stránkách uvádí, že zkonvertuje cokoli na cokoli, tak je lhář, protože bez ztráty informace to z podstaty těch formátů není možné.

LaTeX má nevýhodu, že nutí člověka k příliš ukecanému značkování (všude je spousta kudrlinkových závorek, všude plno \begin{},\end{}) a to člověka odrazuje a získává pocit, že LaTeXový dokument nemůže psát, že ho musí kódovat. Proto tady pan Kufner neopomene pod každým dílem seriálu připomenout LyX, proto vznikly uživatelsky přítulnější formáty (reStructuredText, Wiki atd.). Ovšem tato řešení vzdalují uživatele od zdrojového textu TeXu, ve kterém lze jedině vytvořit a uložit informaci bez kompromisů. Je sice možné napsat makra v TeXu, která přečtou XML, reStructuredText nebo něco podobného (předváděl jsem to např. na jednom tutoriálu na TeXové konferenci), ale není to pro TeX zcela nativní a komplikuje to práci s ním. Proto jsem navrhnul uživatelsky přítulné ale stále TeXovsky nativní značkování v OPmac. Ideální z mého pohledu tedy je toto značkování použít jako základ pro archivaci i psaní. Ovšem svět půjde asi jiným směrem: stále ke větší složitosti, ačkoli já se snažím prosadit jednoduchost.

[ghibulo]

Musím uznat, že Váš příspěvek je velmi přesvědčující. Proč omezovat možnosti autora nějakými Asciidocy/Sphinxy, které v této oblasti TeXu nemůžou konkurovat? Souhlasím s Vámi i v tom, že když má svět na výběr mezi dobrým a méně dobrým, tak často spolehlivě vybírá to méně dobré. V tomto konkrétním případě můžou být důvody následující:

zdánlivě velmi pozvolná křivka závislosti věnovaného času a výsledku. Píšu "zdánlivě", protože se z nějakého důvodu mezinárodně neprosadilo žádné jednoduché řešení à la OPmac. Když má nováček na výběr prokousávat se LaTeXem, vytvořit si všechno sám z nuly v plainu nebo začít pracovat v AsciiDocu/txt2tags/...Lyxu/Wordu, tak je zřejmé, co zvolí. Přitom csplain+opmac je s jednoduchými značkovacími jazyky v této věci zřejmě zcela srovnatelný.

malé množství konverzních nástrojů, asi jako důsledek toho, co uvádíte jako výhodu - že jde o Turingův stroj. Vytvořit konverzní nástroj z formátu, kde má autor možnost vytvářet zapeklitá makra, není tak snadné jako zkonvertovat asciidoc do html. Tohle je ale zřejmě jen otázka času, zatím by možná stačilo omezit se na rozumnou podmnožinu, jejíž hranice by autor dobře znal a respektoval.

poslední bod, který mě napadá, souvisí s předchozím - špatná spolupráce s lidmi, které TeX nepolíbil. Pro společnou úpravu dokumentu na cloudu se z pochopitelných důvodů nejčastěji prosadí nějaké WYSIWYG řešení, v nejlepším případě nějaký hodně snadný značkovací jazyk. Možná, kdybych mohl svou práci z TeXu vyexportovat do rozumně ostylovaného odt-dokumentu, nechat kolegy provést stylové+obsahové úpravy a pak si to převést zpět a pokračovat v závěrečných úpravách již ve svém TeX-prostředí...

Po pravdě jsem velmi zvědav na Vaše řešení konverze do html - jestli to zvládne matiku/obsahy/rejstříky/citace jako odkazy atd. Třeba již zmíněný AsciiDoc je v této věci hodně silnou konkurencí.

[olsak]

Po pravdě jsem velmi zvědav na Vaše řešení konverze do html - jestli to zvládne matiku/obsahy/rejstříky/citace jako odkazy atd. Třeba již zmíněný AsciiDoc je v této věci hodně silnou konkurencí.

Moje html řešení je šité na jednu konkrétní úlohu a matematiku v něm neřeším. To jen, abyste neměl příliš vysoká očekávání...

[ghibulo]

Koukal jsem jak je to řešený v asciidocu a zdá se, že to naštěstí není pro nějakou konverzní utilitu až tak velký problém. Vrazí kolem 2000 řádků scriptů do hlavičky a pak již je možno vkládat LaTeXovské matematické výrazy ohraničené dolary do těla stránky.

[Josef Kufner]

LyX je na jednu stranu WYSIWYG editor, kde není třeba na makra TeXu ani pohledět, ale na druhou stranu umožňuje libovolná makra do dokumentu velmi snadno vkládat (a případně i obalit náhledem). A také umí zobrazovat generovaný LaTeXový kód současně při editaci.

Ve výsledku je to nástroj, kde lze pohodlně psát a nezatěžovat se technickými detaily, ale při tom mít možnost zasáhnout, když automatika nestačí. Tedy uživatel je od zdrojového kódu v TeXu tak daleko, jak zrovna potřebuje. Například náhledy rovnic přímo při editaci výrazně šetří čas, neboť lze přemýšlet nad vzorečkama při psaní a bez přepínání se do PDF. Při sestavování okrasné titulní strany však lze psát přímo v TeXu. Obávám se, že tohle sebelepší sada maker netrumfne, neboť tam vždy bude velký ústupek v uživatelském rozhraní.

[ghibulo]

To jsou jistě velké výhody, ale na druhou stranu - pouhé srovnání složitosti LaTeXu s CSplainu+OPmac ukazuje, že u té "okrasné titulní strany" se zvláště člověk přivyklý na wysiwyg pěkně nadře. Značkovací jazyky (a zvláště tak komplikované jako LaTeX) projevují svojí efektivitu tehdy, když ty značky člověk často používá a nemusí často někde něco hledat a zkoumat. Navíc s tou možností archivovat dokumenty je to oproti plainTeXu také dost nekonkurenční. Nicméně kdyby existoval nějakej konvertor, kterej by ten automatickej LaTeX uměl přerovnat do CSplainu+OPmac, tak si umím představit že by to řešilo ten můj "poslední bod".

[vencas]

Součísti HTML je třeba JavaScript, který turingovsky úplný je. Vedle toho TeX jako jazyk není na obecné programování to nejpřehlednější (Brainfuck je taky turingovsky úplný, ale prostě těžkopádný), což je ostatně taky důvod, proč existuje LuaTeX - načítání OTF lze taky teoreticky napsat v TeXu, ale...

Vy nechcete mít kompromisy v sazbě, používejte TeX. Kdybych dělal pořádné dlouhodobé tiskoviny jako knihy, kde na sazbě záleží, vůbec neváhám v tom, že TeX je jasná volba.

V tom, co většinou píšu, nechci mít zase kompromisy v tom, do jakých formátů lze konvertovat nástroji, které již existují (to je pro mě důležité), třeba HTML, a to i za senu horší sazby do pdf. Jestli se vám chce psát konverze do z TeXu do HTML včetně třeba matematiky (třeba ten Mathjax je taky v JavaScriptu) nebo CSS, prosím, ale jste v tomto odhodlání asi dost osamělý.

Pandoc zkonvertuje cokoliv na cokoliv se ztrátou informace, to se asi rozumí samo s sebou - ale kdo chce psa bít, vždycky si nějakou hůl vymyslí (na jejich webu opravdu nic takového nevidím).

[Fluttershy, yay!]

Součísti HTML je třeba JavaScript

wat

Nebo tím myslíš buzzword HTML5?

[ghibulo]

Se vším co píšete, plně souhlasím. Vaší pragmatický volbě rozumím. Kdysi jsem totiž z podobných důvodů 'vystřízlivěl' a přešel od plainTeXu k značkovacím jednoduchostem. Cítil jsem bolestně na jedné straně nedokonalost svých TeX-maker a na druhé daleko efektnější výstupy (s daleko menší námahou) z AsciiDocu.

Teď mi nicméně přijde, že je to podobné, jako když si člověk vytváří databázi fotek v JPG, hudby v MP3... pro nějakou snadnou použitelnost, místo aby na archivaci používal nějaké bezztrátové formáty. Přitom ty těžkosti, které nás v současné době lákají obětovat sazbu, jsou ve své podstatě snadno řešitelné. Nebo byste si nevybral plainTeX, kdybyste v něm měl nadefinovanou podmnožinu příkazů à la Sphinx, obdobné možnosti konverze a navíc byste v případě potřeby mohl sáhnout po nástrojích, které by Vaše možnosti posunuli o několik levelů výš? Je pak ještě vůbec představitelné, že by Vás něco v budoucnu mohlo donutit změnit vaše ustálené zvyky tvorby dokumentů?

Co se týče mého "osamělého odhodlání" :) ... domnívám se, že to nestojí za řeč. Spíš to asi zatím vidím jen na nějaké temporary řešení pro rychlej přístup k velkému množství formátů (plain+opmac -> txt2tags) a pokud mi nebude stačit pdfko, tak se budu krotit a používat jenom to, co mi můj konvertor sežvejká a přímej export do hlavních výstupních formátů (html, odt) v rozumné kvalitě ve svém případě vidím spíš jen jako takové pokusničení a dokonalou vizi budoucnosti :D

[bhy]

Děkuji za vynikající článek. Mám jeden dotaz a jednu připomínku.
1) jak je na tom OPmac s jinými jazyky než čeština, slovenština a angličtina?
2) text "licence" na OPmac možná uvede do nepohody až stavu naštvanosti package maintainery některých dister:)

[ghibulo]

ad 1) OKTeX?

[olsak]

Děkuji za vynikající článek. Mám jeden dotaz a jednu připomínku.

ad 1) OPmac jazyk neneřeší s výjimkou dvou věcí: má připravena slova Kapitola, Tabulka a Obrázek v uvedených třech jazycích a není problém přidat další, např. \sdef{mt:chap:de}{Kapitel}. Druhá věc je řazení do rejstříku, které je připraveno pro angličtinu a podle české normy. Řazení podle norem jiných jazyků by se muselo dodělat modifikací stávajících maker.

Možná ale Váš dotaz se týkal možnosti psát v daném jazyce a používat dělení slov. To je pak dotaz na CSplain, ne na OPmac. CSplain pod 8bitovým TeXem dovolí načíst všechna dostupná dělení slov jazyků, jejichž abecedy se schovají do evropského kódování T1, což představuje 29 jazyků. CSplain pod 16bitovým TeXem (v Unicode) dovolí načíst všechna dostupná delení slov, což představuje nyní 54 jazyků včetně ruštiny, řečtiny atd.

ad 2) Tím, že jste zmínil uvedené slovo v souvislosti s OPmac, uvedl jste mě do nepohody až stavu naštvanosti:). Pokud maintaineři dister přijmou TeXlive jako celek, který je z pohledu této problematiky velmi různobarevný, pak tam OPmac najdete.

ad OKTeX: s touto myšlenkou jsem si pohrával zhruba před deseti lety, pro jednu věc jsem to použil. Nemám zprávy, že by to někdo jiný použil, takže jsem se tím přestal zabývat a dále jsem to nerozvíjel.

[olsak]

Kolegyně a kolegové,

je skoro týden pryč a zatím nikdo nenapsal řešení, jak dostat TXfonty do matematických vzorečků v XeLaTeXu a v ConTeXtu. Přitom tady někdo uvedl nápovědu, jak postupovat:

Pro vyřešení "soutěžních" otázek (i všemožných dalších problémů s *TeXem) doporučuji tex.stackexchange.com.

Že by ta nápověda nezabrala? Chtěl bych zdůraznit, že TXfonty sice nejsou unicodové, ale pro matematiku to v XeTeXu nevadí.

Připomínám další nezodpovězenou otázku: jak zajistit nekřížení čar v tabulce v ConTeXtu. Nějak mě to utvrzuje v názoru, že přiohnout si sazbu k obrazu svému ve složitějších nadstavbách opravdu není jednoduché...

[lama]

Dobrý den, učím se pracovat s Texem a velice se mi líbí vaše makra pro csplain. Momentálně zpracovávám anglický text a chtěl bych proto vědět, jak přepnout vaše makra aby generovaly anglické názvy (kapitoly, obsah, ...). Koukal jsem na soubor /csplain/base/czech.sty a vypadá to že tam ta možnost je, ale nejsem z toho moc moudrý. Nebo je lepší jít na to jinou cestou?

Děkuji

[olsak]

Soubor czech.sty do csplainu asi 20 let nepatří, protože slouží CSLaTeXu. Loni jsem ho konečně vypoklonkoval do příslušných mezí: do již nepodporovaného CSLaTeXu. Ale v Linuxových distribucích má tento můj úkon asi zpoždění, tj. ve Vámi používané distribuci se ještě neprojevil. Takže doporučuji s tímto souborem provést toto: rm czech.sty.

CSplain negeneruje žádná slova automaticky, takže tam nemá smysl se ptát, jak přeponout automaticky generovaná slova do příslušného jazyka. Na druhé straně OPmac generuje tři slova: Tabulka, Obrázek a Kapitola ve třech jazycích. V jakém jazyce to vyleze, záleží na tom, jaké máte zapnuto dělení slov: implicitně anglické, nebo \chyph české, nebo \shyph slovenské. Rozšíření o další slova nebo jazyky dle potřeby je v OPmac snadné a je popsáno v dokumentaci.

[egg]

\chyph české, nebo \shyph slovenské

Možná jsem hnidopich, ale nebylo by lepší označovat jazyky standardními kódy dle ISO 639-1? Tj \cshyph a \skhyph. Je to, myslím, v zájmu budoucího rozšiřování.

[olsak]

Makra \chyph a \shyph jsou součástí CSplainu 22 let a zůstanou tam. Kromě toho ale CSplain podporuje alternativní přepínače \czlang, \sklang, \delang, \frlang, \rulang, \hulang atd. viz soubor hyphen.lan. Přitom \chyph je zcela totéž jako \czlang.

[egg]

Ale cz je kód státu, ne jazyka. :-/

[Josef Kufner]

A co rozdíly mezi německou němčinou a švýcarskou němčinou (locales de_DE vs. de_CH)? Podle diffu překladu grubu to vypadá, že používají jiné uvozovky.

[olsak]

TeX je primárně na psaní textu, ne na jeho automatické generování. A švýcar ví, jakou má použít uvozovku a němec taky. Oba použijí stejné vzory dělení slov. Nikdo nepotřebuje speciální přepínač.

Pokud budu automaticky generovat švýcarské faktury a ve zdrojové databázi jsou místo uvozovek znaky "coul" (což je bohužel obvyklé), pak udělám makra, která to překlopí na správné uvozovky. Podle tamní normy taky udělám makra, která formátují správně datum, adresu sídla instituce atd. Pokud to dělám v Česku, pracuji podle normy ČSN 01 6910. Teprve v okamžiku, kdy budu chtít vytvořit systém na generování faktur pro více zemí, musím nastudovat legislativu každé z nich a na základě toho vytvořit zřejmě přepínač, který mění způsob formátování dle odpovídající normy.

Jinak děkuji za upozornění na chybu v označení jazyka (cz--cs). Pokusím se to v nejbližší době opravit.