Esiste una documentazione parziale in italiano

Non credo che esista ancora una documentazione in italiano, ma ti posso dire in italiano quali sono le principali differenze fra LaTeX eConTeXt:

Sono due tipi di mark-up completamente diversi, anche se il programma che sotto sotto esegue davvero la compilazione è pdftex per entrambi e per ConTeXt-mkiv anche l’interprete Lua.

Io leggendo la documentazione nelle faq mi è parso di capire che gli autori di ConTeXt sostengano che il loro software è più indicato per realizzare il layout del testo mentre convengono che LaTeX sia più orientato a quello che si deve scrivere nel layout.

Per questo asseriscono che con ConTeXt è più pratico e razionale modificare l’aspetto del documento mentre con LaTeX è più complicato anche se ormai esistono molte classi che sono in grado di adattarsi alle più disparate esigenze.

Quindi nel tuo caso a consiglieresti di usare LaTeX oppure ConTeXt, quali sono gli scopi che si prefiggono?

La differenza è un po’ come andare ad un ottimo self-service (Latex)
o cucinarsi il pranzo (ConTex). Nel primo caso la fatica
è comporre il piatto (immagina di avere moltissima scelta),
nel secondo bisogna prima capire come si fanno le cose elementari e via via si fanno le cose più complesse. Ovviamente come cucini tu a me non piace (e viceversa), mentre il self-service ha un gusto medio che va bene per tutti — ed i piatti particolari non si trovano, mentre tu te li puoi fare se sai cucinare.
ConTeXt con mkiv sta attraversando una intensa fase di sviluppo con luatex e metapost 2.0: la documentazione fa riferimento per lo più a mkii
(pdftex) e non è certamente così estesa ed onnipresente come LaTeX, ma un utente context normalmente non ha paura di guardare il codice
per avere ulteriori informazioni.

E’ vero che certe soluzioni sono obbligate: se devi comporre articoli scientifici al 100% devi usare LaTeX perché così vogliono gli editori,
ed in genere anche i libri scritti in TeX sono per la maggior parte scritti in LaTeX.
Nel caso di database publishing, invece, ConTeXt ha un suo spazio.

Ma a me sembra che nel caso di LaTeX e di pubblicazioni scientifiche le case editrici già predispongano all’autore o a chi ne trascrive il testo la classe da utilizzare.
Quindi in tal caso il problema è unicamente occuparsi del testo, almeno questo mi appare il modo più sensato di usare LaTeX.

Esatto, cosa scrivere e come scrivere è compito tuo. Se vuoi variare il layout lo puoi fare nei limiti della classe.

Infine, e perdonate la mia ignoranza, ma che cosa è mkiv?
La prima voce su google è una automobile… 😕

http://wiki.contextgarden.net/Mark_IV

Ciao vorrei farti qualche altra domanda sulla documentazione, sulla mia bella Debian mi ritrovo tutto questo papello di manuali:

`ls
aleph.pdf letter.pdf mp-cb-en.pdf mtexutil.pdf xfigures-s.pdf
cld-mkiv.pdf mchart.pdf mp-cb-nl.pdf mtexwork.pdf xmanipulate.pdf
columns.pdf mchinese.pdf mp-ch-de.pdf mwidget-p.pdf xmathml-p.pdf
cont-enp.pdf metafun-p.pdf mp-ch-en.pdf mxmltools.pdf xmathml-s.pdf
cont-nlp.pdf mk.pdf mp-ch-nl.pdf pstopdf.pdf xmlfoe.pdf
details.pdf mlabels.pdf mpstopdf.pdf showfont.pdf xml-mkiv.pdf
envelop.pdf mmakempy.pdf mscite-p.pdf showunic.pdf xphysml-p.pdf
eppchtex.pdf mmlexamp.pdf msplit.pdf style.pdf xsteps-s.pdf
example.pdf mmlprime.pdf mtexexec.pdf tiptrick.pdf xxmldir.pdf
ex-gui.pdf mmodes.pdf mtexfont.pdf xchemml-p.pdf
foxet.pdf mmoexamp.pdf mtexmfstart.pdf xcorresp.pdf
hybrid.pdf mpattern.pdf mtexsync-p.pdf xfigures-p.pdf`

A parte quelli in olandese quali si possono scremare o più esattamente quali mi consigli da studiare ritenendoli essenziali?
Grazie in anticipo per la risposta. 😉

accidenti quanta roba…vista tutta insieme viene da mollare tutto.
Comunque la lista completa è in
http://www.pragma-ade.com/wget.txt

Con questi due hai lo spririto di ConTeXt: coprono quasi tutto
http://www.pragma-ade.com/general/manuals/cont-enp.pdf
http://www.pragma-ade.com/general/manuals/metafun-p.pdf

Reference x l’utente esperto
http://www.pragma-ade.com/general/qrcs/setup-en.pdf

Layers
http://wiki.contextgarden.net/Layers
http://www.pragma-ade.com/general/manuals/details.pdf

Colori
http://www.pragma-ade.com/general/manuals/msplit.pdf

Columns, ma orientato al magazine
http://www.pragma-ade.com/general/manuals/columns.pdf

Tabelle
http://wiki.contextgarden.net/Tables_Overview
tabulazioni
http://www.ntg.nl/maps/pdf/22_28.pdf
natural table
http://www.pragma-ade.com/general/manuals/enattab.pdf
http://dl.contextgarden.net/myway/NaturalTables.pdf

“Compilazione” condizionata
http://www.pragma-ade.com/general/manuals/mmodes.pdf

I fonts sono.. difficili
Per MkII
http://www.pragma-ade.com/general/manuals/mfonts.pdf
http://www.pragma-ade.com/general/manuals/mtexfont.pdf

Per MkIV in teoria l’instlalazione è più semplice:
http://www.pragma-ade.com/general/manuals/tools-mkiv.pdf
ma è meglio far riferimento al wiki.

Mi è gia passata la voglia… 😀

Ma permettimi un piccolo sfogo da dove nasce l’esigenza di avere strumenti così complicati per lavorare 😕

Il mio punto di vista, che ho espresso più volte e che continuo a ritenere valido, è il seguente: si tratta di programmazione tipografica.
TeX è un linguaggio di programmazione e la sua semantica è la tipografia.
Credo vi siano al mondo 100 /200 linguaggi di programmazione, alcuni chiaramente
generici (C , C++, Java, Python, Lisp…) alcuni con output dedicato ma semanticamente generico (Assembly per x86 ad esempio), alcuni decisamente semanticamente dedicati
(SQL (sue estensioni proprietarie) , PostScript ad esempio ) altri a mezza via , come Perl — Practical Extraction and Report Language, ma se la cava bene in situazione generiche.
In generale però la teoria che sta dietro a questi linguaggi è solida e distribuita a vari livelli (i.e da un livello base ad un livello avanzato, tanto per capirci) e per ogni linguaggio si trovano anche parecchi esempio di applicazione — ma è raro trovare esattamente il programma completo che cerchi: in genere prendi spunto/adatti quelli esistenti

Nel caso del TeX , però, a situazione è differente: in primo luogo la teoria della programmazione tipografica , in paragone
alle altre teorie viste sopra, non è così sviluppata ed anche difficile da definere. Lo stesso termine tipo-grafia se visto in ottica mondiale ha una significato diverso rispetto a quello al quale noi occidentali siamo abituati, ossia grafia del “tipo” e le sue problematiche di spazio bianco/nero
Per le lingue orientali la tipografia è più tipo-grafica , per le lingua arabe siamo tra grafica e calligrafia (basta pensare alla calligrafia usata per decorazione).
E’ vero che esiste nel mondo una imponente quantità di documenti che hanno in comune delle strutture ( e questo se non altro per
effetto della globalizzazione) e che Knuth è partito da una istanza concreta di documento (essenzialmente i libro di computer science
che è un preciso modello di testo in lingua inglese con espressioni matematiche) per ricavare un modello di documento che va bene per molti casi e che è stato relativamente semplice adattare a nuovo situazioni (tipo ad esempio la composizione da destra verso sinistra).
E’ vero anche che il suo testo fondamentale è un mix di spiegazione del linguaggio TeX, di concetti illustrati solo con esempi, di teoria , ma non è un testo teorico di programmazione tipografica — ed infatti Knuth a prodotto una istanza concreta di documento, il formato plain che può essere usato come base di partenza per implementare altri tipi di documenti ma che oggi è pochissimo usata di per se,

La seconda complicazione è che TeX è un linguaggio di programmazione atipico perché si basa sulle macro (in breve, una macro definisce una serie di simboli che verranno emessi nel flusso di uscita nel momento in cui il programma raggiunge la macro nel flusso in entrata), ed anche perché è un linguaggio di programmazione turing complete — completo come quelli visti in precededenza , C ,C++, Java etc.
E la programmazione con le macro non è esattamente un paradigma di programmazione diffusa — esiste un solo altro linguaggio simil, M4, usato per lo più la configurazione di librerie — e talvolta non è per niente semplice accedere tramite le macro TeX agli stesso oggetti primitivi del TeX: si pensi ad esempio a scomporre una scatola verticale od orizzontale. Insomma, programmare in TeX è complesso e complicato.

Bene, allora forse esiste qualcos’altro ? Un nuovo linguaggio, una nuova teoria ?
No.
Io credo che TeX sia la cosa migliore; le altre soluzioni sono state e saranno varianti del TeX, oppure realizzabili come “estensione”, sia pure massiva , del formato plain.
LaTeX e ConTeXt ricadono in questo casistica, come pure luatex e ConTeXt MKIV
Anche PostScript può essere visto come variante del TeX (e viceversa certo, ma è il dvips che “ha vinto”: ci sono pochi linguaggi di programmazione tipografica simil TeX implementati in postscript)
Il linguaggio macro, poi, è il migliore proprio perché si immerge nel testo — il testo è il programma, in sostanza.
Gli altri linguaggi vedrebbero il testo come input del programma, programma che sarebbe quindi una entità separata dall’input — cosa che, comunque , è facilmente ottenibile anche col TeX.

E’ evidente che se vieni dal mondo di Indesign, trovi pochi punti di contatto se consideri solo l’aspetto DTP (=disegno col mouse), ma chiaramente Tex diventa competitivo quando devi programmare con Indesign, visto che ti ritrovi ad affrontare gli stessi problemi di programmazione.

E’ evidente che se vieni dal mondo di Indesign, trovi pochi punti di contatto se consideri solo l’aspetto DTP (=disegno col mouse), ma chiaramente Tex diventa competitivo quando devi programmare con Indesign, visto che ti ritrovi ad affrontare gli stessi problemi di programmazione.

Quanta saggezza in questa ultima frase.

Moltissime persone, quando sentono parlare di Latex (e dei suoi derivati), inorridiscono e considerano le persone che usano questi strumenti alla stregua dell’uomo preistorico non evoluto.

Mi ritengo un esperto di prodotti quali Word, e anche molto bravo in Latex e posso confermare che con Word fai delle cose che pochissimi possono immaginare …. MA solo se sai programmare bene in VBA e ti fai delle macro che sono complicate tanto quanto la programmazione delle macro in Tex … tanto vale usare il Latex.

Detto questo, posso confermare che molte volte ho fatto prima a produrre degli ottimi elaborati in Latex piuttosto che in Word. Ovviamente non sto parlando di documenti di due paginette.

Mi ritengo un esperto di prodotti quali Word, e anche molto bravo in Latex e posso confermare che con Word fai delle cose che pochissimi possono immaginare …. MA solo se sai programmare bene in VBA e ti fai delle macro che sono complicate tanto quanto la programmazione delle macro in Tex … tanto vale usare il Latex.

E con LuaTeX (in futuro con LuaLaTeX) Lua: TeX = VisualBasicForApplication:Word
e puoi fare cose che risulterebbero molto più complicate usando solo TeX (LaTeX):
cfr ad esempio
http://www.gust.org.pl/bachotex/2011-en/presentations/Scarso_2_2011
Quanto a Word, alla fine credo che il suo unico problema sia, dal punto di vista di disponibilità su diverse piattaforme hw/sw, documentazione, costi, di non essere così accessibile come è il TeX: ad esempio con la TeXLive hai *tutto* il TeX gratis, e
gcc, Lua sono pure disponibili in rete a costo zero.
Quello che più si avvicina è Libre/OpenOffice, ma non è Office.

Ciao clafe.

clafeMi ritengo un esperto di prodotti quali Word, e anche molto bravo in Latex e posso confermare che con Word fai delle cose che pochissimi possono immaginare …. MA solo se sai programmare bene in VBA e ti fai delle macro che sono complicate tanto quanto la programmazione delle macro in Tex … tanto vale usare il Latex.

Anche un utente molto esperto di Word, di VBA e anche di tipografia, non potrà raggiungere il livello di composizione di LaTeX. Mi spiego meglio. Si provi a scrivere una serie di paragrafi in Word, e poi si scriva la stessa serie di paragrafi con LaTeX. Nel 99% dei casi, basterà un’occhiata per notare la differenza. La microtipografia che manca in Word (non sono sicuro che non ci sia proprio, ma sicuramente manca di default) e i “fiumi” che scorrono nei paragrafi tolgono molto alla qualità dello scritto. Se poi parliamo di composizione matematica, allora non c’è più discussione: in Word oltre ad essere più lenta e faticosa la scrittura delle formule, il risultato estetico è ben al di sotto di quello che sa fare LaTeX. C’è poi la questione delle immagini. Word ha la capacità di LaTeX di scegliere il posto migliore per posizionarle?

La mia domanda è: quali sono alcune di queste “cose che pochissimi possono immaginare”?

Grazie e buona giornata,
Marco.

luigi.scarso” post=57010
La differenza è un po’ come andare ad un ottimo self-service (Latex)
o cucinarsi il pranzo (ConTex). Nel primo caso la fatica
è comporre il piatto (immagina di avere moltissima scelta),
nel secondo bisogna prima capire come si fanno le cose elementari e via via si fanno le cose più complesse.

Premetto che ho iniziato da soli 2-3 giorni a leggere i manuali di context ed a spulciare vari siti e forum, ma mi ha incuriosito questa frase perchè mi ha fatto pensare la seguente cosa: qual’è la differenza a cucinarsi il piatto creandosi la propria documentclass latex? (o, dove possibile, customizzando altre).

Ciao

Diciamo che se usi sempre Latex con un numero prefissato di packages e customizzi quelle, allora ti sei creato una specie di context.
Vediamo qualche differenza (L=LateX, C=ConTeXt mkiv)

L) i packages devono stare bene insieme (efficienza = non sovrapposizione di compiti , correttezza=non ridefinire macro altrui)
C) i moduli stanno bene insieme per design

L) ciascun package ha un suo sviluppatore, e latex base ha i l suo mantainer
C) esiste un solo sviluppatore (a dire il vero ne esite un secondo, ma si occupa dei suoi moduli)

L) la maggior parte dei packages *non sono* nel formato (non sono “precompilati” ma caricati runtime)
C) la maggior parte dei packages *sono* nel formato (sono “precompilati”, pochi sono caricati runtime)

L) una scelta accurata dei packages permette di avere un motore ritagliato per le proprie esigenze e questo comporta buone perfomance
C) non sempre tutti i moduli sono necessari per un dato compito, e questo influisce sulle performance.
In entrambi i casi è sempre possibile produrre un formato con i packages (L) / moduli (C) voluti, ma con C è un pochino più complicato.

L) lualatex ed il supporto opentype probabilmente necessitano di un maggiore coordinamento
C) Lua ed opentype hanno il migliore supporto

luigi

Grazie per la risposta. Onestamente la questione rimane ancora un pò confusa per me.
Potresti fornirmi qualche esempio in cui è vantaggioso L rispetto a C e viceversa?

Grazie, ciao

Luigi è il grane esperto di ConTeXt mkiv e di LuaTeX, quindi è la persona più indicata per risponderti.

Io non ho mai usato ConTeXt, anche se l’ho studiato per vedere se avrebbe potuto essermi utile. Ho deciso che per le cose che faccio io il buon vecchio LaTeX è quello che fa per me, ma, come vedi è una conclusione del tutto personale. però conosco abbastanza il sistema TeX per affermare quanto segue:

1) motori di composizione del sistema TeX sono cinque — probabilmente bisognerebbe citare anche aleph, ma ho il sospetto che da quando sono in giro gli altri motori, stia perdendo il suo fascino, anche perché una buona fetta delle librerie di aleph sono state integrate in LuaTeX. I motori sono (li indico con l’estensione .exe, che manca nelle macchine non Windows, ma preferisco usare questa estensione per essere sicuro di essere capito quando parlo di motori di composizione); (a) tex.exe; (b) pdftex.exe; (c) xetex.exe: (d) context.exe; (e) luatex.exe. Forse per context.exe bisognerebbe fare dei distinguo, ma per semplificare supponiamo che sia così. tex.exe viene ancora distribuito ma di fatto non viene mai usato, perché le sue funzionalità sono tutte incorporate in pdftex.exe, che però può produrre l’uscita in formato .dvi, come tex.exe, oppure in formato .pdf ed è questo formato che lo caratterizza nel nome e lo distingue da tex.exe grazie alle maggiori funzionalità del formato .pdf rispetto al formato .dvi. Di fatto i motori usati si riducono a quattro.

2) ogni motore di composizione lavora in congiunzione con un file di formato che ha estensione .fmt; quando dai il comando pdflatex, in realtà dai il comando pdftex.exe & latex.fmt; di formati ce ne sono diversi; il più antico, creato da Knuth stesso è plain.fmt; gli altri sono tutti più o meno moderni; alcuni sono usati in ambiti strettissimi; il più diffuso è latex.fmt. In realtà si tratta di una semplificazione; il file di formato viene creato dal motore di composizione nella sua funzione di inizializzatore, e motori diversi creano formati diversi perché le funzionalità del codice eseguibile sono diverse; quindi pdftex.exe può creare pdflatex.fmt, xetex.exe può creare xelatex.fmt; eccetera, ma questi sono sempre la traduzione in linguaggio macchina e in relazione al motore di composizione dello stesso insieme di macro.

3) Io metterei (pdf)tex.exe & plain.fmt e context.exe sullo stesso piano; non fanno le stesse cose, ma sono essenziali entrambi; context.exe fa molto, molto, molto di più di plain, ma sostanzialmente non richiede pacchetti esterni; sì ne esistono, ma sono pochissimi, non perché non ci sia interesse ad usare context.exe, ma perché context.exe fa già moltissimo per conto suo. Non ho notizie di un xeplain.fmt o di un luaplain.fmt; forse esistono, forse no, ma ho visto usato xetex.exe da solo e anche luatex.exe da solo; Quando Johnathan Kew presentò XeTeX nel 2005 o 2006 ci volle un po’ di tempo prima che uscisse XeLaTeX (xetex.exe & xelatex.fmt) quindi le prime composizioni eseguite con xetex.exe avevano (apparentemente) solo il programma eseguibile e un certo numero di macro definite nella prima parte del file da comporre.

4) L’enorme sistema di macro scritte da Leslie Lamport ha permesso ad un numero enorme di utenti di affacciarsi al mondo del sistema TeX; non è un caso che esistano pdfLaTeX, XeLaTeX, LuaLaTeX, formati dai relativi motori e l’insieme di macro di LaTeX. A fianco dell’insieme di macro di Leslie Lamport moltissimi autori hanno contribuito con una miriade di pacchetti, senza però coordinarsi reciprocamente e senza un controllo superiore che verificasse la compatibilità reciproca; questo con ConTeXt non succede, come ha ben spiegato Luigi.

5) Se un utente di LaTeX fosse costretto a usare sistematicamente molti pacchetti, potrebbe costruirsi una classe da solo nella quale sarebbe lui il responsabile di ogni macro e sarebbe lui stesso ad auto coordinarsi per non ridefinire cose esistenti e per gestire le sue macro in modo compatibile; si preparerebbe la minestra da solo, seguendo la metafora di Luigi. Volendo quell’utente potrebbe anche crearsi un file formato con il nome che preferisce, purché abbia estensione /fmt e purché non usi il nome di uno dei formati esistenti, in modo da includere sia l’insieme di macro di LaTeX, sia quelle dei pacchetti che vuole usare. Secondo me non è una buona idea, ma si può fare; anzi è fatto dal sistema TeX commerciale noto come VTeX dove i file di sillabazione in linguaggio macchina sono compilati ad uno ad uno per ogni lingua (almeno così era fino ad alcuni anni fa) e usati come file .fmt secondari da caricare al momento dell’esecuzione senza bisogno di ingombrare la memoria dell’elaboratore con strutture hash di pattern che non vengono usate. Oggi direi che la cosa sia diventata irrilevante data la grandezza delle RAM di tutti i calcolatori piccoli e grandi, personali, nettop, laptop, oppure mainframe.

6) Se vuoi avere una idea di quanti formati esistono e se hai una distribuzione TeXLive o macTeX va nella cartella …/texlive/2012/texmf-var/web2c/pdftex/per vedere quali e quanti formati sono stati costruiti solo con il motore pdftex.exe; la cartella web2c di quell’albero in pratica contiene sol i file di formato .fmt e i file .log corrispondenti alla loro creazione con tutti i motori possibili, compresi alcuni che non ho nemmeno elencato al punto 1) perché non ho idea di che cosa siano (mi pare che il motore ptex.exe riguardi il giapponese)

Detto questo, non so se hai le idee più chiare o più scure. ma queste sono cose difficili da spiegare senza fare esempi; se hi mai provato ad usare plaintex (cioè tex.exe & plain) puoi avere una idea abbastanza chiara della differenza fra plain e latex; con context.exe è molto più difficile fare esmepi, perché esso è costrito con il medesimo approccio diretto ad ogni singolo aspetto della composizione tipografica, ma fa con un approccio diverso molte delle cose che si pososno fare con LaTeX; per esempio la gestione dei font è molto diversa, am di fatto puoi selezionare le 5 caratteristiche di ogni font in modo autonomo come con LaTeX ma, per esempio, i corpi sono scelti con comandi del tipo \larger oppure \smaller, quindi comandi relativi al corpo del font in uso in quel momento, e non con comandi assoluti come \Large, \small, eccetera che si possono usare con LaTeX; gli ambienti cominciano con \startambiente e finiscono con \stopambiente, ma non sono sicuro che qualunque cosa definita fra questi due delimitatori rimanga locale (questo dipende dalla mia ignoranza, non da un mio dubbio consapevole). Comunque si può accedere ad un qualunque aspetto tipografico dello stampato senza bisogno di pacchetti esterni o di comandi particolarmente complicati. La rigidezza del formato LaTeX non permette di fare certi errori (ne consente molti, ma certi sono evitati per costruzione); context in mani inesperte può produrre danni non indifferenti; in mai esperte fa cose deliziose.

Usare pdflatex o xelatex o lualatex o context dipende da quello che vuoi fare; ognuno ha pregi e difetti; ognuno ha applicazioni preferenziali; direi che context è particolarmente adatto in una tipografia avanzata dove vengono predisposti stampati molto complessi e molto strutturati con informazioni raccolte da database adeguati e dove si usano molte tabelle con figure incluse. Luigi fa cose di quel genere, quindi per lui context è particolarmente utile. Per un libro di novelle o per un testo scolastico, specialmente di scienze “dure”, non credo che context sia particolarmente adatto. Tuttavia l’ho detto all’inizio: l’ho studiato, ma non l’ho mai usato per davvero, quindi Luigi può smentirmi alla grande.

Se siano più chiare o più scure non lo so nemmeno io 🙂
Diciamo che avrei un numero di domande nell’ordine delle centinaia ma prima di porvele proverò a mettervi ordine.

Cmq, giusto per lo storico della discussione, avevo iniziato a documentarmi su context dopo aver letto (non ricordo più dove, sul web) che per l’impaginazione di una rivista sarebbe meglio di LaTeX. Quindi ho letto il manuale di Hagen ma sono rimasto col dubbio che ho già esposto, cioè: non sarebbe meglio fare tutto con le primitive latex? Risposta (attuale/personale): bho! 🙂

Nel frattempo, grazie per le risposte, come sempre preziose.

Ciao

PS. Per quel che riguarda tutto l’abc dei motori di composizione, bhè, quello è scurissimo 😀

DirkPitt” post=79159Grazie per la risposta. Onestamente la questione rimane ancora un pò confusa per me.
Potresti fornirmi qualche esempio in cui è vantaggioso L rispetto a C e viceversa?

Grazie, ciao

Se devi pubblicare articoli scientifici per una rivista o libri scientifici per un editore (tipo springer) , al ~100% la scelta è tra LaTeX o Word.

Se fai database-publishing puoi scegliere tra LaTeX e ConTeXt , ma ConTeXt è più indicato, soprattutto perché puoi usare Lua come useresti python.

Se vuoi scrivere un libro per conto tuo e poi vendere le copie stampate su, per esempio, LuLu (i.e. autopubblicazione ) vanno bene entrambi;
con LaTeX hai più supporto per la matematica, mentre in ConTeXt probabilmente dovresti chiedere qualche aiutino,
con ConTeXt hai più facilità nella gestione del testo.
Tieni conto che la comunità Latex è più vasta di quella di context, ma alla mailing list di context risponde direttamente
lo sviluppatore principale.

Le edizioni critiche si fanno in LaTeX: non è un’area particolarmente attiva in ConTeXt allo stato attuale .

Se hai un testo che assomiglia ad una rivista (testo su multicolonne, foto su più colonne, layout a griglia) ConTeXt credo renda (molto?) meglio di LaTeX,
ma entri in competizione con Scribus prima ed Indesign dopo, per cui bisogna valutare se il gioco vale la candela.

Un apparente vantaggio è il fatto che ConTeXt mkiv integra metapost e quindi unisce la grafica (o meglio la possibilità di fare illustrazioni tecniche) alla tipografia in modo più integrato.
E’ apparente: di fatto metapost è utile per creare qualche effetto, ma per illustrazioni conviene sempre il sistema di prepararle a parte con il migliore tool.
Ad esempio , se usi context e sai che una certa illustrazione viene bene con pgfplots/tikz o pstricks, allora è meglio produrre il relativo pdf con latex ;
se sei con latex e ti serve metapost , allora un pdf fatto con context può essere la soluzione.
E se non ne vieni fuori, inkscape.

PS. Per quel che riguarda tutto l’abc dei motori di composizione, bhè, quello è scurissimo

Be’, certo, questo è un argomento che non si può esaurire in quattro parole; del resto ho scritto diverse pagine su questo argomento sulla GuidaGuIT, dove forse non sono stato più chiaro che nel messaggio precedente.
Ma la questione, che oggi potrebbe apparire di lana caprina date le dimensioni della memoria degli elaboratori e della loro velocità di elaborazione, è che il file latex.ltx con tutte le macro inizialmente scritte da Leslie Lamport è un file di poco più di 8000 righe; contiene alcune migliaia di definizioni di macro, alcune costituite da pochi comandi, altre da alcune righe di programma, altre ancora di molte decine di righe. Se ogni volta che si lancia pdflatex il programma dovesse interpretare ogni macro ogni volta che la deve usare, il tempo di esecuzione per compilare un documento sarebbe decisamente lungo. Se invece il file latex.ltx viene letto da un motore di composizione (quelli che ho indicato con l’estensione.exe) e ogni macro è non solo convertita in un linguaggio facile da eseguire da parte del programma, e facile da reperire in una struttura di record facile da esaminare per trovare le istruzioni da eseguire per ciascuna macro, il tempo di esecuzione cala moltissimo; questa traduzione in linguaggio macchina viene salvata una volta per tutte nel file di formato xxxlatex.fmt, dove xxx è un prefisso che dipende dal motore usato.. è per questo che né da terminale, né attraverso gli editor dedicati vengono mai dati i comandi primitivi “motore & formato” (cioè per esempio “pdftex & latex,fmt”), ma viene dato un comando “pdflatex” che solleva l’utente dal ricordarsi come si fa ad usare ogni comando primitivo e tutto sommato nasconde la vera natura del problema all’utente finale. Se l’utente conosce queste cose è anche in grado di capirne altre. se non le conosce può guidare la macchina lo stesso, ma al primo bubù, non sa che cosa fare e dove andare a cercare la causa del bubù.
In fondo tutti abbiamo la patente a guidiamo un veicolo, ma pochissimi di noi patenetati conoscono la differenza fra il ciclo termodinamico di tipo Otto o di tipo Diesel. Per guidare non serve, e se la macchina si ferma, è inutile andare a cercare le candele in un motore funzionante con il ciclo diesel, o andare a pulire gli iniettori in un motore a ciclo Otto; peggio ancora: constatando che il cadometro del serbatoio segna “zero” e non conoscendo la suddetta differenza, sarebbe un errore caricade di benzina senza piombo il serbatoio di un motore a ciclo Diesel, o di gasolio il serbatoio a ciclo Otto.
Non so se questa metafora non culinaria come quella di Luigi renda l’idea a proposito dei motori e dei formati.

Si rende l’idea:)
Poi mi riguardo la parte della tua guida.

Grazie di nuovo, ciao