In effetti è troppo spaziato. Però credo che sia inevitabile in quel caso. Il motivo di tutti quegli spazi è che “lorenzopantieri” non può essere spezzato e l’unico punto di sillabazione è il punto dopo “www”. Non saprei proprio come fare a migliorare la resa. Il pacchetto url ha diverse opzioni, proverò.
Mettere l’indirizzo su una nuova riga non mi convince; spezzerebbe troppo la voce bibliografica. E poi potrebbe risolvere solo parzialmente il problema. E poi ne sorgerebbero altri: virgola e poi a capo? Senza virgola prima dell’indirizzo? Dopo l’indirizzo, a capo o no?
Enrico, aiuto 😳 😥 🙄Giusto, inziare l’URL in una riga nuova spezzarebbe la voce, e poi non risolverebbe il problema (e ne creerebbe di nuovi).
Resta il fatto che quel risultato è inaccettbile…
Allora farei così, scriviamo pure l’URL di seguito alla altre info e cerchiamo di giustificarlo, quando possibile. Ma se il risultato è proprio inaccettable, con spaziature abnormi fra le lettere dell’URL o fra le parole scritte prima dell’URL, si rinunci alla giustificazione.
Non ho idea di come farlo, mi accodo alla tua richiesta di aiuto a Enrico.
Proverò la nuova versione appena possibile (anche se in questi giorni posso passare pochissimo tempo al computer!).
Ancora qualche osservazione
1. Scrivi “Citato alle pp. 1-2”, ma quell’espressione “pp.” è davvero brutta e burocratica, per il plurale. Scrivere per intero “Citato a pagina 1” e “Citato alle pagine 1,2”.
2. Manca un’opzione “squaren” come in natbib, per avere riferimenti fra parentesi quadre “vedi [Pantieri, 2009]”. Se scrivo
`\renewcommand{\bibleftparen}{[}
\renewcommand{\bibrightparen}{]}`
le parentesi quadre vengono anche nei riferimenti finali, “[Citato a pagina…]” e questo non va bene.L’opzione”multiautfull=true” la metterei di default: se scrivo un record con un numero di autori > 2 mi aspetto che tutti questi autori compaiano nella bibliografia, mentre nelle citazioni basta ovviamente il primo nome seguito da “et al”. Avere l’elenco degli autori amputato può essere sgradevole: magari lascia un’opzione per un utente che volesse quel comportamento.
Grazie mille per il tuo eccellente lavoro, Ivan.
Ciao,
L.
In attesa di consigli sul caso “URL” vediamo le altre questioni.
1) “pp.” è gestita dalla stringa pages. Per una questione di uniformità, se si usa “pp.” nel documento si deve usare “pp.” anche nei riferimenti. Per modificare questo comportamento è sufficiente scrivere:
`\DefineBibliographyStrings{italian}{%
page=pagine,
pages=pagine}`
Però, naturalmente, verrà scritto “pagine” al posto di “pp.” in ogni parte del documento che richiama la stringa pages. Per cambiare tale comportamento solo nei backref bisognerebbe apportare un’ulteriore modifica alla macro pageref, creando un’ulteriore stringa (anzi due) per queto caso. Come sai c’è già il problema delle nuove stringhe backref e backrefs che devono essere definite se si compone in lingue diverse dall’italiano, quindi creare due nuove stringhe (una per “pagina” e una per “pagine”) che valgano localmente all’interno dei backref mi sembra eccessivo. La faccenda è spiegata, in maniera forse un po’ sintetica, anche nella doc.
Se a qualcuno vengono in mente altre soluzioni più soft, ben venga.
2) Interessante rilievo. Le parentesi che racciudono “(citato a p. )” sono gestite dal comando \mkbibparens, che è composto dai comandi \bibleftparen e \bibrightparen, ridefinendo i quali viene modificato anche \mkbibparens. Di conseguenza se si ridefiniscono questi comandi si avranno le parentesi, diciamo quadre, al posto delle parentesi tonde, quindi non solo nei backref, ma anche in [a cura di], [ed. orig. 1632] ecc. Per il caso di (a cura di) ho appena rimediato. Prima era definito come \mkbibparens{a cura di} ora semplicemente: (a cura di), quindi adesso è indifferente alla ridefinizione di \bibleftparen (\bibrightparen). Per il caso [ed. orig. 1632] forse è meglio che sia uniforme alle citazioni, ma non saprei dire. Anche in questo caso posso rimediare nel codice.
Ti chiedo un parere su due (tre) soluzioni possibili, di cui la prima è già disponibile mentre la seconda (e la terza) dovrei prima implementarla.
Soluzione 1 Se si ridefiniscono i comandi \bibleftparen e \bibrightparen, qualora si volessero le parentesi tende nei backref, bisognerebbe aggiungere anche:
`\DeclareFieldFormat{backrefparens}{(#1)}
`
Soluzione 2: Potrei definire un nuovo comando con: `\renewcommand{\backrefparens}[1]{(#1)}`
per il formato dei backref in modo che le parentesi nei backref siano tonde di default. In questo modo, se qualcuno non volesse le parentesi tonde dovrebbe scrivere:
`\renewcommand{\backrefparens}[1]{#1}`
Aggiornerò la documentazione quando avrò scelto la soluzione migliore.
Soluzione 3 ridefinire i comandi tipo \parencite rendendo disponibile una versione con parentesi quadre, magari aggiungendo un’opzione. Questo è un grosso problema perché volevo mantenere gli stili indipendenti dallo schema di citazione. Ora caricano di default lo stile authoryear-comp, ma si può usare qualsiasi stile di citazione, compatibile s’intende. Il problema è questo.
I comandi \parencite sono definiti diversamente negli stili authoryear e authoryear-comp. È semplice ridefinirli in modo da ottenere le parentesi quadre, ma questo andrebbe fatto nei file .cbx, che non si limiterebbero più a richiamare uno stile standard ma sarebbero stili a se stanti.
Quindi dal punto di vista della versatilità sarebbe meglio evitare di ridefinire i comandi \parencite direttamente nei codice.
Le soluzioni 1 e 2 sono più contorte ma danno molto molto meno problemi. D’altra parte, se si decidesse definitivamente lo stile di citazione allora la soluzione 3 è la più elegante. Ricordo che è disponibile anche lo stile di citazione authoryear-icomp-tt che combina gli stili authoryear-comp e authoryear.ibid. Io sarei per usare quest’ultimo di default ma mi piacerebbe lasciare all’utente la scelta.
Metterò l’opzione multiautfull=true di default. Anzi, lo faccio subito altrimenti mi dimentico 🙂 . Prima di aggiornare la versione in rete aspetto di risolvere questi problemi.
Un’ultima cosa: componendo una bibliografia lunga incontri i problemi che ha descritto Pierfranco nel post precedente o il risultato è corretto?
Ciao
Ivan