Na ČVUT FEL byl (a zřejmě stále je) problém v tom, že existuje polorozbitá LaTeX šablona z roku 2014, která je založená na Olšákově TeX šabloně (která mezitím přinejmenším v letech 2018 a 2020 doznala updatu) a která by se neměla používat, protože se mezitím změnil grafický manuál.
Nehledě na to, že prakticky nemá dokumentaci a jenom zjistit, co zadat do konfigurace, aby to na první stranu vyplivlo název správné fakulty, je na půlhodinové hledání ve zdrojácích.
Takže bohužel se to na ČVUT FEL komplikuje žabomyšími válkami mezi TeXem a Latexem, přičemž většina lidí by asi spíš využila LateX, pro který ale bohužel poněkud chybí funkční a graficky korektní šablona.
Dřív existovala i šablona pro MS Office, která byla překvapivě vcelku použitelná, ale z webu zmizela někdy cca v době přechodu na nový grafický manuál.
V letech cca 2014-2016 (nevím, jak předtím) se z pohledu studenta silně tlačilo na to, aby se používal LaTex, ale za předpokladu souhlasu vedoucího byl OK i Office. Pak cca 2017-2019 vzhledem ke komplikacím s šablonami byl nějakou dobu Office OK obecně, načež se zase začal tlačit LaTex... aniž by se opravila šablona.
2018, FIT VUT, LaTeX. Šablona pro závěrečné práce pro Word sice existovala, ale neznal jsem nikoho, kdo by o psaní ve Wordu byť jen uvažoval. Následně na FEKT VUT úplně stejné. Šablona pro Word existovala, ale všini psali v LaTeX.
Prezentace pro obhajobu SP a závěrečné práce se tvořily také v LaTeX. PowerPoint byl tolerován, jenom pokud musely být v prezentaci videa nebo animace.
PS: Laboratorní zprávy a dokumentaci k projektům bylo obvykle možno psát ve Wordu.
14. 3. 2023, 09:25 editováno autorem komentáře
Relativně nedávno psal Scot Aaronson blogový post na téma, jak odlišit crackpoty od seriózního článku (potažno, jak rychle poznat, jestli má smysl plácat drahý čas čtením).
Poměrně rychle se v diskusi vyprofilovala odpověď, že jedna z nejlepších empirických proxy je (ne)použití LaTeXu.
Prakticky jakýkoli matematický nebo fyzikální blog, který má diskusi, tak vyžaduje LaTeX také. Takže by se dalo říct, že jde o profesní předpoklad.
Jazyk XSL-FO, implementovaný knihovnou Apache FOP. Dříve byla jeho výhoda v tom, že je to knihovna – dne, když můžete spustit TeX v kontejneru s omezeními, je to asi už jedno. Zrovna sazba tabulek je ve FOPu jednodušší, než v v TeXu nebo LaTeXu. Hladká sazba naopak bude vypadat lépe z (La)TeXu.
Bylo v plánu do FOPu implementovat sázecí algoritmus z TeXu, ale FOP přežil svou klinickou smrt, takže teď jsou všichni rádi, že občas vyjde nová verze a že ke konfiguraci fontů už nepotřebujete doktorát, takže přepis sázecího algoritmu je na seznamu priorit někde hodně hluboko.
Ten jazyk je nazvaný XSL-FO, protože se obvykle ten FO formát generuje z jiného XML pomocí XSLT. Takže skriptovatelné je to dobře právě v té fázi XSLT transformace.
Co se týče čitelnosti – ano, je to XML. U jednoduchých dokumentů vyhraje čitelností LaTeX, u složitějších je podle mne lepší XML, protože je to pořád stejné XML. Když se podíváte na tabularray, to si vlastně v rámci TeXu vytváří vlastní DSL. Jiné LaTeXové balíčky si zase vytvářejí jiné vlastní DSL. Jednou se parametry předávají pozičně, jednou podle jména. V tomhle má XML výhodu a od té doby jsou nové jazyky akorát horší. V XML by prostě nový balíček zavedl nový jmenný prostor a struktura toho DSL by byla poměrně jasně určená tím, že je to XML.
Pro dokumentaci struktury XML existují standardy, umí je používat třeba editory, které na základě toho mohou napovídat. Takže třeba do editoru nemusíte programovat podporu pro 20 DSL pro různé balíky TeXu, ale stačí jedna obecná pro XSD.
To, že nemusím řešit, jestli se parametry předávají pozičně nebo jménem; jestli je za jménem rovná se, dvojtečka nebo něco jiného; jestli se víc parametrů odděluje mezerou, čárkou nebo středníkem; jestli se texty píšou do dvojitých uvozovek, jednoduchých uvozovek, složených závorek nebo nějak jinak – to všechno dost usnadňuje práci. Zejména když nepoužíváte jenom jeden formát s jedním rozšířením, ale těch formátů a rozšíření používáte dohromady desítky.
".. existují standardy ..."
Jo, několik konkurenčních. A spojuje je to, že jsou čitelné jen pro někoho, kdo se na xml specializuje.
Programátor, který se specializuje na něco jiného, si buď použití xml rozmyslí, nebo si tu validaci napíše ručně. Jak ta podpora pro XSD, tak popis nějakého formátu v XSD jsou extrémně složité v porovnání s tím naprogramovat podporu pro nějaký formát přímo.
Ten druhý odstavec usnadňuje hlavně strojové zpracování. Jako člověku mi standardizovaný způsob předávání parametrů moc nepomůže. Stejně se musím kouknout do manuálu, jaké parametry tam vůbec jsou a co dělají. A to jen v případě, že daný xml formát jen nestrčí nějak strukturovaná data dovnitř xml atributů (jako to dělá třeba SVG).
Rodina XML věcí vyžaduje dost drsné počáteční investice. Nepříjemně často se to vůbec nevyplatí.
Zrovna TeX je v tom nevinně, protože vzniknul dávno před XML. Problém je v nových jazycích, kdy aby se člověk nemusel učit „složité“ XML, musí se učit GitHub Markdown, StackOverflow Markdown, Slack Markdown, JSON, JSON5, YAML…
Ve skutečnosti validaci nebo podporu toho proprietárního formátu nenapíše nikdo. Nebo si myslíte, že teď pro tabularray bude vznikat speciální podpora pro všechny textové editory, které se používají?
Standardizovaný formát parametrů vám samozřejmě pomůže, protože začnete psát col
, a editor už vám doplní, jestli je to colspan
nebo col-span
. V případě proprietárního formátu musíte jít do dokumentace a začít zjišťovat, jak se to vůbec zapisuje.
No ano. Místo složitého xml se rychleji naučím jednodušší Markdown. Všechny ty tři markdowny jsou rozšíření společného základu, který v drtivé většině případů stejně stačí. Přechod mezi těmi variacemi je poměrně triviální.
Je to specializovaný nástroj pro omezenější spektrum problémů. Snaží se dělat jednu věc a díky tomu ji může dělat podstatně líp než to xmlko, protože nemusí platit cenu za obecnost.
Problém je, že nakonec skoro vždycky potřebujete něco komplexnější, a pak už jenom navěky platíte cenu za to, že se pomocí něčeho příliš jednoduchého snažíte řešit složitější problém. Proto existuje tolik variant Markdownu a jakmile chcete něco trošinku složitějšího, místo jednoduchého psaní musíte začít řešit, která varianta Markdownu se používá a kde má dokumentaci. Nebo se podívejte na jazyk Wikipedie – o co snazší by bylo psát zdrojové kódy (a o co dřív by existoval WYSIWYG editor), kdyby to bylo XML. Zatímco takhle to používají jenom lidé, kteří se na Wikipedii specializují – a ostatní sem tam doplní nějaký text, ale málokdo se pustí do používání šablon apod., protože se mu nevyplatí studovat to kvůli jedné editaci.
V tom xml ekosystému ale taky není jen jedna alternativa Markdownu, že?
Problém je IMO ten, že dopředu nevíte, v čem to bude muset být komplexnější. Pokud začnete s něčím jednodušším, budete to muset ohýbat. Pokud vyberete něco složitějšího, budete celou dobu platit za potenciálně nevyužitou složitost. A možná to budete muset ohýbat taky, protože nic není připravené na jakoukoliv eventualitu.
To xml je zrovna ukázkový příklad. Třeba typů pro atributy je dost omezená nabídka, takže se tahle nedostatečná podpora strukturovaných typů hákuje poměrně často (třeba to SVG).
S čím souhlasím je, že kdyby jazyk Wikipedie byl postavený nad XML, tak by dřív existoval editor. Ono se totiž xml bez podpory editoru píše dost blbě. V porovnání třeba s Texem nebo tím Markdownem je tam hromada mechanického datlování.
V XML ekosystému nemusí nikdo vymýšlet svojí odlišnou variantu Markdownu, jenom přidá k základní variantě své další elementy či atributy v novém jmenném prostoru. A když už vzniknou varianty řešící totéž, což je v pořádku (jako vznikly různé balíky řešící tabulky pro LaTeX), dá se mezi nimi jednoduše provádět transformace v XSLT.
Problém je IMO ten, že dopředu nevíte, v čem to bude muset být komplexnější.
To právě u rozumně navrženého jazyka, který počítá s rozšiřitelností, problém není.
Třeba typů pro atributy je dost omezená nabídka
Ta omezená nabídka zahrnuje všechny typy používané v běžných programovacích jazycích. A je podstatně širší, než třeba v JSONu nebo YAMLu. Na rozdíl od JSONu jsou ty typy také dobře definované.
třeba to SVG
V SVG je to udělané špatně. Autoři se úplně zbytečně lekli toho, že by to udělali tak, jak to v XML má být.
Žádný univerzální formát vám nezabrání navrhnout nějaké schéma špatně. Špatné formáty ale brání udělat to schéma dobře.
V porovnání třeba s Texem nebo tím Markdownem je tam hromada mechanického datlování.
Zatímco psát jakoukoli malinko složitější stránku na Wikipedii je trivialita a kód je na první pohled krásně čitelný, že? Viděl jste někdy zdrojový kód nějaké stránky na WIkipedii?
LaTeX se stále používá na technických vysokých školách a co je skvělé, už proniká i na střední školy.
Mimochodem, na Overleaf je mraky šablon pro diplomové práce včetně
https://www.overleaf.com/latex/templates/ctustyle/tskyxwdtwsxm
aktualizované před 10 měsíci.
Jak je to na Overleaf s balíčky? Pro vysázení diplomky v CtuStyle jsem jich kdysi potřeboval celou řadu - SI jednotky, matematické vzorce, obrázky atd.
https://github.com/MR-DOS/TDR_diploma_thesis/blob/master/LaTeX/diplomova_prace.tex