OldClaudio

Anch’io ho cercato di usare Scribus, con scarsissimi risultati. Ma non è una questione di LaTeX o di Scribus.
La questione è che se in una griglia inserisci qualcosa la cui altezza non è multiplo intero del passo della griglia, comporre in gliglia richiede di inserire spazi verticlai che sono più brutti del mancato rispetto della griglia.

Di fatto Scribus e gli altri impaginatori funzionano bene con documenti di solo testo, con i richiami di nota bassi, con uno scartamento (un passo di griglia) non inferiore al corpo amplificato del 15-20%, senza formule e senza figure/tabelle con didasclaia di lunghezza e numero di righe variabile scritte in corpo minore. Insomma LaTeX ottimizza una pagina che contiene o pu o contenenere certe cose; Scribus & Co ottimizza la pagina per altri tipi di testi.

Per costruire un classe per comporre un libro d’arte su due colonne con le colonne pareggiate a fine capitolo, ho dovuto usare multicol e ho dovuto rinunciare alla mobilità automatica degli oggetti flottanti; ho dovuto anche costruire figure e tabelle dentro scatole verticali a cui a posteriori ho dovuto cambiare l’altezza e profondità, perché altrimenti il punto di riferimento non si allineava sulla griglia, e il top della tabella o della figura non risultava allineato correttamente con la linea di base della colonna adiacente. Insomma è stato un supplizio e ho dovuto prevedere ambienti appositi con un mucchio di parametri facoltativi per aggiustare a mano la posizione verticale delle figure.

Di sicuro ridurre lo scartamento con un fattore inferiore a 0.95 è autolesionistico con la maggior parte dei font; scegliendo font dall’occhio interno grande e l’altezza degli ascendenti e la profondità dei discendenti piccole potrebbe funzionare, ma bisogna aspettarsi posizioni in cui la griglia non è rispettata.

Ho scritto un intero libro con i font Latin Modern e uns scartamento normale del 14% maggiore del corpo; ero al limite ma mi era stata imposta l’altezza della gabbia e il numero di righe; ho dovuto intervenire a mano moltissime volte, agendo sulle singole righe. non lo farò mai più.

samiel” post=98857Alla pagina http://www.guitex.org/home/it/guide-tematiche trovo da scaricare
il LaTeX Reference Manual commentato. Tuttavia mi dà la versione 1.8 (23/6/13),
mentre io avevo scaricato da tempo la versione 1.9 (23/8/14).
Forse il link non è aggiornato?

m

Strano, perché a metà dicembre ho caricato la versione 2.0 del 14/12/2014. Forse c’è stato un disguido nel creare il link, ma questo esula dalle autorizzazioni che ho.

Non esiste un comando per imporre uno scartamento fisso; esiste un comando per annullare l’interlinea che è rappresentato dal valore di \lineskip. Nonostante questo non basta, devi anche modificare il margine su cui verificare la necessità dell’interlinea.

Quindi:`\lineskip=0pt
\lineskiplimit=-1000pt`Ti ho già spiegato quali inconvenienti incontri a seguire questa via.

Oppure, se temi che gli ascendenti degli apici di nota siano troppo altri, puoi modificare le macro che imposta questi richiami sia nel testo sia prima della nota in calce, in modo da farli sembrare di altezza nulla; il comando per farlo è \vphantom o hphantom, non ricordo quale dei due, ma per fare questa modifica devi ridefinire alcune macro interne a lLaTeX.

Poi puoi sempre ricorrere al pacchetto grid che dovrebbe realizzare la composizione su una griglia fissa; non so se ce la faccia con le note.

setspace non fa altro che impostare valori diversi per \linespread. Quest’ultimo è una specie di dichiarazione che moltiplica il valore di \baselineskip (lo scartamento fre le righe, ciò la distanza fra lre righe di base di due righe successive, erroneamente troppo spesso chimato interlinea) che come tutte le dichiarazioni è globale se non lo si chiude dentro un ambiente.

Ma mentre non ci sono problemi ad impostare valori di “spread” maggiori di 1, ci sono a impostarli minori di 1.

Ricorda \baselineskip è pari la corpo del font usato più l’interlinea; questa normalmente è fissata in un 20% del corpo; quindi corpo 10pt, interlinea 2pt, scartamento 12pt. Se moltiplichi il valore di \baselinsckip per un numero maggiore di uno, diciamo 1.3, allora lo scartamento diventa 15.6pt, il corpo è rimasto lo stesso, quindi l’interlinea è più che raddoppiata, visto che ora vale 5.6pt invece che 2pt.

Se perì fra i discendenti di una riga e gli ascendenti della riga successiva c’è una distanza inferiore a \lineskiplimit, allora il motore ci composizione inserisce interlinea ulteriore pari a \lineskip. Quindi, sempre per fare un esempio, gli apici di nota salgono tanto in alto da essere meno distanti dal valore di 2pt di \lineskiplimit, allora l’intera riga viene spostata in basso in modo che ci sia 1pt fra l’ascendeza degli apici e i discendenti della riga precedente.

Vedi dunque che non si possono agevolmente mantenere le righe più compatte con fattori \linespread minori di 1, perché gli ascendenti generano il problema e le righe risultano scostate. In generale è poco prudente scendere sotto un valore di 0.95.

Naturalmente se non ti interessa che le righe possano sovrapporsi in parte (cosa che tipograficamente sarebbe molto scorretta) puoi impostare il valore di \lineskip a 0pt e il valore di \lineskilimita ad un valore negativo, così da ottenere righe uniformemente spaziate anche se discendenti e ascendenti di due righe successive possono sovrapporsi.
Ovviamente NON ti consiglio questa soluzione, ma ti consiglio di NON impostare valori di \linspread minori di 1.

La spiegazione di \lineskio e \lineskiplimit è contenuta nella guida tematica Il LaTeX Reference Manual commentato che probabilmente hai già scaricato dall sezione Documentazione/GuidteGuIT Tematichhe di questo sito.

claudio” post=98796Forse bisogna partire da un vocabolario comune

1) dipendenza: il file viene caricato dal pacchetto
2) esclusione: al file viene impedito il caricamento
3) incompatibilità: la compilazione non va a buon fine
ciao
claudio

Sì, sono d’accordo.
Non voglio avere l’ultima parola, quindi prendi quel che dico come una proposta non come una critica alla tua terminologia.

1) dipendenza di x da y: il file y viene caricato dal file x
2) compatibilità di x e y: il file x e il file y non hanno nessun legame reciproco e possono venire caricati in un ordine qualsiasi
3) indipendenza di x da y: il file y, anche se invocato, non viene caricato da y
4) incompatibilità di x e y; se x e y vengono invocati entrambi la compilazione non va a buon fine
5) sequenzialità di x e y: i pacchetti x e y vanno caricati in una sequenza precisa

Naturalmente i 5 nomi possono essere scelti in modo diverso, ma i concetti dopo i due punti, anche se formulati diversamente, restano quelli. Nota che la sequenzialità implica un dipendenza, ma il file x NON carica il file y (o viceversa) ma tocca all’utente invocarli in un ordine preciso.

Come ho già scritto nei messaggi precedenti, escluderei da questa classifica i file che corrispondono alla specificazione di opzioni alla classe o ai pacchetti. Quindi escluderei i file .clo (opzioni di classe), i file .def (opzioni di pacchetti, per esempio graphicx, inputenc, fontenc, eccetera), i file .ldf (opzioni di babel}, i file .fd (richiamati direttamente dalle classi e/o dai pacchetti per gestire i font), i file .cnf o .cfg (file di configurazione di molti pacchetti e di certe classi).

Allora il mio suggerimento non funziona.

Per altro evita accuratamente la barra ribassata; le operazioni di input sembra che da un po’ di tempo permettano l’uso dell’underscore, ma generalmente l’underscore è da evitare perché è un carattere speciale.

Ma syldor è il tuo nome utente? se lo è, prova a scrivere`\usepackage{~/Dropbox/Teo_Latex/bibleref_LXX}`

claudio” post=98788Esempio di caricamento
color prima di xcolor
sono caricati entrambi
xcolor prima di color
viene caricato solo xcolor

Qui non si può parlare di dipendenza ma esclusione dipendente dall’ordine

altri esempi?

Sì e no.

Xcolor contiene già il codice di color, quindi non ne ha bisogno.

Nello stesso tempo nella riga 259 del file xcolor.sty c’è una istruzione che simula il caricamento di color, cosicché se provi a caricarlo \usepackage controlla se è già caricato verificando che il comando \ver@color abbia una definizione non vuota; siccome xcolor definisce quella macro con un argomento non nullo (una data nel formato LaTeX), \usepackage lo ritiene già caricato e non lo ricarica una seconda volta.

Viceversa se color è caricato prima di xcolor, tutte le sue definizioni sono “ricoperte” da quelle di xcolor. Questo è un caso in cui l’autore di xcolor ha fatto le cose per bene; nella documentazione raccomanda di non caricare color; leggendo il codice sappiamo perché: se caricato prima viene sovrascritto, se caricato dopo il suo caricamento non ha luogo.

È difficile in questo caso parlare di dipendenze, ma certamente di incompatibilità gestita correttamente o di esclusione, come l’ha chiamata.

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