robitex

Salve a tutti, non riesco a capire perchè la funzione per fare l’apostrofo non mi funzioni.

All’inizio ho scritto questo:

\documentclass[italian]{article}
\usepackage[italian]{babel}
\usepackage{indentfirst}
\usepackage{geometry}
\geometry{…}

per scrivere ad esempio l’asta faccio: l\’asta

ma ho i seguenti errori:
Undefined control sequence …frase con l’apostrofo…
No hyphenation patterns were loaded for (babel) the language ‘Italian'(babel) I will use the patterns loaded for \language=0 instead
the marginal notes overrun the paper

da quanto ho capito si può evitare di usare E’ la sezione giusta? direi(spero) di si.

All’inizio ho scritto questo:

\documentclass[italian]{article}
\usepackage[italian]{babel}
\usepackage{indentfirst}
\usepackage{geometry}
\geometry{…}

per scrivere ad esempio l’asta faccio: \’ mettendo i pacchetti [T1]{fontenc} e [latin9]{inputenc} ma non mi funzionava lostesso.

Sono ancora alle prime armi, spero di non aver perso un passaggio per strada, come posso risolvere?
Grazie in anticipo.

Una question di encoding del file sorgente?
Prova anche a caricare i pacchetti fontenc con opzione T1 e inputenc con opzione latin1 per windows e utf8 per linux.
Saluti.

Può darsi che interessi Nacitekas; può darsi che interessi anche altri frequentatori del forum.

Premetto che io non lo farei mai e sono perfettamente soddisfatto di usare TeXShop, il progenitore di TeXworks; tuttavia vale la pena di segnalare che il team di OpenOffice.org, che ha già messo a punto un plug-in abbastanza buono per Writer, che si chiama Writer2LaTeX, sta lavorando su un ulteriore plug-in che vuole inserire nella versione 1.2 del suddetto Writer2LaTeX, e che potrebbe far diventare la componente Writer di OpenOffice.org un succedaneo di LyX. In altre parole Writer verrebbe usato come shell editor e cliccando un opportuno bottone si avrebbe la compilazione con pdflatex e cliccando un altro bottone si avrebbe direttamente la vista del documento compilato.

Chi vuole può scaricare dal sito di sourceforge lo screenshot del plug-in allo stato attuale, per usarlo o per testarlo. Io non l’ho fatto, perché la cosa non mi interessa, ma potrebbe interessare altri.

Invece mi permetterei di consigliare a Nacitekas di non ascoltare il canto delle sirene dei word processor che ti fanno vedere subito quello che stati facendo (magari in modo tipograficamente scorretto).

La forza del mark-up di LaTeX è proprio quella di non vedere subito quel che si otterrà obbligando l’autore a concentrarsi sul testo; poi l’autore può usare i trucchi che vuole per marcare il testo sorgente in modo da evidenziare i sezionamenti; usando certi editor, come TeXmakerX può anche contrarre certi ambienti, in modo da non essere distratto dal loro contenuto; oppure può usare la finestra laterale, contenente la struttura, per navigare rapidamente nelle varie sezioni che sta componendo; lo fanno anche altri editor, ma ho citato TeXmakerX perché, come TeXworks, è multipiattaforma e non è legato a un sistema operativo piuttosto che a un altro; la colorazione diversa per distinguere i comandi dal testo ce l’hanno praticamente tutti gli shell editor decenti; la possibilità di eseguire la ricerca dalla finestra tex alla finestra pdf in entrambi i sensi ce l’hanno pochi shell editor, e trovo che sia una cosa decisamente fondamentale.

Poi, in fondo, si tratta sempre di una questione di abitudine; la cosiddetta rampa di apprendimento molto ripida di LaTeX è una storia priva di valore; riguarda solo il cambiamento di una abitudine da “what you see is all you get” a “what you see is what you mean”.

Interessantissima questa cosa di OpenOffice.org ma anche un tantino pericolosa!!!
Infatti, dal punto di vista della diffusione di LaTeX e compagni è da una parte formidabile visto l’elevatissimo numero di utenti OpenOffice.org che non conoscono LaTeX e che così potrebbero considerarne finalmente l’utilizzo.
Dall’altra parte tuttavia, i nuovi utenti potrebbero miscomprendere LaTeX. Alcuni utilizzatori già oggi confondono lo shell editor come il motore tipografico vero e proprio.

Alla fine penso che il beneficio alla diffusione superi l’inconveniente, se solo la guida in linea del plug-in dichiarasse per prima cosa ed in modo molto chiaro cosa fa il plug-in e cosa fa LaTeX.

Per quanto riguarda l’uso dei word processor penso che il peggior difetto non sia in un problematico approccio ai contenuti, ma l’insieme di cattive abitudini su cui l’utente si adagia.
Grazie ed a presto.

Le 5 immagini che devo inserire occupano ognuna una pagina intera e sono in una sezione fissa del documento quindi ciò che mi suggerisci potrebbe fare al caso mio: quindi con geometry. Cosa intendi per nuove funzionalità? Devo verificare di avere l’ultima versione?
Grazie,
Luca

Intendo il nuovo comando \newgeometry della versione 5 del pacchetto.
Adesso è possibile assegnare diversi layout a diverse sezioni del documento.
Studiare il manuale di geometry dando da console il comando:`texdoc geometry`

Ciao.

[quote]La gestione di due TeX Live su Ubuntu non è così semplice. Si potrebbe pensare a uno script che chiamato con un parametro sceglie la distribuzione impostando correttamente il PATH, diciamo
`choosetexlive debian
choosetexlive texlive`
Estrarre o aggiungere dalla variabile PATH la stringa “/usr/texlive/…:” in testa al valore di $PATH non è difficile.

Ma questo purtroppo non risolve il problema; infatti anche se l’ambiente nella propria shell contiene il valore corretto e “pdflatex pippo” punterebbe al giusto eseguibile, lanciare Emacs o Kile con i menù di sistema lascerebbe il valore di default di PATH: ogni processo lanciato da questi userebbe la TeX Live Debian (con gli eseguibili in /usr/bin).

La soluzione che ho trovato, non proprio il meglio, è usare il file .pam_environment. Se voglio usare la TeX Live indipendente, ho questo file nella home che contiene
`PATH=/usr/local/texlive/…:/usr/local.bin:/usr/bin:`
Se voglio usare la TeX Live Debian, devo rinominare questo file, uscire e rientrare dall’account. 🙁

Si potrebbe trovare una via di scampo con un sistema simile a quello usato da MacTeX: aggiungere al PATH standard, in cima, l’indicazione di /usr/texbin; questo sarebbe un link simbolico alla directory degli eseguibili della TeX Live indipendente oppure a /usr/bin. Uno script può facilmente sovrascrivere quel link. Nemmeno questo risolverebbe il problema, perché qualcosa in /usr/local/bin non verrebbe visto prima di un programma con lo stesso nome in /usr/bin nel caso si usi la TeX Live Debian, contraddicendo il principale uso di /usr/local/bin. 🙁

Non c’entra, ma oggi il mirror di Roma2 era di nuovo lentissimo dopo settimane di prestazioni normali. 🙁

Ciao
Enrico

l’annoso problema dell’uso di versioni differenti dello stesso software sotto linux si risolve egregiamente (la battuta con egreg e’ troppo facile… :lol:) con i modules.
vedi qua per info approfondite http://modules.sourceforge.net/man/module.html.
questo implica che, comunque, anche i programmi grafici vadano lanciati da una shell che abbia il modulo adeguato caricato.

Interessante discussione,
perché non farne un qualcosa di più per esempio un articolo per la prossima ArsTeXnica, o una guida da pubblicare sul sito di GuIT?
Una guida passo passo per risolvere i problemi con i moduli potrebbe essere un lavoro utile e piacevole.

capitalaslash che te pare dell’idea?

OT: Lucid è davvero formidabile, il mio PC vecchio di dieci anni è ringiovanito di almeno cinque. :twisted:[/quote]

Aggiungo che la guida potrebbe contenere anche un’altra cosa assai utile:
*** l’installazione e l’uso di TeX Live in rete
Come gestire un unica distribuzione “server” di TeX Live per un gruppo di lavoro che condivida classi di documento specifiche.
Un aggiornamento per esempio delle classi per la “carta intestata” delle comunicazioni aziendali sarebbe centralizzato, quindi immediatamente disponibile ed in modo trasparente per il team.
Un paio di GuITmeeting fa avevo accennato alla cosa direttamente a Norbert Preining che con la sua intuitività tecnologica l’aveva data per un operazione fattibile attraverso Samba.
Grazie.

😯
la tua soluzione non può essere ammessa, perché sostanzialmente è quello che fa lo script d’installazione con i symlink
😆
e poiché dalla mia esperienza e dalla lettura di un post sul forum (di Enrico) mi sono fatto l’idea che i symlink possono essere tutt’altro che una comodità, occorre evitare di applicarli anche se sono comodi.
❗

riesci ad indicarmi questo post?
non sono riuscito a trovarlo con una ricerca nel forum…
o puoi spiegarmi cosa c’e’ di cosi’ cattivo nei simlink?
se e’ solo il problema che finisco nel PATH dell’utente basta sostituire bin con sbin.

Il post credo fosse quello in evidenza nella board principale, ho forse era una discussione che è poi passata a TeX Live dal problema originario.
La mia idea è che se controlli il PATH puoi semplicemente gestire più TeX Live installate sul sistema o affiancare alla distro che so metti una ConTeXt minimal.
Con i symlink va a finire che si deve litigare col sistema per inidizzarlo verso gli eseguibili desiderati.
Poi Enrico può dire la sua e chiarirci meglio.
Bye

Capito 🙂 Grazie mille!!!

è un po’ tardi… ma tu hai installato texlive senza i privilegi di sudo e senza creare i symlinks?

Salve a tutti. Riprendo questa discussione per proporre una soluzione.

Ricapitolando, se non abbiamo attivato i symlink al momento dell’installazione (e probabilmente è bene non farlo perché si “disturba” troppo l’ambiente), il comando sudo tlmgr gui non funziona.
Acquisire i diritti di root per lo script è tuttavia essenziale coma sappiamo. Tuttavia è solo un problema di PATH quindi il comando sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr gui funziona.
Allora perché non definire molto semplicemente un alias? ecco il comando:
alias supertlmgr=”sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr”

In questo modo possiamo lavorare con il nuovo comando così:
supertlmgr update -all

Geniale vero? 8)

Per avere nell’ambiente “globale” un PATH che contenga “/usr/local/texlive/2009/bin/i386-linux” ho modificato il file “/etc/environment”. In questo modo il sistema trova gli eseguibili giusti per qualsiasi programma, anche non lanciato da una shell. Il problema è: come si fa a modificare la scelta (globalmente) senza rimodificare quel file e riavviare?

Come hai modificato il file /etc/environment?

Io farei un
`sudo gedit /etc/environment`.

Per info su il file /etc/environment vedere https://help.ubuntu.com/community/EnvironmentVariables

Ciao