OldClaudio

Claudio, il tuo “esperimento” è molto interessante, ma procede dall’alto in basso e non permette, secondo me, di vedere chi effettivamente è caricato da chi.

Ti faccio un esempio semplice.
amsfonts è caricato da amssymb, sempre; quindi effettivamente uno è autorizzato a ritenere che amsfonts dipenda da amssymb. Giusto; Ma proprio per questo amsfonts non dovrebbe mai venire caricato dall’utente, perché quando ha caricato amssymb, senza il quale non dispone dei comandi per i vari simboli, amssymb carica amsfonts che l’utente lo voglia o no; L’albero amssymb -> amsfonts non interferisce con altri pacchetti.

Altro esempio: caricando graphicx, viene caricato anche graphics; se ne deduce correttamente che il primo dipende dal secondo; sì, è corretto, ma la situazione non è simile a quella di amssymb e amsfonts; se carichi graphics, questo non carica graphicx; quindi esiste una dipendenza, ma unilaterale. Se specifichi graphicx, quindi, esso carica ciò da cui dipende, ma a sua volta carica trig (per le funzioni trigonometriche necessarie per le rotazioni e i cambiamenti di scala che richiedono di costruire adeguatamente la matrice di trasformazione dei linguaggi PDF e PS). Si può dedurre che graphicx dipenda da trig. Ma per stabilire come costruire correttamente la matrice di trasformazione deve conoscere con quel “engine” si sta compilando il file e saputolo, carica un opportuno file .def (dvips.def, pdftex.def, xetex.def,…) quindi graphicx dipende da tutti questi file .def. Ma è giusto chiamarle dipendenze?

Quindi il tuo approccio è giusto, ma va spiegato meglio chi chiama chi e \listfiles dà solo l’elenco dei file caricati; per sapere chi ha caricato che cosa, bisognerebbe esaminare di volta in volta il file .log e controllare l’apertura e la chiusura delle parentesi tonde; nel file .log l’apertura di in file è segnalata dal nome completo di percorso del file preceduto da una tonda aperta; la fine della lettura di quel file è segnalata da una tonda chiusa. Fra queste due parentesi possono venire caricati e letti altri file che a loro volta possono… eccetera; solo così si può sapere esattamente chi chiama che cosa e si può costruire un albero delle dipendenze.

Un’altra cosa: le classi standard di solito per ogni opzione caricano un file che ne implementa le funzionalità; non tutte le opzioni si comportano così, ma è frequente. Per esempio book, report e article per ogni opzione di corpo caricano un file opportuno con estensione .clo che sta per class option, anche la posizione delle equazioni e dei loro numeri dipende da due altri file .clo. In questi casi si può dire che book e compagnia dipendano dai file .clo, ma in parte è vero e in parte no: cioè book e compagni dipendo dai file .clo per impostare i font con i loro corpi, ma di volta in volta scelgono solo una di queste opzioni, non tutte contemporaneamente; per questo io non considererei i file .clo come dei prerequisiti al funzionamento delle classi; certo, almeno uno di questi file ci vuole, ma non è necessario che ci siano anche gli altri file .clo per gli altri corpi. Oppure non è obbligatorio che ci siano solo tre file .clo per i corpi; la classe memoir dispone di una collezione di file .clo per i corpi che va, mi pare, da 7pt a 60pt.

Altre dipendenze soo più delicate; sarebbe una cosa utile se tutti i pacchetti che richiedono di essere caricati dopo di altri lo verificassero e nel caso segnalassero un errore; molti autori lo dicono nella documentazione, ma spesso non creano il codice di verifica o non provvedono a caricare inizialmente il pacchetto o i pacchetti necessari. Per certi versi fanno bene, perché se li caricassero con certe opzioni, e poi l’utente li ricaricasse con altre opzioni si avrebbe l’errore di “option clash”.

Insomma è molto difficile scoprire le vere dipendenze, certamente \listfiles non basta anche se è un buon punto di partenza.

Conclusione: il lavoro che hai cominciato è utile ed interessante, ma dovresti almeno corredare il tuo elenco con dei capoversi esplicativi per avvertire i lettori di alcune cose come quelle che ti ho segnalato (che sono ben lontane dall’esaurire la casistica) in modo che il lettore sia messo sull’avviso.

Ottimo lavoro: continua pure e tienici informati. Grazie

Claudio

Hai provato a scrivere`\usepackage{“/Volumes/Macintosh HD/Users/syldor/Dropbox/Teo_Latex/bibleref_LXX”}`
Generalmente quando i nomi dei file contengono spazi si rende necessario racchiuderli fra doppi apici. Suppongo che la stessa cosa sia valida anche quando si usano dei percorsi completi.

Usando il pacchetto xkeyval le definizioni per le opzioni sono più semplici; mettendo nel pacchetto anche la descrizione del font modificata con l’aggiunta del fattore di scala, si ha il duplice vantaggio di poter specificare con una opzione il fattore di scala nella chiamata del pacchetto, e non si ha nessuna interferenza fra la descrizione dei font di questo pacchetto e quella degli altri font; quindi puoi salvarlo nel tuo albero personale e usarlo con qualunque documento.`\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{lmvttscaled}[2014/12/19 v.1.0 Load Latin Modern variable teletype font with appropriate scale factor]
\RequirePackage{xkeyval}
\DeclareOptionX{scalefactor}[1.0]{\def\lmvtt@scale@factor{#1}}
\DeclareOptionX*{PackageWarning{lmvttscaled}{`\CurrentOption' ignored}}
\ExecuteOptionsX{scalefactor=1.0}
\ProcessOptionsX

\DeclareFontFamily{T1}{lmvtt}{}

\ifx\lmtt@use@light@as@normal\@empty
% macro defined, so we use the light variant as medium (m), and
% medium as semi-bold (sb):
\DeclareFontShape{T1}{lmvtt}{sb}{n}
{<-> [\lmvtt@scale@factor] ec-lmvtt10}{}
\DeclareFontShape{T1}{lmvtt}{sb}{sl}
{<-> [\lmvtt@scale@factor] ec-lmvtto10}{}
\DeclareFontShape{T1}{lmvtt}{sb}{it}
{<->sub*lmvtt/m/sl}{}
%%%%%%%% light (l) and dark (b) variants:
\DeclareFontShape{T1}{lmvtt}{m}{n}
{<-> [\lmvtt@scale@factor] ec-lmvtl10}{}
\DeclareFontShape{T1}{lmvtt}{m}{sl}
{<-> [\lmvtt@scale@factor] ec-lmvtlo10}{}
\DeclareFontShape{T1}{lmvtt}{m}{it}
{<->sub*lmvtt/l/sl}{}

\else
% usual setup of variants:
\DeclareFontShape{T1}{lmvtt}{m}{n}
{<-> [\lmvtt@scale@factor] ec-lmvtt10}{}
\DeclareFontShape{T1}{lmvtt}{m}{sl}
{<-> [\lmvtt@scale@factor] ec-lmvtto10}{}
\DeclareFontShape{T1}{lmvtt}{m}{it}
{<->sub*lmvtt/m/sl}{}
%%%%%%%% light (l) and dark (b) variants:
\DeclareFontShape{T1}{lmvtt}{l}{n}
{<-> [\lmvtt@scale@factor] ec-lmvtl10}{}
\DeclareFontShape{T1}{lmvtt}{l}{sl}
{<-> [\lmvtt@scale@factor] ec-lmvtlo10}{}
\DeclareFontShape{T1}{lmvtt}{l}{it}
{<->sub*lmvtt/l/sl}{}
\fi
% bold is always bold (b):
\DeclareFontShape{T1}{lmvtt}{b}{n}
{<-> [\lmvtt@scale@factor] ec-lmvtk10}{}
\DeclareFontShape{T1}{lmvtt}{b}{sl}
{<-> [\lmvtt@scale@factor] ec-lmvtko10}{}
\DeclareFontShape{T1}{lmvtt}{b}{it}
{<->sub*lmvtt/b/sl}{}
\DeclareFontShape{T1}{lmvtt}{bx}{n}
{<->ssub*lmvtt/b/n}{}
\DeclareFontShape{T1}{lmvtt}{bx}{sl}
{<->ssub*lmvtt/b/sl}{}
\DeclareFontShape{T1}{lmvtt}{bx}{it}
{<->sub*lmvtt/b/sl}{}
\AtBeginDocument{\renewcommand*\ttdefault{lmvtt}}

\endinput` Puoi verificare con questo esempio minimo`\documentclass{article}

\usepackage[T1]{fontenc}

\usepackage{lmodern}
\usepackage[scalefactor=0.9]{lmvttscaled}

\begin{document}

\sffamily Questo testo viene scritto con un font lineare, mentre \ttfamily questo testo viene scritto in teletype a spaziatura variabile.

\end{document}`L’opzione alla chiamata del pacchetto è facoltativa, nel senso che se non specifichi nessun fattore di scala viene usato il valore unitario.

La colpa è del pacchetto fncychap (e/o) dell’opzione Bjarne); commentando la riga la compilazione va sempre a buon fine.

Invece lo stile di capitolo Bjarne non mi sembra una scelta particolarmente felice, visto che il numero del capitolo viene scritto come parola, non come numero; Quindi vedere scritto “Capitolo ONE” fa un certo effetto.:roll:

Uso Latex da quasi 30 anni; non ho mai avuto bisogno di usare gli stili di fncychap; ne ho letto la documentazione, ne ho visto i risultati, ma tutto sommato preferisco crearmi le mie intestazioni di capitolom magari con l’aiuto di altri pacchetti, come titelsec, epr esempio ed altri affini, oppure (ri)scrivendomi da le macro interne invocate da \chapter e da \chpater* non è così difficile, ma certo richiede più lavoro che non quello di invocare un pacchetto; almeno so quello che faccio e mi personalizzo le cose come voglio, non dico meglio, ma certamente in modo che soddisfino meglio il mio occhio.

Ora non direi che sia vietato servirsi di pacchetti preconfezionato e che tutti si riscrivano le macro interne per soddisfare i loro desideri, ma talvolta è l’unica soluzione e non si è vincolati agli stili preconfezionati.

Nel tuo caso ti suggerirei un pacchetto più di base, come titlesec, se prorpio i titolo=li normali non ti piacciono.

Io mi rifaccio sempre al logo, ma non credo che basti; per esempio dal logo non si capisce che hyperref deve essere caricato prima dei pochi pacchetti che lo usano, quindi che ne dipendono, anche se in generale non è sbagliato caricarlo per ultimo; tuttavia se volessi scrivere in ebraico, per esempio, dovresti chiamare il pacchetto bidi dopo hyperref. Questo non lo scopri dal log, ma dalla documentazione dei pacchetti se è ua buona documentazione.

Il file logo ti aiuta a non caricare pacchetti che sono già stati caricati, ma non a caricare certi pacchetti prima che altri pacchetti ne abbiano bisogno.

Si, nel tuo esempio e nel corrispondente logo risulta caricato inputenc da te e un certo numero di pacchetti dal file di formato; questi sono pacchetti che riguardano comandi più o meno sperimentali di LaTeX3 e diverse altre cose, ma leggendo il file .log ti accorgi di quando e in che sequenza sono caricati i pacchetti che tu hai nominato nel preambolo e quelli che vengono caricati dietro le quinte dal file di formato.

camillo” post=27237Sì, nel preambolo ho
`
\usepackage[T1]{fontenc}
`
ma uso ubuntu con tetex-base, tetex-bin, tetex-extra. Devo comunque installare i font CMSuper? Dove li trovo? Comunque con altri files tex (anche molto più ricchi) non ho problemi.
Grazie!

Tetex ha cessato di esistere come distribuzione dal 2005, se ricordo bene, ed è stata soppiantata da TeXLive che contiene ancora un pacchettino chiamato tetex, ma non ho idea di che cosa contenga.

Non solo ma quella installazione era conforme alle prescrizioni Debian; certe versioni di Linux richiedono versioni conformi a Debian, a cominciare da Ubuntu e andando via via su distribuzioni/installazioni/incarnazioni di Linux meno comuni.

Sarebbe il caso di aggiornarsi, non pensi? Su questo forum cerca e leggi i messaggi che contengono la parola texliveubuntu — troverai molti modi di installare una distribuzione TeXLive ufficialmente non conforme a Debian, ma di fatto super-conforme.

Inoltre i CM-super, come i Latin Modern sono i font standard (io preferisco i secondi, altri preferiscono i primi) che sono completamente configurati per l’uso mediante al micro-tipografia gestibile a piena forza solo con pdflatex e lualatex; latex e xelatex, gestiscono solo la protrusione e non l’espansione dei caratteri; ma nessuno dei quattro programmi gestisce l’espansione se non esistono i file di configurazione; io non ne ho mai scritto uno, ma non sarebbe impossibile farlo; in ogni caso sono necessari i font vettoriali, non i font bitmapped usati nel formato DVI di latex. Usare quindi il pacchetto microtype con latex non serve altro che a produrre l’errore che hai segnalato. Oggi, direi, nessuno usa più latex se non per compilare documenti sorgente “vecchi” o per lavori particolarissimi.

In sostanza quella riga dice che babel può usare 79 lingue. Non dice che babel è caricato.