Risposte nei forum create
-
AutoreRisposte
-
::
Per la mia esperienza personale, inserire all’inizio dell’email nome, cognome, insegnamento e corso di laurea può essere utile quando il docente tiene più insegnamenti anche in corsi di laurea o dipartimenti differenti, per inquadrare subito l’ambito dell’email (in generale la matricola è inutile). Mi è capitato di avere a che fare con professori nervosi e sbrigativi che mi hanno rimproverato di aver dovuto leggere “con attenzione” tutta la lettera per capire di cosa si parlasse. Da allora le mie email sono diventate molto schematiche: chi sono, cosa voglio, saluti.
Quanto alla formula di apertura/chiusura, dipende dal grado di confidenza che si ha con un prof. Egregio è l’epiteto più neutrale. Mi è capitato di usare (credo una volta) chiarissimo per indicare effettivamente un docente che aveva questa (rara) attitudine. Ho usato anche stimatissimo e carissimo e nella formula di chiusura mi è capitato di usare perfino “con affetto”. Ovviamente ogni volta credevo veramente in quello che scrivevo. Comunque egregio va benissimo nel 100% delle situazioni perciò vai sicuro.Ciao
::Marco87″ post=87021perché posizionando il punto di partenza dell’arco per lo [tt]strato inferiore[/tt] simmetricamente a [tt](-5,.7)[/tt] rispetto all’asse orizzontale, gli archi non si uniscono essendo tangenti?
Perché non sono tangenti, ma solo simmetrici rispetto all’asse delle ascisse. A te quello che interessa è che le due saette siano uguali. Da un lato hai \(4[1-\sin(125^\circ)]\) e dall’altro \(4[\sin(235^\circ)-(-1)]\), che fa circa 0,7234. Quindi in un caso l’ordinata è [tt]-0.7234[/tt] e nell’altro è [tt]+0.7234[/tt]. Il troncamento dei valori a 0,7 cm (7 mm) è sufficiente perché si veda l’incrocio dei due archi, che è alto quasi mezzo millimetro \(2(0,7234-0,7)\) cm.
Il consiglio è di far partire gli archi dal punto in comune anziché dall’altro, in modo tale da non dover arrotondare niente.
Ciao
::egreg9″ post=86923Con [tt]subcaption[/tt] devi per forza specificare la dimensione orizzontale. Con [tt]subfig[/tt] no.
Scusa il ritardo nella risposta. Strano, per l’uso che ne ho fatto io è bastato scrivere
`
\subcaptionbox{didascalia}{
\includegraphics{figura}}`
e il gioco è fatto. Ovviamente “figura” era già della dimensione opportuna.Ciao
::egreg9″ post=86894Viene anche bollato come obsoleto [tt]subfig[/tt] che non lo è affatto. Basta sapere che non funziona come ci si aspetta con hyperref. Ma fare le stesse cose di subfig con subcaption è doloroso. 😉
Io da un po’ di tempo ho abbandonato [tt]subfig[/tt] in favore di [tt]subcaption[/tt], dopo avere letto in giro che il primo era obsoleto. Quindi ho convertito i vecchi file al secondo pacchetto. Puoi spiegarmi cos’è doloroso fare con [tt]subcaption[/tt]?
Grazie e ciao
9 Luglio 2013 alle 12:51 in risposta a: [Semi OT] – Git + LaTeX: recupero versione precedente #87418::
Il comando che cercavo è
`git checkout— .`Il motivo è che a volte mi può servire rimettere in funzione una vecchia versione che funzionava con un file di classe ormai superato, quindi mi serve riportare tutto indietro.
Ho provato anche
`git checkout` ma il sistema me lo vieta. Ho visto anche il [tt]reset[/tt], ma non è quello che cerco perché cancella le versioni successive. Mi potete spiegare la differenza tra “soft”, “mixed” e “hard”? Perché npn l’ho capita. Grazie
6 Luglio 2013 alle 14:27 in risposta a: [Semi OT] – Git + LaTeX: recupero versione precedente #87415::Elrond” post=86874Sì, certo, ogni commit in git scatta una fotografia dell’intero repository, se tu gli dici di tornare al commit 5 con il primo comando che ti ho detto lui ripristina tutti i file presenti all’epoca, il file di classe apparirà come era stato modificato nel commit 4 e l’immagine1 nella commit 3.
Allora mi sorge un dubbio: perché dobbiamo aggiungere i file nella staging area prima del [tt]commit[/tt] se comunque Git “scatta una fotografia dell’intero repository”?
Forse il [tt]commit[/tt] aggiunge fisicamente una copia dei file aggiunti e un semplice riferimento per gli altri presenti nel repository basandosi non su ciò che c’è nella working directory, ma su ciò che è scritto nel suo database?Grazie. Ho visto che hai aggiunto l’elenco dei comandi alla fine.
Ciao
::Elrond” post=86872Noto solo ora di aver fatto un piccolo disastro nelle ultime modifiche alla guida: per i comandi in linea ho usato [tt]\textt{}[/tt], ma di conseguenza i doppi trattini nel PDF finale appaiono come un unico trattino. Devo sistemare questo problema
Apri e chiudi le graffe tra i due trattini.
Sì, voglio tornare alla versione 5, ma nel commit 5 ho aggiunto solo (s), perché (c) non l’ho modificato. Quando torno indietro, Git capisce che deve prendere (c) dalla versione 4 e (i1) dalla versione 3?
Ciao
::
Sul LuaTeX Reference Manual, nel paragrafo 10.2 si legge (il neretto l’ho aggiunto io):LuaTeX_Reference_ManualThe single internal memory heap that traditional TEX used for tokens and nodes is split into two separate arrays. Each of these will grow dynamically when needed.
The texmf.cnf settings related to main memory are no longer used (these are: main_memory, mem_bot, extra_mem_top and extra_mem_bot). ‘Out of main memory’ errors can still occur, but the limiting factor is now the amount of RAM in your system, not a predefined limit.
<...>
The input line buffer and pool size are now also reallocated when needed, and the texmf.cnf settings buf_size and pool_size are silently ignored.Quindi l’allocazione dinamica riserva la quantità di memoria necessaria non oltre la capacità della RAM del sistema.
Ciao
::Marco87″ post=86814Quindi, se ho capito correttamente, una volta che la pagina in cui compare un disegno viene composta, il disegno viene cancellato dalla memoria. Questo vuol dire che finché impedisco la formazione di una coda piuttosto intasata, non dovrei avere problemi di memoria. È corretto?
Già. E per i disegni in linea con il testo?
OldClaudio” post=86725Quindi ogni programma che si rispetti non deve richiedere memoria al sistema operativo fioo al punto in cui si arrestano gli altri processi, compreso il sistema operativo stesso, per mancanza di RAM.
Il problema, se ho capito bene, è che LaTeX non gestisce l’allocazione dinamica della memoria, perciò non è in grado di utilizzarne quanta gliene serve, ma ne riserva una parte che viene impegnata indipendentemente dal fatto che sia effettivamente utilizzata oppure no, perciò deve essere necessariamente non troppo grande per evitare problemi in sistemi datati. Se è così, si è fatto qualcosa in LaTeX3?
Ciao
-
AutoreRisposte