egreg9

Ciao!
Non capisco perchè, ma con questa impostazione`\usepackage[font={small,sl}, labelfont=bf, justification= RaggedRight]{caption}[2004/07/16]`le mie didascalie non si allineano a sinistra della tal immagine o tabella.

All’inizio pensavo che fosse il comando \centering che metto per ogni float, ma anche togliendolo il risultato è lo stesso: le didascalie sono allineate al centro!

Esempio:`\begin{figure}[!ht]
\centering
\includegraphics[scale=.70]{esempio_js}
\caption{Un semplice programma \js{}.}
\label{es_js}
\end{figure}`
Qualche suggerimento?

L’opzione RaggedRight dice solo di comporre la didascalia sbandierata a destra; nulla nel nome e nella documentazione suggerisce un comportamento come quello che speravi.

LaTeX non ha alcuna nozione di quanto sia larga la tua figura; si può dirglielo, con un po’ di lavoro. Ma vorrei discutere sul tuo progetto grafico, sul quale non concordo.

Vediamo di vedere che cosa fa LaTeX normalmente: compone la didascalia con lo stesso corpo di base del documento su tutta la giustezza, tranne nel caso in cui la didascalia sia più corta. In questo caso la centra.

Con il pacchetto caption puoi agire su molti parametri, ma non hai la possibilità di comporre la didascalia con una giustezza pari alla larghezza della figura. Il motivo è semplice: due figure non saranno mai della stessa larghezza e ti troveresti ad avere didascalie di ampiezze diverse nel documento, magari sulla stessa pagina. Diverso è il caso di didascalie brevi, la centratura evita l’effetto di spaesamento dovuto a un testo che appare appeso al nulla.

Puoi dire a caption di non centrare le didascalie brevi con l’opzione “singlelinecheck=false”. Puoi ottenere l’effetto che speri provando il seguente codice:
`\newlength{\figwd}
\newcommand{\evalfigwd}[2][]{%
\settowidth{\figwd}{\includegraphics[#1]{#2}}}
\newenvironment{myfigure}[2][]
{\begin{figure}[htbp]%
\evalfigwd[#1]{#2}\centering
\begin{minipage}{\figwd}%
\includegraphics[#1]{#2}}
{\end{minipage}\end{figure}}`
Inserirai la figura in questo modo:
`\begin{myfigure}[scale=.70]{esempio_js}
\caption{Un semplice programma \js{}.}
\label{es_js}
\end{myfigure}`
So che la sintassi non è il massimo, ma per un esperimento può andare. Vedrai che le didascalie di dimensione variabile non sono molto gradevoli.

Ciao
Enrico

Enrico, cosa ne pensi della questione iniziale sull’uso o meno del corsivo in apici e pedici?

Non userei un pedice come in $L_\mathrm{eff}$ nemmeno sotto tortura, anche se so che in alcuni campi si usa.

Dipende dalle tradizioni, non c’è altro da fare che consultare i testi di buone case editrici per vedere come fanno.

Sulla questione delle “costanti” in tondo e delle “variabili” in corsivo sono del tutto contrario: per me la “i” unità immaginaria e il numero di Napier “e” vanno sempre e solo in corsivo. Mi viene abbastanza da ridere leggendo che la “c” che indica la velocità della luce va in corsivo perché il suo valore non è costante, dipendendo dalle misure.

Ciao
Enrico

Bella domanda!

Ti do una risposta “d’istinto”. Quello che va assolutamente evitato, secondo me, è di usare i caratteri matematici per un pedice che indica una parola o un’abbreviazione (formata da più lettere) di una parola. Per esempio ho visto -anche su testi “seri”- il seguente:
`V_{eff}`
che produce una spaziatura sbagliata in “eff” -orrendo. Al suo posto,
`V_\text{eff}`
I fisici e gli ingegneri hanno la tendenza ad usare il tondo per le “costanti” e il corsivo per le “variabili”. Personalmente, preferisco indicare tutte le grandezze fisiche in corsivo, logicamente anche quando si trovano al pedice.

Quanto al pedice che “contestualizza” la grandezza fisica cui fa riferimento, è probabilmente anche una questione di gusti. Posto che cercherei di usarne il meno possibile (li trovo pesantucci), forse il tondo è più adeguato, proprio per distiguere dal caso precedente.

Ah, meglio \text{…} di {\rm …} .

Meglio ancora \mathrm, per evitare che il pedice venga corsivo in un contesto corsivo. Infatti si ha
`\textit{Vale la disuguaglianza $L_\text{eff}\ne L_\mathrm{eff}$}`
e questo può accadere, per esempio, negli enunciati dei teoremi. Naturalmente la scomodità del codice può essere alleviata definendosi comandi personali: qualcosa come
`\newcommand{\1}{\mathrm}`
Ciao
Enrico

Ma perchè la coesistenza? ❓ ❓ ❓
Nei listati o uso`basicstyle=\footnotesize\ttfamily, `oppure`basicstyle=\fontfamily{pcr}\footnotesize`
Non li uso contemporaneamente! O uno o l’altro!

Se li usi entrambi nello stesso documento, ti assicuro che l’effetto è disastroso. Così come accade se usi Courier nei listati e CM Typewriter nel corpo del testo.

Ciao
Enrico

ammettiamo pure che jpeg2esp sia quasi impossibile da usare in piattaforma win xp o meglio che servono passaggi assurdi per convertire in eps e quindi un enorme perdita di tempo ( o meglio ancora che a me non è riuscito usarlo 🙂 ), esiste un programma che semplifica la vita in tutto ciò? O devo ogni volta sbattermi per fare queste coneversioni?Se ho immagini jpeg da inserire devo fare tutte queste conversioni?e non mi dite di usare pdfLaTex per la compilazione

Se non esiste mi metto l’anima in pace

Cmq grazie per le risposte.

Non prendertela con noi, se usi un sistema balordo 😉 Scherzo, naturalmente.

Con VersionTracker vedo che c’è un programma shareware che si chiama Able Batch Converter. Non so dire che risultati si ottengano. C’è anche ImageMagick: http://www.imagemagick.org che è gratis. Ma non è particolarmente efficiente nell’incapsulamento di JPEG in EPS, mentre funziona bene per convertire JPEG in PDF.

Ciao
Enrico

Perchè? 😯
Ti ho detto che le parole chiave adesso sono in blu e in grassetto!
Sì, il carattere è leggermente diverso, ma mi va bene, dunque perchè non avrei risolto?
\texttt lo uso durante il testo e anche parecchio, ma che c’entra? Quell’impostazione non coinvolge solo i listati?
Forse il Courier è obsoleto e devo ricercare sempre la compatibilità con questo fantomatico Computer Modern?

Courier non è obsoleto (ma è bruttino). Né CM Typewriter è la quintessenza del carattere da macchina per scrivere. Il problema è la coesistenza fra due tipi di carattere molto diversi tra loro (non “leggermente”) per indicare cose uguali. Ma il documento è tuo, fa’ pure come credi. 😕

La parola “grassetto” in tipografia non si usa; si preferisce “neretto” o “nero” (che propriamente indicano gradazioni leggermente diverse fra loro).

Ciao
Enrico

Visto adesso che hai curato la parte per l’italiano: ottima iniziativa, complimenti e grazie. Non ho visto nessun errore, ma contavo di fare delle prove più specifiche e mirate appunto a comporre una bibliografia italiana, comprese tutte le manie degli umanisti.

Sono appunto quelle manie che mi preoccupano. 😀

Ciao
Enrico

Non capisco perchè, ma con queste impostazioni:`% Gestione dei listati di codice
\usepackage{color}
\definecolor{grayback}{rgb}{0.9,0.9,0.9}
\definecolor{grayrows}{rgb}{0.3,0.3,0.3}
\usepackage{listings}
\lstdefinestyle{num_righe}
{ numbers=left,
stepnumber=1,
numberstyle=\footnotesize\color{grayrows},
numbersep=5pt }

% Definizione dei linguaggi – – – – – – – – – –
\lstdefinelanguage{JavaScript}
{ keywords={function, new, true, false, var, for, do, while, if, break, return},
basicstyle=\footnotesize\ttfamily,
keywordstyle=\color{blue}\bfseries\footnotesize,
backgroundcolor=\color{grayback},
sensitive=false,
showspaces=false,
showstringspaces=false,emph={3}
showtabs=false,
style=num_righe,
morecomment=[l]{//},
morecomment={/*}{*/},
morestring=,
breaklines=true,
breakindent=132pt
}`
non riesco ad ottenere le parole chiave in grassetto…tutto il resto, invece, funziona molto bene.

Perché non esiste il Computer Modern Typewriter nero. Se infatti cambi in
`basicstyle=\fontfamily{pcr}\footnotesize,`
ottieni il nero perché Courier ce l’ha. Puoi usare il pacchetto lmodern, ma la differenza fra lmtt (Latin Modern Typewriter) e lmtk (Latin Modern Typewriter Dark) non è molta, soprattutto se usi il colore blu per il Dark.

Ciao
Enrico