Per chi non lo sapesse, ma anche per chi lo sa ma magari non ci pensava più, le specifiche nelle "icone nominate" definiscono alcune icone per indicare il livello di sicurezza di qualcosa (connessione wireless, affidabilità di un sito, altro...).
Ora, a parte il fatto che io aggiungerei una security-none e una security-broken (e magari fonderei -low e -medium), che ne pensate delle seguenti metafore?
:-)
31 maggio 2007
25 maggio 2007
Piatto ricco mi ci ficco
C'è un'aspetto che forse nessuno ha considerato nella "guerra dei desktop search engine": il fatto che, per come sta andando avanti ora, ne sopravviverà soltanto uno.
Sì perché al momento, in base a quanto so o ho letto in giro per la rete, l'unico punto su cui i vari desktop search engine stanno lavorando di comune accordo (o per lo meno l'unico punto comune a cui si possono riferire) è l'interfaccia per la definizione delle interrogazioni, cioè il progetto fd.o Xesam.
La possibilità di avere una comune "interfaccia" per effettuare una interrogazione è ovviamente cosa buonissima e giustissima, tanto per l'utente finale che cerca nei propri oggetti[1], quanto per gli sviluppatori che volessero rendere la propria applicazione "cercabile"[2]. Se poi tale interfaccia mi permettesse di scrivere interrogazioni complesse e flessibili come queste, allora tanto meglio[3].
Il punto è che ogni altro componente del search engine non è condiviso: non è condiviso il database in cui andare a cercare ciò che è indicizzato (e quindi debbo mantenere aggiornato un database per ogni search engine) e non sono condivisi gli estrattori che permettono di estrarre dati e metadati dagli oggetti (e quindi posso avere oggetti non supportati o supportati in modo diverso a seconda del search engine).
Tali mancanze precludono la modularità che da sempre contraddistingue i sistemi liberi come GNU/Linux, i vari *BSD, i vari *Solaris, modularità per la quale se un "pezzo" del sistema non mi piace, fosse esso il kernel, l'ambiente grafico, la shell, il browser, posso cambiarlo a costo tendente a zero.
Se io passo da una distribuzione di GNU/Linux a OpenSolaris, in gran parte non mi accorgo della differenza, ancor di meno me ne accorgo se entrambi usano per esempio GNOME come UI. Se io passo da Beagle a Tracker, o da un futuro GNOME con Tracker a un futuro KDE con Strigi, come prima cosa debbo reindicizzare tutti i miei oggetti - e non è detto che la cosa richieda poco tempo, anzi.
Analogo discorso per gli estrattori: guardando la questione con occhio lungimirante, non è possibile che il search engine fornisca estrattori per ogni tipo di file. Il search engine dovrebbe fornire una API o dello specifiche per far sì che sia l'applicazione stessa a fornire l'estrattore. La API, le specifiche e la disponibilità degli estrattori dovrebbe essere comune a tutti i search engine. Punto.
Se non è chiaro dove l'ultimo paragrafo volesse andare a parare, nell'attuale situazione, anche ammettendo che il search engine fornisca un modo per installare nuovi estrattori, cosa utilissima, ci troviamo nella condizione in cui ogni search engine dovrebbe/potrebbe avere, per esempio, un suo estrattore per i file JPEG fornito "out of the box" (il formato JPEG è un formato comune, non è proprio di una certa applicazione, quindi è pacifico che sia il search engine a installarlo) e dovrebbe/potrebbe avere anche un estattore per i file XCF fornito da GIMP. Non solo quindi mi troverei con N implementazioni diverse, con N numero di search engine disponibili, dell'estrattore per i file JPEG, ma gli sviluppatori di GIMP dovrebbero sviluppare N diversi estrattori.
Se dipendesse da me, accanto a Xesam cercherei di portare avanti anche una definizione e implementazione comune degli estrattori, qualcosa con una struttura simile ai plugin di GStreamer: un pacchetto extractors-base con gli estrattori di formati comuni/liberi come potrebbero essere i formati di immagini PNG, JPEG, TIFF, SVG, i formati di OpenDocument, i file di testo semplice, i file HTML, i file PDF e cose simili, e un pacchetto extractors-extra con altri estrattori per formati meno comuni e/o meno liberi come i documenti di MS Office o comunque che richiedano librerie o programmi di supporto esoterici. Il fatto che la definizione degli estrattori è comune permetterebbe poi agli sviluppatori di fornire estrattori per il formato proprietario usato dalla loro applicazione (cosa apprezzabile di certo da chi scrive software non libero, come potrebbe essere MathLab; ma ci pensate a cercare con Nautius una definizione di matrice MathLab?!?!?).
Sforando poi nel fanta-development, con estrattori comuni e interrogazioni comuni, non sarebbe possibile per un search engine interrogare direttamente il database di un altro search engine per costruire il suo, invece di scansionare tutti i file??? OK, questa forse è troppo azzardata...
Seth Nickell provò tempo fa a implementarlo in GNOME, come parte di un ambizioso progetto dal nome Storage, ma questo era talmente carico di funzionalità che cadde nel dimenticatoio prima ancora di diventare un minimo usabile. BTW ma che fine ha fatto Seth?!?!?
Con la prossima versione di MacOS Apple darà quindi ai suoi utenti qualcosa di molto simile a quello Storage sognato da molti pochi anni fa. Apple può farlo, non perché sia più brava, ma perché deve vedersela solo con se stessa: è lei che decide quale search engine fornire, quale file sytem, quale interfaccia per gli sviluppatori, non ha "competizione" tra diverse istanze. Ho deciso di inserire questa funzione e lo faccio in questo modo.
Per il software libero è diverso. Non che sia peggio, a me piace pensare e avere la possibilità di scegliere tra diversi progetti con stesse finalità, anche perché le migliorie di uno si riflettono nell'altro, ma, come il progetto freedestkop ci ha insegnato, è necessario permettere l'interoperabilità affinché tutti possano trarre vantaggio da questa varietà di contributi.
-------------------
[1] nel senso di non solo documento o immagine, ma anche conversazioni IM, contatti, calendari...
[2] e badate bene che per applicazioni "cercabili" intendo cose come F-Spot o Rhythmbox: se ho già un motore per definire delle query con cui limitare gli oggetti mostrati, perché mai dovrei scrivere nuovo codice?
[3] ovviamente per permettere agli sviluppatori di costruire applicazioni cercabili, il search engine deve permettere interrogazioni siffatte.
Sì perché al momento, in base a quanto so o ho letto in giro per la rete, l'unico punto su cui i vari desktop search engine stanno lavorando di comune accordo (o per lo meno l'unico punto comune a cui si possono riferire) è l'interfaccia per la definizione delle interrogazioni, cioè il progetto fd.o Xesam.
La possibilità di avere una comune "interfaccia" per effettuare una interrogazione è ovviamente cosa buonissima e giustissima, tanto per l'utente finale che cerca nei propri oggetti[1], quanto per gli sviluppatori che volessero rendere la propria applicazione "cercabile"[2]. Se poi tale interfaccia mi permettesse di scrivere interrogazioni complesse e flessibili come queste, allora tanto meglio[3].
Il punto è che ogni altro componente del search engine non è condiviso: non è condiviso il database in cui andare a cercare ciò che è indicizzato (e quindi debbo mantenere aggiornato un database per ogni search engine) e non sono condivisi gli estrattori che permettono di estrarre dati e metadati dagli oggetti (e quindi posso avere oggetti non supportati o supportati in modo diverso a seconda del search engine).
Tali mancanze precludono la modularità che da sempre contraddistingue i sistemi liberi come GNU/Linux, i vari *BSD, i vari *Solaris, modularità per la quale se un "pezzo" del sistema non mi piace, fosse esso il kernel, l'ambiente grafico, la shell, il browser, posso cambiarlo a costo tendente a zero.
Se io passo da una distribuzione di GNU/Linux a OpenSolaris, in gran parte non mi accorgo della differenza, ancor di meno me ne accorgo se entrambi usano per esempio GNOME come UI. Se io passo da Beagle a Tracker, o da un futuro GNOME con Tracker a un futuro KDE con Strigi, come prima cosa debbo reindicizzare tutti i miei oggetti - e non è detto che la cosa richieda poco tempo, anzi.
Analogo discorso per gli estrattori: guardando la questione con occhio lungimirante, non è possibile che il search engine fornisca estrattori per ogni tipo di file. Il search engine dovrebbe fornire una API o dello specifiche per far sì che sia l'applicazione stessa a fornire l'estrattore. La API, le specifiche e la disponibilità degli estrattori dovrebbe essere comune a tutti i search engine. Punto.
Se non è chiaro dove l'ultimo paragrafo volesse andare a parare, nell'attuale situazione, anche ammettendo che il search engine fornisca un modo per installare nuovi estrattori, cosa utilissima, ci troviamo nella condizione in cui ogni search engine dovrebbe/potrebbe avere, per esempio, un suo estrattore per i file JPEG fornito "out of the box" (il formato JPEG è un formato comune, non è proprio di una certa applicazione, quindi è pacifico che sia il search engine a installarlo) e dovrebbe/potrebbe avere anche un estattore per i file XCF fornito da GIMP. Non solo quindi mi troverei con N implementazioni diverse, con N numero di search engine disponibili, dell'estrattore per i file JPEG, ma gli sviluppatori di GIMP dovrebbero sviluppare N diversi estrattori.
Se dipendesse da me, accanto a Xesam cercherei di portare avanti anche una definizione e implementazione comune degli estrattori, qualcosa con una struttura simile ai plugin di GStreamer: un pacchetto extractors-base con gli estrattori di formati comuni/liberi come potrebbero essere i formati di immagini PNG, JPEG, TIFF, SVG, i formati di OpenDocument, i file di testo semplice, i file HTML, i file PDF e cose simili, e un pacchetto extractors-extra con altri estrattori per formati meno comuni e/o meno liberi come i documenti di MS Office o comunque che richiedano librerie o programmi di supporto esoterici. Il fatto che la definizione degli estrattori è comune permetterebbe poi agli sviluppatori di fornire estrattori per il formato proprietario usato dalla loro applicazione (cosa apprezzabile di certo da chi scrive software non libero, come potrebbe essere MathLab; ma ci pensate a cercare con Nautius una definizione di matrice MathLab?!?!?).
Sforando poi nel fanta-development, con estrattori comuni e interrogazioni comuni, non sarebbe possibile per un search engine interrogare direttamente il database di un altro search engine per costruire il suo, invece di scansionare tutti i file??? OK, questa forse è troppo azzardata...
Conclusioni, ammesso che se ne senta la necessità
Prima una premessa: quanti di voi seguivano lo sviluppo di GNOME nel 2002? Quanti di voi hanno mai senti parlare di Bowie J. Poag? Nel dicembre di quell'anno codesto Bowie postò sulla devel list di GNOME la proposta di un "desktop riavvolgibile". Ovviamente Mr. Poag altro non era che un troll. Però Apple promette per la prossima versione di OSX una applicazioncina dal nome Time Machine, che... beh, installatevi tutti i vari plugin di GStreamer e guardatevi il video nella pagina, è molto più chiaro di molte parole.Seth Nickell provò tempo fa a implementarlo in GNOME, come parte di un ambizioso progetto dal nome Storage, ma questo era talmente carico di funzionalità che cadde nel dimenticatoio prima ancora di diventare un minimo usabile. BTW ma che fine ha fatto Seth?!?!?
Con la prossima versione di MacOS Apple darà quindi ai suoi utenti qualcosa di molto simile a quello Storage sognato da molti pochi anni fa. Apple può farlo, non perché sia più brava, ma perché deve vedersela solo con se stessa: è lei che decide quale search engine fornire, quale file sytem, quale interfaccia per gli sviluppatori, non ha "competizione" tra diverse istanze. Ho deciso di inserire questa funzione e lo faccio in questo modo.
Per il software libero è diverso. Non che sia peggio, a me piace pensare e avere la possibilità di scegliere tra diversi progetti con stesse finalità, anche perché le migliorie di uno si riflettono nell'altro, ma, come il progetto freedestkop ci ha insegnato, è necessario permettere l'interoperabilità affinché tutti possano trarre vantaggio da questa varietà di contributi.
-------------------
[1] nel senso di non solo documento o immagine, ma anche conversazioni IM, contatti, calendari...
[2] e badate bene che per applicazioni "cercabili" intendo cose come F-Spot o Rhythmbox: se ho già un motore per definire delle query con cui limitare gli oggetti mostrati, perché mai dovrei scrivere nuovo codice?
[3] ovviamente per permettere agli sviluppatori di costruire applicazioni cercabili, il search engine deve permettere interrogazioni siffatte.
22 maggio 2007
Datore di lavoro
Qualcuno si offre volontario a stipendio zero per implementare la capplet nell'immagine allegata?
IMHO è il modo migliore per configurare l'ambiente grafico per chi ha problemi di vista, in attesa che le magie a la Compiz arrivino nel toolkit.
Aggiornamento: se a qualcuno andasse veramente di provare, dovrebbe provare a inserirlo direttamente nel modulo gnome-control-center (quindi le utili funzioni di interfaccia a GConf lì presenti e ovviamente scrivendo il codice in C). Le varie checkbox e radiobox, in pratica, altro non dovrebbero fare che impostare dei particolari e opportuni valori nelle chiavi GConf relative ai temi o ai caratteri, per esempio attivando la checkbox Use big text, si dovrebbe impostare a "Sans 18" le chiavi /desktop/gnome/interface/font_name e /desktop/gnome/interface/document_font_name, a "Monospace 18" la chiave /desktop/gnome/interface/monospace_font_name e a "Sans Bold 18" /apps/metacity/general/titlebar_font; disattivandola, invece, si potrebbe o azzerare i valori delle chiavi o, in una versione successiva e più avanzata, i valori che le chiavi avevano prima dell'attivazione.
Analogo discorso per Use big icons, con la cui attivazione si dovrebbe scegliere il tema LargePrint, HicolorLargePrint, HicolorInvertedLargePrint o LowcolorLargePrint in base a quanto impostato nella sezione Apperarance; notare che per impostare un tema si deve agire su tre chiavi, quella del tema dei controlli, quella del tema di metacity e quella del tema delle icone.
IMHO è il modo migliore per configurare l'ambiente grafico per chi ha problemi di vista, in attesa che le magie a la Compiz arrivino nel toolkit.
Aggiornamento: se a qualcuno andasse veramente di provare, dovrebbe provare a inserirlo direttamente nel modulo gnome-control-center (quindi le utili funzioni di interfaccia a GConf lì presenti e ovviamente scrivendo il codice in C). Le varie checkbox e radiobox, in pratica, altro non dovrebbero fare che impostare dei particolari e opportuni valori nelle chiavi GConf relative ai temi o ai caratteri, per esempio attivando la checkbox Use big text, si dovrebbe impostare a "Sans 18" le chiavi /desktop/gnome/interface/font_name e /desktop/gnome/interface/document_font_name, a "Monospace 18" la chiave /desktop/gnome/interface/monospace_font_name e a "Sans Bold 18" /apps/metacity/general/titlebar_font; disattivandola, invece, si potrebbe o azzerare i valori delle chiavi o, in una versione successiva e più avanzata, i valori che le chiavi avevano prima dell'attivazione.
Analogo discorso per Use big icons, con la cui attivazione si dovrebbe scegliere il tema LargePrint, HicolorLargePrint, HicolorInvertedLargePrint o LowcolorLargePrint in base a quanto impostato nella sezione Apperarance; notare che per impostare un tema si deve agire su tre chiavi, quella del tema dei controlli, quella del tema di metacity e quella del tema delle icone.
21 maggio 2007
È tanto liberatorio
A quanti è capitato di recarsi al proprio CED in cerca di un terminale libero e trovarne decine senza nessuno davanti a lavorare, ma con lo schermo bloccato dal salvaschermo? A me diverse volte. È frustrante, specie se tutt'intorno campeggiano diversi minacciosi cartelli con la scritta:
Se siete stati in passato vittime di tali angherie, d'ora in avanti un gruppo di supereroi fuorilegge noti come GNOME Developers correrà in vostro aiuto.
Un nuovo pulsante infatti è stato piazzato nel dialogo di autenticazione e sblocco del salvaschermo. C'era già il comodo Cambia utente, che magari però i sysadmin disabilitavano nella presunzione di innocenza (cioè per chi si allontana per meno di 15 minuti, tempo utile per una telefonata, una sigaretta, una bibita o altro). Ora al suo fianco c'è il tanto liberatorio Lascia messaggio.
Basta un clic ben assestato su Lascia messaggio per permettervi di lasciare ogni genere di improperio al maleducato occupante del terminale pubblico. Per esempio:
Al suo ritorno il maleducato occupante troverà il vostro messaggio pieno di insulti sulla sua scrivania sotto forma di notifica.
Ovviamente è anche possibile la funzionalità inversa, ossia lasciare sul dialogo di sblocco un messaggio - tipo "away" da messagistica istantanea. Al momento è possibile accedere a tale funzionalità solo modificando direttamente la chiave GConf che contiene il messaggio da lasciare.
PS la cosa un po' triste è che non si tratta una nuova funzionalità genuina; sebbene dovrebbe essere il primo ambiente grafico a consentire una cosa del genere in modo predefinito, una rapida ricerca su google ha riportato almeno un paio di addon per windows con funzionalità di messagistica :-|
Non ci si allontana per più di 15 minuti.
Se siete stati in passato vittime di tali angherie, d'ora in avanti un gruppo di supereroi fuorilegge noti come GNOME Developers correrà in vostro aiuto.
Un nuovo pulsante infatti è stato piazzato nel dialogo di autenticazione e sblocco del salvaschermo. C'era già il comodo Cambia utente, che magari però i sysadmin disabilitavano nella presunzione di innocenza (cioè per chi si allontana per meno di 15 minuti, tempo utile per una telefonata, una sigaretta, una bibita o altro). Ora al suo fianco c'è il tanto liberatorio Lascia messaggio.
Basta un clic ben assestato su Lascia messaggio per permettervi di lasciare ogni genere di improperio al maleducato occupante del terminale pubblico. Per esempio:
Al suo ritorno il maleducato occupante troverà il vostro messaggio pieno di insulti sulla sua scrivania sotto forma di notifica.
Ovviamente è anche possibile la funzionalità inversa, ossia lasciare sul dialogo di sblocco un messaggio - tipo "away" da messagistica istantanea. Al momento è possibile accedere a tale funzionalità solo modificando direttamente la chiave GConf che contiene il messaggio da lasciare.PS la cosa un po' triste è che non si tratta una nuova funzionalità genuina; sebbene dovrebbe essere il primo ambiente grafico a consentire una cosa del genere in modo predefinito, una rapida ricerca su google ha riportato almeno un paio di addon per windows con funzionalità di messagistica :-|
17 maggio 2007
A ciascuno il proprio
Liberation sì, Liberation no, l'Italia è divisa. Brevetti sì, brevetti no, la comunità se la ride.
Facendo la somma
Microsoft + Proprietà Intellettuale[1] + Font
otteniamo... una strana notizia, trovata quasi per caso - ma esistono le coincidenze? Froid, o forse Gil Grissom, non ne era molto sicuro.
Insomma, l'innovativa MS che sacrosantemente se la prende con questi ladri dell'opensurcio che fregano il lavoro la macchina e la donna ai seri addetti dell'ambiente IT, non troppo tempo fa si trovò anche lei di fronte alla necessità di fornire ai suoi utenti un nuovo font che andasse a sostituire il vetusto Tahoma. Necessità legata alle ottimizzazioni per piccoli schermi, magari non LCD, che Tahoma si portava appresso. Il nuovo font, Segoe UI, sarebbe dovuto essere "più amichevole, umanistico e meno computeristico" - se poi mi spiegate come fa un font a essere umanistico....
Ora, pare che tale Segoe UI altro non sia che una copia di altro font, tale Frutiger Next, così come Arial è copia di Helvetica.
Se volete, il CD con 36 (trentasei) diversi pesi di Frutiger è disponibile per l'acquisto a soli 950€. Oppure potete continuare a fare gli opensurcisti e cercare su qualche sito di bittorrent, tanto ladri più, ladri meno...
Oh, ovviamente Segoe UI e gli altri 6 font distribuiti con Window Svista possono essere tranquillamente trovati e scaricati sul web, senza nessuno che se ne lamenti...
[1] qualunque cosa ciò significhi
Facendo la somma
Microsoft + Proprietà Intellettuale[1] + Font
otteniamo... una strana notizia, trovata quasi per caso - ma esistono le coincidenze? Froid, o forse Gil Grissom, non ne era molto sicuro.
Insomma, l'innovativa MS che sacrosantemente se la prende con questi ladri dell'opensurcio che fregano il lavoro la macchina e la donna ai seri addetti dell'ambiente IT, non troppo tempo fa si trovò anche lei di fronte alla necessità di fornire ai suoi utenti un nuovo font che andasse a sostituire il vetusto Tahoma. Necessità legata alle ottimizzazioni per piccoli schermi, magari non LCD, che Tahoma si portava appresso. Il nuovo font, Segoe UI, sarebbe dovuto essere "più amichevole, umanistico e meno computeristico" - se poi mi spiegate come fa un font a essere umanistico....
Ora, pare che tale Segoe UI altro non sia che una copia di altro font, tale Frutiger Next, così come Arial è copia di Helvetica.
Se volete, il CD con 36 (trentasei) diversi pesi di Frutiger è disponibile per l'acquisto a soli 950€. Oppure potete continuare a fare gli opensurcisti e cercare su qualche sito di bittorrent, tanto ladri più, ladri meno...
Oh, ovviamente Segoe UI e gli altri 6 font distribuiti con Window Svista possono essere tranquillamente trovati e scaricati sul web, senza nessuno che se ne lamenti...
[1] qualunque cosa ciò significhi
16 maggio 2007
Oh mio zio!
Fresca fresca dalla mia cartella di posta in entrata:
No, ho solo una buona memoria e mi sono ricordato di quel tizio, un'annetto fa, in Germania o dintorni, che ricevette un simile avviso, si costituì e gli spiegarono che in realtà era uno spam/virus.
Mica 'so siemo, hio.
AvvisoCapire che si trattava di un messaggio malevolo non è stato semplice: siete mai stati a sporgere denuncia per qualcosa? Vi hanno mai riletto il verbale che dovrebbe riportare ciò che avete esposto? In tal caso sapete che la sintassi e la grammatica corrispondono a quella usata in questo messaggio.
Sono capitano della polizia Prisco Mazzi. I rusultati dell'ultima verifica hanno rivelato che dal Suo computer sono stati visitati i siti che trasgrediscono i diritti d'autore e sono stati scaricati i file pirati nel formato mp3. Quindi Lei e un complice del reato e puo avere la responsabilita amministrativa.
Il suo numero nel nostro registro e 00098361420.
Non si puo essere errore, abbiamo confrontato l'ora dell'entrata al sito nel registro del server e l'ora del Suo collegamento al Suo provider. Come e l'unico fatto, puo sottrarsi alla punizione se si impegna a non visitare piu i siti illegali e non trasgredire i diritti d'autore.
Per questo per favore conservate l'archivio (avviso_98361420.zip parola d'accesso: 1605) allegato alla lettera al Suo computer, desarchiviatelo in una cartella e leggete l'accordo che si trova dentro.
La vostra parola d'accesso personale per l'archivio: 1605
E obbligatorio.
Grazie per la collaborazione.
No, ho solo una buona memoria e mi sono ricordato di quel tizio, un'annetto fa, in Germania o dintorni, che ricevette un simile avviso, si costituì e gli spiegarono che in realtà era uno spam/virus.
Mica 'so siemo, hio.
Scelte alimentari
P5160008.JPG
Originally uploaded by elleuca.
Magari non avrò visto così tante patatine in vita mia, non ne avrò prese tre alla volta e, forza maggiore, riesco anche a farne a meno, ma affondare il cucchiaio in una caraffa di Nutella da 1 Kg sa dare le sue brave emozioni :-)
14 maggio 2007
The Kids Aren't Alright
È proprio vero che alle volta basta poco. Per esempio sarebbe bastato inserire "kids" nella finestra di ricerca di Tracker per scrivere un post solo invece di due. Ma tant'è.
Nel post precedente, parlavo di un tema per giovanissimi utenti di GNU/Linux e GNOME. Diciamo quella fascia d'età che invece di stare davanti a un computer dovrebbe essere chiusa all'asilo o in ludoteca - o in entrambi, asilo di mattina, ludoteca di pomeriggio - a subire abusi vari <nota per le forze dell'ordine che leggeranno questo periodo: soffro di una grave sindrome di ironia acuta, che mi impedisce di pronunciare o scrivere frasi senza un metterci in mezzo doppi sensi, rimandi, e cose del genere>
Un tema per tale pubblico non può ovviamente sottostare alle stesse regole di un tema per il resto del mondo. Quest'ultimo infatti dovrebbe essere chiaro, leggibile, non distraente, ma pur sempre visivamente appagante - leggi: far credere all'utente che lui è figo perché il suo computer è figo e gli altri no.
Se ne parlò parecchio tempo fa sulla mailing list di gnome-art, proprio quando Cairo fu rilasciato e usato nelle GTK+ (o forse ancora prima con librsvg). Il buon Andreass Nielssen se ne uscì con il seguente mockup per i controlli
e quest'altro per il desktop
Magari ora che il buon Cimi sembra avere voglia di scrivere codice, si potrebbe rispolverare l'idea.
Nel post precedente, parlavo di un tema per giovanissimi utenti di GNU/Linux e GNOME. Diciamo quella fascia d'età che invece di stare davanti a un computer dovrebbe essere chiusa all'asilo o in ludoteca - o in entrambi, asilo di mattina, ludoteca di pomeriggio - a subire abusi vari <nota per le forze dell'ordine che leggeranno questo periodo: soffro di una grave sindrome di ironia acuta, che mi impedisce di pronunciare o scrivere frasi senza un metterci in mezzo doppi sensi, rimandi, e cose del genere>
Un tema per tale pubblico non può ovviamente sottostare alle stesse regole di un tema per il resto del mondo. Quest'ultimo infatti dovrebbe essere chiaro, leggibile, non distraente, ma pur sempre visivamente appagante - leggi: far credere all'utente che lui è figo perché il suo computer è figo e gli altri no.
Se ne parlò parecchio tempo fa sulla mailing list di gnome-art, proprio quando Cairo fu rilasciato e usato nelle GTK+ (o forse ancora prima con librsvg). Il buon Andreass Nielssen se ne uscì con il seguente mockup per i controlli
e quest'altro per il desktop
Magari ora che il buon Cimi sembra avere voglia di scrivere codice, si potrebbe rispolverare l'idea.
Evoluzione della specie
In principio era Clearlooks e Clearlooks era cosa buona. Poi fu Clearlooks Cairo e fu cosa meno buona[1].
Poi venne Clearlooks Glossy[2] e per molti fu cosa strafiga.
Ultimo arrivò Clearlooks Gummy e per quasi tutti è ancora cosa sconosciuta.
E bravo Cimi, è interessante vedere nella pratica come è possibile ottenere stili diversi cambiando un po' i gradienti. Da parte mia, per GNOME 2.20, che se non ve ne foste accorti sarà la 10 versione stabile di GNOME2, avrei amato qualcosa tipo l'azzeramento di tutti i temi e stili esistenti (a11y esclusi, ovvio) per ripartire con qualcosa di ehi-guarda-il-mio-computer-quanto-è-più-ganzo-del-tuo per gli utenti e di utile e flessibile per chi volesse fare il theme designer.
Condivido appieno l'idea di Cimi di usare un solo engine e di fornire diversi stili (meno codice da mantenere, meno casini in installazione, più pulizia, più facile e meno oneroso di risorse scrivere un tema che ne mischi due o più). Se proprio dovessi esprimere una preferenza, se qualcuno avesse a cuore le mie opinioni, mi piacerebbe avere quattro o cinque stili, ognuno caratterizzante o caratterizzato da un diverso materiale: Vetro, Plastica, Metallo, Carta e Carbone.
Vetro sarebbe ovviamente uno stile tipo-Glossy, vanno molto di moda e sarebbe un peccato non averlo; Plastica qualcosa di plasticoso come appunto il nuovo Gummy o il mochup del tema "ufficiale" per Tango o le barre di scorrimento di iTunes 7; Metallo non ne ho proprio idea; Carta uno stile piatto e senza gradienti che lo facciano apparire tridimensionale; Carbone infine, più che uno stile a sé, dovrebbe essere una opzione per rendere migliori i precedenti quando il theme designer volesse fare un tema scuro alla Darkgiloche o Ubuntustudio. Magari una rapida immagine rende meglio l'idea:
Notare come l'outline scuro e quello chiaro, di ovvia derivazione Tanghiana, siano invertiti in Carbon, piccolezza che dovrebbe garantire una migliore resa del tema proprio con colori scuri - il colore del bordo di un widget, al momento, dovrebbe essere scelto rendendo più scuro il colore primario del widget stesso; se il widget è già scuro, per metterne in risalto il bordo, allora sarebbe meglio schiarire; in Paper, oltre all'assenza di gradienti, c'è un solo outline, magari più spesso e con maggiore contrasto rispetto al colore del widget- tale stile potrebbe essere utile sia per creare temi semplici senza trascendere nell'HighContrast, sia colorati temi per bambini piccoli (ricordo un mochup tanto tanto tempo fa, ma non riesco a trovarlo...)
Per ogni stile si potrebbe poi fornire con GNOME 2.20 un diverso tema con diverso schema di colore (che so, Plastica tendente al verde, Vetro tendente al blu e così via), in modo che di base l'utente ha 5 stili e 5 schemi di colore diverso (ricordate che da GNOME 2.18 si possono avere anche i colori temizzabili, vero?) - cosa che, a onor del vero, non accade con l'attuale triade Clearlooks/Glossy/Gummy, tutti tendenti al blu :-(
Chicca finale: come tutte le linee evolutive che si rispettino, anche nei temi vi sono rami "morti". Con l'ingresso di Gummy in gnome-themes, Cimi ha rimosso il tema Inverted. A me piaceva, specie perché faceva uso di colori diversi e freschi. Spero che Cimi possa pubblicarlo su art.gnome.org (magari con un nome diverso... magari "Neanderthal" ). Eccovene una schermata.
Note per i lettori che hanno cose di meglio da fare che leggersi il ChangeLog di gtk-engines
[1] sono almeno due anni che ad ogni versione si aggiorna Clearlooks Cairo in modo che sia più simile al Clearlooks originale
[2] glossy è una opzione di clearlooks
Poi venne Clearlooks Glossy[2] e per molti fu cosa strafiga.
Ultimo arrivò Clearlooks Gummy e per quasi tutti è ancora cosa sconosciuta.
E bravo Cimi, è interessante vedere nella pratica come è possibile ottenere stili diversi cambiando un po' i gradienti. Da parte mia, per GNOME 2.20, che se non ve ne foste accorti sarà la 10 versione stabile di GNOME2, avrei amato qualcosa tipo l'azzeramento di tutti i temi e stili esistenti (a11y esclusi, ovvio) per ripartire con qualcosa di ehi-guarda-il-mio-computer-quanto-è-più-ganzo-del-tuo per gli utenti e di utile e flessibile per chi volesse fare il theme designer.Condivido appieno l'idea di Cimi di usare un solo engine e di fornire diversi stili (meno codice da mantenere, meno casini in installazione, più pulizia, più facile e meno oneroso di risorse scrivere un tema che ne mischi due o più). Se proprio dovessi esprimere una preferenza, se qualcuno avesse a cuore le mie opinioni, mi piacerebbe avere quattro o cinque stili, ognuno caratterizzante o caratterizzato da un diverso materiale: Vetro, Plastica, Metallo, Carta e Carbone.
Vetro sarebbe ovviamente uno stile tipo-Glossy, vanno molto di moda e sarebbe un peccato non averlo; Plastica qualcosa di plasticoso come appunto il nuovo Gummy o il mochup del tema "ufficiale" per Tango o le barre di scorrimento di iTunes 7; Metallo non ne ho proprio idea; Carta uno stile piatto e senza gradienti che lo facciano apparire tridimensionale; Carbone infine, più che uno stile a sé, dovrebbe essere una opzione per rendere migliori i precedenti quando il theme designer volesse fare un tema scuro alla Darkgiloche o Ubuntustudio. Magari una rapida immagine rende meglio l'idea:
Notare come l'outline scuro e quello chiaro, di ovvia derivazione Tanghiana, siano invertiti in Carbon, piccolezza che dovrebbe garantire una migliore resa del tema proprio con colori scuri - il colore del bordo di un widget, al momento, dovrebbe essere scelto rendendo più scuro il colore primario del widget stesso; se il widget è già scuro, per metterne in risalto il bordo, allora sarebbe meglio schiarire; in Paper, oltre all'assenza di gradienti, c'è un solo outline, magari più spesso e con maggiore contrasto rispetto al colore del widget- tale stile potrebbe essere utile sia per creare temi semplici senza trascendere nell'HighContrast, sia colorati temi per bambini piccoli (ricordo un mochup tanto tanto tempo fa, ma non riesco a trovarlo...)
Per ogni stile si potrebbe poi fornire con GNOME 2.20 un diverso tema con diverso schema di colore (che so, Plastica tendente al verde, Vetro tendente al blu e così via), in modo che di base l'utente ha 5 stili e 5 schemi di colore diverso (ricordate che da GNOME 2.18 si possono avere anche i colori temizzabili, vero?) - cosa che, a onor del vero, non accade con l'attuale triade Clearlooks/Glossy/Gummy, tutti tendenti al blu :-(
Chicca finale: come tutte le linee evolutive che si rispettino, anche nei temi vi sono rami "morti". Con l'ingresso di Gummy in gnome-themes, Cimi ha rimosso il tema Inverted. A me piaceva, specie perché faceva uso di colori diversi e freschi. Spero che Cimi possa pubblicarlo su art.gnome.org (magari con un nome diverso... magari "Neanderthal" ). Eccovene una schermata.
Note per i lettori che hanno cose di meglio da fare che leggersi il ChangeLog di gtk-engines
[1] sono almeno due anni che ad ogni versione si aggiorna Clearlooks Cairo in modo che sia più simile al Clearlooks originale
[2] glossy è una opzione di clearlooks
12 maggio 2007
3 orizzontale: quotidiano comunista a diffusione nazionale
Soluzione: Liberazione
OK, non era facile come domanda, ma la cosa verameeente affascinante è che il giornale non c'entra niente con contenuto di questo post. Questo post infatti si occuperà della nuova famiglia di font/fonte/tipo\ di\ carattere pubblicamente rilasciato da RedHat pochi giorni fa.
Visto che siamo così fortunati da avere anche un comunicato ufficiale, andiamo a vedere cosa dice.
Ovviamente si parte dal fatto che il rilascio nasce da un'esigenza, anzi un'esigenza fondamentale dell'ecosistema di GNU/Linux: senza di esso i sistemi operativi liberi/aperti e le loro interfacce grafiche resterebbero sempre in secondo piano rispetto alla contropartita di Microsoft.
Tale esigenza è l'avere disponibile, gnuliberamente[1] disponibile, un tipo di carattere che abbia la stessa metrica dei tipi di carattere distribuiti (ma non gnuliberamente) con Microsoft Windows e/o con Microsoft Office. Attenzione non lo stesso aspetto/stile, ma la stessa metrica, ossia, traducendo dal comunicato "tipi di carattere che assumano la stessa spaziatura orizzontale di quelli Microsoft in modo che, quando sostituiti a quelli di MS, una riga di testo sia visualizzata nello stesso modo". Per capire cosa ciò voglia dire, ecco una bella schermata catturata da OpenOffice.org Writer e ritagliata:
Notare come nelle prime due la larghezza del testo, a parità di dimensione in punti (12) sia pressoché la stessa, sebbene la forma della lettere sia diversa, mentre la terza riga appare enormemente più larga. Ecco spiegato in pratica la differenza di metrica.
Tale differenza è identificabile come problema perché in primo luogo Microsoft "forza" i suoi avventori a usare tali tipi di carattere, impostandoli come predefiniti nella stesura di documenti, in secondo luogo perché tali tipi non sono liberamente (ri)distribuibili. In pratica, allo stato attuale, sarebbe impossibile visualizzare in modo corretto - e senza infrangere la EULA sulla ridistribuzione e/o il riutilizzo dei tipi di carattere di MS - la gran parte dei documenti prodotti con sistemi MS - specie considerando che l'utente medio di MS Word non cambia il tipo di carattere predefinito se non con qualche oscuro font che ha solo lui, che gli pare figo, ma che in realtà è illegibile e inguardabile e altresì considerando che l'utente medio, ma anche quello avanzato, non è avvezzo a usare la divisione logica del testo in titoli e paragrafi, ma inserisce nuovi paragrafi e a capo in base a come gli appare davanti il testo (ecco perché, credo, dicono che la metrica è importante, un testo basato su paragrafi se ne frega della metrica, no?).
Per risolvere questa mancanza e per liberare i nostri computer, RedHat ha quindi progettato un nuovo tipo di carattere... momento, non lo ha progettato né sviluppato, ma ha chiesto ad Ascendent Corp. di farlo in sua vece. Ascendent che, oltre ad essere una ditta che sviluppa tipi di carattere, è anche LA ditta che ha sviluppato per MS i tipi di carattere che RedHat giudica dannosi per la nostra libertà.
La cosa affascinante è la modalità con cui questo nuovo tipo di carattere è stato rilasciato: i diritti su di esso sono comunque mantenuti da Ascendent, che può fornirlo a terzi secondo una tradizionale licenza proprietaria, RedHat però riceve una licenza che le permette di sublicenziare a costo zero i tipi di carattere secondo i termini della "GPL+font exception".
Le eccezioni alla GPL sono che se si inserisce (embed) il tipo di carattere in un documento, il documento non sarà automaticamente coperto da GPL (modificando il font, non si è obbligati a mantenere tale eccezione), più un'altra di cui francamente non comprendo appieno l'utilità visto che è già sotto GPL (riguarda la disponibilità di accesso a oggetto e sorgente, ma forse con termini lievemente diversi).
RedHat ci tiene poi a precisare che lo sviluppo di questi tipi di carattere avverrà in due fasi: nella prima, quella appena raggiunta, si prevede il rilascio di un gruppo di tipi di carattere utilizzabili, nella seconda, alla fine dell'anno, un successivo rilascio dello stesso gruppo di caratteri, ma con supporto completo per l'hinting.
Domanda polemica numero 1: perché chiedere i servigi di Ascendent? Capisco che, visto che si volevano font che sarebbero andati a sostituire altri font prodotti da loro, avrebbero saputo dove mettere le mani, ma in fondo esistono già entità che hanno prodotto font con licenza libera (vedi SIL per Gentium e Bitstream per Vera) e che hanno comunque all'attivo migliaia di font prodotti (troppo spesso proprietari: Bitstream per esempio vende un CD con 1450 font a circa 1$ l'uno). Continuare a collaborare con loro sarebbe stato un bel riconoscimento per i precedenti prodotti e per la precedente volontà di usare licenze libere per i loro prodotti.
Domanda polemica numero 2: perché questo valzer di diritti e licenze? Non era più chiaro e più indice di "non siamo secondi a nessuno" se i font erano da subito liberi, senza il sublicenziamento? Giuro che non lo capisco, anche perché a questo punto, chi andrebbe a chiedere ad Ascendent di licenziarli il font quando può prenderlo da RedHat sotto GPL? Magari quelli che costruiscono stampanti? Mah!
Domanda polemica numero 3: con tutto il casino dei brevetti sugli algoritmi di rendering dei font, come cacchio spera RedHat che alla fine non ci si possa accorgere della differenza? Cavoli, qui (nel mio ambiente GNOME, intendo), basta cambiare una opzione nella scheda Dettagli dello strumento di preferenze Tipi di carattere che cambia tutto!! Quando ci si occuperà per benino di FreeType, dotandola di un algoritmo cazzuto, magari liberamente patentato[2]?
Domanda polemica numero 4: e macos? (nota per il lettore: la precedente domanda è da leggersi tipo "e la macelleria?" in Non ci resta che piangere) come funziona la metrica dei tipi di carattere predefiniti di MacOS? Risolve anche quella o in fatto che non sia nominato vuol dire che è tutt'altro problema?
Innanzitutto scordatevi di usare Liberation Sans e Liberation Mono come sostituto degli analoghi Vera (o DejaVu): leggetevi le note di rilascio della famiglia Vera per capire quanta cura si sia destinata affinché funzionassero al meglio con Freetype. D'altro canto, come mostrato nell'immagine predente, le dimensioni sono ben diverse, per cui al momento non è pensabile usare in modo indifferente e interscambiabile Vera e Libertation. La finalità delle due famiglie è diversa, per cui credo sia necessario diversificare l'ambito.
La famiglia Liberation è pensata invece per essere usata in modo interscambiabile e indifferente con Times New Roman, Arial e Courier New. Sfruttando i meccanismi di alias forniti da Fontconfig (ossia quella porzione di sw che si occupa di scegliere quale file TTF caricare dall'hard disk quando un'applicazione chiede una certa famiglia di font), si dovrebbe fare in modo di usare Liberation Serif al posto di Times New Roman e via dicendo.
Proviamo con un esempio più completo, ossia il testo dell'annuncio visualizzato in Epiphany con i tre caratteri (è una gif animata). Nelle prime due schede, tranne qualche differenza su glifi, curvature e posizioni dei puntini sulle i, il posizionamento del testo sulla pagina è pressoché identico. Diverso il discorso per la terza scheda, quella che fa uso di Vera Serif: il carattere è bello, ma il testo è posizionato in modo completamente differente.
Partendo quindi dal presupposto che su un sistema GNU/Linux (ma anche *BSD o altro, non siamo così limitati), le famiglie incriminate non sono e non dovrebbero essere disponibili, che comunque volenti o nolenti sul web o nei documenti tali famiglie sono usati, ben venga l'opera di RedHat. Specie se nella seconda futura incarnazione saranno curati nella resa con Freetype così come i Bitstream Vera.
Orsù quindi, pinguini e diavoletti, cerbiatti, ochette e gibboni, scaricate i tipi di carattere e usate questo file per applicare la sostituzione a tutti i programmi basati su Fontconfig (il che vuol dire praticamente tutto ciò che è basato su GTK+, ma forse non Mozilla e OpenOffice.org, i quali potrebbero dover essere configurati a parte).
---------------------
[1] neologismo appena inventato
[2] liberamente patentato indica registrato come altri brevetti, ma con la garanzia che chiunque possa usarlo se in modo libero. Lo so che è un controsenso, ma IBM e la stessa RedHat hanno già fatto cose simili.
OK, non era facile come domanda, ma la cosa verameeente affascinante è che il giornale non c'entra niente con contenuto di questo post. Questo post infatti si occuperà della nuova famiglia di font/fonte/tipo\ di\ carattere pubblicamente rilasciato da RedHat pochi giorni fa.
La storia finora
Perché parlare di un evento che epocale certo non sembra, vista la mole di tipi di carattere disponibili più o meno legalmente sul web? Secondo me perché forse non si è capita (o non si è espressa in modo chiaro per tutti i lettori, cfr il post di Felipe) la finalità e la portata del rilascio.Visto che siamo così fortunati da avere anche un comunicato ufficiale, andiamo a vedere cosa dice.
Ovviamente si parte dal fatto che il rilascio nasce da un'esigenza, anzi un'esigenza fondamentale dell'ecosistema di GNU/Linux: senza di esso i sistemi operativi liberi/aperti e le loro interfacce grafiche resterebbero sempre in secondo piano rispetto alla contropartita di Microsoft.
Tale esigenza è l'avere disponibile, gnuliberamente[1] disponibile, un tipo di carattere che abbia la stessa metrica dei tipi di carattere distribuiti (ma non gnuliberamente) con Microsoft Windows e/o con Microsoft Office. Attenzione non lo stesso aspetto/stile, ma la stessa metrica, ossia, traducendo dal comunicato "tipi di carattere che assumano la stessa spaziatura orizzontale di quelli Microsoft in modo che, quando sostituiti a quelli di MS, una riga di testo sia visualizzata nello stesso modo". Per capire cosa ciò voglia dire, ecco una bella schermata catturata da OpenOffice.org Writer e ritagliata:
Tale differenza è identificabile come problema perché in primo luogo Microsoft "forza" i suoi avventori a usare tali tipi di carattere, impostandoli come predefiniti nella stesura di documenti, in secondo luogo perché tali tipi non sono liberamente (ri)distribuibili. In pratica, allo stato attuale, sarebbe impossibile visualizzare in modo corretto - e senza infrangere la EULA sulla ridistribuzione e/o il riutilizzo dei tipi di carattere di MS - la gran parte dei documenti prodotti con sistemi MS - specie considerando che l'utente medio di MS Word non cambia il tipo di carattere predefinito se non con qualche oscuro font che ha solo lui, che gli pare figo, ma che in realtà è illegibile e inguardabile e altresì considerando che l'utente medio, ma anche quello avanzato, non è avvezzo a usare la divisione logica del testo in titoli e paragrafi, ma inserisce nuovi paragrafi e a capo in base a come gli appare davanti il testo (ecco perché, credo, dicono che la metrica è importante, un testo basato su paragrafi se ne frega della metrica, no?).
Per risolvere questa mancanza e per liberare i nostri computer, RedHat ha quindi progettato un nuovo tipo di carattere... momento, non lo ha progettato né sviluppato, ma ha chiesto ad Ascendent Corp. di farlo in sua vece. Ascendent che, oltre ad essere una ditta che sviluppa tipi di carattere, è anche LA ditta che ha sviluppato per MS i tipi di carattere che RedHat giudica dannosi per la nostra libertà.
La cosa affascinante è la modalità con cui questo nuovo tipo di carattere è stato rilasciato: i diritti su di esso sono comunque mantenuti da Ascendent, che può fornirlo a terzi secondo una tradizionale licenza proprietaria, RedHat però riceve una licenza che le permette di sublicenziare a costo zero i tipi di carattere secondo i termini della "GPL+font exception".
Le eccezioni alla GPL sono che se si inserisce (embed) il tipo di carattere in un documento, il documento non sarà automaticamente coperto da GPL (modificando il font, non si è obbligati a mantenere tale eccezione), più un'altra di cui francamente non comprendo appieno l'utilità visto che è già sotto GPL (riguarda la disponibilità di accesso a oggetto e sorgente, ma forse con termini lievemente diversi).
RedHat ci tiene poi a precisare che lo sviluppo di questi tipi di carattere avverrà in due fasi: nella prima, quella appena raggiunta, si prevede il rilascio di un gruppo di tipi di carattere utilizzabili, nella seconda, alla fine dell'anno, un successivo rilascio dello stesso gruppo di caratteri, ma con supporto completo per l'hinting.
Ciò che le fonti non dicono
Bene, bravi, dieci più. Ma ho qualche dubbio, qualche polemichina, qualche sassolino nella scarpa che mi fa tanto tanto male, ahi!Domanda polemica numero 1: perché chiedere i servigi di Ascendent? Capisco che, visto che si volevano font che sarebbero andati a sostituire altri font prodotti da loro, avrebbero saputo dove mettere le mani, ma in fondo esistono già entità che hanno prodotto font con licenza libera (vedi SIL per Gentium e Bitstream per Vera) e che hanno comunque all'attivo migliaia di font prodotti (troppo spesso proprietari: Bitstream per esempio vende un CD con 1450 font a circa 1$ l'uno). Continuare a collaborare con loro sarebbe stato un bel riconoscimento per i precedenti prodotti e per la precedente volontà di usare licenze libere per i loro prodotti.
Domanda polemica numero 2: perché questo valzer di diritti e licenze? Non era più chiaro e più indice di "non siamo secondi a nessuno" se i font erano da subito liberi, senza il sublicenziamento? Giuro che non lo capisco, anche perché a questo punto, chi andrebbe a chiedere ad Ascendent di licenziarli il font quando può prenderlo da RedHat sotto GPL? Magari quelli che costruiscono stampanti? Mah!
Domanda polemica numero 3: con tutto il casino dei brevetti sugli algoritmi di rendering dei font, come cacchio spera RedHat che alla fine non ci si possa accorgere della differenza? Cavoli, qui (nel mio ambiente GNOME, intendo), basta cambiare una opzione nella scheda Dettagli dello strumento di preferenze Tipi di carattere che cambia tutto!! Quando ci si occuperà per benino di FreeType, dotandola di un algoritmo cazzuto, magari liberamente patentato[2]?
Domanda polemica numero 4: e macos? (nota per il lettore: la precedente domanda è da leggersi tipo "e la macelleria?" in Non ci resta che piangere) come funziona la metrica dei tipi di carattere predefiniti di MacOS? Risolve anche quella o in fatto che non sia nominato vuol dire che è tutt'altro problema?
Alla fine della fiera
Polemiche a parte, qual è il reale vantaggio? Dipende dai punti di vista e da come si pensa di usare la famiglia di tipi di carattere.Innanzitutto scordatevi di usare Liberation Sans e Liberation Mono come sostituto degli analoghi Vera (o DejaVu): leggetevi le note di rilascio della famiglia Vera per capire quanta cura si sia destinata affinché funzionassero al meglio con Freetype. D'altro canto, come mostrato nell'immagine predente, le dimensioni sono ben diverse, per cui al momento non è pensabile usare in modo indifferente e interscambiabile Vera e Libertation. La finalità delle due famiglie è diversa, per cui credo sia necessario diversificare l'ambito.
La famiglia Liberation è pensata invece per essere usata in modo interscambiabile e indifferente con Times New Roman, Arial e Courier New. Sfruttando i meccanismi di alias forniti da Fontconfig (ossia quella porzione di sw che si occupa di scegliere quale file TTF caricare dall'hard disk quando un'applicazione chiede una certa famiglia di font), si dovrebbe fare in modo di usare Liberation Serif al posto di Times New Roman e via dicendo.
Proviamo con un esempio più completo, ossia il testo dell'annuncio visualizzato in Epiphany con i tre caratteri (è una gif animata). Nelle prime due schede, tranne qualche differenza su glifi, curvature e posizioni dei puntini sulle i, il posizionamento del testo sulla pagina è pressoché identico. Diverso il discorso per la terza scheda, quella che fa uso di Vera Serif: il carattere è bello, ma il testo è posizionato in modo completamente differente.
Partendo quindi dal presupposto che su un sistema GNU/Linux (ma anche *BSD o altro, non siamo così limitati), le famiglie incriminate non sono e non dovrebbero essere disponibili, che comunque volenti o nolenti sul web o nei documenti tali famiglie sono usati, ben venga l'opera di RedHat. Specie se nella seconda futura incarnazione saranno curati nella resa con Freetype così come i Bitstream Vera.
Orsù quindi, pinguini e diavoletti, cerbiatti, ochette e gibboni, scaricate i tipi di carattere e usate questo file per applicare la sostituzione a tutti i programmi basati su Fontconfig (il che vuol dire praticamente tutto ciò che è basato su GTK+, ma forse non Mozilla e OpenOffice.org, i quali potrebbero dover essere configurati a parte).
---------------------
[1] neologismo appena inventato
[2] liberamente patentato indica registrato come altri brevetti, ma con la garanzia che chiunque possa usarlo se in modo libero. Lo so che è un controsenso, ma IBM e la stessa RedHat hanno già fatto cose simili.
Iscriviti a:
Post (Atom)