luigi.scarso

Mi fa piacere, ma immagino che ross e ulrike lavorino su due engine differenti, (pdftex & luatex) e le soluzioni (in latex) temo non possano prescindere dall’engine. Inutile dire che ritengo luatex adeguato, se non altro perché ConTeXt mkiv produce pdf/a-2a ormai da un po’ di tempo (con annesso MathML) .
Ma devo ammettere che ho una prospettiva diversa, più generale , ed il requisito LaTeX è un vincolo che non è e non deve essere necessario: pdf/a-2a pdf/ua deve funzionare (in luatex) a prescindere da latex. Detto in altro modo: luatex non deve avere limiti strutturali
tali da impedire ad un formato la produzione di pdf di un certo tipo. ConTeXt dimostra che per pdf/a-2a questi limiti sembra non ci siano, probabilmente non ci sono neppure per pdf/ua,
ma dobbiamo considerare ad esempio pdf 2.0, o fonts variabili.

Siamo ben consci delle “osservazioni” sulla stabilità, ma questo credo chiarisca:
https://mailman.ntg.nl/pipermail/ntg-context/2018/093154.html

Siamo fermamente intenzionati a seguire la roadmap sopra tracciata.

Come ‘miscreants’ della TeXLive (https://www.tug.org/texlive/) e devoloper di LuaTeX, il mio è un punto di vista di parte.

1) TeXLive offre 17 “destinazioni” — aarch64-linux amd64-freebsd amd64-netbsd armhf-linux i386-cygwin i386-freebsd
i386-linux i386-netbsd i386-solaris sparc-solaris win32 x86_64-cygwin x86_64-darwin
x86_64-darwinlegacy x86_64-linux x86_64-linuxmusl x86_64-solaris .
Trovare un installer che funzioni per tutte è arduo, trovare un GUI installer quasi impossibile.
TeXLive usa perl, un linguaggio più-che-solido che funziona praticamente ovunque
(il che rende felici gli amministratori di sistema), e usa Tk come GUI, che non piace a nessuno
ma almeno fornisce una minima funzionalità GUI.

2) L’installazione è descritta in https://www.tug.org/texlive/doc/texlive-en/texlive-en.html
In 3.2.2 Selecting what is to be installed ci sono gli schemi:

Select scheme:
===============================================================================
a [ ] full scheme (everything)
b [ ] medium scheme (small + more packages and languages)
c [ ] small scheme (basic + xetex, metapost, a few languages)
d [ ] basic scheme (plain and latex)
e [ ] minimal scheme (plain only)
f [ ] ConTeXt scheme
g [ ] GUST TeX Live scheme
h [ ] infrastructure-only scheme (no TeX at all)
i [ ] teTeX scheme (more than medium, but nowhere near full)
j [ ] custom selection of collections

In genere consiglio “b” o “c”, oppure la full se non si hanno problemi di banda e/o spazio su disco.

3) TeXLive tende ad essere universale, i.e. si rivolge al mondo, non
solo ad utenti window/osx/linux occidentali (che sono comunque una fetta molto rilevante).
Detta diversamente: con una full installation uno ha un pezzetto di mondo nel pc.

#####

Ieri sera ho installato la full, circa 50 minuti tra download ed installazione, come usuale.
Uso la full perché devo poter correggere eventuali bugs in luatex.
Ho provato install-tl-unx.tar.gz con schema small, circa 510M in poco meno di 10 minuti, anche qui nessuna sorpresa.
Ho la fibra ottica di Telecom, situazione piuttosto comune in città.

Per quanto riguarda MikTeX: è una distribuzione TeX che supporta win (ed ultimamente osx e linux)
che ha una sua storia consolidata. Non sono sorpreso che abbia un installer più user friendly di TeXLive.
Dal punto di vista di LuaTeX, MikTeX usa i sorgenti da TeXLive e li adatta,
il che implica che in teoria potrebbero esserci discrepanze tra luatex di texlive e luatex di miktex.
Ad esempio scaricando il sorgente di miktex, per luatex 1.07.0 ho notato un “Development id: 6635”
mentre texlive ha “Development id: 6686” .
Questo è piuttosto importante, perché 6635 potrebbe non essere completamente ok: durante la fase finale
di TeXLive è fondamentale che il mio codice sia costantemente allineato con texlive (e viceversa)
e la differenza tra i due numeri mi dice che qualcosa è cambiato. Potrebbe essere qualcosa
che non ha niente a che fare con luatex (per esempio file di documentazione aggiornati).
Comunque, fino ad oggi non sono a conoscenza di incompatibilità.
Non credo che TeXLive possa essere così user friendly come MikTeX, ma riguardando gli schemi
mi viene da pensare che nulla impedisce di proporre (= implementate e testare) un “humanist scheme”.
Esiste un ConTeXt scheme, un GUST scheme (per il tex user group polacco) un teTeX scheme (e chi sa la ricorda più teTeX)…
non vedo perché non possa esistere un “humanist scheme”.
Ovviamente, non chiedete a me cosa metterci dentro a questo “humanist scheme”.

Per quanto riguarda l’utente che “vuole solo fare la tesi e basta”, capisco che l’installazione di MikTeX è più appetibile,
ma non così diversa da TeXLive. Detto in altri termini: ormai si richiede che un qualsiasi utente universitario sappia scaricare
ed installare un programma da una pagina web. Se non lo sa fare imparerà, se non vuole imparare, amen, è una sua scelta. Le cose da “nerd” non sono queste, sono ben altre.
Mi viene da pensare però che forse l’università dovrebbe fornire un qualche tipo di supporto, tipo una installazione LaTeX, almeno
per garantire omogeneità di stile, o perlomeno una pagina html con i passi fondamentali per installare i programmi (ok, Overleaf è fantascienza).
Ovviamente la risposta in Italia è del tipo “l’università non ha soldi, gli studenti/dottorandi… si arrangino”.
Capisco un po’ meno l’osservazioni sul tempo di installazione: mezz’ora per installare un programma per fare una tesi
che richiede almeno un mese significa qualcosa come 0.3% del tempo dedicato all’installazione.
Non lo vedo come il principale problema: il problema è dopo, i.e. come usare LaTeX senza distogliere troppe energie dalla tesi.
Se un laureando non ha alcuna intenzione di imparare LaTeX perché semplicemente non ha energie/tempo da investire in qualcosa che dopo non userà,
ne qualsiasi schema TeXLive e ne MikTeX sono la soluzione — è meglio che usi LibreOffice o Word.

Grazie per le segnalazioni, cercheremo al più presto di correggere. Il vecchio sito è
sempre in attesa di esser trasferito nello nuova piattaforma, alcuni link nel frattempo sono diventati morti.

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

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.

l “Suspect” del report so riferisce giustamente ad una situazione del colori non gestibile direttamente con il pdftex di 10 anni fa — e da allora le cose non sono molto cambiate, tranne che con ConTeXt MkIV si introduce il supporto per PDF/X e PDF/A.

Hm, no, non mi sono spiegato bene.
La situazione a cui mi riferisco è che in media un utente TeX non conosceva molto oggi come allora il mondo del colore, quindi in genere si accontenta dello spazio colore RGB e CMYK senza profili.
Ma basta vedere in
texmf-dist/doc/pdftex/manual/samplepdf/samplepdf.tex
(line 648) per capire che è possibile associare un profilo ad una immagine (ed ad uno spazio colore) quindi è possibile gestire direttamente in pdftex (vers. 1.21 in poi)
i profili colore.
In ConTeXt MkIV le cose sono solo organizzate in modo più coerente con PDF/X e PDF/A

[quote]Ciao a tutti,

Sto scrivendo la mia tesi di laurea che prevede listati in PHP e HTML e pertanto ho installato il pacchetto listings il problema è che durante la compilazione non funziona nulla non crea il pdf.

Grazie anticipatamente

Salvatore

Capisco l’ansia, ma ci serve un esempio minimo e sapere che sistema usi.

hai ragione:

uso windows 7 ho installato miktex 2.9 e uso texmakerx come editor

[/quote]
Intendevo “esempio minimo compilabile” — di sicuro questo non compila, cioè non produce alcun pdf. Non è per essere pedanti, ma può essere che il tuo codice sia giusto e ti sia imbattuto in un bug: finché non lo vediamo non lo sappiamo.