SugarscapeJS - Agenti artificiali per società artificiali

Sugarscape è un modello multiagente di simulazione di società artificiali (per un dato valore di società), reso famoso dal libro Growing artificial societies: social science from the bottom up, scritto da Joshua M. Epstein e Robert Axtell nel 1996. Da allora, ha dato origine a una discreta quantità di programmi che emulavano, in forma più o meno completa, il progetto delineato in quello studio, e ancora continua a produrne.
SugarscapeJS, come il nome stesso dovrebbe suggerire, è una sua versione in JavaScript, realizzata da me, in cui cerco di inserire, a mano a mano che procedo col lavoro, il maggior numero possibile degli elementi proposti nello studio originale. Al momento ho incorporato quasi tutte le regole contenute nei capitoli due, tre e nella prima metà del quattro: mancano i prestiti, ossia la seconda metà del quarto capitolo, e le malattie, che occupano il capitolo cinque. Arriveranno anche loro.
Per chi non conosce il testo di riferimento, una breve presentazione della struttura di Sugarscape, che è distinto in tre componenti di base: gli agenti, l’ambiente in cui interagiscono tra loro e le regole in base alle quali interagiscono tra loro e con l’ambiente stesso.
Gli agenti sono gli abitanti della società artificiale. Di fatto, sono quadratini colorati che si muovono sullo schermo, ma voi potete immaginarli più o meno come preferite. Possiedono alcune proprietà, come età, sesso, durata massima della vita, campo visivo, metabolismo e così via: molte di queste proprietà possono essere regolate prima di avviare la simulazione, altre sono assegnate in modo pseudocasuale al momento della nascita. Hanno anche la capacità di muoversi nell’ambiente e interagire con altri agenti, ma di questo parlerò poi.
L’ambiente è una griglia di 50 x 50 caselle, su cui gli agenti vivono e si muovono. Una scacchiera, insomma. Ogni casella può ospitare un solo agente alla volta e possiede una quantità determinata di risorse, rinnovabili col tempo. L’ambiente può presentare una distribuzione delle risorse molto diversa, ma qui ho scelto, per il momento, la struttura più famosa e più spesso associata con Sugarscape, con le risorse concentrate in due “picchi” (o quattro, se si sceglie di usare una seconda risorsa). Le risorse sono zucchero (di base) e spezia (opzionale).
Le regole sono un insieme di comandi che determinano il modo in cui gli agenti si comportano. La regola di base per il movimento, ad esempio, prevede che ogni agente cerchi, all’interno del proprio campo visivo, la più vicina casella libera che contiene la maggiore quantità di risorse, che si muova per occupare quella casella e raccolga tutto il contenuto. Vi sono poi regole che determinano il modo in cui le risorse ricresceranno, il modo in cui l’agente interagisce con altri agenti, sia per la riproduzione, sia per il combattimento, sia anche per la “conversione” di chi appartiene a una cultura diversa, e altre regole ancora arriveranno, per commerciare e determinare come avvenga la trasmissione di malattie all’interno di Sugarscape: in molti casi, è possibile decidere quali regole applicare e quali ignorare, così da simulare ciò che vogliamo e osservare solo i risultati che ci interessano.
Sulla base di questi tre componenti, Sugarscape si ripropone di provare a costruire le dinamiche di una società “dal basso”, ossia impostando solo semplici regole generali e osservando poi il modo in cui si svolge l’interazione tra agenti e territorio, seguendo le suddette regole. Interazione che spesso è interessante, in effetti, e forse anche istruttiva, ma su questo punto non mi pronuncio. A ogni modo, vediamo le regole disponibili finora.
Ogni agente può vedere fino a una certa distanza, stabilita casualmente alla nascita, e ha bisogno di consumare a ogni turno una certa quantità di zucchero (e spezia, se usiamo due risorse) per mantenersi vivo: primo obiettivo è dunque la ricerca di zone con tanto zucchero, da raccogliere e consumare. E già questo produce un notevole effetto-formicaio nella simulazione, oltre a introdurre una selezione naturale che porta alla rapida estinzione di chi ha campo visivo scarso e metabolismo elevato. Se gli agenti morti non sono sostituiti, si arriva presto a uno stallo, che ci dice quale sia la capacità di portata per quell’ambiente.
Introducendo le stagioni, modifichiamo il modo in cui lo zucchero (e la spezia, ma ormai dovreste aver capito l’andazzo) è rigenerato nell’ambiente: se prima era uniforme su tutto il territorio, adesso l’ambiente è diviso in due zone, nord e sud, e in quelle due zone si alternano ogni X turni estate (rigenerazione massima delle risorse) e inverno (rigenerazione minima delle risorse). Gli agenti cominceranno a migrare in massa al cambiamento delle stagioni.
Già sulla base di questo, possiamo osservare come si distribuiscano le ricchezze tra gli agenti, ossia la quantità di zucchero posseduta da ognuno. O almeno, potremmo vederlo: in realtà, per adesso ho solo un grafico con l’indice Gini, ma in futuro introdurrò anche tabelle che mostrino in modo meno tecnico e più comprensibile la tendenza generale a una disparità sociale piuttosto accentuata.
Una vera interazione tra agenti compare solo col capitolo tre del libro. Per prima cosa, si può introdurre la riproduzione sessuale, come alternativa alla rigenerazione causale a ogni decesso: ogni agente in età fertile, e con un quantitativo minimo di risorse, a ogni turno cercherà tra i propri vicini un potenziale partner, che sia di sesso opposto, di età fertile, che abbia risorse e che non sia suo parente stretto (tecnicamente, Sugarscape non vieta l’incesto, nella sua formulazione originaria, ma io ho voluto introdurre questo limite, per renderlo più realistico e “umano”, così come il limite di una sola riproduzione per turno). Questa regola da sola cambia gli equilibri ambientali, portando a una continua oscillazione nel numero di agenti supportati. Possiamo poi introdurre anche l’eredità, ossia la possibilità che i figli ottengano una parte uguale delle risorse dei genitori, alla morte di questi: principale effetto sarà una tendenza ad accentuare le disparità sociali.
Dopo l’eredità, arriva l’ereditarietà. Qualche centinaio di turni ci mostra come, anche senza averla espressamente introdotta, la selezione naturale porta ad avere agenti con visione sempre migliore e un metabolismo che rapidamente crolla al minimo. Una tendenza che avevamo già visto anche in assenza di riproduzione, ma che va alle stelle quando la riproduzione è presente. Curiosamente, però, l’aumento della visione non è costante e di tanto in tanto si può invertire.
Ma una società non è solo sesso, nonostante YouPorn dimostri il contrario. Assieme alla possibilità di riproduzione sessuale, esistono anche due “culture” di base, indicate col colore rosso e blu. Sono di fatto una lista di numeri binari, la cui lunghezza è regolabile a piacimento, ma è meglio che sia sempre dispari: se prevalgono gli 1, il nostro agente apparterrà a una cultura; se prevalgono gli 0, apparterrà all’altra. Le culture non sono stabili e possono cambiare nel corso della simulazione, a seconda del modo in cui gli agenti interagiscono tra loro: le culture si intrecciano al momento della nascita di nuovi agenti, ma anche solo muoversi all’interno di Sugarscape porta gli agenti in contatti con altri agenti, in un continuo influenzarsi a vicenda. Se così vogliamo.
Dalla cultura alla guerra. Un’altra regola opzionale ci permette di decidere che le due culture non coesistano pacificamente in Sugarscape: se così vogliamo, rossi e blu cercheranno di sopraffarsi a vicenda, fino a che ne resterà uno solo, oppure fino a che non si raggiungerà un equilibrio da guerra fredda, con le due culture rinchiuse nelle proprie zone di influenza e in continuo contrasto lungo i confini.
Col capitolo quattro arriva una seconda risorse, che affianca lo zucchero: è la spezia. Grazie alla presenza di due risorse, gli agenti possono adesso commerciare, scambiando il surplus per ottenere i beni di cui hanno maggiore scarsità. In teoria. In pratica, il raddoppiamento delle risorse comporta anche un raddoppiamento delle possibilità di morire e spesso la nostra simulazione si chiuderà con l’estinzione totale degli agenti: quando non succede, però, otteniamo un passabile commercio.
Gli agenti, poi, sono divisi tra due categorie di commercianti: aggressivi e cauti. Un agente cauto scambia solo il proprio surplus, solo nella misura minima e punta a un profitto modesto, ma costante: tipica formica, per intenderci. Un agente aggressivo, invece, si butta negli scambi anche a rischio di perderci, non si ritira mai da una offerta e punta sempre al colpaccio. A volte gli riesce.
I prestiti tra gli agenti costituiscono la seconda parte del capitolo quattro, ma non li ho ancora implementati, proprio come non ho ancora implementato il capitolo cinque, dedicato a malattie e sistemi immunitari. Altra cosa che manca, presente nel capitolo due, è la produzione di inquinamento, che al momento ho escluso in quanto la formulazione data dal libro non è molto interessante e non aggiunge granché alla simulazione. Magari la riesumerò in futuro.
In breve, questo è SugarscapeJS. La velocità della simulazione varia molto a seconda del browser utilizzato, ma dovrebbe comunque funzionare su ogni browser decentemente moderno, anche se non è ottimizzato per dispositivi con schermi piccoli. Raccolta e produzione di dati e grafici avrà bisogno ancora di molto lavoro, ma la simulazione è già utilizzabile e fornisce alcuni risultati. Se si è di bocca buona, almeno.

Prova SugarscapeJS

Modificare ebook con Calibre

Calibre è un programma gratuito e libero, già famoso come strumento per la conversione e in generale la gestione degli ebook, tanto da essere stato etichettato in più occasioni come lo iTunes degli ebook. Che questo sia da intendersi come un complimento o un insulto è aperto alla vostre interpretazioni e mi asterrò dal proporvi la mia, che propende per al seconda.
Etichette a parte, Calibre è usato soprattutto per convertire un ebook da un formato all’altro, nonché per fungere da biblioteca virtuale e, se si vuole, anche per trasferire testi dal computer a un qualsiasi lettore esterno, e viceversa. Le sue funzioni, però, non si esauriscono qui. Tra quelle introdotte più di recente (anche se quanto di recente dipende dall’ultima volta che lo avete aggiornato: non è che sia proprio una novità dell’ultima ora, ecco) vi è la possibilità di modificare ebook. Alcuni formati di ebook. E per “modificare” non intendo solo convertirli, ma proprio editarne il contenuto, come si può fare con un qualsiasi documento all’interno di un elaboratore di testi come Word o Writer.
La modifica di ebook all’interno di Calibre è disponibile soltanto per due formati, che sono poi anche quelli che ha più senso modificare con questo programma: EPUB e AZW3. Il primo formato dovrebbe essere noto a tutti ed è quello utilizzato dalla maggior parte dei dispositivi di lettura che non siano il Kindle. Il formato AZW3, invece, potrebbe suonare più esotico a molti, ma di fatto è una versione riveduta e corretta del MOBI, ossia il formato base per il suddetto Kindle.
La nuova funzione di modifica la trovate facilmente nella barra degli strumenti di Calibre ed è la penultima voce in fondo a destra:

Selezionate lo ebook da modificare, cliccate sulla icona e si aprirà la finestra di modifica:

Come potete vedere, non è poi molto diversa da quella di Sigil o da quella di un qualsiasi altro elaboratore id testi ridotto all’osso o quasi. Non aspettatevi funzioni speciali o particolari, dunque: è uno strumento che vi permette di modificare il codice di uno ebook, ma senza campanelli e lucine colorate. Almeno per adesso, poi in futuro si vedrà.
Non so quanti di voi lo vorranno usare per modificare un file EPUB, dato che Sigil permette già di fare la stessa cosa e in modo più completo (ebbene sì, è ancora più spartano ed essenziale di Sigil, che lo crediate oppure no), ma può essere utile per modifiche rapide e immediate, senza bisogno di uscire dal programma che state utilizzando. Ammesso che il programma che state utilizzando sia Calibre, ovviamente. Molto più interessante, invece, è la possibilità di modificare ebook per il Kindle.
Come ho detto, il secondo formato che potete modificare utilizzando questo strumento è lo AZW3. Il formato AZW3, anche se non proprio del tutto, è quasi completamente identico al MOBI. Da un certo punto di vista. Da un altro punto di vista è un MOBI arricchito, per permette di andare al di là di una grafica in bianco e nero e striminzita, che è la sola grafica concessa dal MOBI. Funziona col Kindle e la conversione dal MOBI è quasi indolore: molto spesso non si nota neppure la differenza, almeno sul piano grafico.
Cosa significa tutto questo? Significa che, se volete modificare uno ebook in formato MOBI, lo potete convertire prima in AZW3 e poi modificare all’interno di Calibre. Il che è più o meno come convertirlo in EPUB e poi modificarlo, d’accordo, ma la distanza tra i due formati è minore e molto probabilmente non avrete bisogno di una seconda conversione a lavori ultimati, per poter leggere il risultato sul vostro Kindle, dato che il Kindle apre senza problemi il formato AZW3. A meno che il vostro Kindle non sia alquanto datato, nel qual caso potrebbero anche esserci problemi.

Scantanador, un roguelike "in fieri"

Cliccate qui per provare Scantanador 0.0.1 Alpha.
Scantanador è il nome di un roguelike programmato da me, in JavaScript, e basato sulla libreria ROT.JS, libreria JavaScript (che sorpresa!) che contiene diverse funzioni per semplificare la vita a chi, per una qualunque forma di pazzia, decida di programmare un nuovo roguelike. Come potete immaginare, io sono tra questi pazzi.
I comandi sono semplici e sono più o meno i classici di un roguelike. Voi siete la @ al centro dello schermo, vi muovete coi tasti freccia, il tastierino numerico o clicando/toccando il quadrante dello schermo corrispondente alla direzione. Premendo [Invio], o cliccando/toccando l'icona @, potete aprire un menu, con le azioni principali. Il tasto [?] vi mostrerà una lista di tasti, coi comandi corrispondenti.
Al momento, Scantanador è poco più di uno scheletro, ancora in ampia fase di lavorazione e con ponteggi e impalcature sparsi più o meno ovunque. Se il mio obiettivo fosse stato quello di creare un 7DRL, ossia un roguelike programmato in sette giorni, il lavoro sarebbe ormai molto vicino alla conclusione: basterebbe annodare un paio di fili, infilarci un mostro finale, magari due o tre oggetti in più e stop, il gioco è fatto. In tutti i sensi. Siccome però, nella mia pazzia o incoscienza, progetto di realizzare qualcosa di molto più ampio, la conclusione è rinviata a un futuro più o meno lontano, ma che prima o poi arriverà. Almeno, è quanto spero.
Il modello a cui più mi sono ispirato, nella progettazione, è stato ToME, storico roguelike degli anni ‘90 e oltre, nonché uno dei pilastri del genere. Per essere precisi, il mio modello è stato la vecchia versione di ToME, ossia quella che ancora si chiamava Troubles of Middle Earth e che ha chiuso i battenti con la versione 2.3.5, per rinascere poi sotto altro nome, ma identica sigla. Perché una versione così vecchia? Perché è la versione che ho giocato e amato di più, e che mi ha fatto perdere piacevolmente una montagna di ore, ai tempi dell’università: il gioco più recente è senza dubbio migliorato e più ampio, ma alla nostalgia non si comanda. E poi tutti i gusti sono guasti, no?
Nella versione definitiva, quando arriverà, Scantanador presenterà più dungeon, collegati tra loro da un mondo di superficie, oppure un solo, lunghissimo dungeon: ancora non ho deciso, ma il tempo per scegliere non mi manca, con tutto il lavoro ancora in corso. Per il momento, questa versione di prova, versione alpha che più alpha non si può, presenta un solo dungeon, di dieci livelli, e senza mostro finale. Insoddisfacente? Certo, ma è anche una versione di base, che serve a me più che altro come palestra in cui provare le funzionalità che vado via via aggiungendo: potete considerarlo una demo, in altri termini, almeno per il momento.
Trattandosi di un roguelike in JavaScript, è quindi destinato a essere utilizzato soprattutto in un browser e da dispositivi di ogni tipo e dimensione, finora mi sono concentrato principalmente sul supporto vari tipi di input: in pratica, può essere giocato utilizzando la tastiera, nella migliore tradizione dei roguelike, ma può anche essere giocato utilizzando il mouse, oppure le ditate sullo schermo. In teoria. In pratica l’ho potuto collaudare soltanto su un ristretto numero di dispositivi, per adesso, per cui ogni segnalazione di malfunzionamento sarà gradita.
Altro aspetto su cui ho lavorato molto, aspirando a un gioco di lunga durata, è il salvataggio delle partite. Il salvataggio utilizza il localStorage, per cui la partita è salvata all’interno del browser che state utilizzando: se riaprite il gioco con lo stesso browser, dovreste pote ripartire dal punto in cui avevate salvato. A meno che non siate morti dopo il salvataggio, ovviamente: come ogni roguelike che si rispetti, Scantanador abbraccia la filosofia del permadeath, ossia “si muore una volta soltanto”. Quando il vostro personaggio muore, i salvataggi sono cancellati. Punto. Ovviamente, utilizzando il localStorage voi potete imbrogliare quanto volete, se avete una minima conoscenza del JavaScript, perché i dati del salvataggio sono nelle vostre mani, facilmente accessibili.
Riassumendo, vediamo di elencare in breve ciò che è già presente in questa prima versione del gioco, (chiamiamola Scantanador 0.0.1) e ciò che sarà introdotto più avanti.
Già sviluppato:
-supporto per tastiera, mouse, touch;
-salvataggio e caricamento delle partite;
-combattimento corpo a corpo, più alcune armi;
-alcune armature, utilizzabili da player e mostri;
-combattimento a distanza (semplificato), più alcune armi;
-pozioni con effetti immediati o prolungati (alcune);
-oggetti con poteri speciali (alcuni);
-player e mostri possono raccogliere, gettare e utilizzare (alcuni) oggetti;
-mostri con poteri speciali (alcuni);
-meccanismo di combattimento riadattato dal d20 system.
Da sviluppare:
-migliorare il combattimento a distanza;
-nuovi mostri, nuovi oggetti, nuovi poteri;
-mostri più intelligenti (o meno stupidi);
-esperienza e passaggio di livello;
-classi per il player;
-abilità speciali per player e mostri;
-nuovi dungeon/ampliamento dungeon;
-mostro finale;
-magia;
-trappole;
-oggetti da identificare;
-correggere singolari/plurali;
-PNG?
E molto altro, al primo posto la correzione di tutti gli errori che troverò strada facendo. In pratica, come dicevo all’inizio, per adesso ho posto le basi: il resto consiste nell’edificare sopra queste basi. Sperando che reggano.
Ah, la grafica è ovviamente in ASCII: sono tradizionalista, ma soprattutto possiedo le capacità artistiche di un merluzzo. Inserire immagini e trasformarlo in un gioco contemporaneo non sarebbe difficile; realizzare immagini decenti lo è, almeno per me. Che poi in realtà non è proprio definibile come ASCII; dato che utilizzo caratteri Unicode, ma non importa.

Scantanador - A roguelike "in fieri"

Click here to try Scantanador 0.0.1 Alpha.
Scantanador is the name of a roguelike in JavaScript, which I’m programming. It utilizes the library ROT.JS, which is a very nice tool to help a poor, distressed programmer, who is working on a roguelike: its author seems to have a difficult relationship with semicolon and suchlike, but that’s another matter. It’s a good library, if you are crazy enough to program a roguelike. I am.
Command keys are quite easy and are, more or less, those you find in any roguelike. You are the @ in the centre of the screen and you can walk around by using arrow keys, numpad, or clicking/tapping the portion of the screen corresponding to a given direction. Pressing [Enter], or clicking/tapping on the @ icon, you can access to the menu, which lists all the main commands. The ? key will show you a list of all the keys used in the game.
Right now, Scantanador is little more than a skeleton, a bare-bone structure on which I am still working and a lot of work is still needed. A lot. If I were aiming for a 7DRL, which is to say a roguelike wrote and concluded within 7 days, I would be almost there: add a little more stuff, a final boss, maybe another pair of objects and the game would be ready. But not. Since I am crazy enough to think about a bigger game (way bigger), I still have a long way to go, before having a game which, somehow, can be seen as completed. Some day I’ll get there, for sure. Or, at least, I hope.
My model is ToME, mainly, which is a historical roguelike from ‘90s, but still alive and kicking. More or less. In truth, the version I’m using as an inspiration is not exactly alive and kicking, being the old 2.3.5 version, which was still called “Troubles of Middle Earth”, before kicking the bucket and being reborn with a different name and quite a different world. Why am I looking and the old version, if there is a new one, which is richer and probably better in every aspect? Because ToME 2.3.5 (and all the previous versions) is the one I played and loved the most, the game on which I wasted away many and many hours, when I was in college. It’s nostalgia, pure and simple, and I know it, but... it’s a matter of tastes, right? And all tastes are a waste, in the end. More or less. Let’s say so, okay?
Ina distant day, Scantanador will posses many dungeons, all connected by a wilderness or maybe just one dungeon, but extremely deep: I’ m not sure, yet, but I still have plenty of time, to make up my mind about it. There is still an awful lot of work, for me. Anyway, this demo version (which is really an Alpha release, but very alpha) has only one dungeon, with 10 levels, and without a final boss. Not satisfying? I know, I know, but it’s a first release, which manly serves to me as a playground, where I can test new stuff and see if everything works correctly, any time I add some new object, monster or power. It’s just a demo, as I said.
Being a JavaScript game, it should work on a very wide range of browsers and devices, and work fine everywhere. Or at least fine enough. This is the reason why I concentrated on supporting many kind of input: you can play it with your keyboard, with a mouse, tapping on a touchscreen and so on. Or, at least, you should be able to: I could only test it on a limited number of devices and browsers, so I’m not sure that it will really work everywhere. If you find something wrong, just tell me and I’ll fix it.
Given that I’m trying to program a game, which could last many hours, I also spent quite some time on the save and load process. The game is saved inside the browser you’re using to play it, in its localStorage object: if you open Scantanador with the same browser, you should be able to restart a previously saved game. Unless you died after the last save, of course: as a true roguelike, at least in spirit, Scantanador follows the philosophy of permadeath, which is to say “you can only die once”. Once you die, your character and all the saved game are deleted. That’s all. Of course, since it utilizes the localStorage, you can cheat the living shit out of a saved game, if you really want and if you have a minimal working knowledge of JavaScript: all the data are in you browser and very easy to access.
In short, let’s see what has already been implemented in Scantanador (version 0.0.1) and what is still waiting in line.
Already here:
-keyboard, mouse, touch support;
-saving and loading of a game;
-melee fight, plus some weapons;
-some armours, which can be equipped by player and monsters;
-ranged fights (simplified), plus some ranged weapons;
-potions with immediate and prolonged effects (some);
-items with special powers (some);
-player and monsters can pick up, drop and use (some) items;
-monsters with special powers (some);
-slightly changed d20 system rules;
Still waiting:
-improving the ranged fight;
-new monsters, items, powers;
-smarter monsters (or at least less stupid);
-experience points and level-ups;
-classes for the player;
-special abilities for player and monsters;
-new dungeons/bigger dungeon;
-last boss;
-magic system;
-traps;
-unidentified items;
-fix singular/plural;
-NPC?
And much more, starting from all the bugs I will surely have to squash. Put another way, as I said at the very beginning, I only put the basis for a game: now I must build over it, hoping that everything will be solid enough to hold.
Ah, graphics are obviously in ASCII: I’m quite the traditionalist, but I am also as artistic as a cod. It would be easy to add graphical tiles to the game and turn it into something more modern, but it’s not easy to make decent graphical tiles, at least for me. And, by the way, it’s not really ASCII, since I’m using Unicode characters, but never mind.

Sigil 0.8.0, cosa cambia

Sigil, il programma per creare e modificare e-book in formato EPUB, è ancora vivo e, dopo quasi un anno di silenzio, finalmente ne abbiamo una nuova versione, la 0.8.0, per l’appunto. Non che ci siano stati grandi cambiamenti, almeno in superficie, ed è probabile che grandi cambiamenti non ci saranno neppure in un futuro prossimo, dato il ritmo con cui il suo sviluppo procede: al momento, Sigil è un programma sviluppato e mantenuto, di fatto, da una sola persona, il che non offre grandi prospettive di aggiornamenti rapidi. Ma vediamo cosa sia cambiato.

Prima di tutto, è cambiato il sito da cui poter scaricare gratuitamente Sigil. Le nuove versioni, per Windows, GNU-Linux e Macintosh, sono scaricabili da GitHub, ossia da questa pagina, invece che dal vecchio sito di Google Code. Non proprio un cambiamento radicale, ma la scelta della versione giusta potrebbe risultare meno chiara del passato, considerata la discutibile grafica della pagina. Leggete con cura il testo biancastro, sullo sfondo verde dei pulsanti, e dovreste poter reperire la versione che vi serve. Dopo aver visto come procurarci il programma, passiamo alle novità nel suo funzionamento. Che di fatto è una sola.

Lasciano da parte le correzioni di alcuni errori, presenti nella precedente versione 0.7.4, la grande novità di Sigil 0.8.0 è la introduzione di una infrastruttura, che supporta l’utilizzo di plugin in questo programma. Più o meno come quella che ha Calibre, giusto per dare una idea. In altri termini, è possibile programma re e aggiungere nuove funzioni a Sigil, attraverso un sano fai-da-te informatico. Per chiunque abbia le competenze necessarie, è ovvio.

Al momento, il supporto di plugin è ancora parecchio limitato, sia perché di fatto è disponibile un solo linguaggio di programmazione, per realizzare i plugin, sia perché i plugin stessi non esistono: se li volete, dovete programmarveli voi, oppure modificare plugin già esistenti per programmi analoghi. Piuttosto che niente, è pur sempre meglio piuttosto.

Nello specifico, l’unico linguaggio di programmazione supportato, per realizzare plugin, è il Python, sia nella versione 2 che nella versione 3 del linguaggio. Una scelta che mi entusiasma moltissimo, dato che trovo la programmazione in Python piacevole come una colonscopia, ma questo è solo un parere personale. In apparenza, molti altri apprezzano invece il linguaggio: buon per loro.

Gusti a parte, la scelta è motivata dal fatto che il Python è un linguaggio già ampiamente usato per realizzare plugin in altri programmi, per cui non dovrebbe essere troppo difficile riciclare e modificare plugin già esistenti, adattandoli alle necessità di Sigil. In particolare, pare che i plugin di Calibre siano riciclabili in Sigil con poche modifiche, dato che la struttura di base è la stessa per i due programmi. O almeno, così sostiene la persona che si occupa dello sviluppo di Sigil e chi sono io per contraddirlo?

Plugin a parte, per il resto non ci sono cambiamenti nel funzionamento di Sigil: tutto ciò che avevo detto per la precedente versione rimane valido anche per questa. Anche la sua interfaccia non è cambiata, a parte l’aggiunta di una nuova voce di menu: Plugin, per l’appunto, e dovreste poter immaginare a cosa serva. Vedremo se, dopo questa versione, altre ne arriveranno, con novità più consistenti e, magari, miglioramenti più consistenti. Considerato il ritmo, non la aspetterei prima della prossima estate, ma spero di esserne smentito.

Guida al CSS per e-book

Il CSS è il principale linguaggio di programmazione, per realizzare la grafica di siti e applicazioni web, ma è anche la prima scelta quando si tratta di impaginare un ampio settore di formati e-book. Dopo aver parlato in più occasioni delle regole del CSS più comunemente utilizzate, per impaginare uno e-book, mi sono infine deciso a scrivere anche una guida in merito, in cui raccolgo, riorganizzo ed estendo quanto già si poteva trovare nei singoli post. La si può considerare una presentazione di un sottoinsieme del CSS, ossia quello che trova spazio (o che ha senso applicare) in uno e-book: altre proprietà che non ho toccato sono di uso più comune in un sito web e, sebbene non impossibile, il loro utilizzo in un libro sarebbe quantomeno discutibile. In altri termini, se vi accorgete di avere spesso bisogno di proprietà più complesse, è probabile che il vostro progetto funzionerà meglio sotto forma di app, piuttosto che di e-book.

Questa è la lista degli argomenti trattati, capitolo per capitolo:

0 - Presentazione

1 - Introduzione: CSS e HTML

2 - Il foglio di stile CSS

3 - Selezionare gli elementi

4 - Ereditarietà e stili a cascata

5 - Impostare i margini

6 - Formattare il paragrafo

7 - Formattare il testo

8 - Liste e tabelle

Se i titoli non sono sufficienti, ecco anche una brevissima presentazione di ogni capitolo e del relativo contenuto.

1 - Introduzione: CSS e HTML

Capitolo dedicato a una presentazione generale del CSS e dello HTML, con uno excursus su come strutturare un capitolo di e-book e quali tag siano utilizzati più di frequente.

2 - Il foglio di stile CSS

Capitolo dedicato al foglio di stile: la sua anatomia, la struttura di una regola, come assegnare un foglio di stile a una pagina e così via.

3 - Selezionare gli elementi

Capitolo dedicato ai selettori: come selezionare un tag, per poi modificarlo con una apposita regola CSS, ma anche come creare e selezionare una classe di stile, come funzionano i selettori discendenti e quali sono le pseudoclassi e gli pseudoelementi usati più di frequente in uno e-book.

4 - Ereditarietà e stili a cascata

Capitolo dedicato al funzionamento della ereditarietà nelle regole del CSS: come si tramandano le proprietà CSS da un tag all'altro, ma anche come funziona la "cascata", ossia il processo per cui una proprietà, assegnata a un tag, è valida anche per i tag che sono contenuti in quel primo tag.

5 - Impostare i margini

Capitolo dedicato alle regole più generali, per impaginare un capitolo: come impostare i margini tra i vari elementi di una pagina, come impostare il margine tra l'inizio del contenuto e il bordo dello schermo, come racchiudere un elemento in una cornice, come decorare lo sfondo di un elemento.

6 - Formattare il paragrafo

Capitolo dedicato alla impaginazione dei singoli paragrafi: come allineare il contenuto del paragrafo, come formattare soltanto la prima lettera o la prima riga di un paragrafo, impostare i rientri iniziali e così via.

7 - Formattare il testo

Capitolo dedicato al testo e ai caratteri: come impostare e incorporare font, come regolare le dimensioni del testo, lo spazio tra le linee, il colore del testo e altre decorazioni più o meno decorative.

8 - Liste e tabelle

Capitolo dedicato alla formattazione e alla impaginazione di liste e tabelle: contiene una descrizione dei tag utilizzati per realizzarle e delle proprietà che possono essere loro assegnate, specifiche per questi due tipi di struttura.

A titolo di esempio, i capitoli sono consultabili liberamente anche qui, cliccando sui link corrispondenti. Per tutto il resto, potete procurarvi la Guida: la sua versione in EPUB, peraltro, è liberamente vivisezionabile con Sigil (o anche solo con un qualsiasi programma per aprire cartelle compresse), così da studiarne in concreto la struttura, e può essere convertita facilmente in qualsiasi altro formato con Calibre, così da adattarsi al lettore di vostra preferenza, ma può anche essere modificata, se qualcosa non vi dovesse piacere. La versione per Kindle è inevitabilmente meno malleabile, per i limiti insiti nel formato utilizzato dal Kindle. In entrambi i casi, a ogni modo, non sono presenti DRM o accidenti simili.

Un semplice modello di EPUB per romanzi

Avevo già scritto, in passato, una guida su come realizzare un e-book utilizzando solo Sigil e tanta buona volontà. Ricollegandomi in parte a quanto dicevo in quella occasione, e alla luce di diversi commenti ricevuti in vari articoli su EPUB e problemi di impaginazione, ho preparato un semplice e basilare modello di EPUB, che può essere liberamente utilizzato sia come fonte di ispirazione, sia come scheletro per un vostro lavoro. Il modello mostra un modo molto spartano, in cui il contenuto di un e-book può essere diviso, fornendo anche un esempio di foglio di stile con alcune formattazioni di base, che si ritrovano spesso in romanzi e altri tipi di testo.

Come usarlo? Dipende da cosa ne volete fare. Potete aprirlo con Sigil e osservarne la struttura, alternando la Vista Libro e la Vista Codice, così da avere una idea sia del modo in cui il testo apparirà, sia di come sia composto il suo scheletro, oppure potete utilizzarlo come punto di partenza per il vostro lavoro, incollando il vostro testo all'interno delle pagine, assegnando alle varie parti le classi CSS più indicate, modificando gli attributi e i valori delle suddette classi CSS, e così via. Con un consiglio: se scegliete di copiare il testo da un documento DOC o DOCX, ossia da un documento scritto con Word, non copiatelo direttamente nello EPUB, altrimenti porterà con sé tutte le sozzerie aggiunte da Word. Copiate il testo dal documento di Word, incollatelo in una pagina del Blocco Note, copiatelo di nuovo dal Blocco Note e incollatelo nello EPUB: in questo modo il testo sarà filtrato a dovere e potrete ricostruirne l’impaginazione attraverso il CSS, senza dovervi preoccupare delle spiacevoli eredità lasciate da Word. Si perderanno anche corsivi e grassetti, è vero, e li dovrete aggiungere di nuovo con Sigil, ma il risultato finale sarà complessivamente migliore.

A ogni modo, guardiamo cosa ci sia in questo modello di EPUB.

Se lo apriamo con Sigil, vedremo che le cartelle contenenti materiale sono solo due: la cartella Text e la cartella Styles. Nessuno vi vieta di utilizzare anche le altre cartelle, ma queste sono le uniche due  indispensabili, se vogliamo creare uno e-book: text è la cartella che contiene il testo del libro, come suggerisce il nome, e Styles è la cartella che contiene le regole della sua impaginazione. Immagini, font e altro possono essere aggiunti a piacimento, ma non li considero elementi basilari.

La cartella Text contiene cinque files, così disposti:

Cover.xhtml

Titolo.xhtml

Copyright.xhtml

Testo.xhtml

Biografia.xhtml

Tutti questi files possono essere rinominati a piacimento: il nome attuale serve soltanto a fornire una indicazione dei rispettivi ruoli. Anche l’ordine con cui appaiono può essere modificato a piacimento, se quello attuale non è adatto o soddisfacente. Infine, ognuno di essi può essere rimosso, se lo e-book che stiamo preparando non possiederà quel componente; se invece lo e-book possiederà componenti extra come note e bibliografia (probabile), sarà sufficiente aggiungere un file html vuoto, usando l’apposita voce di Sigil, e trascinarlo in alto o in basso nella lista delle pagine, per posizionarlo dove lo vogliamo.

Cover.xhtml è al momento una pagina bianca. Come suggerisce il nome, è qui che inseriremo l’immagine di copertina del nostro e-book, se abbiamo in programma di metterne una. Con Sigil, è sufficiente cliccare sul pulsante Inserisci File, selezionare la nostra immagine e dare un Ok. Opzionalmente, possiamo anche cliccare col tasto destro del mouse su questo file, nel Navigatore della colonna sinistra di Sigil, e scegliere dal menu contestuale Aggiungi Semantica -> Copertina.

Titolo.xhtml è la pagina in cui possiamo inserire il titolo del nostro e-book, il nome del suo autore e, opzionalmente, il logo della casa editrice o cose simili. Se non abbiamo inserito una copertina, sarà questa pagina a farne le veci.

Copyright.xhtml è una pagina in cui inserire le note di copyright (come suggerisce il nome) e altri elementi simili. In questo caso, a titolo di esempio, io ho inserito un modello di nota di copyright, una nota sulla copertina (titolo della immagine di copertina, se esistente, ed eventuali credits) e, in coda, una tipica nota che accompagna molte opere di narrativa, cioè il tipico “ogni riferimento a cose, fatti o persone realmente esistenti” eccetera eccetera.

Testo.xhtml è la pagina che contiene il grosso del nostro e-book. Indicativamente, per semplificare sia la scrittura che la lettura  sui vari dispositivi,è utile spezzettarla in tante pagine quanti sono i capitoli del libro (avremo quindi Testo1, Testo2, Testo3, eccetera), ma non è obbligatorio: se a voi piace di più, potete usare un solo file monolitico, in cui travasare tutta la vostra opera. Nel foglio di stile CSS che accompagna lo e-book ho inserito alcune formattazioni di base: rientro per tutti i paragrafi a eccezione del primo, testo giustificato, primo paragrafo del capitolo con lettera ingrandita, eccetera. Uno sguardo alla Vista Codice vi dirà subito come utilizzare le classi CSS che ho inserito.

Biografia.xhtml, infine, è la pagina che conterrà la biografia dell’autore, una sezione su cui non mi pare ci sia molto altro da aggiungere.

Come vedete, non ho inserito una pagina con l’indice dello e-book, perché di questo si occupa già Sigil: la tavola dei contenuti (ToC) può essere creata in un paio di secondi, purché vi siate ricordati di utilizzare correttamente i tag di intestazione (i tag da <h1> a <h6>, per intenderci) per i titoli delle varie parti del libro.

Il foglio di stile CSS è Stile.css, contenuto nella cartella Styles: contiene alcune formattazioni di base, che hanno valore di semplici linee guida. Ho impostato ad esempi un colore per lo sfondo di tutte le pagine e un font di base per il testo, ho azzerato i margini per il tag <p>, così da rimuovere gli spazi vuoti tra un paragrafo e l’altro, ho inserito un certo spazio tra le varie sezioni, eccetera. Niente di particolare, insomma, ma può essere di aiuto come punto di partenza per qualsiasi tipo di impaginazione abbiate in mente. Per una discussione generale sull'uso del CSS in uno e-book, vi rimando alla serie di articoli che avevo scritto mesi fa: prima o poi troverò forse sia il tempo che la voglia di scrivere qualcosa di più completo, come un manuale specifico per le regole di CSS usate normalmente in un e-book, ma qualsiasi manuale generico di CSS può andare bene, se volete sapere come fare qualcosa di particolare, non contenuto nei miei articoli.

In questo modello di EPUB sono utilizzati soltanto font di base, che dovrebbero essere presenti su ogni tipo di dispositivo; se preferite utilizzare font originali e/o insoliti, li dovrete incorporare nel vostro e-book, ma anche di questo ho già parlato in precedenza.

Per finire, i metadati dello EPUB non sono stati inseriti, ma a questo dovrete eventualmente provvedere voi (premete F8 e si aprirà la finestra dei metadati). Il nome dell’autore, il titolo del libro e la lingua in cui è stato scritto sono gli unici metadati obbligatori, se volete superare il test di convalida, ma potete aggiungere qualsiasi altro metadato vogliate (codice ISBN, editore, data di pubblicazione, eccetera).

Realizzare semplici animazioni in CSS

Già in precedenza avevo dedicato una serie di post al CSS e al suo utilizzo, per curare la impaginazione e in generale la grafica di uno EPUB. Tornerò oggi nei paraggi, parlando di una delle principali novità introdotte col cosiddetto CSS3 (etichetta di comodo, sotto cui sono raccolte svariate cose), ossia le animazioni. Dubito che potranno essere di qualche utilità, per realizzare uno e-book (o almeno io lo spero, dato che un libro con immagini animate, che si spostano qui e là nella pagina, non è proprio di mio gusto), ma può comunque essere vantaggioso tenere in considerazione questa possibilità.

Quando si pensa ad animazioni più o meno belle e sensate, in una pagina web, di solito il primo strumento a cui le si collega è il JavaScript. Niente di strano: dopotutto, il JavaScript è nato proprio per dare vita ai siti, che agli albori del web erano alquanto statici, e la manipolazione degli elementi di una pagina è tuttora uno dei suoi principali usi, almeno a livello di web design. La possibilità di creare e gestire animazioni utilizzando il CSS, però, ci offre in alcuni casi una valida alternativa, soprattutto in termini di consumo di risorse e di velocità: se tutto ciò che dobbiamo fare è muovere una immagine o modificarne la visibilità, il CSS è la soluzione migliore.

Le animazioni, dunque. Ciò che ci è offerto da questa recente funzione del CSS è la possibilità di animare il passaggio da un insieme di proprietà a un altro, una sola volta o ripetutamente, usando animazioni lineari o con effetti particolari. Ad esempio, se fissiamo come punto di inizio un valore di opacity: 0 e come punto di arrivo un valore di opacity: 1, l'elemento a cui è assegnata questa animazione diventerà visibile a poco a poco, nel tempo di durata della animazione. Se fissiamo invece due diversi valori di color, uno come inizio e uno come fine, sarà il colore dell'elemento a cambiare a poco a poco. In breve, possiamo animare il passaggio da (più o meno) qualsiasi proprietà del CSS a qualunque altra proprietà, per gli elementi che scegliamo.

I passaggi necessari per utilizzare una animazione sono due: creare l'animazione e assegnarla a uno o più elementi della pagina. La prima cosa da fare, dunque, è definire la regola nel nostro foglio di stile CSS; la regola per una animazione è leggermente diversa da una normale regola del CSS, ma non troppo. Questa è la struttura di base.

@keyframes nome {
    from {

    }
    to {

    }
}

La parte più insolita è probabilmente costituita dallo @ iniziale, che contraddistingue questo e altri tipi di nuove regole, ma non è niente per cui perdere il sonno: possiamo considerare il blocco @keyframes come una formula, per introdurre la sequenza di operazioni che compongono la nostra animazione, e vivere serenamente.

Ciò che ho indicato come "nome" può essere un nome qualunque, che caratterizzerà la nostra animazione: scegliete quello che preferite, purché ogni animazione abbia un nome diverso dalle altre. Il nome ci servirà più avanti, per assegnare questa animazione agli elementi che animeremo.

All'interno della prima coppia di parentesi graffe dovremo elencare le varie tappe della nostra animazione; come è ovvio, le tappe dovranno essere almeno due, ossia un inizio e una fine. Dopo la parola from, elenchiamo le proprietà di partenza: il colore che un elemento possiede all'inizio della nostra animazione, oppure le sue dimensioni iniziali, o qualsiasi altra cosa cambierà nel corso del processo. Dopo la parola to, invece, elenchiamo le proprietà che l'elemento possiederà alla fine del processo. Una volta fissato inizio e fine, la transizione sarà gestita automaticamente dalla animazione.

Se la nostra animazione non dovrà passare direttamente dallo stato iniziale a quello finale, ma vogliamo che attraversi particolari fasi intermedie, le possiamo specificare utilizzando un valore in percentuale. Ad esempio,

from {
    color: red;
}
50% {
    color: white;
}
to {
    color: blue;
}

descrive una animazione che modifica il colore di un elemento: si parte dal rosso, si arriva al bianco a metà dell'animazione (ossia al 50%) e si conclude con un colore blu. Se vogliamo, poi, possiamo esprimere in percentuale anche from e to, invece di usare le parole: non farà alcuna differenza. Se ci piacciono particolarmente i numeri, dunque, potremo scrivere 0% al posto di from e 100% al posto di to, il che renderà forse più chiare le fasi intermedie della nostra animazione. Per ogni tappa, come è ovvio, possiamo inserire tutte le proprietà CSS che vogliamo, in base a ciò che è necessario per la nostra animazione: se vogliamo modificare contemporaneamente la posizione, il colore e la dimensione di un elemento, basterà elencare tutte le rispettive proprietà CSS dentro le varie tappe, una dopo l'altra. Ad esempio,

from {
    width: 200px;
    background-color: red;
}
to {
    width: 400px;
    background-color: blue;
}

porterà il nostro elemento da una larghezza di 200 pixel a una larghezza di 400 pixel, modificando nel frattempo il suo colore di sfondo da rosso a blu.

Una volta costruita la regola, dovremo assegnarla a un elemento. Operazione molto semplice: basta aggiungere alcune proprietà alla normale regola CSS, che abbiamo creato per quell'elemento. Le proprietà obbligatorie sono due: animation-name, che avrà come valore il nome della nostra animazione, e animation-duration, che avrà come valore la durata dell'animazione. Se ad esempio vogliamo applicare agli elementi di classe .invisibili una animazione di nome fantasma, che avrà una durata di 3 secondi, scriveremo

.invisibili {
    animation-name: fantasma;
    animation-duration: 3s;
}

Questo è il minimo indispensabile. Ci sono poi altre proprietà, che ci permettono un maggiore controllo sulla nostra animazione, e che probabilmente vorremo usare, ma le uniche strettamente necessarie sono il nome e la durata. Vediamo rapidamente le altre proprietà.

animation-timing-function ci permette di controllare il ritmo con cui la nostra animazione è eseguita. Se le assegniamo un valore linear, il ritmo sarà regolare dall'inizio alla fine; se assegniamo un valore ease, la nostra animazione partirà lentamente, si velocizzerà al centro e rallenterà verso la fine. Esistono diversi valori che possiamo assegnare ed è meglio testarli sul campo, per decidere il più adatto alle nostre esigenze.

animation-delay ci permette di eseguire la nostra animazione con un certo ritardo, espresso in secondi: con un valore di 2s, ad esempio, l'animazione partirà dopo due secondi, invece di partire subito.

animation-iteration-count ci permette di stabilire quante volte dovrà essere ripetuta la nostra animazione (se la vogliamo ripetere): basta assegnare come valore il numero di ripetizioni da eseguire, oppure la parola infinite, se vogliamo eseguirla ininterrottamente, per tutto il tempo in cui la pagina è aperta (attenzione: può diventare molto fastidioso per i visitatori).

animation-direction può essere usata per modificare la direzione in cui sarà eseguita la nostra animazione: assegnandole il valore alternate, l'animazione sarà eseguita alternatamente da from a to e da to a from, se abbiamo scelto di ripetere la nostra animazione.

animation-fill-mode, infine, ci permette di controllare l'aspetto finale del nostro elemento: se le assegniamo il valore forward, l'elemento manterrà l'aspetto che possiede alla fine della nostra animazione; in caso contrario, a fine animazione tornerà al suo aspetto iniziale.

Se non abbiamo voglia di scrivere una sfilza di proprietà extra, possiamo usare la formula abbreviata, proprio come accade per le proprietà font, margin, padding e altre. In questo caso, useremo la proprietà animation, seguita dalla lista di tutti i valori. Ad esempio,

animation: prova 3s linear 4 alternate 2s forward;

è una comoda abbreviazione per questa sfilza di proprietà:

animation-name: prova;
animation-duration: 3s;
animation-timing-function: linear;
animation-iteration-count: 4;
animation-direction: alternate;
animation-delay: 2s;
animation-fill-mode: forward;


Ovviamente non è necessario utilizzare tutte le proprietà, nella forma abbreviate, ma è utile rispettare questo ordine: nome, durata, timing, numero di ripetizioni, direzione, ritardo, fill mode.

Siccome poi questa funzione CSS non è ancora standardizzata su tutti i browser, è molto probabile che vi ritroverete costretti a utilizzare i vari prefissi, per alcuni o per tutti i browser: sperimentate prima le animazioni nella forma senza prefissi, come abbiamo visto sopra e poi, se necessario, aggiungete via via le alternative ci prefissi: -webkit- per Chrome e Safari, -moz- per Firefox, -o- per Opera. Con Internet Explorer, le animazioni funzionano soltanto dalla versione 10 in poi, ma almeno non richiedono prefissi. Lo so, è un lavoraccio, ma per adesso è necessario.

Gli strumenti per sviluppatori di Google Chrome

Tra gli strumenti disponibili nel menu di Google Chrome, la voce Strumenti per sviluppatori è probabilmente la più importante e utile, almeno per chiunque sia interessato anche al “dietro le quinte” di una pagina. Come il nome stesso suggerisce, questa voce raccoglie una serie di strumenti, pensati principalmente per chi si occupa di produrre pagine o applicazioni web, ma in linea generale possono essere utili e interessanti anche per chi non si sognerebbe mai di diventare uno sviluppatore, ma vuole solo saperne un po’ di più e vedere come funzionano le cose.

Gli strumenti disponibili sono otto e descriverli tutti quanti in un colpo solo occuperebbe troppo spazio: per semplificare il mio lavoro, dunque, li dividerò arbitrariamente e li descriverò un poco alla volta. Partirò oggi dalle due schede che, probabilmente, saranno usate più spesso: Elements e Console, ossia la prima e l’ultima nell'ordine in cui Google Chrome ce le offre.

Elements è la scheda in cui possiamo esaminare il contenuto effettivo della pagina che abbiamo davanti: più precisamente, ne possiamo esaminare il contenuto finale. Nel menu di Chrome esiste già una funzione “Visualizza sorgente”, che ci mostra il codice di una pagina: la scheda Elements è simile, ma non identica. Visualizzando il codice sorgente, infatti, noi vediamo il contenuto del file HTML originario, senza le modifiche che possono essere state effettuate utilizzando il JavaScript; la scheda Elements, invece, ci mostra il codice della pagina finale, dopo che tutte le modifiche tramite JavaScript sono state applicate. Inoltre, sempre da qui possiamo anche esaminare il CSS per ogni componente della pagina, nella colonna di destra della scheda.

Una buona norma della programmazione web prescrive che il contenuto di una pagina sia sempre e comunque accessibile, anche per chi ha disabilitato il JavaScript: se questa norma fosse sempre rispettata, la visualizzazione del codice sorgente dovrebbe mostrarci già tutto il testo, tutte le immagini e tutti gli altri elementi contenuti in una pagina. Come la maggior parte delle buone norme, però, non sempre è rispettata alla lettera; di conseguenza, una parte più o meno cospicua del contenuto, in molti siti, è aggiunta successivamente col JavaScript. Sempre attraverso il JavaScript, parti della pagina possono essere nascoste o mostrate, modificando il CSS corrispondente, col risultato che la pagina davanti a noi è spesso molto diversa, rispetto al contenuto descritto nel file HTML iniziale.

Elements ci mostra dunque un file HTML virtuale, che descrive la pagina così come ci appare sullo schermo in questo momento. Se una immagine è stata aggiunta col JavaScript, Elements ce la mostrerà nel punto in cui è stata aggiunta, con tutti i tag HTML e tutte le regole di stile che le sono state assegnate, proprio come se avesse fatto parte fin dall’inizio della pagina. Se una parte della pagina è stata invece nascosta, in seguito a una qualche nostra azione, non la vedremo apparire in questa sezione.

Come è facile da intuire, Elements è molto utile per esaminare il contenuto della pagina, sia mentre noi ci stiamo lavorando, sia quando siamo curiosi di studiare il lavoro altrui, ma questa è solo una parte delle sue funzioni. Oltre a guardare, infatti, in questa scheda possiamo anche modificare il contenuto di una pagina, in modo molto semplice. O almeno, molto semplice se sappiamo orientarci tra i nodi di una pagina HTML e se conosciamo HTML e CSS: dopotutto, questi si chiamano “strumenti per sviluppatori” e la conoscenza dei linguaggi per la programmazione web è data per scontata, essendo rivolti agli sviluppatori di pagine e siti. Non ci piace il colore dello sfondo, oppure il colore dei caratteri? Da qui lo possiamo modificare. Clicchiamo prima col tasto sinistro del mouse sul nodo da modificare e poi, nella colonna di sinistra, cerchiamo la proprietà CSS che ci interessa e clicchiamola col tasto sinistro: in questo modo, la potremo modificare a nostro piacimento.

Se invece clicchiamo su un elemento HTML col tasto destro del mouse, si aprirà un menu contestuale, in cui ci saranno offerte altre possibilità di intervento: ad esempio, potremo modificare lo HTML, selezionando la voce “Edit as HTML”, oppure rimuovere quel particolare nodo dalla pagina, selezionando “Delete node” (se un banner vi ha rotto le scatole, potrete cancellarlo da qui). Eliminare un nodo, ad esempio, può essere un sistema rapido, per levarsi dai piedi quei fastidiosi avvisi, che impediscono di leggere una pagina fino a che non avete cliccato “Mi piace” su una pagina Facebook, oppure fino a che non vi siete registrati e cose simili.

Ovviamente, ogni modifica apportata alla pagina varrà soltanto per noi: ciò che modifichiamo è la copia locale, caricata nel nostro browser, e non la pagina originale, contenuta nel sito. Nonostante questo, è pur sempre uno strumento valido, per adattare le pagine ai nostri gusti o per rapidi interventi di correzione, oltre alle sue normali funzioni di studio ed esame della pagina.

Console è la scheda di chi ama smanettare col JavaScript. Può essere utilizzata per eseguire brevi porzioni di codice nella pagina (sempre sul lato cliente, sia chiaro), ma è molto più importante il suo ruolo di semplice ambiente di sviluppo per JavaScript. Di fatto, la console è uno spartano (ma poi neanche tanto spartano, nel caso di Google Chrome) REPL, ossia uno spazio in cui possiamo dialogare col JavaScript, direttamente nel nostro browser: scriviamo un comando o una funzione, premiamo Invio, e la console ci restituirà subito il risultato del comando o della funzione. Se stiamo studiando o imparando il JavaScript, possiamo trascorrere ore in perfetta letizia, dialogando col nostro linguaggio di programmazione; se invece stiamo lavorando alla realizzazione di una pagina e qualcosa va storto, è qui che ci saranno segnalati gli errori relativi al JavaScript.

Chiunque abbia mai utilizzato un REPL in vita propria, magari trastullandosi col Lisp o altri linguaggi di programmazione affini (anche Scala va bene), non dovrebbe avere problemi con la Console. Un REPL è un Read-Eval-Print-Loop, ossia un ciclo continuo di lettura, esecuzione e stampa del codice: noi scriviamo un comando, una funzione o qualsiasi altra cosa, premiamo Invio, e il comando (o funzione, o altro) sarà eseguito e poi scritto sullo schermo, dopodiché la console sarà pronta per il comando successivo. Ovviamente, comandi e funzioni dovranno essere in JavaScript, per poter funzionare, ma nel peggiore dei casi potete sempre utilizzarla come calcolatrice alternativa.

Come dicevo all’inizio, la console può essere utilizzata fondamentalmente in due modi: come ambiente di sviluppo per il JavaScript, oppure per alterare il contenuto della pagina che abbiamo davanti.

Come ambiente di sviluppo, è spartano ma funzionale, nonché molto utile se stiamo imparando (o se vogliamo imparare) la programmazione in JavaScript. Possiamo usarla per scrivere ed eseguire funzioni, ad esempio, ma con un’avvertenza: se vogliamo andare a capo, non dobbiamo premere Invio, ma Shift+Invio. Se premiamo Invio da solo, il codice sarà eseguito e ci ritroveremo con un messaggio di errore, se la nostra funzione era a metà. Dettagli a parte, ha il vantaggio considerevole di suggerirci i nomi di variabili, metodi, oggetti e funzioni a nostra disposizione: se cominciamo a scrivere qualcosa, la console ci mostrerà tutti i modi validi in cui possiamo concludere quella parola, proprio come accade in ambienti di sviluppo più raffinati. Ad esempio,

La console ricorda anche tutto ciò che abbiamo già fatto, durante la nostra sessione di lavoro: se abbiamo creato nuove variabili globali, oppure nuove funzioni, o nuovi oggetti, anche i loro nomi appariranno tra i suggerimenti, accanto a funzioni, metodi e oggetti già inclusi nel motore JavaScript di Google Chrome. Di fatto, la console offre tutto ciò che è strettamente indispensabile, per programmare in JavaScript.

Se invece vogliamo utilizzarla per alterare la pagina corrente, il principio di base è lo stesso, ma cambia il contesto: dalla console avremo accesso a tutto il JavaScript della pagina su cui l’abbiamo aperta, incluse eventuali altre librerie importate (jQuery, ad esempio, che è spesso presente). Se stiamo allegramente sprecando tempo con un gioco in JavaScript e vogliamo barare, possiamo farlo da qui, modificando ad esempio il numero assegnato alla variabile che contiene il punteggio. Ogni modifica avrà effetto a livello locale, ossia nella pagina aperta sul nostro browser: se dunque abbiamo usato la console, per truccare il nostro punteggio in un gioco, il nostro punteggio truccato non avrò effetto su una eventuale classifica dei migliori punteggi, ospitata nel sito del videogioco. O almeno, non dovrebbe avere effetto, a meno che il gioco non sia stato progettato molto male e abbia un livello di sicurezza pari a zero, ma questo è un altro paio di maniche.

Three.js – Una libreria per un WebGL semplificato

WebGL è una nuova tecnologia, incorporata nei browser (o almeno in buona parte dei browser), che permette di creare e disegnare immagini e animazioni 3D su una pagina web, senza bisogno di utilizzare plugin o programmi esterni, come il Flash, ma basandosi soltanto sul buon vecchio JavaScript. Questo per dirla in modo molto semplice, sorvolando sulla storia e tutto il resto.

Per visualizzare una grafica prodotta con WebGL, o per utilizzare un videogioco basato su WebGL, è sufficiente avere un browser che supporti questa tecnologia: in pratica, più o meno tutti i browser, a parte Internet Explorer, almeno per il momento. per utilizzare WebGL in modo attivo, ossia per programmare grafiche o videogiochi in 3D, gli strumenti necessari sono sempre un browser che lo supporti, una discreta conoscenza del JavaScript e una buona conoscenza di algebra lineare, se siete così pazzi o determinati, da voler programmare a mano le matrici. Se non siete così pazzi o così determinati, non preoccupatevi: praticamente nessuno lo fa, se non in fase di apprendimento. Di solito, la parte più algebricamente hardcore è affidata a librerie JavaScript, che si occupano per noi dei calcoli più complicati, lasciandoci il piacere e il privilegio di lavorare sul risultato dei calcoli. La più usata di queste librerie è Three.js, di cui parlerò oggi.

Se ricordate la versione 3D di Pong, presentata come uno degli ultimi esperimenti su Chrome, la parte grafica è stata realizzata proprio con la libreria Three.js, come accennavo nel relativo articolo: questo per dare un esempio concreto del suo utilizzo. Niente di strano: si possono scrivere a mano le matrici e ci si può occupare personalmente di tutti i calcoli necessari, ma questo va bene solo in fase di apprendimento, quando è necessario capire i meccanismi della grafica 3D. Quando però si passa dall'apprendimento alla produzione, librerie ausiliarie come Three.js sono fondamentali, per ridurre il lavoro e il tempo da spendere sul progetto. In linea generale, usare Three.js per lavorare col WebGL è come usare jQuery per lavorare col JavaScript: entrambe le librerie costituiscono un modo per interagire a un livello più alto di astrazione con la materia grezza che si trova sotto di esse. Esattamente come jQuery, poi, Three.js non è l’unica libreria esistente, per lavorare col WebGL, ma solo una delle più diffuse e più usate.

Le caratteristiche di Three.js, dunque. Prima e principale caratteristica, comune anche alle altre librerie della stessa famiglia, è di occuparsi per conto nostro della matematica necessaria: significa che ci risparmieremo parecchie linee di codice, ad alto tasso di errori e basso tasso di divertimento (soprattutto se non amiamo la matematica). Sempre per conto nostro, Three.js si occupa anche della fase di rendering per ogni oggetto presente in scena: noi dovremo soltanto indicarle cosa fare e la libreria saprà come farlo, senza bisogno di nostre istruzioni. Inoltre, al puro WebGL unisce anche altri elementi, che spesso lo accompagnano ma che non sono parte diretta di quella tecnologia: ad esempio, il supporto per il mouse, così da poter interagire direttamente con la scena, spostando e trascinando oggetti e così via. Infine, ma non meno importante, Three.js permette facilmente di introdurre una soluzione alternativa, anche per quei browser che non supportano il WebGL: se non è presente il supporto per il 3D, possiamo sostituirlo col normale canvas 2D. Come è ovvio, il risultato estetico non sarà identico, ma la grafica o il videogioco funzioneranno ugualmente.

Three.js, poi, è orientata verso una programmazione a oggetti, il che può essere sia un vantaggio, sia uno svantaggio, a seconda dei punti di vista e delle abitudini di lavoro col JavaScript: se decidete di usare questa libreria, preparatevi a dover ricorrere spesso a new, per creare nuovi oggetti, che possono essere figure geometriche, luci, videocamere, la scena che contiene tutta la grafica e così via. Così ha deciso il suo autore.

Una caratteristica curiosa di Three.js, poi, è la presenza di un grande numero di esempi, abbinata a una documentazione alquanto scarna, sul piano dei manuali: quando scaricate la libreria, non aspettatevi niente di più elaborato di un basilare “Hello World”, incluso nel pacchetto. È possibile però trovare altrove guide e tutorial, principalmente in inglese, e anche accenni o capitoli dedicati a questa libreria, nei testi generali sul WebGL. Chi preferisce imparare smanettando col codice, però, avrà appunto oltre cento esempi con cui divertirsi, vivisezionandoli e sperimentando varie modifiche, per capire con la pratica il loro funzionamento. Tra parentesi, molti di questi esempi richiedono la presenza di un server, per funzionare: se ne avete uno installato sul vostro computer, apriteli da lì e ne guadagneranno anche le prestazioni.

I passaggi fondamentali, per creare e popolare una scena, non sono poi molto diversi da quelli che avevamo già visto, parlando di Blender: siamo sempre nel campo della grafica 3D, dopotutto, e a cambiare sono solo il linguaggio e il tipo di ambiente. Per un qualsiasi tipo di progetto con Three.js, avremo bisogno di inserire un renderer, una camera e una scena, al cui interno potremo poi sistemare oggetti (o mesh, per sembrare più professionali), luci e quant'altro. In altri termini, gli oggetti fondamentali che dovremo creare con new, nella funzione iniziale, sono:

THREE.Renderer - un oggetto che si occupa di disegnare la scena sullo schermo.

THREE.Scene - il contenitore di tutto ciò che apparirà sullo schermo.

THREE.Camera - la videocamera virtuale, attraverso cui vedremo la scena.

A questi tre oggetti, indispensabili, potremo poi aggiungerne altri, per avere anche qualcosa da vedere sullo schermo. Questi oggetti supplementari sono

THREE.Light - una sorgente di luce, di un colore a nostra scelta, indispensabile se vogliamo che sia resa la illusione di tridimensionalità degli oggetti (senza luce, appariranno bidimensionali).

THREE.Object3D - la classe base degli oggetti raffigurabili: alcuni tipi sono già definiti e pronti all'uso, altri li possiamo creare noi.

La tipologia base di oggetti, come già abbiamo visto con Blender, è Mesh e a ogni mesh dovremo assegnare due altri oggetti, nel momento della creazione: THREE.Geometry, che contiene la forma dell’oggetto (cubo, sfera, prisma eccetera) e THREE.Material, che contiene informazioni sulle qualità dell’oggetto, come il colore. In un qualsiasi progetto con Three.js, dunque, la funzione iniziale creerà un renderer, una scena, una camera, aggiungerà alla scena i vari oggetti presenti e la camera, infine passerà la mano al loop, che continuerà a ridisegnare lo schermo,a  intervalli regolari. Un esempio di come fare tutto questo lo troviamo già nel pacchetto della libreria, sotto forma di breve tutorial nella cartella "docs"; per il resto, potremo divertirci a squartare la caterva di esempi disponibili.

Esperimenti di Chrome: Cube Slam e WebRTC

Una quarantina di anni fa, quando i computer vivevano la loro età del rame e i videogiochi erano ancora in piena età della pietra, compariva sulla scena Pong, uno dei primi esemplari di gioco. Pong aveva una struttura molto semplice: due lineette verticali, una a destra e una a sinistra, si rilanciavano a vicenda un quadratino, potendosi muovere solo verso l’alto o verso il basso. Con una certa dose di fantasia, era una simulazione di ping-pong.

Curiosamente, proprio questo videogioco “preistorico” è stato scelto da Google, per essere utilizzato come cavia con cui testare e mostrare una nuova tecnologia per la comunicazione web: ne è nato così Cube Slam, uno degli ultimi esemplari appartenenti alla categoria dei Chrome Experiments, ossia applicazioni web sviluppate per mostrare quale sia il supporto offerto da Google Chrome a vari tipi di tecnologie sperimentali. Nel caso di Cube Slam, la tecnologia in questione è il WebRTC, che consente una comunicazione diretta da browser a browser, usando soltanto elementi nativi del browser stesso: niente Flash o altri tipi di plugin esterni, insomma. Ma guardiamo meglio cosa sia Cube Slam.

Questa è la schermata introduttiva, che apparirà se ci colleghiamo alla pagina con Google Chrome. Altri tipi di browser, come Firefox o Safari, potrebbero funzionare, ma non è garantito: dopotutto, è un progetto che serve a mostrare le funzionalità di Chrome e non ci si può aspettare che sia anche ottimizzato per funzionare altrettanto bene su altri browser.

Come possiamo vedere al centro, il campo di gioco è più o meno identico a quello del vecchio Pong, con una notevole variante: Cube Slam è tridimensionale, di conseguenza le due lineette sono sostituite da due parallelepipedi e il quadratino è adesso un cubo. Differenze marginali, si potrebbe dire. Una differenza più notevole è data dal contenuto del gioco, dove il semplice tic toc delle due lineette che si rilanciano l’un l’altra un quadratino è stato arricchito da svariati elementi extra, come campi gravitazionali, ostacoli, bombe e più o meno tutto l’armamentario che si può immaginare in un videogioco di questo tipo.

Sempre dalla schermata introduttiva, possiamo notare un altro particolare, cioè le due modalità di gioco offerte: contro un amico, oppure contro un orso. La seconda, per quanto possa suonare bizzarra, è soltanto un modo per dire che giocheremo contro il computer, ossia contro una tipica AI da videogioco, in questo caso impersonata da un orso. La prima opzione è invece molto più interessante, perché ci conduce al cuore dell’esperimento: la comunicazione diretta via browser, nel caso specifico tra il nostro browser e quello di un amico, contro il quale giocheremo.

WebRTC, ossia Web Real Time Communication, è una nuova tecnologia, per introdurre una comunicazione diretta tra browser, utilizzando solo le risorse a disposizione dei browser, senza appoggiarsi a programmi esterni. In particolare, il fine di WebRTC è quello di rendere la comunicazione audio e video, attraverso i browser, semplice e immediata quando la comunicazione testuale. Cube Slam utilizza WebRTC per collegarci direttamente col browser di un nostro amico, se scegliamo di giocare contro un amico e se l’amico è in linea (ovviamente), gestendo in modo diretto la comunicazione tra noi e lui: noi vedremo sullo schermo il nostro amico e lui vedrà noi. Niente di diverso da una normale video chat, da un certo punto di vista, ma la differenza sta nel modo in cui la comunicazione è realizzata: direttamente dal browser e non utilizzando un plugin di Skype, come ad esempio fa Facebook. peraltro, lo scopo stesso del gioco è proprio quello di abbattere lo schermo del nostro avversario, cosa che avverrà dopo che lo avremo colpito per tre volte.

Per essere giocato contro un amico, quindi, Cube Slam richiede la presenza di webcam e microfono (sì, oltre a vederci, possiamo anche insultarci in diretta, mentre giochiamo): se non utilizziamo un firewall (pessima abitudine), i dati saranno trasmessi direttamente dal nostro browser al browser del nostro amico, senza bisogno di un server, in un modo simile a quanto avviene con programmi P2P, come eMule o BitTorrent.

Per quanto riguarda la grafica, che è in 3D, può essere visualizzata in due modi: se il nostro browser supporta il WebGL, che è una grafica 3D nativa dei browser, il gioco sarà visualizzato utilizzando quella, dato che è stato prodotto con three.js, una libreria JavaScript per semplificare il ricorso alla grafica 3D; in assenza di WebGL, invece, ripiegherà sulla simulazione del 3D attraverso il CSS, così da garantire un risultato simile, anche se non proprio identico, anche su altri browser.

Scribus, alternativa libera a InDesign

Scribus è un programma di impaginazione libero e open source, disponibile per tutti i principali sistemi operativi: Windows, Macintosh, Linux/UNIX e così via. Meglio ancora, è disponibile in lingua italiana e corredato da una valida guida interna (anche questa in gran parte in italiano), che ne descrive la struttura, le funzioni principali e fornisce anche un breve tutorial, con un esempio concreto di creazione di un documento. È un buon punto di partenza e vale la pena cominciare da lì il proprio studio di Scribus.

L’installazione del programma non dovrebbe presentare particolari problemi, ma per gli utenti Windows c’è un’avvertenza: al termine della procedura di installazione, se decidete di aprire il file readme, Scribus vi segnalerà che avreste dovuto installare un altro programma, prima di Scribus, e cioè Ghostscript. Se non lo avete installato, a ogni successivo avvio Scribus si lamenterà di non riuscire a trovarlo: è bene dunque scaricare e installare Ghostscript, prima di installare Scribus. A ogni modo, è anche possibile utilizzare Scribus, senza aver installato Ghostscript, ma alcune funzioni non saranno disponibili, ossia le funzioni per cui è richiesto Ghostscript: nello specifico, non potrete importare file in formato EPS, utilizzare l’anteprima di stampa, o generare codici a barre. Nei sistemi operativi Linux/UNIX, invece, Ghostscript è di solito già installato, per cui il problema non si pone, anche se potrebbe essere necessario aggiornarlo.

Una volta installato, al primo avvio vi troverete molto probabilmente davanti a questa finestra,

cioè la finestra per la creazione di un nuovo documento. A differenza di un elaboratore di testi, come ad esempio Word o Writer, o anche il semplice Blocco Note, non ci sarà già una pagina bianca standard ad aspettarvi, pronta a essere profanata dai vostri scritti: dovrete crearla voi stessi, in base alle vostre esigenze per quel particolare lavoro. per facilitarvi le cose, ma anche per darvi un primo suggerimento su come cominciare, Scribus vi proporrà subito la finestra per la creazione di un nuovo documento. Se lo trovate troppo invasivo, o se non amate in generale essere imboccati con le operazioni da svolgere, potete sempre selezionare “Non mostrare più questa finestra di dialogo”, in basso a sinistra: in questo caso, all'avvio vi troverete davanti il programma nudo e crudo, in attesa che voi apriate un file già esistente, oppure creiate un nuovo documento.

Come ho detto in precedenza, nella guida di Scribus è presente un tutorial in italiano, che vi mostrerà le principali funzioni del programma: se decidete di seguirlo, lo troverete nella sezione Documentazione -> Le basi di Scribus, col titolo “Iniziare subito a lavorare con Scribus”. Un altro possibile punto di partenza è il tutorial online, che potete raggiungere dal menu Aiuto -> Guide online, sotto il nome di “Primi passi con Scribus”.

Più in generale, è utile leggere tutti gli articoli presenti nella sezione “Le basi di Scribus”, nella guida interna, se non avete mai utilizzato un programma di questo genere. È opportuno ripetere, infatti, che Scribus non è un programma per la creazione o la scrittura di testo, ma per la sua impaginazione: anche se contiene un elaboratore di testo molto semplice (poco più di un Blocco Note), il suo utilizzo fondamentale consiste nell'importare documenti e poi impaginarli, non crearli da zero. In altri termini, se volete creare un semplice volantino, con due righe di testo, potete farlo direttamente con Scribus, senza problemi; se invece lo volete usare per impaginare un libro o una rivista, scrivete prima di tutto il testo col vostro editor preferito, salvatelo in un formato TXT o ODT e poi utilizzate pure Scribus per impaginarlo, aggiungere le immagini e così via. Una volta concluso il lavoro, il risultato finale potrà essere esportato come PDF, come immagine, oppure stampato (o anche tutte e tre le cose assieme, volendo).

Le funzioni di base di Scriptus possono poi essere semplificate, utilizzando script per automatizzare diversi tipi di operazioni: alcuni sono preinstallati e li potete trovare elencati nel menu Script, ma potete aggiungerne quanti volete, in base alle vostre esigenze. L’unico requisito necessario è saper programmare in Python, cioè il linguaggio in cui gli script sono realizzati; inoltre, è anche possibile aggiungere plugin, in questo caso realizzati in C++. La guida di Scribus fornisce qualche informazione in proposito, nella sezione For Developers, assieme a una introduzione alla creazione di plugin in C++, ma non è stata tradotta in italiano: nulla vi vieta di leggerla, se siete interessati all'argomento.

Guida al CSS per EPUB – Come lavorare

Nella puntata precedente abbiamo parlato di bordi, margini e di come impostare (o annullare) la distanza tra gli elementi all'interno di una pagina. Con questo non abbiamo certo esaurito il discorso sul CSS, che include svariate altre funzioni per impaginare gli elementi su più colonne, animarli e così via, ma tutto ciò che poco o nulla a che fare con gli EPUB: se vogliamo che un nostro e-book sia leggibile senza problemi anche su uno smartphone, dobbiamo limitarci a una sola colonna e il ricorso ad animazioni, oltre ad avere poca attinenza coi libri in generale, potrebbe non essere supportato da tutti i lettori in circolazione. Volendo, il problema relativo alla dimensione dello schermo può essere risolto, ricorrendo a un layout adattabile (come accade su molti siti web), ma è un argomento che va ben al di là sella semplice introduzione al CSS e, semmai, lo affronterò in futuro. Per adesso, vediamo invece di riassumere il discorso, con un esempio più concreto.

Supponiamo di dover lavorare su una pagina strutturata in questo modo:

<body>
<div class=”titolo”>
<h2>Capitolo 1</h2>
</div>
<div class=”testo”>
<p class=”primo”>Testo del primo paragrafo.</p>
<p>Testo del paragrafo.</p>
<p>Testo del paragrafo.</p>
<p>Testo del paragrafo.</p>
<p>Testo del paragrafo.</p>
<p>Testo del paragrafo.</p>
<p>Testo del paragrafo.</p>
</div>
</body>

Corrisponde più o meno a una struttura ideale, per lavorare col CSS. Come ho accennato in precedenza, diversi tag HTML possiedono una formattazione di base, inserita automaticamente dal browser o dal dispositivo di lettura: il tag <p>, ad esempio, sarà quasi sempre seguito da una riga vuota, a separarlo dal paragrafo successivo, mentre i vari tag usati per i titolo, come <h1>, <h2> e così via, avranno già in partenza una dimensione differente, rispetto al testo normale, e spesso saranno anche visualizzati in grassetto. Queste impostazioni automatiche possono andarci bene, ma possono anche essere una seccatura, se vogliamo avere un controllo totale sulla grafica della pagina. Se le consideriamo una seccatura, nella prima parte del foglio di stile possiamo inserire alcune regole per annullarle: le ho riassunte nel file CSS che potete scaricare da qui. Per usarle, copiate il contenuto e incollatelo all'inizio del vostro foglio di stile, così da fare piazza pulita di tutto, prima di cominciare il lavoro.

Per scrivere il nostro foglio di stile, ricordiamo sempre il principio di base del CSS: partiamo dalle regole più generali, che costituiranno la base del nostro stile, e procediamo poi verso le regole più specifiche, che riguarderanno soltanto piccole porzioni di testo. Nella nostra pagina di esempio, il tag di base è <body>, che li include tutto. È il capofamiglia, se ricordiamo la struttura gerarchica dello HTML. Subito dopo di lui, vengono i tag <div class=”titolo”> e <div class=”testo”>, alla pari: sono tag fratelli (oppure sorelle, come preferite), nonché figli del tag <body>. Il tag <div class=”titolo”> ha un solo figlio, ossia il tag <h2>, e il suo ramo si conclude lì; il fratello <div class=”testo”>, invece, ha diversi figli, tutti i tag <p>, e ognuno di essi avrà probabilmente altri figli, se abbiamo usato qualche corsivo o grassetto, oppure se abbiamo inserito link, immagini o altro. È una famiglia molto ramificata, ma dobbiamo sempre ricordare la sua struttura: i figli ereditano lo stile del padre, a meno che questo stile non sia modificato in una delle loro regole.

Se vogliamo impostare uno sfondo che valga per tutto il capitolo, impostiamolo come regola per il tag <body>. Scriveremo ad esempio:

body{
    color: yellow;
}

se vogliamo che il capitolo abbia uno sfondo giallo. Potremo poi cambiare il colore dello sfondo per un tag specifico, ma il giallo sarà il colore di base per lo sfondo di tutti gli elementi della pagina. Se vogliamo impostare un font di base, modificandolo eventualmente per i titoli, il tag body è sempre un buon punto in cui impostarlo. Unendolo alla regola precedente, otterremo

body{
  color: yellow;
  font-family: “Times New Roman”, Times, serif;
}

che assegnerà uno sfondo giallo alla pagina e imposterà il font di base per tutto il testo. Per modificare il font del titolo, poi, basterà scrivere

.titolo{
  font-family: "Arial Black", Arial, sans-serif;
}

In questo modo, il tag <div class=”titolo”> utilizzerà un font diverso, che sarà ereditato dai suoi figli (il solo tag <h2>, in questo esempio). Il contenuto di <div class=”testo”>, invece, erediterà il font impostato per <body>, che è suo padre. Se la catena di genitori, figli e fratelli ci confonde, può essere utile tracciare un breve schema della rete di rapporti, così da averla sempre a portata di occhio, mentre scriviamo il foglio di stile: può aiutare a chiarire perché un determinato elemento abbia un certo colore, oppure utilizzi un certo font.

Il tag body è un ottimo posto anche per inserire tutte le regole che determineranno i margini della pagina, quando spazio vuoto dovrà essere lasciato sui bordi, eccetera. Ad esempio, se al tag body aggiungiamo anche una regola

padding: 7px 10px 5px 10px;

tutta la pagina presenterà un margine alto di sette pixel, laterale di dieci pixel e basso di cinque pixel: avremo insomma creato una piccola cornice bianca attorno al contenuto della pagina.

Titolo e testo, nel nostro esempio e nella maggior parte delle pagine ben strutturate, sono due elementi fratelli: le regole che assegniamo a uno non influiscono sull'altro ed è bene così. Per separarli, inserendo un certo spazio tra il titolo e il primo paragrafo del testo, non premiamo tre o quattro volte il tasto “Invio”, perché il risultato non è garantito. Il modo migliore per separarli è usare i margini, come già abbiamo visto. ad esempio, se scriviamo la regola
.titolo{
  margin-bottom: 30px;
}

avremo la garanzia che il titolo e il primo paragrafo saranno separati da uno spazio vuoto di trenta pixel. Possiamo assegnare qualsiasi valore, a seconda delle nostre preferenze, ma la cosa importante è assegnarlo alla proprietà margin-bottom, che determina la distanza tra la fine di questo elemento e l’inizio del successivo.

Venendo al testo, molti libri scelgono di rientrare la prima riga di ogni paragrafo. Se vogliamo adottare questo stile per il nostro EPUB, basterà una regola del tipo
p{
  text-indent: 2em;
}
che produrrà un rientro pari a due caratteri nella prima riga di ogni tag <p>. Il primo paragrafo di un capitolo, a volte, riceve un trattamento particolare: per questo gli abbiamo assegnato una classe “primo”, che useremo nel CSS per modificare soltanto quel paragrafo. Ad esempio,
p.primo{
  text-indent: 0;
}
azzera il rientro per il tag <p> che possiede un attributo class=”primo”, ossia il primo paragrafo del nostro capitolo. Essendo poi una regola più specifica, è meglio inserirla dopo la regola generale, che abbiamo scritto per il tag <p>. Se poi vogliamo davvero sbizzarrirci e dare un aspetto particolare alla prima lettera del capitolo, in memoria degli antichi testi miniati medievali, possiamo ricorrere a una regola ancora più specifica, ossia
p.primo:first-letter{
  position: relative;
  display: block;
  float: left;
  font-weight: bold;
  font-size: 4.4em;
  line-height: 0.8em;
  color: rgb(40,40,40);
}
che potrete divertirvi a decifrare, sulla base delle puntate precedenti. In linea di massima, la regola di rivolge alla prima lettera del paragrafo con classe “primo”: ingrandisce la lettera, la colora, la rende in grassetto e la allinea al resto del paragrafo. Questa regola, che è specifica al massimo grado (riguarda solo una lettera di un paragrafo), la collocheremo alla fine della parte del foglio CSS dedicata ai paragrafi.
Tutte le regole che modificano elementi interni a un tag <p>, come possono esserlo i tag <b>, <i> e così via, li sistemeremo subito dopo la sezione dedicata al paragrafo: una buona organizzazione del foglio di stile ci aiuterà a vedere meglio i rapporti di parentela tra gli elementi. Il foglio di stile, dunque, potrebbe avere una struttura finale di questo tipo:
body{
  //regole globali
}
.titolo{
  //regole per la sezione “titolo”
}
.titolo h2{
  //regole specifiche per il tag <h2>, quando si trova in un elemento con class”titolo”
}
.testo{
  //regole generali per il corpo del capitolo
}
p{
  //regole specifiche per i paragrafi
}
p.primo{
  //regole specifiche per il paragrafo con classe “primo”
}
p.primo:first-letter{
  //regole specifiche per la prima lettera del paragrafo con classe “primo”
}
b{
  //regole specifiche per il tag <b>
}
e così via. Combinando i tag, possiamo ottenere regole sempre più specifiche e precise, ad esempio la regola
p b{
//regole per i tag <b> all’interno di un tag <p>
}
che si rivolge soltanto a un sottogruppo dei tag <b>, ossia quelli che sono figli di un tag <p>. Il principio di base, che dobbiamo sempre ricordare per risparmiarci fatica inutile è: partiamo dal generale e scendiamo sempre più verso il particolare. Ricordarlo e applicarlo non ci metterà al sicuro dagli errori, ma ci aiuterà a ridurli e a localizzarli più facilmente.

Guida al CSS per EPUB – Impostare i margini

Nella puntata precedente abbiamo visto alcune delle proprietà che dobbiamo modificare, per cambiare l’aspetto di un paragrafo o della pagina: è un buon inizio, per posizionare correttamente un elemento, ma ancora non basta, soprattutto se siamo interessati a controllare gli spazi tra un elemento e l’altro (le famigerate righe vuote tra i paragrafi, insomma, contro cui spesso ci si trova a dover combattere). Se convertiamo un documento con Calibre, e non prestiamo attenzione a tutti i valori da impostare, molto spesso ci troveremo coi paragrafi separati tra loro da fastidiose linee bianche, proprio come accade quando scriviamo qualcosa in Sigil. Per capire cosa siano e imparare a evitarle o eliminarle, dobbiamo prima osservare come il CSS gestisca lo spazio nello HTML.

Pensiamo a un tag HTML (e al suo contenuto) come a una porzione di spazio, uno dei mattoncini LEGO che formano la pagina. Ognuno di questi tag, in linea di massima, è rappresentato come un rettangolo, più o meno grande a seconda dei casi: il tag <body> è un rettangolo grande quanto la pagina intera, il tag <p> è grande quanto il paragrafo contenuto, il tag <h1> sarà grande invece quando la riga di titolo corrispondente, e così via. Una pagina è dunque un muro, composto da tanti mattoni, di dimensione diversa: ogni tag è un mattone e il contenuto del tag determina la grandezza del mattone.

Il CSS ci permette di impostare e controllare tre proprietà spaziali, per ogni mattone: margin, padding e border. Border è il più semplice di tutti: è il perimetro del rettangolo e possiamo usarla per disegnare una “cornice” attorno a un elemento. Padding è lo spazio vuoto tra il bordo e il contenuto interno: se abbiamo deciso di racchiudere un paragrafo in una cornice, usando border, padding ci dirà quanto spazio bianco vedremo tra la cornice e il testo del paragrafo. Margin, infine, è lo spazio che separa il bordo di un tag dal bordo dei tag che lo circondano: è lo spazio che fa da cuscinetto tra un mattone e l’altro, separandoli. L’insieme di questi tre elementi forma il cosiddetto “modello a box”, nel CSS.

In breve, border segna il confine di un elemento, padding è lo spazio interno tra il confine e il contenuto dell’elemento, margin è lo spazio esterno tra il confine e gli altri elementi che lo circondano. Ognuna di queste tre proprietà può essere impostata individualmente, per ognuna delle quattro direzioni, oppure può essere impostata con un comando solo per tutti e quattro i lati. Inoltre, ognuna può essere impostata a zero, se vogliamo eliminare le formattazioni automatiche di alcuni tag (tipo <p>).

padding

Come detto, è lo spazio che separa il contenuto di un elemento dal suo bordo: se vogliamo disegnare una cornice attorno al testo, padding è la proprietà che dovremo impostare, per lasciare un certo spazio tra il bordo e il testo. Se un elemento utilizza la proprietà background-color, per colorare lo sfondo, allora anche la fascia di padding sarà colorata, in quanto è interno all'elemento.

A seconda dei casi, possiamo utilizzare una delle quattro varianti “locali” di padding, per impostarlo solo su un lato, oppure possiamo usare direttamente padding, per impostarlo in una volta sola su tutti e quattro i lati. Le quattro varianti sono padding-top, padding-right, padding-bottom, padding-left, sistemate come nella immagine soprastante: per ognuna possiamo indicare una delle unità di misura permesse dal CSS, per indicare quanto spazio lasciare. Ad esempio,

padding-top: 5px;
padding-left: 10px;

lasciano rispettivamente uno spazio vuoto di cinque pixel sopra il contenuto dell’elemento, e uno spazio vuoto di dieci pixel a sinistra del contenuto. Se invece scriviamo

padding: 5px 10px 5px 10px;

possiamo impostare in una volta sola la distanza per tutte e quattro le direzioni: in questo caso, il primo numero sarà la distanza in alto, il secondo la distanza a destra, il terzo la distanza in basso e il quarto la distanza a sinistra. Se vogliamo usare questa proprietà “unica”, è importante ricordare il corretto ordine: alto-destra-basso-sinistra, ossia top-right-bottom-left. Per memorizzare la sequenza, partite da sopra e muovetevi in senso orario. Se invece li impostiamo individualmente, non è importante seguire un ordine.

Infine, se vogliamo assegnare lo stesso valore a tutti e quattro i lati, possiamo utilizzare una formula ancora più breve, ossia

padding: 10px;

In questo modo, tutti e quattro i lati avranno un margine interno di dieci pixel (o di qualsiasi altro numero indicheremo).

margin

Come detto, è lo spazio che separa questo elemento dagli altri elementi che lo circondano: il suo “spazio vitale”, se preferite pensarla così. Funziona esattamente come padding, in tutto e per tutto, ma non sarà colorato, se abbiamo impostato un valore per background-color, in quanto lo spazio di margin non fa parte del nostro elemento, ma è esterno. Avremo dunque margin-top, margin-right, margin-bottom e margin-left, come proprietà individuali, e margin come proprietà unica, che le riassume tutte quante. Ad esempio,

margin-top: 12px;
margin-right: 8px;

imposteranno il margine esterno a dodici pixel in alto (margin-top) e a otto pixel sulla sinistra (margin-left). Utilizzando invece la formula abbreviata, possiamo scrivere

margin: 4px 5px 10px 6px;

così imposteremo un margine in alto di quattro pixel, a destra di cinque pixel, in basso di dieci pixel e a sinistra di sei pixel. Se vogliamo usare lo stesso numero per tutti e quattro i lati, la formula abbreviata resta sempre

margin: 5px;

proprio come abbiamo già visto per padding. Queste due proprietà funzionano allo stesso modo e cambia solo il luogo in cui collocano lo spazio vuoto nell'elemento: margin lo colloca all'esterno del bordo, padding lo colloca all'interno del bordo.

border

Concludiamo proprio col bordo. La proprietà border disegna una cornice attorno a un elemento e, può essere utilizzata sia per tracciare questa cornice attorno a tutto l’elemento, sia per tracciarla solo su alcuni dei quattro lati. Come i suoi colleghi, dunque, anche border ha le versioni specifiche, ossia border-top, border-right, border-bottom e border-left, che tracciano il bordo soltanto sul rispettivo lato del nostro elemento, ma i valori da attribuire a queste proprietà sono alquanto diversi: per disegnare un bordo, infatti, dovremo assegnare valori come il colore, lo spessore e lo stile.

Il primo valore che indichiamo, di solito, è lo spessore del bordo, espresso in pixel. Il secondo valore indica lo stile con cui sarà disegnato il bordo e lo possiamo scegliere tra i seguenti: solid, dotted, dashed, double, groove, ridge, inset, outset, none, hidden. Solid è una normale linea chiusa, dotted è una linea punteggiata, dashed una linea tratteggiata, double una linea doppia, none elimina il bordo, hidden lo nasconde (di fatto ottiene lo stesso risultato di none, cioè il bordo non si vedrà, ma nascondere una cosa è diverso da eliminarla), mentre gli altri quattro producono particolari effetti grafici, più semplici da vedere che da descrivere. Infine, il terzo valore è il colore che il bordo dovrà avere e lo possiamo impostare seguendo le regole già viste prima, parlando degli attributi color e background-color. Qualche esempio:

border: 2px dotted red;

border-bottom: 1px solid rgb(0, 0, 255);

nel primo caso, tracceremo su tutti e quattro i lati un bordo punteggiato, dallo spessore di due pixel e di colore rosso; nel secondo caso, tracceremo sotto l’elemento un bordo solido, dallo spessore di un pixel e di colore blu (una sottolineatura blu, insomma).

Possiamo utilizzare la forma abbreviata border, soltanto se vogliamo che il bordo sia identico su tutti e quattro i lati; se vogliamo disegnare bordi di spessore o di colore diverso, dovremo utilizzare le proprietà individuali per i quattro lati, ossia border-top, border-right, border-bottom e border-left. Non so perché qualcuno dovrebbe desiderare un bordo arlecchino e di dimensioni diverse, per una parte del proprio EPUB, ma questo è un altro paio di maniche: se il vostro senso estetico vi spinge in questa direzione, usate le quattro proprietà individuali; se siete tradizionalisti e volete un bordo uniforme su ogni lato, usate pure la formula abbreviata.

Ovviamente, border, margin e padding possono essere utilizzati su qualsiasi tipo di tag, ma non sempre otterremo il risultato previsto da noi. Lo HTML distingue infatti tra due tipi di tag, ossia quelli che creano un blocco nel testo e quelli che coabitano su una stessa linea. I tag <p> e <div> sono esempi tipici di tag che creano blocchi (servono proprio a dividere la pagina in sezioni logiche) e sono spesso accompagnati da una separazione grafica sullo schermo; i tag <b>, <span> e <a> sono esempi tipici di tag che coabitano su una stesa linea, senza dividere la pagina in blocchi. In caso di tag “in linea”, assegnare margini in alto e in basso non funzionerà come previsto, mentre i margini laterali non daranno problemi: non possiamo insomma usare padding-top o margin-bottom per aumentare lo spazio tra le linee. O almeno, non normalmente.

Esiste infatti una proprietà particolare, che ci permette di decidere se un tag dovrà comportarsi come un blocco, oppure come un tag “in linea”: è la proprietà display. Se a un tag assegniamo il valore

display: inline;

quel tag coabiterà pacificamente sulla stessa linea con altri tag, a prescindere da quale sia il suo tipo; se invece gli assegniamo il valore

display: block;

quel tag creerà un blocco indipendente all'interno della pagina, proprio come il tag <p>, e potremo controllare i sui margini su tutti e quattro i lati.
Nella prossima puntata, tireremo le somme.