- Questo topic ha 27 risposte, 7 partecipanti ed è stato aggiornato l'ultima volta 17 anni, 6 mesi fa da
lorenzo.pantieri.
-
CreatoreTopic
-
6 Settembre 2008 alle 8:58 #26646::
Carissimi,LaTeX è un programma eccezionale, ma nessun programma è privo di difetti. Nulla di irrimediabile, naturalmente: in fin dei conti, uno dei punti di forza di LaTeX è la sua modularità, ed è sempre possibile superare le sue limitazioni caricando uno o più pacchetti o aggiungendo qualche riga di codice ad hoc.
In questo senso, questo topic, che ha l’obiettivo di individuare qualche difetto di LaTeX, è solo un gioco, una curiosità che nasce dalla mia esperienza di lettore e scrittore di guide al nostro programma preferito.
Innanzitutto, bisogna definire che cosa si intende per “LaTeX”. Qui, con “LaTeX” intendo il programma di composizione con le sue classi standard (article, book e report), senza l’ausilio di alcun pacchetto.
Più difficile è dire con precisione che cos’è un “difetto”, anche perché probabilmente entrano in gioco considerazioni soggettive…
Ad ogni modo, ecco alcuni aspetti di LaTeX (nel senso appena specificato) che considero difetti…
1. Le didascalie delle figure e delle tabelle non sono automaticamente in corpo più piccolo rispetto al testo, né incolonnate sotto la prima linea del testo, se formate da almeno due righe. (Per farlo, occorre caricare il pacchetto caption con le opzioni font=small e format=hang.)
2. Inoltre, LaTeX non separa automaticamente la didascalia di una tabella dalla tabella stessa (di regola, la didascalia si scrive sopra la tabella, ma LaTeX “non lo sa”): bisogna provvedere con del codice ad hoc (per esempio caricando il pacchetto caption e, una volta per tutte, scrivendo nel preambolo \captionsetup
{position=top}).
3. Nella composizione delle tabelle, il comando \hline offerto da LaTeX per realizzare i filetti orizzontali ha una resa tipografica insoddisfacente a causa del poco spazio tra le linee orizzontali e il testo delle celle. (Vanno usati al suo posto i comandi \toprule, \midrule e \bottomrule del pacchetto booktabs.)
4. La spaziatura dell’ambiente eqnarray è inconsistente. (Vanno usati gli appositi ambienti di amsmath.) Anche la scelta di non correggere, nelle recenti versioni di LaTeX, quell’ambiente vistosamente bacato, solo per mantenere la retro-compatibilità, mi sembra piuttosto discutibile.
5. Nella composizione delle formule matematiche, non esistono comandi predefiniti per il modulo, la norma e il prodotto scalare. Inoltre, è possibile introdurre alcuni simboli scientifici notevoli, come ad esempio la costante di Planck ridotta, solo grazie a pacchetti specifici, come amssymb. In generale, il solo LaTeX, senza le estensioni AMS, non è per nulla soddisfacente nel trattamento della matematica (mancano infatti ambienti o comandi specifici per comporre formule fuori corpo opportunamente incolonnate, matrici, integrali multipli, font specifici per la matematica…). Spero di non essere espulso dal forum per quest’ultima affermazione! 😉
6. Il codice per inserire formule in corpo $…$ è una vistosa (e IMHO fastidiosa) eccezione alla regola secondo cui gli ambienti di LaTeX iniziano con un comando diverso da quello che li termina (cosa che in molti casi facilita la diagnostica dei problemi). Il codice \(…\), sintatticamente ortodosso, non è però robusto.
7. È possibile inserire direttamente i caratteri accentati, gestire lingue diverse dall’inglese e inserire immagini solo caricando pacchetti specifici (inputenc, babel, graphicx).
8. I font standard di LaTeX non contengono caratteri speciali per la maggior parte delle lettere accentate usate nelle lingue europee. (Per rimediare, com’è noto, è sufficiente servirsi dei font EC, attivati caricando il pacchetto fontenc con l’opzione T1.)
9. Le eventuali pagine bianche inserite alla fine di un capitolo, quando si seleziona l’opzione openright, hanno testatina e piè di pagina (bleah!). (Perché siano vuote, bisogna ridefinire il comando \cleardoublepage, aggiungendo nel preambolo del codice “di basso livello”. Le classi KOMA risolvono il problema in modo più elegante.)
10. L’indice analitico nella classe book non inizia automaticamente in una pagina destra. (Bisogna inserire un \cleardoublepage.) Più che una scelta deliberata di chi ha scritto quella classe, mi sembra una semplice dimenticanza (càpita: ma perché non rimediare?).
11. Le colonne dell’ultima pagina dell’indice analitico non sono bilanciate automaticamente. (Occorre del codice ad hoc; serve anche il pacchetto multicol.)
12. In certe condizioni, per esempio quando si attiva \raggedbottom, una nota a piè di pagina può non essere… in fondo alla pagina. (Per rimediare si può caricare il pacchetto footmisc con l’opzione bottom, che però può introdurre altri problemini di impaginazione…)
13. I messaggi d’errore di LaTeX sono a volte criptici. Per esempio, il seguente
`\documentclass{article}
\renewcommand{\fi}{Firenze}
\begin{document}
Boh!
\end{document}`
produce un enigmatico
`! LaTeX Error: Missing \begin{document}.`14. LaTeX non è fornito di serie di comandi predefiniti per realizzare un frontespizio degno di questo nome. Esisite, è vero, il comando \maketitle, ma c’è qualcuno che lo usa davvero? Fortunatamente, ora esiste il pacchetto frontespizio (di E. Gregorio), che rimedia a questa vistosa lacuna.
15. Il comando \dots è sempre seguito da uno spazio sottile, cosa che rende inconsisitente la spaziatura di una scrittura come [\dots]. (Occorre definirsi un comando ad hoc, o caricare il pacchetto ellipsis, che corregge questo bug, ma che purtroppo è incompatibile con amsmath.)
Naturalmente, tutti i problemi precedenti ammettono una soluzione (per comodità, l’ho indicata, fra parentesi, in corrispondenza di ogni punto), ma IMHO sarebbe opportuno che le soluzioni venissero incluse direttamente in LaTeX. Certo, ci potrebbero essere dei (piccoli, per lo più) problemi di impaginazione e compatibilità con documenti vecchi, ma credo che il gioco varrebbe la candela.
Chi vuole partecipare al “gioco”, anche semplicemente esprimendo il suo parere su qualcuno dei punti precedenti, è il benvenuto!
Ciao,
L.
-
CreatoreTopic
-
AutoreRisposte
-
-
6 Settembre 2008 alle 9:30 #26647::
Interessante come gioco. Tutte le cose che hai detto sono giuste, ma credo che il buon Knuth e Lamport dopo di lui non avrebbero mai potuto sistemare questi “bug” anche perchè non potevano metterli tutti in preventivo; detto questo loro hanno rilasciato un codice sorgente funzionante e fortunatamente OpenSource in modo che chi potesse migliorarlo, studiarlo era incentivato a farlo e soprattutto aveva la possibilità di farlo!
Quindi per questo che man mano sono nati i pacchetti in modo (come hai giustamente detto) di estendere e potenziare il linguaggio con righe ad hoc o con pacchetti.Mi pare di capire che tu vorresti includere alcune di queste soluzioni direttamente nel sorgente/compilatore del TeX/LaTeX in modo che non si presentino o non debbano essere caricati i pacchetti ma questo mi sembra controproducente per diversi motivi:
1) Sarebbe impossibile gestire tutti i casi che si possono presentare e quindi servirebbero ancora i pacchetti per i casi che mancano;
2) Il compilatore TeX/LaTeX perderebbe di modularità e secondo me anche di “pulizia” del codice.
E’ come se tu chiedessi che il compilatore C/C++/python/java/etc…avesse già all’interno alcune funzioni che generalmente sono incluse nelle librerie, sarebbe, penso, molto difficile la sua gestione e il suo aggiornamento, invece con librerie divise per “funzioni” (inteso come categoria di problema che devi risovere) è molto più facile.Questa è a grandi linee la mia opinione, aspettiamo anche quella di altri.
Ciao Alberto
-
6 Settembre 2008 alle 9:49 #26648::
Ciao Lorenzo,ho trovato questo tuo messaggio decisamente interessante. Sono un utente LaTex che qualche spruzzatina di informatica ce l’ha giusto per capire come alcune strutture dei vari pacchetti funzionano ed eventualmente apportare qualche modifica per adattarli alle diverse esigenze..(la chiamo informatica del copia e incolla..che però vedo funziona a dovere anche per il personale CED del’azienda in cui lavoro)
La mia conoscenza di LaTex non mi permette però di comprendere la complessità di questo software che ha la capacità di produrre documenti così eleganti. Mi capita spesso di chiedermi che razza di elaborazioni debba fare il pc per seguire tutte le istruzioni di Latex..e come nel corso degli anni il programma sia cresciuto “sedimentando” piano piano tutte le novità e gli sviluppi.
Forse è proprio questa la difficoltà del LaTex: non c’è (o non conosco) un canale specifico che raccolga le giuste segnalazioni per prevedere gli sviluppi successivi. Se ad esempio Microsoft vuole sviluppare un software mette assieme ricerche di mercato e programmatori e tira fuori un programma (pieno di bug, poco utile ma che per loro fa tanto mercato 👿 )..nel caso degli utenti italiani, ma in generale di tutto il mondo, esiste un canale che raccoglie le segnalazioni più importanti (as es. dai forum) per poi implementarle in modo corretto nel sorgente di LaTex? In poche parole c’è qualcuno che segnala i problemi e c’è qualcuno che raccoglie queste segnalazioni? Ho l’impressione che spesso i problemi si superino solo quando chi ci si imbatte decide di scrivere un pacchetto per superarli. E questo qualcuno ne deve sapere di programmazione in LaTex e di creazione di pacchetti..cosa poco frequente rispetto alla massa di utilizzatori.
Fino a quel momento ci tocca lavorare di fantasia..anche se fino ad ora con la mole di pacchetti che sono in circolazione ho sempre superato gli ostacoli.Ad onor del vero l’unico problema irrisolto è stata l’impossibilità di avere la stessa numerazione per le citazioni a piè pagina di autori (forse usavo jurabib) e per le note..le due cose seguivano due numerazioni distinte con un risultato poco piacevole. Forse avrei dovuto usare BibLaTex come mi era stato consigliato sul forum ma per urgenza ho preferito togliere le uniche due note a piè pagina e lasciare solo le citazioni..
Forse non ho seguito proprio il filone proposto da Lorenzo, ma per chi come me si considera un neofita, a volte è interessante trovare approfondimenti di questo genere per chiarirsi dubbi o conoscere meglio pregi e difetti di LaTex oltre ad avere una panoramica su di esso che vada oltre il semplice utilizzo del programma sul proprio pc.
Ciao
Cristiano
-
6 Settembre 2008 alle 17:59 #26649::
Personalmente, non ho conoscenze così approfondite da poter valutare oggettivamente la “bontà” della soluzione proposta. Mi affido dunque agli esperti del forum.
Volevo però ringraziare Lorenzo per aver sintetizzato in questa discussione i principali “bug” (di alcuni dei quali non ero a conoscenza) del nostro amato software. La salverò per utilizzarla come utile promemoria qualora dovessi incappare in qualcuno dei problemi citati.
Ciao.
r.
-
7 Settembre 2008 alle 6:54 #26650::
mi inserisco nella discussione (che trovo molto interessante) spezzando però una lancia a favore del LaTeX.
Lo uso ormai da diversi anni, e ho capito che la vera ricchezza del LaTeX sono …i suoi package! 😛
perchè esistono package che permettono di fare qualsiasi cosa. Basta conoscerli. Non mi pare pensabile che il solo “LaTeX base” possa pensare a tutto, sarebbe come dire che ad ogni compilazione tutti i package dovrebbero essere caricati, con conseguenze nefande per il tempo di compilazione! e questo include anche i package AMS (che pure io uso sempre)In particolare concordo pienamente sulle osservazioni che riguardano il brutto layout; tuttavia
4. (…) la scelta di non correggere, nelle recenti versioni di LaTeX, quell’ambiente vistosamente bacato, solo per mantenere la retro-compatibilità, mi sembra piuttosto discutibile
…eppure… se io avessi scritto un vecchio documento latex e vedessi che all’improvviso mi cambia layout mi altererei non poco… !!!
14. (…) Esiste, è vero, il comando \maketitle, ma c’è qualcuno che lo usa davvero?
Sì: io e molti di quelli che pubblicano articoli sulle riviste…
-
7 Settembre 2008 alle 8:04 #26651::
16. Ecco un altro bug:
`\[
\left(
\begin{array}{cc}
\displaystyle\frac{a}{b} & \displaystyle\frac{a}{b} \\
\displaystyle\frac{a}{b} & \displaystyle\frac{a}{b}
\end{array}
\right)
\]`
Sgradevole, vero?Naturalmente, basta aggiungere una spaziatura, manualmente:
`\[
\left(
\begin{array}{cc}
\displaystyle\frac{a}{b} & \displaystyle\frac{a}{b} \\[2.5ex]
\displaystyle\frac{a}{b} & \displaystyle\frac{a}{b}
\end{array}
\right)
\]`Ah, se qualcuno crede che usando l’apposito ambiente di amsmath il problema non si presenti,
`\[
\begin{pmatrix}
\dfrac{a}{b} & \dfrac{a}{b} \\
\dfrac{a}{b} & \dfrac{a}{b} \\
\end{pmatrix}
\]`
è invitato a ripensarci!…credo che il buon Knuth e Lamport dopo di lui non avrebbero mai potuto sistemare questi “bug” anche perchè non potevano metterli tutti in preventivo…
Vero, preventivare tutti i possibili “bug” di un software è impossibile: solo con l’uso vengono scoperti!
Quindi per questo che man mano sono nati i pacchetti in modo (come hai giustamente detto) di estendere e potenziare il linguaggio con righe ad hoc o con pacchetti.
Certo.
La vera ricchezza del LaTeX sono… i suoi package!
Lo penso anch’io.
Non mi pare pensabile che il solo “LaTeX base” possa pensare a tutto, sarebbe come dire che ad ogni compilazione tutti i package dovrebbero essere caricati, con conseguenze nefande per il tempo di compilazione! e questo include anche i package AMS (che pure io uso sempre).
Mi pare di capire che tu vorresti includere alcune di queste soluzioni direttamente nel sorgente/compilatore del TeX/LaTeX in modo che non si presentino o non debbano essere caricati i pacchetti ma questo mi sembra controproducente per diversi motivi:
1) Sarebbe impossibile gestire tutti i casi che si possono presentare e quindi servirebbero ancora i pacchetti per i casi che mancano;
2) Il compilatore TeX/LaTeX perderebbe di modularità e secondo me anche di “pulizia” del codice.Vedete, io non ho mai detto che LaTeX debba “pensare a tutto” o che debbano essere “inclusi tutti i pacchetti”! Anzi, ho esordito dicendo che uno dei punti di forza di LaTeX è la sua modularità!
Tuttavia, di regola quando si scopre un bug in un software, non credete che sarebbe meglio porvi rimedio nelle versioni successive?
Non sono un esperto di programmazione LaTeX “di basso livello”, ma non credo che aggiungere un \cleardoublepage alla definizione dell’indice analitico (punto 10) o aggiungere
`\makeatletter
\def\cleardoublepage{\clearpage
\if@twoside
\ifodd\c@page
\else
\null\thispagestyle{empty}\clearpage
\fi
\fi}
\makeatother`
per rimediare il problema delle pagine bianche (punto 9) minerebbe la solidità delle fondamenta del nucleo di LaTeX! Anche ridefinire eqnarray con un
`\setlength\arraycolsep{2pt} `
non credo sarebbe causa di terremoti diprogrammazione! Un discorso analogo si può fare per molti dei sedici bug che ho evidenziato.se io avessi scritto un vecchio documento LaTeX e vedessi che all’improvviso mi cambia layout mi altererei non poco… !!!
Vero, tu avresti quel fastidio, ma tutti gli utenti (tu compreso!) che scriverebbero un documento nuovo, potrebbero beneficiare delle correzioni!
D’altra parte, il problema sviluppo/retrocompatibilità si ripresenta in ogni software e, più in generale, in ogni settore tecnologico. Dubito che un documento redatto con Word 1.0 si apra senza alcun problema con una versione moderna di Word! Dubito che esista un software (o un formato, PDF compreso) completamente libero da questi problemi.
Allo stesso modo, pensa alle videocassette che stanno in libreria a prendere polvere: il DVD è una tecnologia incompatibile con VHS, e la transizione non è stata certo indolore (ben più dolorosa dell’eventuale aggiornamento di qualche linea di codice!). Lo stesso si può dire per il passaggio dal vinile (e dalle musicassette) al CD. Tuttavia, non credi che, alla fine, il gioco sia valso la candela?
Ma stiamo andando OT.
Ciao,
L.
-
7 Settembre 2008 alle 19:14 #26652::
Carissimi,
LaTeX è un programma eccezionale, ma nessun programma è privo di difetti. Nulla di irrimediabile, naturalmente: in fin dei conti, uno dei punti di forza di LaTeX è la sua modularità, ed è sempre possibile superare le sue limitazioni caricando uno o più pacchetti o aggiungendo qualche riga di codice ad hoc.
In questo senso, questo topic, che ha l’obiettivo di individuare qualche difetto di LaTeX, è solo un gioco, una curiosità che nasce dalla mia esperienza di lettore e scrittore di guide al nostro programma preferito.
Innanzitutto, bisogna definire che cosa si intende per “LaTeX”. Qui, con “LaTeX” intendo il programma di composizione con le sue classi standard (article, book e report), senza l’ausilio di alcun pacchetto.
Più difficile è dire con precisione che cos’è un “difetto”, anche perché probabilmente entrano in gioco considerazioni soggettive…
Ad ogni modo, ecco alcuni aspetti di LaTeX (nel senso appena specificato) che considero difetti…
1. Le didascalie delle figure e delle tabelle non sono automaticamente in corpo più piccolo rispetto al testo, né incolonnate sotto la prima linea del testo, se formate da almeno due righe. (Per farlo, occorre caricare il pacchetto caption con le opzioni font=small e format=hang.)
2. Inoltre, LaTeX non separa automaticamente la didascalia di una tabella dalla tabella stessa (di regola, la didascalia si scrive sopra la tabella, ma LaTeX “non lo sa”): bisogna provvedere con del codice ad hoc (per esempio caricando il pacchetto caption e, una volta per tutte, scrivendo nel preambolo \captionsetup
{position=top}).
Scelte del progettista della classe.
3. Nella composizione delle tabelle, il comando \hline offerto da LaTeX per realizzare i filetti orizzontali ha una resa tipografica insoddisfacente a causa del poco spazio tra le linee orizzontali e il testo delle celle. (Vanno usati al suo posto i comandi \toprule, \midrule e \bottomrule del pacchetto booktabs.)
Questo è davvero un difetto.
4. La spaziatura dell’ambiente eqnarray è inconsistente. (Vanno usati gli appositi ambienti di amsmath.) Anche la scelta di non correggere, nelle recenti versioni di LaTeX, quell’ambiente vistosamente bacato, solo per mantenere la retro-compatibilità, mi sembra piuttosto discutibile.
Purtroppo Lamport decise di definire eqnarray in quel modo. È troppo tardi per modificare.
5. Nella composizione delle formule matematiche, non esistono comandi predefiniti per il modulo, la norma e il prodotto scalare. Inoltre, è possibile introdurre alcuni simboli scientifici notevoli, come ad esempio la costante di Planck ridotta, solo grazie a pacchetti specifici, come amssymb. In generale, il solo LaTeX, senza le estensioni AMS, non è per nulla soddisfacente nel trattamento della matematica (mancano infatti ambienti o comandi specifici per comporre formule fuori corpo opportunamente incolonnate, matrici, integrali multipli, font specifici per la matematica…). Spero di non essere espulso dal forum per quest’ultima affermazione! 😉
Il progetto di Lamport non mirava certo a un programma per scrivere testi con molta matematica.
6. Il codice per inserire formule in corpo $…$ è una vistosa (e IMHO fastidiosa) eccezione alla regola secondo cui gli ambienti di LaTeX iniziano con un comando diverso da quello che li termina (cosa che in molti casi facilita la diagnostica dei problemi). Il codice \(…\), sintatticamente ortodosso, non è però robusto.
Non era robusto, lo è diventato da parecchi anni. Nel manuale, Lamport dice di usare l’ambiente math oppure \(…\).
7. È possibile inserire direttamente i caratteri accentati, gestire lingue diverse dall’inglese e inserire immagini solo caricando pacchetti specifici (inputenc, babel, graphicx).
8. I font standard di LaTeX non contengono caratteri speciali per la maggior parte delle lettere accentate usate nelle lingue europee. (Per rimediare, com’è noto, è sufficiente servirsi dei font EC, attivati caricando il pacchetto fontenc con l’opzione T1.)
9. Le eventuali pagine bianche inserite alla fine di un capitolo, quando si seleziona l’opzione openright, hanno testatina e piè di pagina (bleah!). (Perché siano vuote, bisogna ridefinire il comando \cleardoublepage, aggiungendo nel preambolo del codice “di basso livello”. Le classi KOMA risolvono il problema in modo più elegante.)
Questo non avresti nemmeno dovuto pensarlo. Adesso rifletti sul perché ti dico così. 🙂
10. L’indice analitico nella classe book non inizia automaticamente in una pagina destra. (Bisogna inserire un \cleardoublepage.) Più che una scelta deliberata di chi ha scritto quella classe, mi sembra una semplice dimenticanza (càpita: ma perché non rimediare?).
Dimenticanza, suppongo. Di fatto all’epoca \cleardoublepage non esisteva.
11. Le colonne dell’ultima pagina dell’indice analitico non sono bilanciate automaticamente. (Occorre del codice ad hoc; serve anche il pacchetto multicol.)
Sacrificio alla semplicità.
12. In certe condizioni, per esempio quando si attiva \raggedbottom, una nota a piè di pagina può non essere… in fondo alla pagina. (Per rimediare si può caricare il pacchetto footmisc con l’opzione bottom, che però può introdurre altri problemini di impaginazione…)
Idem
13. I messaggi d’errore di LaTeX sono a volte criptici. Per esempio, il seguente
`\documentclass{article}
\renewcommand{\fi}{Firenze}
\begin{document}
Boh!
\end{document}`
produce un enigmatico
`! LaTeX Error: Missing \begin{document}.`Questo esempio è fuorviante: stai ridefinendo un comando che non compare nell’indice analitico del manuale di LaTeX e c’è un chiaro avviso a non fare mai una cosa del genere.
14. LaTeX non è fornito di serie di comandi predefiniti per realizzare un frontespizio degno di questo nome. Esisite, è vero, il comando \maketitle, ma c’è qualcuno che lo usa davvero? Fortunatamente, ora esiste il pacchetto frontespizio (di E. Gregorio), che rimedia a questa vistosa lacuna.
15. Il comando \dots è sempre seguito da uno spazio sottile, cosa che rende inconsisitente la spaziatura di una scrittura come [\dots]. (Occorre definirsi un comando ad hoc, o caricare il pacchetto ellipsis, che corregge questo bug, ma che purtroppo è incompatibile con amsmath.)
Vedi più giù.
Naturalmente, tutti i problemi precedenti ammettono una soluzione (per comodità, l’ho indicata, fra parentesi, in corrispondenza di ogni punto), ma IMHO sarebbe opportuno che le soluzioni venissero incluse direttamente in LaTeX. Certo, ci potrebbero essere dei (piccoli, per lo più) problemi di impaginazione e compatibilità con documenti vecchi, ma credo che il gioco varrebbe la candela.
Chi vuole partecipare al “gioco”, anche semplicemente esprimendo il suo parere su qualcuno dei punti precedenti, è il benvenuto!
Come vedi mi presto. Difetti veri ne hai indicati tre: l’implementazione di tabular, l’ambiente eqnarray e l’errore con l’indice analitico.
LaTeX nasce per essere integrato da moduli aggiuntivi; non si può pensare a un software che tenga conto di tutte le esigenze tipografiche presenti, passate e future. Perciò buona parte dei tuoi punti non erano nemmeno da menzionare. Non prendertela, mi raccomando.
Ciao
Enrico
-
8 Settembre 2008 alle 8:17 #26653::
1. Le didascalie delle figure e delle tabelle non sono automaticamente in corpo più piccolo rispetto al testo, né incolonnate sotto la prima linea del testo, se formate da almeno due righe. (Per farlo, occorre caricare il pacchetto caption con le opzioni font=small e format=hang.)
2. Inoltre, LaTeX non separa automaticamente la didascalia di una tabella dalla tabella stessa (di regola, la didascalia si scrive sopra la tabella, ma LaTeX “non lo sa”): bisogna provvedere con del codice ad hoc (per esempio caricando il pacchetto caption e, una volta per tutte, scrivendo nel preambolo \captionsetup
{position=top}).
Scelte del progettista della classe.
Sono scelte, certo, ma le trovo assai poco felici.
Pensa che il caporedattore di una casa editrice per cui lavoravo (avevo il compito di migliorare l’impaginazione dei documenti inviati dai loro autori) mi disse di aver ricevuto un documento particolarmente brutto, con “addiruttura, le didascalie scritte non in corpo più piccolo rispetto al resto”…
Ai miei occhi (ma non solo ai miei!), questi sono difetti, anche se certo qui siamo nell’ambito dei giudizi soggettivi di cui dicevo all’inizio.
4. La spaziatura dell’ambiente eqnarray è inconsistente. (Vanno usati gli appositi ambienti di amsmath.) Anche la scelta di non correggere, nelle recenti versioni di LaTeX, quell’ambiente vistosamente bacato, solo per mantenere la retro-compatibilità, mi sembra piuttosto discutibile.
Purtroppo Lamport decise di definire eqnarray in quel modo. È troppo tardi per modificare.
Perché troppo tardi? Che cosa potrebbe accadere di male nel ridefinire la spaziatura dell’ambiente? Problemi TeXnici? A livello di impaginazione, non credo che l’utente finale, con un vecchio documento che usa eqnarray ridefinito, avrebbe problemi particolari…
5. Nella composizione delle formule matematiche, non esistono comandi predefiniti per il modulo, la norma e il prodotto scalare. Inoltre, è possibile introdurre alcuni simboli scientifici notevoli, come ad esempio la costante di Planck ridotta, solo grazie a pacchetti specifici, come amssymb. In generale, il solo LaTeX, senza le estensioni AMS, non è per nulla soddisfacente nel trattamento della matematica (mancano infatti ambienti o comandi specifici per comporre formule fuori corpo opportunamente incolonnate, matrici, integrali multipli, font specifici per la matematica…). Spero di non essere espulso dal forum per quest’ultima affermazione! 😉
Il progetto di Lamport non mirava certo a un programma per scrivere testi con molta matematica.
Non si finisce mai di imparare! Pensavo che TeX e LaTeX fossero nati fin da subito per scrivere (anche) testi con molta matematica! Ti andrebbe di sviluppare un po’ la tua affermazione?
In ogni caso, la cosa non è comunque decisiva, almeno IMHO. Ora LaTeX viene usato specialmente per comporre matematica: le estensioni AMS io le includerei senz’altro nel nucleo di LaTeX. Non sto dicendo, l’ho detto e lo ripeto, che LaTeX dovrebbe includere “tutti” i pacchetti! (Una cosa del genere non la penserei neanche dopo essermi scolato in sequenza una bottiglia di sangiovese e una di albana.) Sto dicendo che potrebbe essere giunto il momento che certe (poche, pochissime) estensioni venissero comprese nel suo codice.
Oppure, molto più semplicemente, mi accontenterei che l’utente fosse almeno al corrente dell’esistenza di questi difettucci (che un eufemista potrebbe anche chiamare “feature”!), per potervi porre rimedio caricando il pacchetto o scrivendo il codice “giusto” (e in questo senso Rosaria ha capito perfettamente lo spirito della mia iniziativa!).
6. Il codice per inserire formule in corpo $…$ è una vistosa (e IMHO fastidiosa) eccezione alla regola secondo cui gli ambienti di LaTeX iniziano con un comando diverso da quello che li termina (cosa che in molti casi facilita la diagnostica dei problemi). Il codice \(…\), sintatticamente ortodosso, non è però robusto.
Non era robusto, lo è diventato da parecchi anni. Nel manuale, Lamport dice di usare l’ambiente math oppure \(…\).
Non lo sapevo: grazie mille!
7. È possibile inserire direttamente i caratteri accentati, gestire lingue diverse dall’inglese e inserire immagini solo caricando pacchetti specifici (inputenc, babel, graphicx).
8. I font standard di LaTeX non contengono caratteri speciali per la maggior parte delle lettere accentate usate nelle lingue europee. (Per rimediare, com’è noto, è sufficiente servirsi dei font EC, attivati caricando il pacchetto fontenc con l’opzione T1.)
9. Le eventuali pagine bianche inserite alla fine di un capitolo, quando si seleziona l’opzione openright, hanno testatina e piè di pagina (bleah!). (Perché siano vuote, bisogna ridefinire il comando \cleardoublepage, aggiungendo nel preambolo del codice “di basso livello”. Le classi KOMA risolvono il problema in modo più elegante.)
Questo non avresti nemmeno dovuto pensarlo. Adesso rifletti sul perché ti dico così. 🙂
I primi due punti (con l’eccezione di graphicx) erano più che altro una provocazione! Il punto 9. però non capisco come “non avrei dovuto pensarlo”. Quella “testatina sul nulla” (che si ottiene con lo stile di pagina predefinito della classe book) l’ho sempre trovata più surreale di un quadro di Magritte!
`\documentclass{book}
\usepackage{lipsum}
\begin{document}
\chapter{Magritte}
\lipsum[1-2]
\section{Boh}
\lipsum
\chapter{Bah}
\lipsum
\end{document} `
Anche l’autore delle classi KOMA riconosce l’esistenza del problema (che in quelle classi viene risolto molto semplicemente con l’opzione di classe cleardoubleempty).Qui devi proprio spiegarmi che cosa vuoi dire!!
10. L’indice analitico nella classe book non inizia automaticamente in una pagina destra. (Bisogna inserire un \cleardoublepage.) Più che una scelta deliberata di chi ha scritto quella classe, mi sembra una semplice dimenticanza (càpita: ma perché non rimediare?).
Dimenticanza, suppongo. Di fatto all’epoca \cleardoublepage non esisteva.
Beh, all’epoca magari no, ma oggi sì! Del resto, quando è stato scritta la prima versione di LaTeX non esistevano neanche i telefoni cellulari, ma non mi pare un buon motivo per non usarli oggi… 😯 Spiegati meglio!
11. Le colonne dell’ultima pagina dell’indice analitico non sono bilanciate automaticamente. (Occorre del codice ad hoc; serve anche il pacchetto multicol.)
Sacrificio alla semplicità.
Come sopra. Knuth e Lamport hanno fatto anche troppo! Tuttavia il loro lavoro può essere migliorato! Vale anche per Galileo, per Newton, per Einstein!
12. In certe condizioni, per esempio quando si attiva \raggedbottom, una nota a piè di pagina può non essere… in fondo alla pagina. (Per rimediare si può caricare il pacchetto footmisc con l’opzione bottom, che però può introdurre altri problemini di impaginazione…)
Idem.
idem! 😉
13. I messaggi d’errore di LaTeX sono a volte criptici. Per esempio, il seguente
`\documentclass{article}
\renewcommand{\fi}{Firenze}
\begin{document}
Boh!
\end{document}`
produce un enigmatico
`! LaTeX Error: Missing \begin{document}.`Questo esempio è fuorviante: stai ridefinendo un comando che non compare nell’indice analitico del manuale di LaTeX e c’è un chiaro avviso a non fare mai una cosa del genere.
“Tutti noi commettiamo errori, e tutti noi ne paghiamo le conseguenze”, dice il Dr. House… Chi ridefinisce \fi non lo fa certo apposta! Proprio per questo, sarebbe il caso che il messaggio d’errore fosse più chiaro.
14. LaTeX non è fornito di serie di comandi predefiniti per realizzare un frontespizio degno di questo nome. Esisite, è vero, il comando \maketitle, ma c’è qualcuno che lo usa davvero? Fortunatamente, ora esiste il pacchetto frontespizio (di E. Gregorio), che rimedia a questa vistosa lacuna.
15. Il comando \dots è sempre seguito da uno spazio sottile, cosa che rende inconsisitente la spaziatura di una scrittura come [\dots]. (Occorre definirsi un comando ad hoc, o caricare il pacchetto ellipsis, che corregge questo bug, ma che purtroppo è incompatibile con amsmath.)
Vedi più giù.
A scanso di equivoci, il pacchetto sul frontespizio non è tra quelli che includerei in LaTeX! Quando a \dots, è un piccolo bug, ma fastidioso.
LaTeX nasce per essere integrato da moduli aggiuntivi; non si può pensare a un software che tenga conto di tutte le esigenze tipografiche presenti, passate e future.
D’accordo al 100%. Sto solo dicendo che quando si trova un difettuccio di design, sarebbe i caso di migliorare! In fin dei conti, i sistemi operativi vengono costantemente aggiornati (e la loro interfaccia viene costantemente limata e perfezionata).
Non prendertela, mi raccomando.
Ma figurati: è un piacere!
Un salutone,
Lorenzo
-
8 Settembre 2008 alle 8:58 #26654::
[quote]
1. Le didascalie delle figure e delle tabelle non sono automaticamente in corpo più piccolo rispetto al testo, né incolonnate sotto la prima linea del testo, se formate da almeno due righe. (Per farlo, occorre caricare il pacchetto caption con le opzioni font=small e format=hang.)2. Inoltre, LaTeX non separa automaticamente la didascalia di una tabella dalla tabella stessa (di regola, la didascalia si scrive sopra la tabella, ma LaTeX “non lo sa”): bisogna provvedere con del codice ad hoc (per esempio caricando il pacchetto caption e, una volta per tutte, scrivendo nel preambolo \captionsetup
{position=top}).
Scelte del progettista della classe.
Sono scelte, certo, ma le trovo assai poco felici.
Pensa che il caporedattore di una casa editrice per cui lavoravo (avevo il compito di migliorare l’impaginazione dei documenti inviati dai loro autori) mi disse di aver ricevuto un documento particolarmente brutto, con “addiruttura, le didascalie scritte non in corpo più piccolo rispetto al resto”…
Ai miei occhi (ma non solo ai miei!), questi sono difetti, anche se certo qui siamo nell’ambito dei giudizi soggettivi di cui dicevo all’inizio.[/quote]
Le classi standard sono pensate per essere contenitori generici, da sostituire poi con chiamate della classe più adatta alla pubblicazione. Quindi forniscono solo un minimo essenziale. È vero che, in passato, non c’erano moltissime classi più specifiche fra cui scegliere, ma non è un difetto di LaTeX, quanto degli utenti di alto livello (editori) che non le hanno sviluppate.[quote]4. La spaziatura dell’ambiente eqnarray è inconsistente. (Vanno usati gli appositi ambienti di amsmath.) Anche la scelta di non correggere, nelle recenti versioni di LaTeX, quell’ambiente vistosamente bacato, solo per mantenere la retro-compatibilità, mi sembra piuttosto discutibile.
Purtroppo Lamport decise di definire eqnarray in quel modo. È troppo tardi per modificare.
Perché troppo tardi? Che cosa potrebbe accadere di male nel ridefinire la spaziatura dell’ambiente? Problemi TeXnici? A livello di impaginazione, non credo che l’utente finale, con un vecchio documento che usa eqnarray ridefinito, avrebbe problemi particolari…[/quote]
L’argomento è stato molto dibattuto; gli sviluppatori hanno deciso di lasciare eqnarray come sta, avvisando che c’è di meglio. Sarebbe come cercare di raddrizzare la torre di Pisa, con la differenza che almeno quella è bella: il rimedio potrebbe rivelarsi peggiore del male.Il progetto di Lamport non mirava certo a un programma per scrivere testi con molta matematica.
Non si finisce mai di imparare! Pensavo che TeX e LaTeX fossero nati fin da subito per scrivere (anche) testi con molta matematica! Ti andrebbe di sviluppare un po’ la tua affermazione?
Per chi scriveva matematica “pesante” c’era Plain. Lamport voleva rivolgersi a un pubblico diverso: gente non troppo propensa a cercare di risolvere le difficoltà.
Può darsi che abbia impostato male la faccenda, ma che ci si può fare?
[quote]7. È possibile inserire direttamente i caratteri accentati, gestire lingue diverse dall’inglese e inserire immagini solo caricando pacchetti specifici (inputenc, babel, graphicx).
8. I font standard di LaTeX non contengono caratteri speciali per la maggior parte delle lettere accentate usate nelle lingue europee. (Per rimediare, com’è noto, è sufficiente servirsi dei font EC, attivati caricando il pacchetto fontenc con l’opzione T1.)
9. Le eventuali pagine bianche inserite alla fine di un capitolo, quando si seleziona l’opzione openright, hanno testatina e piè di pagina (bleah!). (Perché siano vuote, bisogna ridefinire il comando \cleardoublepage, aggiungendo nel preambolo del codice “di basso livello”. Le classi KOMA risolvono il problema in modo più elegante.)
Questo non avresti nemmeno dovuto pensarlo. Adesso rifletti sul perché ti dico così. 🙂
I primi due punti (con l’eccezione di graphicx) erano più che altro una provocazione! Il punto 9. però non capisco come “non avrei dovuto pensarlo”. Quella “testatina sul nulla” (che si ottiene con lo stile di pagina predefinito della classe book) l’ho sempre trovata più surreale di un quadro di Magritte!
`\documentclass{book}
\usepackage{lipsum}
\begin{document}
\chapter{Magritte}
\lipsum[1-2]
\section{Boh}
\lipsum
\chapter{Bah}
\lipsum
\end{document} `
Qui devi proprio spiegarmi che cosa vuoi dire!![/quote]
Quando LaTeX è nato, si rivolgeva a gente che scriveva solo in inglese americano. E le codifiche a 8 bit non esistevano. E poi ne hanno inventate a centinaia. E su decine di sistemi operativi incompatibili. Non va trascurato anche che TeX era strettamente a 7 bit.Quando poi ci si è evoluti, i rimedi sono stati trovati. Nella seconda edizione del manuale di Lamport, queste faccende sono menzionate.
La testatina sul nulla è conseguenza di quanto detto prima. Le classi standard sono solo un modello di vestito, per intenderci quelli disegnati su carta: nessuno li indossa, ma vanno usati per tagliare e cucire il vestito vero.
[quote]10. L’indice analitico nella classe book non inizia automaticamente in una pagina destra. (Bisogna inserire un \cleardoublepage.) Più che una scelta deliberata di chi ha scritto quella classe, mi sembra una semplice dimenticanza (càpita: ma perché non rimediare?).
Dimenticanza, suppongo. Di fatto all’epoca \cleardoublepage non esisteva.
Beh, all’epoca magari no, ma oggi sì! Del resto, quando è stato scritta la prima versione di LaTeX non esistevano neanche i telefoni cellulari, ma non mi pare un buon motivo per non usarli oggi… 😯 Spiegati meglio![/quote]
Gli sviluppatori vogliono garantirsi che, per quanto possibile, i documenti possano essere sempre compilati così come sono. Prova ad aprire con un word processor di oggi un file di dieci anni fa.[quote]11. Le colonne dell’ultima pagina dell’indice analitico non sono bilanciate automaticamente. (Occorre del codice ad hoc; serve anche il pacchetto multicol.)
Sacrificio alla semplicità.
Come sopra. Knuth e Lamport hanno fatto anche troppo! Tuttavia il loro lavoro può essere migliorato! Vale anche per Galileo, per Newton, per Einstein![/quote]
È esattamente ciò che devono fare i pacchetti aggiuntivi.[quote]13. I messaggi d’errore di LaTeX sono a volte criptici. Per esempio, il seguente
`\documentclass{article}
\renewcommand{\fi}{Firenze}
\begin{document}
Boh!
\end{document}`
produce un enigmatico
`! LaTeX Error: Missing \begin{document}.`Questo esempio è fuorviante: stai ridefinendo un comando che non compare nell’indice analitico del manuale di LaTeX e c’è un chiaro avviso a non fare mai una cosa del genere.
“Tutti noi commettiamo errori, e tutti noi ne paghiamo le conseguenze”, dice il Dr. House… Chi ridefinisce \fi non lo fa certo apposta! Tuttavia, sarebbe il caso che il messaggio d’errore fosse più chiaro. [/quote]
Impossibile, in questo caso e in molti altri: se si ridefinisce un comando di quel tipo le possibilità di errori pazzeschi diventano innumerevoli. Ti assicuro che i messaggi di errore sono davvero molto più informativi rispetto a quelli degli inizi.L’impianto elettrico di casa tua toglie corrente quando c’è un sovraccarico, mica ti dice anche dove c’è stato il sovraccarico: può forse “sapere” quale errore hai commesso?
Nel caso di \fi, l’errore viene scoperto quando TeX cerca di comporre un capoverso durante l’espansione di \document, perché trova un comando orizzontale il quale causa l’espansione del contenuto di \everypar: a quel punto il registro \everypar contiene ancora il codice che emette il messaggio di errore “Missing \begin{document}”; questo registro viene modificato proprio alla fine dell’espansione di \document, perché allora si possono comporre capoversi senza problemi. Spero che tu ti renda conto che è del tutto improponibile caricare \renewcommand con la verifica di tutti i comandi “pericolosi”.
La situazione potrebbe cambiare con LaTeX3, nel quale ogni primitiva di TeX verrà chiamata internamente con un altro nome. Di fatto, però, ridefinire \fi o \box sarà sempre piuttosto pericoloso, perché sarebbe incompatibile con molti pacchetti LaTeX2 che si potranno ancora usare.
Ciao
Enrico
-
12 Settembre 2008 alle 9:18 #26655::
Le classi standard sono pensate per essere contenitori generici, da sostituire poi con chiamate della classe più adatta alla pubblicazione. Quindi forniscono solo un minimo essenziale. È vero che, in passato, non c’erano moltissime classi più specifiche fra cui scegliere, ma non è un difetto di LaTeX, quanto degli utenti di alto livello (editori) che non le hanno sviluppate.
[…]
La testatina sul nulla è conseguenza di quanto detto prima. Le classi standard sono solo un modello di vestito, per intenderci quelli disegnati su carta: nessuno li indossa, ma vanno usati per tagliare e cucire il vestito vero.
Caro Enrico, prima di rispondere ho preferito pensarci su un po’!
In definitiva, credo che stiamo dicendo cose non troppo diverse. Io dico che le classi standard presentano dei difetti (come ad esempio la “testatina sul nulla” o il formato infelice delle didascalie), e che sarebbe opportuno incorporare il codice che corregge quei difetti direttamente nelle classi standard.
Tu dici che le classi standard non adrebbero usate 😯 (non si tratta di un’affermazione da poco!!!), ma andrebbero sostituite con altre classi, più mirate e “rifinite”, che però… non ci sono (in quanto chi doveva farlo non le ha sviluppate).
Resto della mia opinione. Ben lungi dalla folle idea che le classi standard debbano incorporare “tutto”, penso che sarebbe il caso di inserire, ad esempio, questo codice
`\makeatletter
\def\cleardoublepage{\clearpage
\if@twoside
\ifodd\c@page
\else
\null\thispagestyle{empty}\clearpage
\fi
\fi}
\makeatother`
e anche questo
`\usepackage[font=small,format=hang]{caption}`
(e poco altro: vedi alcuni dei punti che ho evidenziato nel primo intervento) direttamente nelle classi standard. Se la chiamata al pacchetto può essere “pericolosa”, ci si mette direttamente il codice corrispondente, e si sviluppa quello.Non credo che, TeXnicamente parlando, l’ostacolo sia insormontabile. Si avrebbe solo qualche problemino di retro-compatibilità, ma la retro-compatibilità non può essere il solo elemento da considerare, quando si sviluppa qualcosa. Altrimenti useremmo ancora le VHS e le musicassette!
Ciao,
L.
-
12 Settembre 2008 alle 9:42 #26656::
Non credo che, TeXnicamente parlando, l’ostacolo sia insormontabile. Si avrebbe solo qualche problemino di retro-compatibilità, ma la retro-compatibilità non può essere il solo elemento da considerare, quando si sviluppa qualcosa. Altrimenti useremmo ancora le VHS e le musicassette!
Non ho affatto detto che le classi standard non vanno usate. Anzi, il loro essere contenitori generici è la loro forza.
Non usi più le musicassette, ma il CD. Le cassette avevano limitazioni, non le hanno modificate per migliorarle, semplicemente hanno inventato qualcosa di nuovo. Le VHS continuano a funzionare come prima, se hai un lettore adatto. Bene, nulla vieta di scrivere una classe che faccia ciò che desideri; ma ciò che è scritto per le classi standard deve continuare a essere composto esattamente nello stesso modo.
Quanto al bug di index, prova a segnalarlo (prima vedi se per caso c’è già una segnalazione e le eventuali risposte).
Ciao
Enrico
-
12 Settembre 2008 alle 9:48 #26657::
Non usi più le musicassette, ma il CD. Le cassette avevano limitazioni, non le hanno modificate per migliorarle, semplicemente hanno inventato qualcosa di nuovo. Le VHS continuano a funzionare come prima, se hai un lettore adatto. Bene, nulla vieta di scrivere una classe che faccia ciò che desideri; ma ciò che è scritto per le classi standard deve continuare a essere composto esattamente nello stesso modo.
Devo ammettere che il ragionamento di Enrico ha un suo fondamento, in effetti. Non me ne voglia Lorenzo… 😛
Ciao.
r.
-
12 Settembre 2008 alle 10:07 #26658::
Non ho affatto detto che le classi standard non vanno usate. Anzi, il loro essere contenitori generici è la loro forza.
Mi pare che tu abbia detto che le classi standard, in quanto contenitori generici, non andrebbero usate dall’utente finale, che dovrebbe usare classi “più adatte alla pubblicazione”, basate sì su quelle standard, ma diverse. Se queste classi ci fossero, la cosa andrebbe benissimo anche a me: l’utente dovrebbe scrivere con la classe, poniamo, articolo.cls, limata e rifinita, per esempio, senza la “testatina sul nulla” e con le didascalie scritte in formato decente, basata su article.cls, che potrebbe allora restare invariata. (Allo stesso modo, chi adopera un Mac usa un’interfaccia semplice ed elegante, mentre in realtà sotto il cofano batte un OS Unix, ruvido e arcigno.) Tuttavia, come tu stesso dici, l’utente finale usa (spesso) direttamente article.cls, e gli tocca rimediare ai difettucci di quella classe aggiungendo pezzetti di codice — e queste “toppe” non sono il massimo della comodità…
ciò che è scritto per le classi standard deve continuare a essere composto esattamente nello stesso modo.
Mah, questo è un punto su cui siamo in disaccordo (non càpita spesso, e tutte le poche volte che è successo, col tempo ho scoperto che avevi ragione tu: il lettore è avvisato!). Ora come ora, penso — scusami per l’irriverenza del paragone — che anche i Dieci Comandamenti sono stati modificati, nel corso della storia (per gli interessati: è stato soppresso il comandamento “non farai né idolo né immagine”, che era il secondo; tutti gli altri sono stati spostati di uno nella numerazione e l’ultimo è stato sdoppiato, per far tornare il conto). Quindi non capisco perché il codice delle classi standard di LaTeX debba invece restare “sacro e inviolabile”. 😉
http://it.wikipedia.org/wiki/Dieci_comandamenti
Quanto al bug di index, prova a segnalarlo (prima vedi se per caso c’è già una segnalazione e le eventuali risposte).
Lo farò senz’altro, Enrico!
A presto,
Lorenzo
-
12 Settembre 2008 alle 10:39 #26659::
Non ho affatto detto che le classi standard non vanno usate. Anzi, il loro essere contenitori generici è la loro forza.
Mi pare che tu abbia detto che le classi standard, in quanto contenitori generici, non andrebbero usate dall’utente finale, che dovrebbe usare classi “più adatte alla pubblicazione”, basate sì su quelle standard, ma diverse. Se queste classi ci fossero, la cosa andrebbe benissimo anche a me: l’utente dovrebbe scrivere con la classe, poniamo, articolo.cls, limata e rifinita, per esempio, senza la “testatina sul nulla” e con le didascalie scritte in formato decente, basata su article.cls, che potrebbe allora restare invariata. (Allo stesso modo, chi adopera un Mac usa un’interfaccia semplice ed elegante, mentre in realtà sotto il cofano batte un OS Unix, ruvido e arcigno.) Tuttavia, come tu stesso dici, l’utente finale usa (spesso) direttamente article.cls, e gli tocca rimediare ai difettucci di quella classe aggiungendo pezzetti di codice — e queste “toppe” non sono il massimo della comodità…
ciò che è scritto per le classi standard deve continuare a essere composto esattamente nello stesso modo.
Mah, questo è un punto su cui siamo in disaccordo (non càpita spesso, e tutte le poche volte che è successo, col tempo ho scoperto che avevi ragione tu: il lettore è avvisato!). Ora come ora, penso — scusami per l’irriverenza del paragone — che anche i Dieci Comandamenti sono stati modificati, nel corso della storia (per gli interessati: è stato soppresso il comandamento “non farai né idolo né immagine”, che era il secondo; tutti gli altri sono stati spostati di uno nella numerazione e l’ultimo è stato sdoppiato, per far tornare il conto). Quindi non capisco perché il codice delle classi standard di LaTeX debba invece restare “sacro e inviolabile”. 😉
Stai paragonando mele con pere.
Se vuoi usare la classe book per la tua tesi puoi farlo, correggendo gli aspetti che ti interessano secondo le indicazioni di una buona guida, oppure usi la classe fornita dalla tua università (se c’è).
Ma dopo che l’hai scritta, desideri che possa essere ricompilata quando ti pare, dando lo stesso risultato. Chi ha usato LaTeX nel modo corretto sa di poterci contare; certo, a volte le versioni successive aggiungono qualcosa che non fa ricompilare come prima, perché ci si è accorti di un errore: inevitabile con un software complesso che ciò accada. In generale si può stare sicuri, gli sviluppatori hanno fatto sempre un ottimo lavoro.
Ciao
Enrico
-
14 Ottobre 2008 alle 9:34 #26660::
Sono un principiante quindi siete avvertiti…Credo di comprendere le motivazioni sia di Lorenzo che di Enrico.
Però credo che una soluzione (banale?) per coniugare le due visioni ci sia.Cosa costerebbe migliorare la classe book aggiungendo un’opzione version sulla falsariga del pacchetto mhchem? Ad esempio, specificando \documentclass[version=2]{book} si userebbe la nuova versione della classe book.
Compilare un vecchio sorgente sarebbe quindi indolore.
Cosa ne pensate?
-
14 Ottobre 2008 alle 16:57 #26661::
Sono un principiante quindi siete avvertiti…
Credo di comprendere le motivazioni sia di Lorenzo che di Enrico.
Però credo che una soluzione (banale?) per coniugare le due visioni ci sia.Cosa costerebbe migliorare la classe book aggiungendo un’opzione version sulla falsariga del pacchetto mhchem? Ad esempio, specificando
`\documentclass[version=2]{book}`
si userebbe la nuova versione della classe book.Compilare un vecchio sorgente sarebbe quindi indolore.
Cosa ne pensate?
Sono d’accordo, naturalmente… ma non decido io! 😉
Ciao,
L.
-
3 Marzo 2009 alle 9:39 #26662::
Riprendo questa discussione per aggiungere all’elenco un altro bug di LaTeX, corretto dal pacchetto mparhack, cheImplements a workaround for the LaTeX bug that marginpars will sometimes come out at the wrong margin.
http://www.ctan.org/tex-archive/help/Catalogue/entries/mparhack.html
http://www.ctan.org/tex-archive/macros/latex/contrib/mparhack/Ciao,
L.
-
6 Marzo 2009 alle 9:46 #26663::
Ciao a tutti.Per caso, ho trovato che esiste un’apposita pagina del sito del LaTeX Project dal significativo titolo “LaTeX bugs database”…
http://www.latex-project.org/cgi-bin/ltxbugs2html
Ciao,
L.
-
10 Marzo 2009 alle 22:34 #26664::
Ciao a tutti,un altro “bug” di LaTeX riguarda la scelta decisamente spartana fatta da Lamport nel gestire le citazioni multiple.
Come ben sapete il comando \cite può accettare più chiavi, es. \cite{pippo,pluto,paperino},
restituendo in output i numeri secondo l’ordine di citazione.
Questo fa sì che l’output può eventualmente essere non ordinato, es. [22,3,5].
Normalmente su qualsiasi libro si trova sempre [3,5,22].Analogamente, se ci sono più riferimenti con numeri consecutivi, es. [1,2,3,4,5], LaTeX li lascia così come sono anziché comprimerli come ci si aspetta: [1-5].
Il primo problema può essere risolto a mano modificando l’ordine di citazione una volta terminata la stesura del documento, per il secondo la faccenda è più complessa.
Tra i pacchetti che risolvono questi “bug”, c’è cite, segnalatomi da Lorenzo Pantieri, che risolve tutto molto semplicemente. È sufficiente caricarlo nel preambolo senza alcuna opzione. La documentazione si trova alla fine del file cite.sty e vi trovate anche alcune opzioni molto interessanti.
Ciao ciao.
Fra
-
12 Marzo 2009 alle 18:28 #26665::
Un altro “bug” di LaTeX credo sia il ricorrente problema delle testatine sbagliate usando i comandi di sezionamento asteriscati, che si risolve con un \markboth.Bisognerebbe ridefinire i vari comandi di sezionamento affinché lancino \markboth in automatico.
Una volta avevo provato a ridefinirli ma c’erano problemi con la generazione dell’indice.
Forse Enrico ha già risolto il problema in questo topic ma non ne sono sicuro.
Ciao ciao.
Fra
-
12 Marzo 2009 alle 21:15 #26666::
Un altro “bug” di LaTeX credo sia il ricorrente problema delle testatine sbagliate usando i comandi di sezionamento asteriscati, che si risolve con un \markboth.
Bisognerebbe ridefinire i vari comandi di sezionamento affinché lancino \markboth in automatico.
Una volta avevo provato a ridefinirli ma c’erano problemi con la generazione dell’indice.
Forse Enrico ha già risolto il problema in questo topic ma non ne sono sicuro.
Ciao ciao.
FraBasta non usarli; \chapter* non va usato mai; la classe book ha la funzionalità apposita (introdotta per la prima volta dalla classe amsbook) per evitarlo, adoperando \frontmatter e \mainmatter.
Ciao
Enrico
-
14 Marzo 2009 alle 7:40 #26667::
Un altro “bug” di LaTeX credo sia il ricorrente problema delle testatine sbagliate usando i comandi di sezionamento asteriscati, che si risolve con un \markboth.
Bisognerebbe ridefinire i vari comandi di sezionamento affinché lancino \markboth in automatico.
Basta non usarli; \chapter* non va usato mai; la classe book ha la funzionalità apposita (introdotta per la prima volta dalla classe amsbook) per evitarlo, adoperando \frontmatter e \mainmatter.
Sono d’accordo sia con Enrico sia con Francesco. Se si usano i comandi \frontmatter e \mainmatter messi a disposizione dalla classe book il problema non si presenta. Se però si usa la classe report (che non ha \frontmatter e \mainmatter) il problema c’è: l’unico modo è impostare manualmente le testatine con \markboth.
Si tratta quindi di un (altro piccolo) bug di LaTeX: per la precisione di un bug della classe report.
Dire, come fa Enrico, che il comando \chapter* non va usato mai equivale a dire -se non sbaglio!- che, se in un documento c’è bisogno di inserire un capitolo non numerato (una prefazione, un sommario “esteso”, …) non bisogna usare la classe report, ma la classe book (eventualmente con le opzioni openany e oneside). Sono d’accordo, naturalmente: la classe report mi è sempre sembrata un doppione di book!
Ciao,
L.
-
14 Marzo 2009 alle 10:22 #26668::
Se si usano i comandi \frontmatter e \mainmatter messi a disposizione dalla classe book il problema non si presenta. Se però si usa la classe report (che non ha \frontmatter e \mainmatter) il problema c’è: l’unico modo è impostare manualmente le testatine con \markboth.
Si tratta quindi di un (altro piccolo) bug di LaTeX: per la precisione di un bug della classe report.
Sbagliato. La classe report non abilita di default le testatine.
Ciao
Enrico
-
15 Marzo 2009 alle 10:32 #26669::
Sbagliato. La classe report non abilita di default le testatine.
Certo. Però resta il fatto che se si usano insieme:
1. la classe report,
2. lo stile di pagina headings,
3. un capitolo non numerato introdotto con \cahpter*,
il problema della testatina sbagliata si presenta eccome!Naturalmente, esistono diverse soluzioni per questo problemino:
1. impostare a mano le testatine con \markboth;
2. non usare lo stile di pagina headings;
3. usare un’altra classe, come book (con \frontmatter), o amsbook.Il problema comunque c’è!
Sto scrivendo un paragrafetto che sintetizzi questa storia, da inserire nella prossima versione dell’Arte. Domani lo sottopongo alla vostra attenzione!
Buona domenica,
L.
-
15 Marzo 2009 alle 10:56 #26670::
Sbagliato. La classe report non abilita di default le testatine.
Certo. Però resta il fatto che se si usano insieme:
1. la classe report,
2. lo stile di pagina headings,
3. un capitolo non numerato introdotto con \cahpter*,
il problema della testatina sbagliata si presenta eccome!Naturalmente, esistono diverse soluzioni per questo problemino:
1. impostare a mano le testatine con \markboth;
2. non usare lo stile di pagina headings;
3. usare un’altra classe, come book (con \frontmatter), o amsbook.Il problema comunque c’è!
Sto scrivendo un paragrafetto che sintetizzi questa storia, da inserire nella prossima versione dell’Arte. Domani lo sottopongo alla vostra attenzione!
Buona domenica,
L.Siamo alle solite: considerare “baco” ciò che non si gradisce. La classe report è pensata per rapporti tecnici, nei quali ogni parte importante ha il suo numero. È possibile che qualche parte non abbia un numero, in tal caso la soluzione è di usare \pagestyle{headings} dal momento in cui si vogliono le testatine che non devono esserci nelle parti non numerate. Se prendi una motozappa per curare il giardino di casa ti puoi aspettare qualche problemino con le aiuole delle rose.
Il vero baco, se proprio vogliamo andare a cercarlo, è nella definizione di \@evenhead e \@oddhead nello stile myheadings, dove \slshape dovrebbe essere sostituito da un comando “generico” modificabile dall’utente. E nell’imposizione di \MakeUppercase per le testatine dello stile headings insieme a \slshape. Lo dico ancora una volta: le classi standard servono solo come classi “generiche”; il vero “baco” è di non averle pensate in modo sufficientemente flessibile. La classe memoir però è un chiaro esempio di dove si deve arrivare se si vuole qualcosa di veramente flessibile: quante pagine ha il manuale? Anche escludendo l’interessante parte “tipografica”, rimane piuttosto massiccio.
Ciao
Enrico
-
15 Marzo 2009 alle 11:48 #26671::
Sbagliato. La classe report non abilita di default le testatine.
Sembra che i comandi che vanno a modificare il layout non vadano usati e che ci si debba limitare ad utilizzare solo quelli messi a disposizione, o autorizzati esplicitamente, dalla classe in uso perché altrimenti non si hanno garanzie sul risultato (oppure usare pacchetti per quella classe).
Concludo che \pagestyle è un comando generico non contemplato dalla classe report,
mentre \chapter* è definito all’interno della stessa. (È così?)Allora mi domando, perché la classe book, che vuole essere compatibile con \pagestyle, ha il comando \chapter* “sbagliato”?
Oppure, siccome book mette a disposizione i comandi appositi \frontmatter, \mainmatter, ecc. . ., perché c’è \chapter*? È rimasto da una versione più vecchia per motivi di compatibilità?Siamo alle solite: considerare “baco” ciò che non si gradisce. La classe report è pensata per rapporti tecnici, nei quali ogni parte importante ha il suo numero. È possibile che qualche parte non abbia un numero, in tal caso la soluzione è di usare \pagestyle{headings} dal momento in cui si vogliono le testatine che non devono esserci nelle parti non numerate. Se prendi una motozappa per curare il giardino di casa ti puoi aspettare qualche problemino con le aiuole delle rose.
Il vero baco, se proprio vogliamo andare a cercarlo, è nella definizione di \@evenhead e \@oddhead nello stile myheadings, dove \slshape dovrebbe essere sostituito da un comando “generico” modificabile dall’utente. E nell’imposizione di \MakeUppercase per le testatine dello stile headings insieme a \slshape. Lo dico ancora una volta: le classi standard servono solo come classi “generiche”; il vero “baco” è di non averle pensate in modo sufficientemente flessibile. La classe memoir però è un chiaro esempio di dove si deve arrivare se si vuole qualcosa di veramente flessibile: quante pagine ha il manuale? Anche escludendo l’interessante parte “tipografica”, rimane piuttosto massiccio.
Ciao
EnricoSono d’accordo. Però per chi vuole usare LaTeX con le classi standard, dovrebbe esserci allora una piccola guida per ogni classe che dica cosa si può fare.
La documentazione ufficiale, credo classes.dvi, è sostanzialmente il commento dei codici delle classi e basta.Sbaglio?
Ciao ciao.
Fra
-
15 Marzo 2009 alle 12:52 #26672::
Sbagliato. La classe report non abilita di default le testatine.
Sembra che i comandi che vanno a modificare il layout non vadano usati e che ci si debba limitare ad utilizzare solo quelli messi a disposizione, o autorizzati esplicitamente, dalla classe in uso perché altrimenti non si hanno garanzie sul risultato (oppure usare pacchetti per quella classe).
Concludo che \pagestyle è un comando generico non contemplato dalla classe report,
mentre \chapter* è definito all’interno della stessa. (È così?)Infatti: \pagestyle è un comando del nucleo di LaTeX al quale le classi si possono appoggiare per definire i loro stili di pagina, ma che è ovviamente accessibile anche all’utente finale. I comandi di sezione sono definiti dalle classi: per esempio non ce n’è nemmeno uno nella classe minimal.
Allora mi domando, perché la classe book, che vuole essere compatibile con \pagestyle, ha il comando \chapter* “sbagliato”?
Oppure, siccome book mette a disposizione i comandi appositi \frontmatter, \mainmatter, ecc. . ., perché c’è \chapter*? È rimasto da una versione più vecchia per motivi di compatibilità?All’inizio di LaTeX non c’erano \frontmatter e simili; li introdusse Downes nella classe amsbook, con LaTeX2e vennero aggiunti alla classe book e, purtroppo, non molto usati anche perché il manuale uscì con la seconda edizione parecchio dopo.
Siamo alle solite: considerare “baco” ciò che non si gradisce. La classe report è pensata per rapporti tecnici, nei quali ogni parte importante ha il suo numero. È possibile che qualche parte non abbia un numero, in tal caso la soluzione è di usare \pagestyle{headings} dal momento in cui si vogliono le testatine che non devono esserci nelle parti non numerate. Se prendi una motozappa per curare il giardino di casa ti puoi aspettare qualche problemino con le aiuole delle rose.
Il vero baco, se proprio vogliamo andare a cercarlo, è nella definizione di \@evenhead e \@oddhead nello stile myheadings, dove \slshape dovrebbe essere sostituito da un comando “generico” modificabile dall’utente. E nell’imposizione di \MakeUppercase per le testatine dello stile headings insieme a \slshape. Lo dico ancora una volta: le classi standard servono solo come classi “generiche”; il vero “baco” è di non averle pensate in modo sufficientemente flessibile. La classe memoir però è un chiaro esempio di dove si deve arrivare se si vuole qualcosa di veramente flessibile: quante pagine ha il manuale? Anche escludendo l’interessante parte “tipografica”, rimane piuttosto massiccio.
Ciao
EnricoSono d’accordo. Però per chi vuole usare LaTeX con le classi standard, dovrebbe esserci allora una piccola guida per ogni classe che dica cosa si può fare.
La documentazione ufficiale, credo classes.dvi, è sostanzialmente il commento dei codici delle classi e basta.Sbaglio?
La documentazione c’è, nel manuale di Lamport. Anche nella “Not so short guide”, credo.
Ciao
Enrico
-
16 Marzo 2009 alle 9:21 #26673::
Siamo alle solite: considerare “baco” ciò che non si gradisce. La classe report è pensata per rapporti tecnici, nei quali ogni parte importante ha il suo numero. È possibile che qualche parte non abbia un numero, in tal caso la soluzione è di usare \pagestyle{headings} dal momento in cui si vogliono le testatine che non devono esserci nelle parti non numerate.
Ciao Enrico, è probabile che il nome “baco di LaTeX” usato in questa discussione (a mo’ di piccola provocazione!) non sia appropriato. Al posto di “baco” sarebbe forse meglio dire “comportamento inaspettato” di LaTeX”.
Nomi a parte, la sostanza è che ci sono situazioni in cui LaTeX può produrre risultati inaspettati (o sgraditi, o potenzialmente sgraditi). Penso sia buona cosa che l’utente conosca queste situazioni, capisca le ragioni delle scelte di LaTeX e sappia, eventualmente, come rimediare.
Per esempio, un utente potrebbe scrivere un (apparentemente) innocuo
`\documentclass{report}
\usepackage{lipsum}
\pagestyle{headings}
\begin{document}
\tableofcontents
\chapter*{Introduzione}
\lipsum\lipsum\chapter{Foo}
\lipsum\chapter{Bar}
\lipsum
\end{document} `
o un ancor più semplice
`\documentclass{book}
\usepackage{lipsum}
\begin{document}
\tableofcontents
\chapter*{Introduzione}
\lipsum\lipsum\chapter{Foo}
\lipsum\chapter{Bar}
\lipsum
\end{document} `
e trovarsi con la testatina sbagliata nell’introduzione.I rimedi, come dicevo, ci sono, e sono tutti relativamente semplici. Quello di usare le testatine solo a partire dai capitoli numerati è sicuramente risolutivo. Parimenti risolutivi sono usare \markboth o \frontmatter (con la classe book) o un’altra classe (come amsbook).
Adesso cerco di sintetizzare il tutto, alla luce di questi nuovi elementi!
Grazie mille,
L.
-
-
AutoreRisposte
- Devi essere connesso per rispondere a questo topic.