Un bug di babel

ivan” post=66977C’è qualcosa che non va in quello che ho detto? Si può fare meglio?
Non è forse il caso di implementare la cosa direttamente in babel?

No, non mi pare ci siano grandi controindicazioni; ma allo stesso modo dovresti ridefinire anche vari altri comandi. Scriverei
`\makeatletter
\DeclareRobustCommand\itshape
{\penalty\@M\hskip\z@skip\not@math@alphabet\itshape
\mathit\fontshape\itdefault\selectfont}
\makeatother`

Se posso dare la mia opinione, in quel caso è meglio evitare la sillabazione se non proprio in situazioni disperate.

Ciao
Enrico

Ciao Ivan,
siccome sono io che mi occupo della parte italiana di babel, ho dei dubbi ad implementare una cosa del genere; forse posso studiare qualcosa di più intelligente (dal punto di vista di babel, non della soluzione trovata) che non tocchi nient’altro dentro alle definizioni del nucleo di LaTeX. Ci penserò.

Nel frattempo ci sono due punti da notare:
!) il motore di composizione (che sia tex, pdftex, xetex, luatex) non divide in sillabe la prima parola dopo un cambiamento di font
2) Nella GuidaGuIT, verso la fine del paragrafo C.1 sulla sillabazione, si suggerisce di inserire un grumo di colla di larghezza nulla come ti ha suggerito Enrico; la penalità è giusto che ci sia in modo che il motore di composizione non vada a capo dopo l’apostrofo; tuttavia io definirei un comando \hz, brevissimo da scrivere (babel definisce un comando simile che si chiama, mi pare, \allowbreak), così:
`
\newcommando\hz{\nobreak\hskip0pt}
`
e poi scriverei semplicemente
`
dell'\emph{\hz enciclopedia}
`
Non capita spesso di dover inserire \hz nei punti da sillabare quando il programma di composizione non è capace di farlo da solo. Io ho alle mie spalle almeno 5000 pagine di libri e documenti vari composti con LaTeX nell’arco di una trentina di anni e ho incontrato problemi di questo genere solo due o tre volte in questo arco di tempo… e di pagine.

Comunque ci sono questi due trucchi molto semplici
1) quando scrivi in italiano (e il problema si presenta in questo caso) puoi sempre mettere un doppio apice dopo la prima sillaba della parola che non si divide:
`
\dell'\emph{en”ciclopedia}
`
Il doppio apice in italiano è attivo e segna un punto lecito di cesura, in pratica spezzando senza spazio intermedio una parola in due monconi; se deve avere una cesura proprio fra i due monconi ci mette una trattino di cesura e va a capo.

2) se nel tuo file hai caricato il pacchetto etoolbox, questo ridefinisce e definisce un certo numero di macro che permettono di “riparare” o di modificare le macro che interessa modificare. nel tuo caso continua a usare \emph che a sua volta usa \em, ma nel preambolo o in un tuo file di classe o di estensione aggiungi questo poco codice:
`
\makeatletter % non serve nel file .cls e .sty; serve solo nel preambolo
\addto\em{\nobreak\hskip\z@}
`
e il tuo \emph funziona come desideri.

Ciao
Claudio

ivan” post=67066Grazie Claudio,

io però rimango dell’idea che si tratti di un vero e proprio baco.
Non c’è alcun motivo per cui
`dell'enciclopedia`
venga sillabato correttamente e
`dell'\emph{enciclopedia}` no.

Il problema va risolto a monte. Credo proprio che metterò il codice necessario in suftesi, però mi piacerebbe che venisse risolto in fixltx2e, per esempio.
È chiaro che lo stesso problema si ripresenterebbe nel caso del maiuscoletto, del grassetto, ecc.
Ma questo mi preoccupa meno perché sono situazioni che difficilmente si presentano nel testo normale.
Nel caso si volessero ridefinire tutti i comandi normali per il cambio di font, il consiglio su etoolbox è ottimo 🙂

Ciao
Ivan

Non è un baco: su questo non c’è alcun dubbio (a meno che non si consideri un bug di TeX il fatto che non ammetta la sillabazione della prima parola che segue un cambio di font).

Se qualcuno proponesse agli sviluppatori di LaTeX di inserire \penalty\@M\hskip\z@ all’inizio di ogni comando di cambiamento di font si sentirebbero le pernacchie fino in alta montagna. 🙂 Ti ripeto che, se TeX mi spezzasse automaticamente una parola singola in quella situazione, mi arrabbierei: voglio essere io a decidere se è il caso di spezzarla o se ci sono altri modi di risolvere il problema.

Ciao
Enrico

ivan” post=67069

Non è un baco: su questo non c’è alcun dubbio (a meno che non si consideri un bug di TeX il fatto che non ammetta la sillabazione della prima parola che segue un cambio di font).

Se qualcuno proponesse agli sviluppatori di LaTeX di inserire \penalty\@M\hskip\z@ all’inizio di ogni comando di cambiamento di font si sentirebbero le pernacchie fino in alta montagna. 🙂 Ti ripeto che, se TeX mi spezzasse automaticamente una parola singola in quella situazione, mi arrabbierei: voglio essere io a decidere se è il caso di spezzarla o se ci sono altri modi di risolvere il problema.

Premesso che questa è una battaglia di principio e che è evidente che problemi simili non ci cambiano la vita, ribadisco alcune cose.
Non mi pare (ma potrei sbagliarmi) che tra le regole della lingua italiana ce ne sia una la quale dice che
non si può sillabare
`dell'\emph{enciclopedia}`
Se questa sillabazione è possibile in italiano, e LaTeX gestisce la sillabazione automaticamente, allora così dev’essere.
Forse non sarà un problema di LaTeX, ma

Ho parlato di bug in maniera impropria. Però non mi pare una buona giustificazione il fatto che gli sviluppatori hanno deciso che in quella situazione non avviene la sillabazione.
Dov’è il confine tra bug e scelta del programmatore?
Immaginiamo di avere un testo un testo che parla di molti altri testi: l’Eutifrone, l’Eneide, l’Alfieri, ecc. ecc. Immaginiamo un’antologia, o un’opera di storia della letteratura o di letteratura comparata.
Quanti sarebbero i casi di `dell'\emph{titoloincorsivo}`
che andrebbero sistemati a mano?
Se poi la gabbia è stretta, come un libro comune, le probabilità di incontrare un caso simile aumenterebbero.
Ripeto: non vedo la ragione per una scelta simile. Magari nell’inglese e nelle altre lingue non ci sono casi simili, ma in italiano ci sono, anche se rari.
E se LaTeX sillaba automaticamente lo deve fare anche in quel caso, altrimenti mi aspetto che non sillabi mai quando c’è di mezzo un apostrofo.

Ciao
Ivan

Usa LuaLaTeX. 🙂

A me dispiace che con LuaLaTeX succeda, se devo dire la verità. Questo è un caso in cui l’automatismo ha conseguenze negative.

Le situazioni che proponi si risolvono con la ridefinizione che proponi. Ogni testo ha le sue particolarità e le sue esigenze: non è detto che ciò che va bene in un documento vada bene in tutti gli altri.

Ciao
Enrico

E se LaTeX sillaba automaticamente lo deve fare anche in quel caso, altrimenti mi aspetto che non sillabi mai quando c’è di mezzo un apostrofo.

Ivan, come ti ho già detto non è colpa dell’apostrofo, ma del cambiamento di font; Enrico dice giustamente che vuole essere padrone di decidere quando eseguire la cesura. Io penso che il problema si possa mettere al contrario; quando non ci vuole la cesura? in questo caso la soluzione manuale esiste ed è quella o di mettere la parola dentro una scatola, oppure di definizre un comando molto stenografico con il quale all’inizio del testo racchiuso dentro uno dei comandi \text..{…} o di \emph{…} si invochi la lingua “nohyphenation”, cosa che Enrico ha mostrato più volte [la lingua nohyphenation è una delle lingue di default nelle distribuzioni contemporanee del sistema Te].

Io penso che a livello di fixltx2e si potrebbe mettere un patch in fondo a tutte le definizioni (non dei comandi) di cambio di font; oppure si potrebbe pensare ad un pacchettino fixltxhyph2e che lo faccia e chi vuole se lo carica. Potrebbe anche diventare una opzione di fixltx2e. è una cosa banale da fare, ma forse resterebbero fuori alcuni comandi che l’utente si potrebbe definire da solo o che non sono così frequenti, difficile da usare con il comando \fontfamily quando i nomi delle famiglie sono in numero sterminato.

Impedire la sillabazione dopo l’apostrofo sempre, anche quando non c’è cambiamento di font? certo sarebbe possibile e facilissimo da fare, ma si cadrebbe in quello che fa già Word per conto suo; giammai! 😈

Le lingue che usano l’apostrofo normalmente come segno di elisione sono poche; io conosco solo l’italiano, il francese, il catalano, e il romancio; non conosco il romancio (conosco un poco quello ufficiale della Confederazione Svizzera, che leggo senza problemi) parlato dalla gente e non so quanti grigionesi usino LaTeX per scrivere in romancio, sennò mi cimenterei anche con la sillabazione del romancio. Per ora non mi pare che esista nelle distribuzioni del nostro sistema.

Voglio vedere come fanno per il france e il catalano; per il francese è una cosa seria, perché elidono sempre e lo fanno molto più spesso di noi in italiano. Per noi non sarebbe sbagliato omettere l’elisione e scrive della \emph{enciclopedia} ma per il frances sarebbe un errore grave omettere l’elisione; per altro anche se omettiamo l’elisione e perciò non abbiamo apostrofi fra i piedi, \emph{enciclopedia} non verrebbe comunque divisa in sillabe. Invece \emph{enciclopedia britannica} manche mancherebbe di cesure nella prima parola ma “britannica” si dividerebbe benissimo.

Il problema, come vedi è molto complesso.

Resta il fatto che né pdftex né pdflatex, forse nemmeno context, xetex e luatex eseguono cesure nella prima parola dopo un cambiamento di font.

ivan” post=67073

per altro anche se omettiamo l’elisione e perciò non abbiamo apostrofi fra i piedi, \emph{enciclopedia} non verrebbe comunque divisa in sillabe. Invece \emph{enciclopedia britannica} manche mancherebbe di cesure nella prima parola ma “britannica” si dividerebbe benissimo.

Non mi pare, o forse ho capito male…:
`
\documentclass[draft]{article}

\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[italian]{babel}

\begin{document}

come la mettiamo con questaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \emph{Enciclopedia}?

come la mettiamo con questaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \emph{Enciclopedia Britannica}?

\end{document}
`

Ciao
Ivan

Per la precisione, TeX non sillaba una “parola” che contiene al suo interno un cambio di font. In questo caso “Enciclopedia” viene sillabato, infatti.

Ciao
Enrico

Confermo (con un po’ di stupore):
`
\documentclass{minimal}
\usepackage[latin1]{inputenc}
\uspeackage{T1]{fontenc}
\usepackage[italian]{babel}
\begin{document}

\showhyphens{l'elettricità \emph{elettricità} l'\emph{elettricità} l'\emph{\hskip0pt elettricità}}
\end{document}

Non produxce nulla in unscita, ma nella “console” appaiono queste indicazioni
[code]
Underfull \hbox (badness 10000) in paragraph at lines 14–14[]
\T1/cmr/m/n/10 l'e-let-tri-ci-t‡
\T1/cmr/m/it/10 elet-tri-ci-t‡
\T1/cmr/m/n/10 l'\T1/cmr/m/it/10 elettricit‡
\T1/cmr/m/n/10 l' \T1/cmr/m/it/10 elet-tri-ci-t‡
\T1/cmr/m/n/10 l'\T1/cmr/m/it/10 e-let-tri-ci-t‡
`
che ho riformattato un pochine per confrontarle meglio.

Si noti che il nome interno del font non indica il cambiamento di font, ma il nome del font in vigore nel momento di trattare la parola divisa o non divisa in sillabe. il segno ‡ rappresenta à, ma non è questo quello che influisce sulla sillabazione.

Come si vede il pizzichino di colla di larghezza nulla risolve il problema. E, scrivendo in italiano, il doppio apice lo risolve ancora meglio.

In LuaTeX hanno cambiato l’algoritmo per la sillabazione, che ora è più flessibile anche per quello che si può mettere negli argomenti di \discretionary. In particolare la prima parola di un capoverso viene esaminata per la sillabazione e anche cambiamenti di font all’interno di una parola sono ignorati, mentre con TeX tradizionale rendevano impossibile la sillabazione. Solo \kern espliciti la impediscono.

Ciao
Enrico

Posto che il confine tra “caratteristica” e “difetto” è a volte sottile, concordo con Ivan. Non vedo ragioni (grammaticali, logiche, tipografiche) perché nell’espressione

l’enciclopedia

“enciclopedia” venga sillabata, mentre in

l’\emph{enciclopedia}

no.

Poi siamo d’accordo: è una finezza che difficilmente creerà problemi nell’uso.

Ciao,
L.

Ho appena avuto una piacevole discussione con Daniel Flipo (frenchb.ldf — il file di descrizione della lingua per scrivere in francese).
Giustamente egli mi fa osservare che il problema nasce dall’algoritmo di Frank Liang, l’ideatore della sillabazione del sistema TeX.

Ma giustamente mi fa notare che la soluzione (tolto il doppio apice, che in francese è attivo, ma non ha le stesse funzioni che ha in italiano) deve essere lasciata all’autore che sa quando si può sillabare un parola evidenziata e quando no. L’autore ha diversi mezzi, dal riformulare la frase perché la prola evidenziata non cada in fin di riga, all’introduzione della cesura discrezionale (che in italiano verrebbe inserita con il doppio apice).

A questo punto io propendo per l’uso di \hz che ho mostrato in un precedente messaggio di questo forum e che in quei rari casi in cui il problema si dovesse presentare non sarebbe una cosa grave che l’autore decida se sillabare o non sillabare e come.

Mi fa piacere sentire che in luatex il problema non esista più; se l’algoritmo di luatex è adattabile, può darsi che venga adottato anche da LaTeX3 e da XeLaTeX; speriamo…

OldClaudio” post=67096Giustamente egli mi fa osservare che il problema nasce dall’algoritmo di Frank Liang, l’ideatore della sillabazione del sistema TeX.

Non mi sorprende: quello segnalato da Ivan è un evidente problemino TeXnico.

OldClaudio” post=67096Ma giustamente mi fa notare che la soluzione (tolto il doppio apice, che in francese è attivo, ma non ha le stesse funzioni che ha in italiano) deve essere lasciata all’autore che sa quando si può sillabare un parola evidenziata e quando no. L’autore ha diversi mezzi, dal riformulare la frase perché la prola evidenziata non cada in fin di riga, all’introduzione della cesura discrezionale (che in italiano verrebbe inserita con il doppio apice).

Beh, mi sembra un tentativo poco riuscito di salvarsi in corner. “L’autore che sa quando si può sillabare un parola evidenziata e quando no.” Non regge: la sillabazione è affare di (La)TeX, non dell’autore. Ripeto: non vedo alcuna ragione (logica, grammaticale, tipografica) perché la prima (e solo la prima) parola in corsivo dopo un apostrofo non debba essere sillabata. È un piccolo bug, via.

OldClaudio” post=67096Mi fa piacere sentire che in luatex il problema non esista più; se l’algoritmo di luatex è adattabile, può darsi che venga adottato anche da LaTeX3 e da XeLaTeX; speriamo…

Certo, speriamo. 😉 Ma non è una cosa da non dormirci la notte: il bug segnalato da Ivan è piccolo.

Ciao,
L:

OldClaudio” post=67096Ho appena avuto una piacevole discussione con Daniel Flipo (frenchb.ldf — il file di descrizione della lingua per scrivere in francese).
Giustamente egli mi fa osservare che il problema nasce dall’algoritmo di Frank Liang, l’ideatore della sillabazione del sistema TeX.

Ma giustamente mi fa notare che la soluzione (tolto il doppio apice, che in francese è attivo, ma non ha le stesse funzioni che ha in italiano) deve essere lasciata all’autore che sa quando si può sillabare un parola evidenziata e quando no. L’autore ha diversi mezzi, dal riformulare la frase perché la parola evidenziata non cada in fin di riga, all’introduzione della cesura discrezionale (che in italiano verrebbe inserita con il doppio apice).

Che è esattamente la mia opinione.

In realtà l’algoritmo di Liang non c’entra; è che Knuth, di fronte al problema di scrivere il programma che lo realizza ha scelto (con ottimi motivi) che le parole candidate alla sillabazione fossero tutte in un unico font.

Ciao
Enrico

egreg9″ post=67099
Che è esattamente la mia opinione.

In realtà l’algoritmo di Liang non c’entra; è che Knuth, di fronte al problema di scrivere il programma che lo realizza ha scelto (con ottimi motivi) che le parole candidate alla sillabazione fossero tutte in un unico font.

Ciao
Enrico

Infatti; dividere in fin di riga una parola evidenziata le fa perdere buona parte dell’evidenza; non può essere che l’autore a decidere se dividere o non dividere una parola evidenziata.

Per il resto, probabilmente Enrico ha letto da tesi di Frank Liang, e sa quanto quell’hash per accedere ai pattern sia complicato; magari oggi ci sono algoritmi migliori, chissà; ma allora era già una decisione forte che una parola contenente comandi (control sequence o caratteri attivi), compreso quello dell’accento (che fu il motivo principale per il quale Ferguson inventò MLTeX) non venisse sillabata; altrimenti l’hash avrebbe dovuto essere molto più complesso, credo, e molto più lento per svolgere il suo lavoro, tanto da rallentare in modo insopportabile le macchine della fine degli anni ’70. Ricordiamoci che la prima versione si chiamava TeX78. Poi con la versione 3 di TeX la maggior parte dei problemi sono svaniti e sono rimasti questi nèi, che in fondo danno pochissimo fastidio.

egreg9″ post=67099In realtà l’algoritmo di Liang non c’entra; è che Knuth, di fronte al problema di scrivere il programma che lo realizza ha scelto (con ottimi motivi) che le parole candidate alla sillabazione fossero tutte in un unico font.

Alla luce di questo intervento di Enrico (e dopo averci pensato un po’ su) rettifico in parte la mia posizione.

LaTeX è un programma nato per scrivere in inglese, e usato oggi per scrivere in un numero enorme di lingue.

In generale, una parola scritta in più font è una parola “eccezionale”: va benissimo che, in sede di progettazione generale, si decida di non sillabare queste parole “eccezionali” e di lasciar decidere all’utente caso per caso.

L’italiano, però, è (come tutte) una lingua con le proprie peculiarità: un’espressione come
`l'\emph{enciclopedia}`
non è un’unica parola (anche se LaTeX, di fatto, la vede così), ma sono due parole (l’articolo e il sostantivo) scritte senza spazi in mezzo. Non credo che in inglese esistano situazioni analoghe.

Ecco perché sarebbe il caso che il modulo italiano di babel (e non l’algoritmo generale di [La]TeX) inserisse questa peculiarità, in modo che vengano spezzate a dovere cose come
`l'\emph{enciclopedia}`
`un'\emph{enciclopedia}`
`dell'\emph{enciclopedia}`
ma non altre tipo
`\emph{emo}stasi`

OldClaudioInfatti; dividere in fin di riga una parola evidenziata le fa perdere buona parte dell’evidenza; non può essere che l’autore a decidere se dividere o non dividere una parola evidenziata.

Non sono d’accordo. Se fosse vero, bisognerebbe che nessuna parola evidenziata venisse spezzata da LaTeX, e non solo la prima dopo un apostrofo.

Il “problema” è, ripeto, che LaTeX vede un’espressione come
`un'\emph{enciclopedia}`
come un’unica parola con cambio di font. Il modulo italiano di babel dovrebbe insegnare a LaTeX che quelle sono due parole scritte senza spazi in mezzo.

Ciao,
L.

Ci sto lavorando su; non disperare.

L’unica cosa è che mandare una nuova versione di italian.ldf a Johannes Brams per aggiungere una modifica (ne ho in mente diverse) vuol dire, se va bene, che forse sarà disponibile fra due anni su CTAN. È per questo che circa un anno fa avevo proposto al GuIT di avere una cartella di upload/download di pacchettini anche piccoli o di aggiornamenti anche modesti di file che siano utili solo per gli utenti italiani. Ancora non se ne è fatto niente, ma la discussione è ancora aperta.

OldClaudio” post=67107Ci sto lavorando su; non disperare.

Nessuna disperazione, ci mancherebbe: il difetto (la caratteristica) segnalato dal nostro abile Ivan è davvero una finezza.

OldClaudio” post=67107L’unica cosa è che mandare una nuova versione di italian.ldf a Johannes Brams per aggiungere una modifica (ne ho in mente diverse) vuol dire, se va bene, che forse sarà disponibile fra due anni su CTAN.

Questo è, in linea di principio, davvero un grosso problema. 🙁 Due anni nell’informatica sono come due secoli. Gli aggiornamenti “bug fix” di un software che si rispetti (MacOS, per non far nomi) hanno cadenza settimanale.

OldClaudio” post=67107È per questo che circa un anno fa avevo proposto al GuIT di avere una cartella di upload/download di pacchettini anche piccoli o di aggiornamenti anche modesti di file che siano utili solo per gli utenti italiani. Ancora non se ne è fatto niente, ma la discussione è ancora aperta.

È una toppa, e come tutte le toppe non mi affascina più di tanto. Il problema va risolto a monte, è LaTeX (con i suoi pacchetti) che deve essere sempre aggiornato, in modo (semi)trasparente per l’utente (come MacOS, sempre per non far nomi).

Da quando lo conosco, “LaTeX” ha compiuto grandi passi avanti, in direzione della facilità di installazione, aggiornamento e utilizzo.

C’è ancora molto lavoro da fare.

Ciao,
L.

L’ultima versione aggiornate di italian.ldfsu CTAN porta la data:

2008/03/14 v1.2t Italian support from the babel system

Io fino ad oggi ho usato la versione personale (che però ho inviato a CTAN a più riprese, l’ultima volta l’anno scorso):

2010/01/03 v1.2w Italian support from the babel system

Come sai, oggi ho prodotto la versione:

2011/12/24 v1.2x Italian support from the babel system

che risolve il problema di Ivan a livello di proprietà della lingua.

Ovviamente si tratta comunque di un patch; nel senso che con calma provvederò a staccare il codice e metterlo in un file a parte da inviare a CTAN non nel settore lingue, ma nel settore contributed, perché lo si possa usare anche in catalano, francese e romancio (le uniche lingue di cui ho qualche nozione e che usano l’apostrofo di elisione vocalica).

Ottimo lavoro, Claudio. Come sai, sono restio a mettere roba generale (così importante, poi) nell’albero personale. Il mio sistema diventerebbe non standard, se ci fossero degli errori la patch potrebbe esserne subdolamente responsabile. E poi dovrei ricordarmi ogni volta (a ogni aggiornamento della distribuzione) che sto usando una versione sperimentale, mentre sono sicuro che finirei per dimenticarmene…

Purtroppo devo passare la mano, qui. 🙁

In ogni caso, grazie per il tuo lavoro!

Torno sulla sillabazione con [tt]\emph[/tt] e sulla definizione del comando [tt]\hemph[/tt]:

ivan” post=66977[…]
In questo modo, però, bisogna usare un comando apposito all’occorrenza, quindi ho pensato di trovare una soluzione più generale.
Spulciando tra source2e.pdf sono arrivato a questo:
`\makeatletter
\DeclareRobustCommand\itshape
{\penalty10000\hskip0pt\not@math@alphabet\itshape
\mathit\fontshape\itdefault\selectfont}
\makeatother
`
[…]

C’è qualcosa che non va in quello che ho detto? Si può fare meglio?

Ciao
Ivan

Qualcosa che non va c’è: 🙂
`\documentclass{suftesi}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lipsum}

\makeatletter
% Queste due sono le definizioni in suftesi.cls. Togliendo il commento non compila:
\DeclareRobustCommand\itshape{%
\penalty\@M
% \hskip\z@skip
\not@math@alphabet\itshape\mathit
\fontshape\itdefault\selectfont}
\titleformat{\paragraph}[runin]
{\itshape}
{}
{}
{}
[.\hspace*{1em}]
\makeatother

\begin{document}
\paragraph{Dà errore}
\lipsum[1]
\end{document}`

Digitando `H’, titlesec spiega che il secondo argomento obbligatorio di [tt]\titleformat[/tt] non può contenere materiale orizzontale. Cioè non può esserci quel [tt]\hskip\z@skip[/tt].

Una soluzione sarebbe dare a [tt]\titleformat[/tt] la vecchia definizione di [tt]\itshape[/tt]:
`\titleformat{\paragraph}[runin]
% {\itshape}
{\not@math@alphabet\itshape\mathit
\fontshape\itdefault\selectfont}
{}
{}
{}
[.\hspace*{1em}]`

Ma probabilmente ne esistono di migliori. 🙂

Ciao
Antonio

antonio.macrì” post=69199Ma probabilmente ne esistono di migliori. 🙂

Probabilmente
`\makeatletter
\DeclareRobustCommand\itshape
{\ifhmode\penalty\@M\hskip\z@skip\fi\not@math@alphabet\itshape
\mathit\fontshape\itdefault\selectfont}
\makeatother`
ammesso che si voglia proprio ridefinire \itshape per risolvere un problema inesistente. Una combinazione “apostrofo+parola in corsivo” è certamente una rarità e qui si sta usando un cannone per il moscerino.

Ancora meglio:
`\usepackage{xpatch}
\makeatletter
\xpretocmd{\itshape}{\ifhmode\penalty\@M\hskip\z@skip\fi}
\makeatother`
ma chi non ha una distribuzione aggiornata non ha xpatch.

Nota per Ivan: introdurre una penalità 10000 ogni volta che si passa al corsivo non mi sembra una buona idea. Vero che uno spazio davanti a questa penalità può essere usato per spezzare una riga senza penalità. Non sono sicuro che in situazioni particolari la penalità sia innocua.

Ciao
Enrico

Hai provato con il pacchetto (e la sua documentazione) FiXLtxHyph?
[Su TexLive da un mesetto almeno]

egreg9″ post=69200

Ma probabilmente ne esistono di migliori. 🙂

Probabilmente
`\makeatletter
\DeclareRobustCommand\itshape
{\ifhmode\penalty\@M\hskip\z@skip\fi\not@math@alphabet\itshape
\mathit\fontshape\itdefault\selectfont}
\makeatother`
ammesso che si voglia proprio ridefinire \itshape per risolvere un problema inesistente. Una combinazione “apostrofo+parola in corsivo” è certamente una rarità e qui si sta usando un cannone per il moscerino.

Ancora meglio:
`\usepackage{xpatch}
\makeatletter
\xpretocmd{\itshape}{\ifhmode\penalty\@M\hskip\z@skip\fi}
\makeatother`
ma chi non ha una distribuzione aggiornata non ha xpatch.

Correggimi se sbaglio: [tt]\hskip[/tt] forza il passaggio al modo orizzontale; nel testo normale si è già in modo orizzontale (tranne all’inizio di un capoverso), per cui [tt]\ifhmode[/tt] è vero, mentre i titoli sono composti in modo verticale ([tt]\ifhmode[/tt] falso). Perché titlesec impone che si rimanga in modo verticale (come fa)?

Grazie!

Aggiunta: ho visto che c’è il controllo esplicito:
`#1\ifhmode\ttl@hmode@error\fi`

Ma non mi è chiaro il funzionamento di \titleformat (non mi sembra facile da capire).

OldClaudio” post=69212Hai provato con il pacchetto (e la sua documentazione) FiXLtxHyph?
[Su TexLive da un mesetto almeno]

Il modo di modificare \em che usate è scorretto perché \em è definito con \DeclareRobustCommand (o equivalente). Quindi il comando giusto da modificare non è \em, ma \csname em \endcsname che nel seguito indicherò con \em§ (la § sta per “spazio”).

Vediamo un po’. Voi date
`\let\originalem\em
\let\newem\em
\addto\newem{\hz}`
Se la lingua è fra le quattro dichiarate, succede che passando a una di queste viene eseguito
`\let\em\newem`
La chiamata di \em eseguirà
`\protect\em§\hz`
e, nel caso in cui \em compaia in un \write, nel file verrà scritto
`\em \nobreak\hskip\z@skip`
che, quando il file sarà riletto eseguirà due volte \hz, una dalla nuova espansione di \em e l’altra del codice scritto nel file.

Un comando robusto non va mai modificato con \let. Si rischia molto di andare in un circolo vizioso. Se proprio volete seguire questa strada, usate \LetLtxMacro del pacchetto letltxmacro.

Questa è una versione un pochino più sicura:

`\newcommand\hz{\nobreak\hskip\z@skip}
%%% keep the inner version of \em
\expandafter\let\expandafter\FLH@ori@em\csname em \endcsname
%%% patch it
\let\FLH@new@em\FLH@ori@em
\g@addto@macro\FLH@new@em{\hz}
%%% cycle through the supported language
\def\@tempa{catalan,french,italian,romansh}
\@for\@tempb:=\@tempa\do{
\@ifundefined{captions\@tempb}{}
{
\expandafter\g@addto@macro\csname extras\@tempb\endcsname{\FLH@setnew@em}
\expandafter\g@addto@macro\csname noextras\@tempb\endcsname{\FLH@setori@em}
}
}
%%% helper macros
\def\FLH@setnew@em{\expandafter\let\csname em \endcsname\FLH@new@em}
\def\FLH@setori@em{\expandafter\let\csname em \endcsname\FLH@ori@em}`

Naturalmente vi sarete accorti che il pacchetto non fa quello che deve se fra le lingue chiamate con babel c’è il francese (per i soliti motivi). Quindi è certamente meglio aggiungere in coda
`\AtBeginDocument{\@nameuse{extras\bbl@main@language}}`
in modo da correggere questo “piccolo” difetto. Infatti
`\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[french,italian]{babel}
\usepackage{fixltxhyph}
\begin{document}
\show\em
\end{document}`
produce
`> \em=macro:
->\protect \em .`
mentre, togliendo “french”, si ottiene
`> \em=macro:
->\protect \em \hz .`
come vorreste.

Ciao
Enrico

antonio.macrì” post=69213
Correggimi se sbaglio: [tt]\hskip[/tt] forza il passaggio al modo orizzontale; nel testo normale si è già in modo orizzontale (tranne all’inizio di un capoverso), per cui [tt]\ifhmode[/tt] è vero, mentre i titoli sono composti in modo verticale ([tt]\ifhmode[/tt] falso). Perché titlesec impone che si rimanga in modo verticale (come fa)?

Non è che imponga che si rimanga in modo verticale: semplicemente emette un errore se non lo si è. L’argomento in questione potrebbe contenere comandi di spaziatura o filetti o altro materiale verticale che ovviamente non può essere inserito se si è già in modo orizzontale (forzerebbe una fine capoverso).

Ciao
Enrico

Enrico, in teoria (e in pratica, solo quasi, però) hai ragione, ma a me risulta che nel file aux il comando \emph appia scritto benissimo, così come nel file toc.
D’altra parte l’utente non dovrebbe mi usare la dichiarazione \em ma il comando \emph per i noti motivi.

Però l’esperimento con il francese ([tt]\usepackage[english, romansh,italian,french, catalan]{babel}[/tt]) e l’inserimento di [tt]\show\em[/tt] prima di [tt]\begin{document}[/tt] e dopo il cambio di ciascuna delle altre lingue mi mostra sempre:
`
\show\em
?
> \em=macro:
->\protect \em \hz .
`
Tranne che prima di [tt]\begin{document}[/tt] dove manca [tt]\hz[/tt], ma solo lì.

Il codice potrebbe essere migliorato secondo quanto hai suggerito e lo farò di certo, ma per l’uso comune non vengono espanse macro due volte e non si manifestano inconvenienti di sorta con il francese, per lo meno io non sono riuscito a riprodurre i tuoi esempi.

OldClaudio” post=69243Enrico, in teoria (e in pratica, solo quasi, però) hai ragione, ma a me risulta che nel file aux il comando \emph appia scritto benissimo, così come nel file toc.
D’altra parte l’utente non dovrebbe mi usare la dichiarazione \em ma il comando \emph per i noti motivi.

Però l’esperimento con il francese ([tt]\usepackage[english, romansh,italian,french, catalan]{babel}[/tt]) e l’inserimento di [tt]\show\em[/tt] prima di [tt]\begin{document}[/tt] e dopo il cambio di ciascuna delle altre lingue mi mostra sempre:
`
\show\em
?
> \em=macro:
->\protect \em \hz .
`
Tranne che prima di [tt]\begin{document}[/tt] dove manca [tt]\hz[/tt], ma solo lì.

Il codice potrebbe essere migliorato secondo quanto hai suggerito e lo farò di certo, ma per l’uso comune non vengono espanse macro due volte e non si manifestano inconvenienti di sorta con il francese, per lo meno io non sono riuscito a riprodurre i tuoi esempi.

A parte “romansh” che non ho, confermo che, quando c’è il francese fra le lingue caricate, \hz non c’è (con \show\em subito dopo \begin{document}). C’è dopo un comando \selectlanguage{italian}.

La scusa che \em non va usato non regge. 🙂 Il rischio del circolo vizioso rimane.

Ti allego la versione LaTeX3:
`\RequirePackage{expl3}
\ExplSyntaxOn
\cs_new_protected:Npn \hz { \nobreak \hskip \c_zero_skip }
\cs_set_eq:Nc \flh_ori_em: { em ~ }
\tl_set:No \l_tmpa_tl { \flh_ori_em: }
\tl_put_right:Nn \l_tmpa_tl { \hz }
\exp_args:NNV \cs_set:Npn \flh_new_em: { \l_tmpa_tl }
\clist_map_inline:nn { catalan , french , italian , romansh }
{
\cs_if_exist:cT { captions #1 }
{
\tl_put_right:cn { extras #1 } { \flh_set_new_em: }
\tl_put_right:cn { noextras #1 } { \flh_set_ori_em: }
}
}
\cs_new:Npn \flh_set_new_em: { \cs_set_eq:cN { em ~ } \flh_new_em: }
\cs_new:Npn \flh_set_ori_em: { \cs_set_eq:cN { em ~ } \flh_ori_em: }
\ExplSyntaxOff`
Le idee sono esattamente le stesse. La cosa più interessante, secondo me, è il ciclo che è molto più leggibile: la funzione \clist_map_inline:nn esegue un ciclo su ogni elemento della lista data come primo argomento e l’elemento viene messo a disposizione del codice da eseguire nel secondo argomento come #1. Niente \@tempa da espandere (non nel vostro caso, perché la usate dentro \csname, ma in altre occasioni è necessario). \cs_if_exist:nT è come \@ifundefined, ma si può dare solo l’argomento del caso “vero”; esistono naturalmente anche \cs_if_exist:cTF e \cs_if_exist:cF.

Come si vede, gli spazi sono del tutto ignorati e aumentano la leggibilità del codice. Per darne uno reale si usa ~.

Anche \exp_args:NNV è interessante. NN indica che si devono saltare i due comandi successivi e la V dice che al terzo posto ci deve essere, tra graffe, una variabile (nel caso \l_tmpa_tl) di cui si usa il valore (per una variabile token list è la sua espansione di primo livello). L’analogo tradizionale

`\expandafter\let\expandafter\flh@new@em\expandafter{\@tempa}`

è molto meno leggibile.

Ciao
Enrico

Grazie mille del codice latex3; vedrò di modificare il pacchetto con questo codice.

Ciao
Claudio

Ho preferito usare etoolbox e i suoi comandi; il codice ora credo che senza un solo expandafter sia molto più leggibile.

Ma, qui ci vuole un grazie speciale di origine serendipica per Enrico: con le sue osservazioni mi ha costretto a rimeditare ogni piccolo dettaglio di quel che avevo fatto:i \addto (come per altro anche g@addto@macro, se non sbaglio) aggiungono il comando in coda al testo sostitutivo, non all’inizio, quindi la definizione che avevo fatto forse funzionava per miracolo o per errori che si compensavano, ma conteneva un errore logico.

Ora impacchetto il tutto ed eseguo l’upload su CTAN, questa volta il comando robusto \em non è stato minimamente toccato ma è stato toccato il comando con lo spazio in coda al suo nome.

Grazie di cuore, Enrico.

OldClaudio” post=69265Ho preferito usare etoolbox e i suoi comandi; il codice ora credo che senza un solo expandafter sia molto più leggibile.

Ma, qui ci vuole un grazie speciale di origine serendipica per Enrico: con le sue osservazioni mi ha costretto a rimeditare ogni piccolo dettaglio di quel che avevo fatto:i \addto (come per altro anche g@addto@macro, se non sbaglio) aggiungono il comando in coda al testo sostitutivo, non all’inizio, quindi la definizione che avevo fatto forse funzionava per miracolo o per errori che si compensavano, ma conteneva un errore logico.

Ora impacchetto il tutto ed eseguo l’upload su CTAN, questa volta il comando robusto \em non è stato minimamente toccato ma è stato toccato il comando con lo spazio in coda al suo nome.

Grazie di cuore, Enrico.

Prima o dopo cambia poco: la parte “em originale” che rimane è tutta di assegnazioni e non ha alcuna influenza sulla composizione del capoverso, per quanto riguarda spazi e penalità. A te interessa che fra la “elle apostrofo” e la parola seguente ci sia \nobreak\hspace{0pt}. Che sia prima o dopo il cambiamento di font non ha alcuna importanza.

Ciao
Enrico

Evidentemente le mie rotelline sono consunte; è vero, non era un miracolo, era normale.

Fa bene di tanto in tanto che qualcuno ci faccia rendere conto che le rotelline sono consunte.

Grazie
Claudio