Článek v LaTeXu - veselé historky z natáčení (diskuse)

[pavlix]

Děs a běs. Nemůžu si pomoct, ale tvůj příspěvek na mě působí dojmem, že jsi něco pochopil hodně špatně. A oni nejspíš taky.

Na rozdíl od většiny "normální" populace jsem se rozhodl tentokrát - když to časopis umožňuje - neposílat rukopis jako .doc ale v LaTeXu.

Na LaTeXu je dobré to, že je to textový formát, takže je vždy možné ho alespoň ručně zpracovat. Pokud se rozhodli umožňovat zasílání v LaTeXu, měli by tak činit s plným vědomím toho, že ten formát dokážou zpracovat.

gnuplotu, GIMPu a podobných OSS.

Nenapadají mě dva odlišnější programy ze stejné oblasti. Hovořit o gnuplotu, GIMPu a podobných OSS mi přijde jako parádní nesmysl.

První otázka je jasná: "Jak to mám upravovat ?" Otevřeš tex ne ? "No jo, ale vono mně to nejde vodevřít." Po několika minutách evangelizace na téma LyX

Tady bych se už zastavil na tom, že nedokážou pracovat s inzerovanými formáty.

Nechceme průhledné TIFFy

Neschopnost upravit si průhledný format do neprůhledného aniž by tě s tím otravovali, to je fakt gól.

Můj časopis se rozhodl, že tiffy musí být CMYK (naštěstí mám kolegu s Fotošopem, protože v Linuxu bych si na tenhle problém musel vzít měsíc dovolenou)

Jako by editace obrázků nějak zásadně souvisela s operačním systémem.

font management program asi Linux nemá

Co by to mělo být a jak by ti to mělo v daném případě pomoct?

I když se jedná o open-access CC-like časopis, který propaguje LaTeX, píšou tam i různě postižení techniční jedinci, s LaTeXem si připadám jako bojovník s větrnými mlýny a co se týče obrázků, cítím se být perzekuován. Nicméně vše dobře dopadlo a snad článek přijmou...

Spíš to vyznívá, že to původně dělal někdo, kdo to uměl, ale musel to předat někomu jinému. To se stává. Ale popravdě řečeno když chci dodat text, tak se mi jako vhodnější jeví buď nějaký vylepšený text (wiki-like nadpisy, hvězdičkované zvýraznění), nebo ještě lépe HTML (generované třeba z té wiki-like syntaxe, to už je jedno). Obrázky ať už si tam dolepěj, jak chtěj.

[Georgius]

Děs a běs. Nemůžu si pomoct, ale tvůj příspěvek na mě působí dojmem, že jsi něco pochopil hodně špatně. A oni nejspíš taky.

Myslím, že já ne, viz níže.

Na LaTeXu je dobré to, že je to textový formát, takže je vždy možné ho alespoň ručně zpracovat. Pokud se rozhodli umožňovat zasílání v LaTeXu, měli by tak činit s plným vědomím toho, že ten formát dokážou zpracovat.

Vtip je v tom, že TeX se posílá až úplně nakonec a před tím se nahrává PDF preview vyrobené za použití jejich šablony. Bez obrázků, ale s legendami k obrázkům (takže vysázím pro spoluautory preview s obrázky a před odesláním z toho vlastní obrázky vyházím a nahraju jejich úžasným webovým systémem)

gnuplotu, GIMPu a podobných OSS. Nenapadají mě dva odlišnější programy ze stejné oblasti. Hovořit o gnuplotu, GIMPu a podobných OSS mi přijde jako parádní nesmysl.

Pokud chci udělat hezký graf, pak použiju gnuplot a výstup do eps. Když dělám bitmapu, tak v GIMPu. Mezi "podobné OSS" patří třeba Rko, z kterého lezou grafy, ImageMagick a vím_já_co_ještě na bitmapy ...

První otázka je jasná: "Jak to mám upravovat ?" Otevřeš tex ne ? "No jo, ale vono mně to nejde vodevřít." Po několika minutách evangelizace na téma LyX - Tady bych se už zastavil na tom, že nedokážou pracovat s inzerovanými formáty.

To bylo o spoluautorech, nikoliv redakci časopisu

Nechceme průhledné TIFFy - Neschopnost upravit si průhledný format do neprůhledného aniž by tě s tím otravovali, to je fakt gól.

Jj, vopruzáci.

Můj časopis se rozhodl, že tiffy musí být CMYK (naštěstí mám kolegu s Fotošopem, protože v Linuxu bych si na tenhle problém musel vzít měsíc dovolenou).

Jako by editace obrázků nějak zásadně souvisela s operačním systémem.

Přiznejme si to otevřeně - OSS je s CMYKem na štíru, widle + Masox mají "ten fotošop".

font management program asi Linux nemá

Co by to mělo být a jak by ti to mělo v daném případě pomoct?

Nevím, ale v té chybové hlášce to radí

Spíš to vyznívá, že to původně dělal někdo, kdo to uměl, ale musel to předat někomu jinému. To se stává. Ale popravdě řečeno když chci dodat text, tak se mi jako vhodnější jeví buď nějaký vylepšený text (wiki-like nadpisy, hvězdičkované zvýraznění), nebo ještě lépe HTML (generované třeba z té wiki-like syntaxe, to už je jedno). Obrázky ať už si tam dolepěj, jak chtěj.

Obrázky se nahrávaj separé, většina lidí dodá Word. Bohužel časopisů co používají tenhle redakční systém není málo ...

[chrono]

Přiznejme si to otevřeně - OSS je s CMYKem na štíru, widle + Masox mají "ten fotošop".

Je otázne, ako často je používanie CMYK naozaj nutné a zmysluplné (hlavne ak sa to používa so vstupnými dátami, ktoré nie sú CMYK).

[Georgius]

Zkuste to vysvětlit v tiskárně Jinak v tomto konkrétním případě je to úplně absurdní, protože prezentuji barvy tvořené právě pro RGB, ale musí se tisknout v CMYKu. Achjo.

[pavlix]

Já taky tisknu doma všechno v CMYKu (protože to je to, co strkám fyzicky do tiskárny), ale to neznamená, že kvůli tomu musím šílet při přípravě obrázků.

[Georgius]

Osobně rozdíl taky *většinou* nevidím, ale pokud se odevzdávají podklady do tisku (časopisy, knihy), tak přes RGB prostě nejede vlak - do problematiky nijak hluboko nevidím, ale asi jde o to, že když si vytiskneš blbě jednu fotku z dovolený, tak se nic neděje, ale když rozjedeš rotačky a vypadne ti tisíc kopií se špatnejma barvama tak máš celkem problém ...

[pavlix]

Samé neurčité kecy...

[Georgius]

Hele, já svoje obrázky tisknu v RGB a je mi to šumák. Ale spousta odborných časopisů rigidně trvá na CMYKu. Zeptej se jich proč

[pavlix]

To musíš mít nějakou zázračnou tiskárnu :D.

[Georgius]

tady mně někdo chytá za slovo Samozřejmě že tiskárna je CMYK, ale data posílám CUPSu bez explicitní konverze ...

[pavlix]

Ale to se po předchozích příspěvcích dostáváme k tomu, co jsem psal já. Jaký je technický rozdíl mezi tím, že:

a) Konvertuju RGB obrázek na CMYK.

b) Konvertují RGB obrázen na CMYK.

[sigma]

V tom, že barevné prostory RGB a CMYK nejsou shodné, takže ta konverze není bezztrátová? A když ji provedu sám, nemůžu pak říkat, že to mělo vypadat jinak? Resp. sám mám nad tou konverzí kontrolu a můžu ji přizpůsobit tak, aby výstup odpovídal požadavkům. Plus u vektorových podkladů vč. PDF jde o separaci K kanálu, což může lépe udělat autor dokumentu, než dodatečně tiskárna z RGB podkladů.

Tiskárna nějakým způsobem ručí za to, že na papíře bude výstup včetně barev odpovídat dodaným podkladům. Pokud jsou podklady RGB, tak to není dost dobře možné, protože tu konverzi lze udělat mnoha různými způsoby, a v tiskárně neví, který je pro zákazníka nejlepší.

[pavlix]

Což by ale jen potvrzovalo mojí domněnku, že pokud dodávám něco časopisu nebo grafikům a nemám o tom páru, tak by zase bylo lepší to nechat na nich. Oni si to udělají podle svých potřeb a výsledek dají na tu tiskárnu.

[sigma]

Některé barvy z RGB spektra nejde pomocí CMYK vyjádřit. Takže při konverzi rastrového obrázku z RGB dojde k určitému "poškození" barev a původní autor je ten, kdo může nejlíp posoudit, jestli to v konkrétním případě vadí a případně to nějak řešit. V některých situacích může být lepší, když to bude dělat grafik, ale dost možná by kvůli tomu musel pak komunikovat s autorem. Tak bych to viděl tak, že si tím v časopise šetří čas - delegují tu práci na autora, a ten pak nemůže říkat, že "se to vytisklo blbě".

[w4rr10r]

...jinými slovy nemáš páru, jak to u takových časopisů chodí.

[pavlix]

Jen u makových.

[stativ]

Pokud jde o časopis, tak bych na to nesázel. S tiskárnou by ses nejspíš domluvil, protože tam na to mají lidi.

[stativ]

Což mě přivádí k myšlence, že problém u časopisu bude v tom, že za a) tiskárna by nebyla nadšená z toho, když by jim poslali časopis, kde je půlka obrázků v CMYK, čtvrtina v sRGB a zbytek v něčem blíže neidentifikovaném a za b) v časopisu nemají lidi na to, kteří by se poprali s bodem a).

[elenril]

Pokud chci udělat hezký graf, pak použiju gnuplot a výstup do eps.

Nemyslím, že zrovna gnuplot s EPS je ta nejlepší cesta k hezkým grafům pro použití v texových dokumentech. Pokud si člověk nedá spoustu práce s nastavováním, tak má výsledek většinou jiné fonty, jiné tlouštky čar atd., takže celý ten graf pak hrozně bije do očí jak nezapadá do textu. Taky když jsem naposled používal gnuplot, tak moc dobře neuměl ani pitomou českou diakritiku, o pokročilejší matematice ani nemluvě.

JedináSprávnáCesta(tm) jsou podle mě v současné době řešení založená na PGF/TikZ, např.:

* gnuplotí výstup do PGF (asi by mohl být lepší než eps, ale pořád fuj gnuplot)

* čistý TikZ sám o sobě dokáže lecos nakreslit, umí i nějakou základní kooperaci s gnuplotem. Pokročilejší věci se v tom ale dělat nedají.

* balík pro latex s názvem pgfplots, což je nádstavba nad PGF/TikZ právě pro kreslení grafů. Tady se už toho dá udělat celkem dost, ale už jsem narážel na problém toho že TeX má dost omezené výpočetní schopnosti (např. neumí velká čísla).

* já ted používám matplotlib s PGF výstupem. Bud to volám z pythonovského skriptu, anebo to používám interaktivně z ipythonu. V porovnání s gnuplotem to má nesrovnatelně širší možnosti. Jen člověk musí trochu umět python.

[petr_p]

Gnuplot má výstup epslatex, kdy vyrobí texový dokument s popisky a zvlášť grafiku v EPS. Člověk si pak daný obrázek zkompiluje TeXem sám. Není to dokonalé (gnuplot hádá, kolik místa má nechat na popisky), ale v podstatě to funguje.

TiKZ je více texový, ale na specializované nástroje nemá. Jednoduchý graf nebo stavový automat umí, ale pokud člověk potřebuje složitější nebo rozsáhlejší vizualizaci, tak gnuplot nebo dot poslouží stále lépe.

[elenril]

Pokud se bavíme o ručním psaní tikzových příkazů, tak souhlasím, složitější věci jsou v tom neudržovatelné. Ale pokud se použije nějaký jiný program co má tikzový výstup, tak se už dá zvládnout podstatně víc.

Zmíněný matplotlib se mi opravdu osvědčil, nemyslím že by za gnuplotem v čemkoliv zaostával.

[MadCatX]

Ad CMYK: Pro GIMP existuje plugin Separate+, který by vám na úpravu obrázků a jejich následný export do CMYK TIFFu možná stačil...

[Georgius]

díky za tip, někdy zkusím

[Tomáš Pelc]

Ano, potvrzuji: GIMP + plugin Separate jsou schopni produkovat TIFF s CMYK bez problémů. Zkoušel jsem takto předat podklady do tiskárny a uspěl jsem "bez ztráty kytičky".

[xkomczax]

Sice je to off-topic, ale nedá mi to nezeptat se když se to tu nakouslo: zkoušel někdo použít plugin Separate+ na nějaký vektor? Třeba na text vytvořený v GIMPu. V tom případě totiž dostávám špatné výsledky: hrany jsou dost "zubaté". Neví někdo co s tím? Změnit někde nějaké nastavení? Zkoušel jsem vše možné, hledal kde se dalo, ale nic

[xkomczax]

Nikdo nereaguje, tak si musím odpovědět sám. Po nějakém tom experimentování jsem došel k tomu, že není problém s vektory jako takovými, ale s alpha kanálem. Důvodem, proč jsem na to přišel u vektorových objektů je jednoduchý: používal jsem antialiasing, který se však do CMYK nepřevedl a díky tomu vzniklo ono "okousání". Jedinou možností jak převést takový obrázek je prý přes commandline utilitku convert z balíčku ImageMagick (zatím jsem nezkoušel).

Když už tu to téma je, nedá mi to trochu si nezaspamovat: můj návod jak na převod z RGB do CMYK právě přes zmiňovaný GIMPovský plugin Separate+

[User682]

zdravim,

pridam podobny pribeh.

Tak me tak pred casem napadlo, ze je urcite skvele prijimat clanky v openDocument formatu ci v necem jinem, co otevre Libre/OpenOffice, protoze autor by mel psat zejmena obsah a potom az nejake html ci zda vubec.

Nejdrive jsem vystrizlivel, kdyz jsem zjistil, ze do redakcniho systemu potrebuji trochu vice cistci html a ne staticky pozicovane veci. A neco bez pevne nastavenych velikosti a barev.

Nejdrive se sepsala nejaka cistici vec na xhtml. Pouzitelnost ale casem nic moc.

Zacal jsem tedy psat vlastni konvertor z odt do xhtml a po nejake dobe jsem jej odladil. Uspora prace znacna.

Hodne pomohlo, kdyz clovek zjistil, ze je vyhodne stavet novy xml strom odspoda.

Clovek zjisti, ze ne vsechny editory jsou open-document compatible.....

Obcas byly radosti z Abiwordem - neexistujici styly a divne prolinkovane.

Google Docs Vam rad namnozi elementy po jednom pismenu treba 250x. Aneb piseme filtry.

V OpenOffice si uzijete s nejakymi OLE objekty jako obrazky z nejakych screeenshotu.

A dalo by se pokracovat.....

Prubezne dopisuju Unit testy a nejaky integracni test. Semtam z toho vypadne nejaka chyba, ale jinak to zacina byt hodne stabilni. Je to vcelku zajimave, jak testy narustaji do velikosti kodu, ze se snizuje "vyteznost chyb".

Abych se nenudil, tak zakaznik chce nejak zpracovavat v Jave dokumenty z MS Office a neco i z openDokumentu. Kvalita neplacenych knihoven nic moc. Na neco to staci. Pokud potrebujete cist ci neco extrahovat, tak to je obcas jednodussi si napsat nejakou transformaci rucne na XML. Horsi je to se zapisem.

Je to vcelku obcas zabava delat s temi dokumenty. Clovek se nenudi. At uz to ma nalepku 'open' nebo ne. Mozna dobrej "byznys" casem. Obcas si pri procitani specifikaci a lusteni, co to vlastne v tech dokumentech je, vzpominam na ty boje za nove formaty (open dokument) a za uvolneni specifikaci. Jeste, ze ty specifikace jsou. Jen jsem tak mel asi iluzi a chimeru dohromady, ze bude i hodne napsanych kvalitnich knihoven....

gf

[luky]

oofice se daji pouzit z radky na konverzi dokumentu, upravil jsem tak mraky dokumentu v doc: doc -> odt -> filtr -> odt -> doc. Celkem to i fungovalo

[Bystroushaak]

Je ten script někde k dostání? Já psal něco podobného, ale vyzískat z té kopy hnoje byť jen základy formátování stálo víc energie, než jsem do toho nakonec byl ochotný vložit.

[Jindřich]

znáte writer2xhtml? já jsem tedy používal (velmi úspěšně) druhou větev writer2latex

[Jindřich]

P. S. Je samozřejmě třeba používat vlastní konfiguraci, ne tu předvolenou, viz dokumentace.

[Bystroushaak]

Díky za radu, až to budu opět potřebovat, tak se na to podívám.

[User682]

Mam to jako aplikaci v Jave. Umi to zaklady HTML. Doslova s tim delam clanky uz asi rok. Ma to asi 4300 radku v Jave.

Muzu Vam poslat soukrome workspace do Eclipse. Casem to asi budu stejne opensourcovat. Spise jako vyukovy material a jen nekde vystavit....

Je to pro Vas jeste zajimave ?

Na cem jste se konkretne zasekl o open dokumentem ?

Jinak by se mi hodil nejaky algoritmus, jak odradkovavat - konverze na p nebo br elementy v xhtml. Asi jsem cetl zatim malo specifikaci (element text:p + styly).

gf

[Bystroushaak]

Na cem jste se konkretne zasekl o open dokumentem ?

Na lenosti/nedostatku motivace to psát kvůli jednomu případu.

Jinak by se mi hodil nejaky algoritmus, jak odradkovavat - konverze na p nebo br elementy v xhtml. Asi jsem cetl zatim malo specifikaci (element text:p + styly).

Nedávno jsem napsal něco podobného pro cherrytree. V podstatě to bere html bez <p> tagů a vyrobí je to na základě odřádkování podobně, jako to funguje tady na abclinuxu.

Muzu Vam poslat soukrome workspace do Eclipse. Casem to asi budu stejne opensourcovat. Spise jako vyukovy material a jen nekde vystavit....

Zatím to nepotřebuji, ale až zas budu, tak si o to napíšu. Každopádně díky za nabídku.

[Luboš Doležel (Doli)]

Na HTML je lepší se vykašlat úplně, jsou s tím jen problémy. Na články v .odt se mračím, to je lepší, aby mi to poslali v plaintextu s nějakými poznámkami.

Příští engine AbcL proto bude všude používat Markdown. Zatím postupně dopisuju společné funkce enginu (věci kolem diskuzí, redakčního systému apod.), otestuje se to na ITBizu.

[User682]

zdravim,

s HTML mam take velke problemy. Jeden z nejhorsich formatu na publikace, co znam.

Co se tyce Markdown, tak dejte vedet, jak jste pochodili. Zkusenosti me budou zajimat. Jeste si o nem neco prectu.

Osobne ale budu stavet na nejakem prumyslovem standartu. Tedy ODF + kancelarsky balik. Je otazka, zda by to nemel byt interni format a zbytek by se pregeneroval. A uzivat si vyhod WYSIWYG editoru. Do toho zmeny a poznamky. Nebo nejake lepsi strukturovani dokumentu.

Moje zkusenosti s formaty od autoru:

- 25% lidi Vam doda kvalitni XHTML a vetsinou i kvalitni clanek.

- 25% lidi Vam doda nekvalitni HTML. Polovina z toho srot. To je asi to nejhorsi. tidy + vim a uz to opravujete. Nekdy kopie do Office a pak s tim neco vubec delat.

- 50% lidi Vam doda ODT nebo Word. Tak 20% z celku Word. Zejmena docx.

Ono uz jsem parkrat zazil, ze mi lidi/geeci rikali: pouzij toto, je to skvely, naprogramuj to a ve finale to pouziva jeden clovek. Ne-li nikdo.

Asi zasadni problem je v dnesni dobe penize na clanky. Kdyz vidim, jak nektere weby plati 1300-1500/Kc za odborny velmi kvalitni clanek a jede to, tak podle me nejvetsi problem jsou honorare. Do toho si vemte nejake dane z honoraru a Vasi praci. Cele to stoji z vetsiny na financich a mit jich vice. A za 500 stovek dneska mate mozna jednu tasku nakupu.

Vetsina lidi Vam dneska, kdyz uz bude chtit neco delat, radeji vezme programovani za par stovek na hodinu. Nebo nebude nic delat = fb+youtube. Nebo bude resit politiku.

Predstava, ze autory/lidi ucim novy format nebo HTML a jeste blbe platim v tyhle dobe.... To je cesta do pekel. Beru to jako neco volitelneho, ale ne neco majoritniho. On je posledni dobou dost casto pozadavek na aplikace, aby byly intuitivni a pokud mozno bez zaskoleni.

gf

[w4rr10r]

- 50% lidi Vam doda ODT nebo Word. Tak 20% z celku Word. Zejmena docx.

To je u linuxového webu dost smutné.

[Heron]

Kdyby jenom u webu. Dokonce i uchazeči o práci administrátora linuxových serverů posílají CV v docx. A někomu ta poznámka o docx přišla natolik divná, že na sebe upozornil v diskusi.

[ewew]

Zrejme uchádzači predpokladajú, že keď sa tam používa linux,unix, tak si poradia aj docx. Iná možnosť je, že iné nepoznaju. Napíš aký formát by bol ideálny. Varianty Wordu sú problém. Každá verzia iný formát a spätna kompatibilita je otázna. Ja väčšinou používam PDF. Tam je šanca, že to budú mať na protistrane nainštalované.

[w4rr10r]

Nebo jsou to pravděpodobně prostě lempli.

[pavlix]

Napíš aký formát by bol ideálny.

V dnešní době je de facto standardem pro sdílení hotových tiskových dokumentů PDF, které ty sám používáš.

[Heron]

Iná možnosť je, že iné nepoznaju.

Jejich problém. Nashledanou.

Napíš aký formát by bol ideálny.

PDF/A. Případně, kdyby to někdo poslal v PostScriptu, zaujal by ještě víc. Přinejhorším ten odt, ale jako posílat životopis, tedy finální dokument, ve formátu určeném na editaci ... to je mi prostě nějak proti srsti.

[w4rr10r]

Šíma je známý troll.

[Heron]

Aha, nevěděl jsem.

[Bystroushaak]

Já jsem za HTML tady rád. Nedokážu si moc představit, jak píšu delší a trochu složitější blog v markdownu. I kdybych ho napsal v HTML a pak konvertoval do markdownu, stejně bude docela těžké ho sem naportovat tak, aby to fungovalo jak chci. Z mých zkušeností navíc plyne, že markdown v určitém bodě přestane stačit a vymyslí se značka pro vkládání html.

[chrono]

Do markdown sa dá vkladať html kód (používa sa to napr. na pridávanie tabuliek).

[Josef Kufner]

A k čemu pak potřebuju Markdown?

[pavlix]

K pohodlnému psaní 99.9% věcí.

[Bystroushaak]

Markdown (pokud se tedy bavíme o konkrétní verzi značkovacího jazyka) moc pohodlný není. To už teda radši ten wysiwyg editor, za předpokladu, že z něj nepolezou zrůdnosti, jaké lezou z většiny.

[chrono]

Existujú aj wysiwyg editory pre markdown.

[pavlix]

Cokoli, co umí označkovat nadpisy a zvýraznění a podporuje odstavcování prázdnými řádky je podle mě pohodlnější než HTML.

[Bystroushaak]

Jak se to vezme.

Různé wiki-like značkovací jazyky se člověk musí naučit a pak si je pamatovat, což je zrovna pro mě docela nepohodlné, protože to obnáší pamatování si naprosto náhodných informací, které na rozdíl od HTML, nedávají vnitřní smysl. Jeden používá pro nadpisy # na začátku řádku, jiný =, další pak = po obou stranách a pamatovat si to je časem pěkný ojeb. Nehledě na to, že je to v podstatě k ničemu, protože na rozdíl od HTML ani jeden z nich není široce podporovaný standard, se kterým můžeš přijít kamkoliv a vědět, že tam bude fungovat.

Jinak osobně mi nejvíc vyhovuje místní systém odvozování odstavců a pár tlačítek, které umí dynamicky přidat různé základní tagy.

[Fluttershy, yay!]

Různé wiki-like značkovací jazyky

Mně stačí jeden, možná dva.

se člověk musí naučit a pak si je pamatovat

Och, jak strašné! Wie ein Horror!

to obnáší pamatování si naprosto náhodných informací, které na rozdíl od HTML, nedávají vnitřní smysl

Vnitřní smysl a HTML v jedné větě? Na čem jedeš?

Jeden používá pro nadpisy # na začátku řádku

Překvapivě se to obvykle moc neliší od konvencí používaných třeba v e-mailech už po desetiletí.

Naučit se takový jazyk je asi jako naučit se základy Pythonu — oproti začátkům programování v Javě.

[Bystroushaak]

Mně stačí jeden, možná dva.

No, to se máš.

Och, jak strašné! Wie ein Horror!

Ono je docela nahovno pořád řešit, jestli se v tomhle dělá tučný text *, **, __, ''', nebo nějakým dalším nesmyslem, který zrovna autorům přišel dokonale smysluplný.

Vnitřní smysl a HTML v jedné větě? Na čem jedeš?

HTML používá pro tagy anglické zkratky, které jsou navíc stejné z různých editačních nástrojů, jako je třeba word. Uznávám, že psát je ručně je docela opruz, ale zapamatovat si je je imho podstatně lehčí a v životě se to hodí víc.

[Fluttershy, yay!]

Typický příklad je definition list. -_-

[Bystroushaak]

Ty jsou v článcích k vidění opravdu často.

[Fluttershy, yay!]

Ano, resp. já je používám.

[Fluttershy, yay!]

Ale když jsme u toho, zrovna rozšíření Markdownu zvládá i věci jako začlenění vzorců v LaTeXu (možný automatizovaný překlad do MathML) nebo poznámky pod čarou.

[Bystroushaak]

Proč potom nepsat rovnou v latexu? :D

[Fluttershy, yay!]

Konverze z LaTeXu do HTML vypadá jak? Navíc LaTeX je plný balastu — standardně i pro drobnosti jako správné uvozovky.

[Josef Kufner]

Protože LaTeX je plnohodnotný programovací jazyk. Je to příliš mocný nástroj, než aby ho bylo možné spolehlivě zpracovávat. Na dokument je potřeba něco, co není Turing complete.

[Divný host]

Na sledování změn můžu doporučit mít tex soubory a obrázky ve verzovacím systému. Git je fajn, ale pro netechnické uživatele má nejspíše nepřekonatelnou učící křivku. Subversion je jednodušší, ale zase je potřeba mít server (nejspíš půjde využít nějaký free hosting).