Quel punto interrogativo non era nel mockup.

Il file si apre, le schermate compaiono, le frecce sembrano al loro posto. Poi noti piccoli riquadri tratteggiati con un punto interrogativo. Non sono una scelta creativa del tuo capo. Sono il modo in cui l’editor dice: «Ho trovato un’icona, ma non so ancora disegnarla». Una frase molto ragionevole, tradotta in una grafica che somiglia vagamente a un problema più grave.

È successo durante una prova reale di Telario. La prima implementazione disegnava un insieme limitato di forme: database, ingranaggi, buste e poche altre. Le icone non riconosciute diventavano segnaposto. Il documento poteva contenere l’identificativo corretto; semplicemente il renderer non aveva una rappresentazione per quel nome. L’apertura dell’archivio era riuscita, mentre la copertura grafica era incompleta.

La soluzione non era aggiungere a mano soltanto le due forme visibili nello screenshot. Prima bisognava capire quale raccolta usasse il documento, dove reperirla e con quali condizioni fosse possibile distribuirla in un repository pubblico. Il risultato è un’integrazione locale di Font Awesome Free, con alias storici, licenza e verifiche. Il percorso è più interessante del conteggio finale, perché mostra quanto lavoro si nasconda dietro una piccola icona apparentemente ovvia.

1. Che cosa significa davvero il segnaposto

Un segnaposto è una risposta dell’interprete, non una diagnosi universale sul file. Può significare che il controllo è stato letto ma non viene rappresentato, che una risorsa non è disponibile nel perimetro supportato o che un nome non trova corrispondenza nel catalogo. Prima di parlare di dati mancanti, bisogna distinguere questi casi. La grafica da sola non basta a stabilire se l’informazione sia stata persa.

Nel caso delle icone, Telario legge un identificativo nelle proprietà del controllo e lo passa al renderer. Se il nome non trova un percorso grafico riconosciuto, compare il riquadro con ?. L’identificativo può rimanere nei dati originali. È quindi possibile conservare correttamente un’informazione e mostrarla male o non mostrarla ancora. Questo confine è fondamentale per non scambiare un limite di visualizzazione per un archivio danneggiato.

La prima verifica utile è guardare quali icone funzionano e quali no. Se il database compare e il desktop diventa un punto interrogativo, l’ipotesi di un catalogo parziale è più concreta di un generico problema di apertura. Poi si controlla l’identificativo. Il procedimento è piccolo: sintomo, dato letto, regola di risoluzione e risultato grafico. Serve a correggere il livello giusto, invece di tentare modifiche al documento nella speranza che il segnaposto smetta di protestare.

2. Il nome dell’icona è un dato strutturato

Un nome come desktop-solid non è soltanto una descrizione in inglese. Contiene almeno due informazioni: soggetto e stile. folder-regular e folder-solid possono rappresentare la stessa categoria di oggetto con tracciati differenti. La distinzione interessa sia la resa sia la risoluzione del catalogo. Cercare soltanto una parola contenuta nella stringa può funzionare per una demo e diventare ambiguo quando i nomi aumentano.

La versione iniziale riconosceva pochi casi con condizioni dirette. Era sufficiente a mostrare alcuni simboli comuni, ma non costituiva un catalogo. Un’integrazione più ampia deve invece distinguere un nome esatto, un alias e una richiesta di stile non disponibile. L’ordine delle regole conta: un nome moderno valido non deve essere trasformato prima da una regola pensata per un nome storico.

Il documento di prova conteneva desktop, cartelle, database, spunte e varianti di cerchio. Gli identificativi osservati sono stati utili per definire casi realistici di compatibilità, senza includere il progetto privato nel repository. I test possono usare quei nomi e dati sintetici. Per verificare la risoluzione di desktop-solid non serve distribuire il diagramma aziendale da cui è emersa la mancanza. Un buon esempio conserva la struttura tecnica necessaria e rimuove il contesto che non serve.

3. La fonte originale viene prima dell’estrazione

La documentazione Balsamiq dichiara l’uso di Font Awesome per le icone. È un punto di partenza migliore dell’idea di estrarre tutte le risorse da una copia installata del programma. Se una raccolta ha una fonte ufficiale separata, conviene verificare quella: provenienza, versione, formati e condizioni di utilizzo diventano più leggibili.

Questa verifica non autorizza a concludere che ogni icona di ogni versione Balsamiq sia disponibile nello stesso pacchetto aperto. Nel tempo possono cambiare cataloghi, stili e nomi; inoltre gli utenti possono importare risorse personalizzate. L’affermazione corretta è circoscritta: esiste una raccolta ufficiale Font Awesome Free utilizzabile secondo la sua licenza, e Telario può integrarla senza prendere risorse proprietarie dal programma originale.

La differenza è pratica. Un repository pubblico dovrebbe poter spiegare da dove arriva ogni asset distribuito. «Era nella cartella dell’app» è una provenienza tecnica, ma non chiarisce i diritti di redistribuzione. «È stato estratto dalla release ufficiale Free, con licenza e versione conservate» offre invece una catena verificabile. Non elimina ogni possibile domanda, ma evita di costruire l’integrazione su un presupposto invisibile. Prima si identifica il materiale utilizzabile; poi si scrive il resolver che lo rende compatibile con i nomi del documento.

4. Open non significa senza copyright

Le icone possono essere protette dal diritto d’autore e contemporaneamente distribuite con una licenza che consente uso e redistribuzione. Non c’è contraddizione. La licenza stabilisce le condizioni; il carattere aperto non cancella gli autori. Per questo la domanda utile non è soltanto «sono protette?», ma «quale materiale stiamo usando, con quale licenza e quali obblighi dobbiamo rispettare nella distribuzione?».

Font Awesome Free distingue i materiali: icone in SVG e JS sotto CC BY 4.0, font sotto SIL OFL 1.1 e codice non relativo a font o icone sotto MIT, secondo la licenza ufficiale della release. Telario usa i tracciati delle icone Free e include la licenza upstream insieme alle attribuzioni. La distinzione tra formati conta: non conviene applicare automaticamente a un file SVG la licenza che si è letta per un font.

Questa pagina descrive il materiale incluso nel progetto e la scelta adottata; non è una garanzia legale universale per qualunque risorsa futura. Se cambia la fonte o si aggiunge un altro catalogo, la verifica va rifatta sul componente concreto. Una procedura corretta è ripetibile proprio perché non dipende dall’idea generica che «le icone su Internet sono libere». Gli asset aperti sono utili anche perché permettono di documentare con precisione come possono essere usati.

5. Free e Pro non sono la stessa raccolta

Un nome famoso non identifica automaticamente un’unica licenza per tutti i contenuti disponibili. Font Awesome offre materiale Free e materiale Pro. L’integrazione di Telario seleziona soltanto gli stili elencati come Free nei metadati della release scelta. Non include il catalogo Pro e non considera l’eventuale disponibilità di una risorsa in un altro prodotto come autorizzazione a distribuirla.

Questa regola ha una conseguenza visibile: un’icona può esistere nel pacchetto Free con uno stile e non con un altro. Se il documento richiede database-regular, Telario usa la variante Free disponibile database-solid. Il soggetto resta riconoscibile, ma l’aspetto non è identico. La sostituzione viene documentata e riguarda la visualizzazione, non il valore conservato nel documento.

È un compromesso esplicito. Per leggere un diagramma, una variante dello stesso soggetto può essere sufficiente. Per una revisione rigorosa dell’iconografia, potrebbe non esserlo. Il software non conosce automaticamente il livello di fedeltà richiesto dalla tua attività. Deve offrire un risultato coerente e informazioni sufficienti per valutarlo. La scelta più importante è evitare una promessa falsa: un catalogo Free completo non coincide necessariamente con tutte le varianti che qualcuno può aver usato in qualunque documento creato altrove.

6. La versione fissata rende il catalogo riproducibile

Telario include 2.060 varianti della release Font Awesome Free 6.7.2. Il numero descrive varianti distribuite, non una garanzia di copertura totale di ogni possibile archivio Balsamiq. La release viene indicata perché una fonte senza versione può cambiare nel tempo, rendendo difficile riprodurre un risultato o capire perché un nome prima funzionasse in un certo modo.

Uno script legge i metadati ufficiali, estrae gli stili dichiarati Free, conserva dimensioni e tracciati, recupera alias e regole storiche e copia la licenza. L’output viene distribuito insieme all’app. Chi rigenera il catalogo può risalire alla stessa fonte invece di affidarsi a un insieme di file raccolti manualmente in momenti diversi.

La riproducibilità aiuta anche le verifiche. Se un aggiornamento modifica un tracciato, un alias o una disponibilità di stile, il cambiamento può essere confrontato con la release precedente. Non si tratta soltanto di aggiornare un numero nel README. Un catalogo è una dipendenza di rendering: può cambiare ciò che l’utente vede e la dimensione della build. Merita quindi un aggiornamento deliberato, accompagnato da controlli sui nomi e sulle geometrie, invece di un recupero automatico dell’ultima risorsa disponibile a ogni apertura dell’editor.

7. I vecchi nomi richiedono una mappa

Gli archivi durano spesso più delle convenzioni con cui sono stati creati. Un nome storico può riferirsi a un’icona che oggi ha un identificativo diverso. Le regole di compatibilità e gli alias consentono di collegare quelle convenzioni senza modificare il documento originale. È un problema simile a una traduzione: lo stesso concetto deve trovare una rappresentazione nel vocabolario corrente.

Telario usa gli alias dei metadati e le corrispondenze storiche della raccolta. Un nome come file-o richiede anche attenzione allo stile outline, non soltanto alla parola file. La risoluzione considera prima un identificativo moderno esatto; poi interpreta suffissi e corrispondenze. Il nome esatto ha precedenza per evitare che una regola storica trasformi un identificativo attuale già valido.

Questo ordine è stato importante nei test. Una collisione tra un nome moderno e una corrispondenza storica può produrre un’icona riconoscibile ma sbagliata. Se la verifica controlla soltanto «esiste un tracciato», il problema passa inosservato. Confrontare ogni variante del catalogo con la propria geometria impedisce invece che un resolver troppo zelante riscriva il significato di un nome valido. La compatibilità è utile quando amplia ciò che si riesce a leggere senza rompere ciò che era già espresso correttamente.

8. I tracciati viaggiano con l’app

Le icone vengono disegnate come percorsi SVG. Non serve interrogare una CDN per ogni controllo o attendere che un font remoto venga caricato per sostituire un carattere. Questo si accorda con l’architettura locale dell’editor: una volta ricevuti gli asset dell’app, il renderer dispone della raccolta necessaria per i casi supportati.

La scelta aumenta il contenuto distribuito nella build. Non esistono cataloghi completi a dimensione zero. Il vantaggio è l’indipendenza delle rappresentazioni durante l’uso e la possibilità di includere percorsi vettoriali anche nelle esportazioni. La dimensione va misurata e organizzata, per esempio separando il catalogo in un chunk dedicato, senza fingere che una divisione dei file elimini i byte che devono comunque essere trasferiti.

In SVG ogni icona ha un sistema di coordinate e dimensioni proprie. Disegnare il tracciato nel viewBox corretto evita di deformare un’icona larga come se fosse quadrata. Il colore può essere applicato al percorso nel contesto del controllo. Sono dettagli tecnici piccoli, ma spiegano perché integrare una raccolta non significhi soltanto copiare un file JSON. I dati devono essere collocati correttamente nella rappresentazione della pagina e verificati anche quando escono dall’interfaccia per diventare un documento esportato.

9. Sei casi da verificare prima di dire «risolto»

Un nome moderno esatto

Parti da un identificativo presente nel catalogo, per esempio desktop-solid. Il resolver dovrebbe restituire le dimensioni e il tracciato di quella variante, senza trasformazioni inattese. Il test più forte confronta il risultato con il dato incluso, non soltanto con l’esistenza di un oggetto. Altrimenti due icone differenti potrebbero passare entrambe come successo.

Questa verifica va estesa all’intero catalogo, perché gli errori di precedenza possono interessare nomi che non compaiono nella demo. Il documento di prova può aver rivelato il problema, ma non deve delimitare tutta la soluzione. Una correzione utile aggiunge capacità generale e controlla che il meccanismo funzioni anche lontano dal primo screenshot. La domanda non è «il desktop ora compare?». È «i nomi esatti continuano tutti a indicare la propria geometria?». Le due verifiche si completano e intercettano errori diversi.

Un nome storico outline

Prova una corrispondenza come file-o. Il nome richiede una traduzione verso l’icona corrente e uno stile coerente con l’intenzione storica quando disponibile. Se il resolver ignora lo stile, può trovare un soggetto corretto e produrre una silhouette diversa da quella attesa. Il risultato sembra plausibile, ma perde una parte del significato visivo del nome.

Confronta l’uscita con la variante corrente corrispondente e verifica eventuali prefissi supportati. Non estendere automaticamente la regola a tutte le stringhe con la stessa terminazione senza controllare il catalogo. La compatibilità storica beneficia di una fonte strutturata più di quanto benefici di una serie crescente di sostituzioni intuitive. Un alias esplicito è leggibile e verificabile; una condizione generica può risolvere un esempio e alterarne altri. I test servono a rendere evidente quel confine prima che venga incontrato in un documento reale.

Una variante non disponibile come Free

Usa il caso database-regular. Il comportamento previsto è una sostituzione visiva con database-solid, disponibile nel catalogo incluso. La prova deve verificare sia la presenza dell’icona sia il fatto che la richiesta originale non venga riscritta nel modello del documento. Visualizzare un equivalente e cambiare il dato persistito sono due operazioni differenti.

Questa distinzione permette di migliorare in futuro il renderer senza dover annullare modifiche introdotte soltanto per la visualizzazione. Se una versione successiva dispone di una rappresentazione più adatta, può partire dall’identificativo originale conservato. L’utente dovrebbe conoscere la sostituzione quando la fedeltà dello stile conta. Per una mappa tecnica può bastare riconoscere il database; per una scelta di design serve il riferimento corretto. Il fallback è una capacità pratica, non un certificato di equivalenza grafica. Chiamarlo con il suo nome evita aspettative che il codice non può sostenere.

Un suffisso legato alle convenzioni del documento

Nel file osservato compariva circle-small-solid. La risoluzione lo collega al cerchio solido senza interpretare small come un soggetto diverso. Questo tipo di compatibilità va mantenuto stretto e comprensibile: il fatto di aver osservato una convenzione non autorizza a rimuovere arbitrariamente parole da qualsiasi nome.

Usa un test dedicato per il caso noto e confrontalo con la variante di base. Se trovi altre forme simili in futuro, verifica prima come sono usate e quale informazione esprimono. Dimensione del controllo, dimensione richiesta dell’icona e nome del soggetto possono convivere nelle proprietà senza essere intercambiabili. Un resolver troppo aggressivo può trasformare un nome sconosciuto in un’icona apparentemente valida ma semanticamente errata. A volte un segnaposto esplicito è preferibile a una rappresentazione sbagliata che nessuno pensa di controllare. La comodità della tolleranza deve restare subordinata alla chiarezza del risultato.

Un’identità che resta sconosciuta

Un nome fuori dal catalogo deve continuare a produrre un esito riconoscibile. L’obiettivo dell’integrazione non è eliminare ogni punto interrogativo scegliendo un simbolo qualsiasi. Se manca una corrispondenza affidabile, il segnaposto segnala un limite reale e invita a verificare il documento. Nascondere il dubbio renderebbe l’interfaccia più pulita e il diagramma meno attendibile.

Prova un nome sintetico inesistente e controlla che non venga accidentalmente associato a una forma soltanto per una sottostringa. Il renderer precedente può ancora offrire alcune rappresentazioni specifiche, ma una stringa completamente sconosciuta deve restare distinguibile. Questa è una proprietà utile da conservare dopo l’ampliamento del catalogo. Un interprete parziale lavora meglio quando riconosce ciò che non comprende. Il punto interrogativo non è un fallimento estetico da cancellare a ogni costo; è un’informazione di stato da ridurre con copertura corretta e mantenere quando l’alternativa sarebbe inventare.

L’icona dentro un’esportazione

La prova non finisce sul canvas. Esporta un controllo supportato e verifica che il risultato contenga percorsi vettoriali, dimensioni corrette e nessun riferimento necessario a un servizio esterno per disegnare l’icona. Un simbolo visibile nell’interfaccia può dipendere da risorse che non accompagnano l’uscita, se i due percorsi non sono stati progettati insieme.

Apri anche il PNG se quello sarà il formato della consegna. Una corretta struttura SVG è importante, ma la rasterizzazione è un passaggio ulteriore. Quando segnali una differenza, indica in quale livello compare: canvas, SVG esportato o PNG. Questa informazione riduce il campo dell’indagine e impedisce di correggere un resolver quando il problema riguarda scala o composizione dell’uscita. Il catalogo, il renderer e l’esportazione formano una catena. Ogni anello ha un criterio di verifica diverso e nessuno può essere sostituito interamente dalla soddisfazione di vedere finalmente sparire il primo punto interrogativo.

10. I marchi richiedono un’attenzione separata

Le raccolte di icone comprendono anche loghi di prodotti e aziende. La licenza delle forme non elimina i diritti sui marchi rappresentati. La licenza ufficiale Font Awesome ricorda che le icone dei marchi rappresentano i rispettivi titolari e non implicano approvazione o affiliazione. Per un progetto pubblico è una distinzione da mantenere anche nel testo del sito.

Rappresentare un servizio nominato in un diagramma non è la stessa cosa di usare quel logo come identità del proprio prodotto. Telario ha un marchio separato: una finestra e una griglia in petrolio e arancio. Non usa il marchio Balsamiq per presentarsi come versione ufficiale o come progetto collegato. Il nome del formato e del prodotto originale serve a spiegare la compatibilità, con la dichiarazione di indipendenza visibile.

Queste attenzioni non devono trasformarsi in un catalogo di paure ipotetiche. Servono a descrivere correttamente ciò che si distribuisce e il rapporto che esiste davvero. Fonte degli asset, attribuzione degli autori, diritti sui marchi e identità del progetto sono temi collegati ma distinti. Separarli rende più facile prendere decisioni concrete quando si aggiunge una risorsa, invece di affidarsi a un’unica frase vaga sulla libertà di usare tutte le icone.

11. Le attribuzioni devono seguire il pacchetto

Una nota in una conversazione non accompagna la build. Per questo la licenza ufficiale è inclusa nei file pubblici del progetto e nelle informazioni sulle librerie di terze parti. Chi scarica o serve l’app deve poter ritrovare la provenienza dei componenti senza conoscere la storia della loro integrazione. Le attribuzioni sono un contenuto distribuito, non soltanto una decisione presa una volta.

Lo script che raccoglie le licenze deve conservare anche quella delle icone. In caso contrario un aggiornamento ordinario potrebbe rigenerare il file delle note ed eliminare una sezione aggiunta a mano. È un piccolo esempio di manutenzione completa: correggere il risultato presente e il processo che lo ricrea. Un file giusto oggi è meno utile se il comando documentato lo rende sbagliato domani.

La documentazione delle icone specifica release, copertura, sostituzioni e modalità di rigenerazione. Questo permette a un futuro intervento di partire da informazioni concrete. Se si decide di aggiornare il catalogo o modificare i fallback, si sa quale comportamento deve essere confrontato. La chiarezza riduce anche il rischio di descrivere il progetto come interamente coperto da una licenza generale già scelta: la licenza dell’app resta una decisione distinta, mentre ogni dipendenza mantiene le proprie condizioni.

12. Copertura e fedeltà sono misure diverse

Un conteggio alto è facile da comunicare. Non risponde, da solo, alla domanda più importante: l’icona richiesta dal documento viene rappresentata con il soggetto e lo stile corretti? Un catalogo può contenere migliaia di varianti e comunque mancare un identificativo personalizzato. Può risolvere un nome con un fallback riconoscibile e non riprodurre l’aspetto originale. Copertura e fedeltà devono essere raccontate separatamente.

La verifica sul documento che ha fatto emergere il problema ha attraversato quattro pagine e settantadue icone, senza segnaposto ? e senza errori JavaScript. È un risultato concreto su quel campione, non una certificazione su tutti gli archivi esistenti. I test automatici ampliano la fiducia nel meccanismo controllando tutte le varianti incluse e casi di alias. Le due prove rispondono a domande diverse e sono entrambe utili.

Per valutare il tuo documento, controlla prima se le icone importanti sono riconoscibili. Poi verifica gli stili che influenzano il significato o la revisione grafica. Se trovi una differenza, identifica il nome richiesto e il risultato mostrato. Una segnalazione precisa può portare a un nuovo alias, a una correzione di precedenza o alla documentazione di un limite. La domanda migliore non è «avete tutte le icone?», ma «che cosa succede a questo identificativo e perché?».

13. Una manutenzione sostenibile comincia da casi piccoli

Le regressioni possono nascondersi in una modifica che sembra soltanto additiva. Aggiungere un catalogo più grande cambia il percorso di risoluzione e può alterare icone già rappresentate. Per questo i test non si limitano ai simboli mancanti iniziali. Controllano le geometrie del catalogo, la differenza tra stili, i nomi storici e il comportamento delle identità sconosciute.

Quando compare un nuovo caso, conviene costruire una fixture sintetica con il minimo necessario: tipo Icon, identificativo, colore e dimensioni. Se il problema dipende da un gruppo o da una trasformazione, si aggiunge quel contesto. Il campione cresce per rispondere a una domanda, non perché il documento originale aveva molte altre informazioni. La riduzione rende il test più leggibile e protegge i contenuti privati.

Il risultato migliore è una correzione che un’altra persona può verificare leggendo poche righe e aprendo un esempio non riservato. In un piccolo progetto personale questo conta molto: la manutenzione futura non dovrebbe richiedere di ricordare quale cliente, quale pagina e quale messaggio avevano originato ogni regola. Il codice può conservare il caso tecnico mentre la storia aziendale rimane fuori dal repository. È un modo semplice di far crescere la compatibilità senza far crescere allo stesso ritmo il debito di contesto.

14. Cosa controllare nel tuo prossimo mockup

Parti dalla pagina di compatibilità e usa la demo per conoscere l’interfaccia. Quando apri il tuo archivio, osserva le icone decisive per il diagramma e confronta almeno una pagina con un riferimento noto. Non interpretare automaticamente un simbolo diverso come errore del documento: potrebbe essere uno stile sostituito o una differenza del renderer.

I dettagli tecnici e la provenienza sono raccolti nella documentazione delle icone. Le condizioni dei materiali si trovano nella licenza ufficiale Font Awesome Free. La documentazione Balsamiq sulle icone chiarisce il rapporto con la raccolta di origine, senza trasformare Telario in un prodotto affiliato.

15. Una procedura per aggiungere la prossima corrispondenza

Un criterio utile è chiedersi se la regola proposta descrive un fatto osservato oppure una somiglianza intuitiva. Nel primo caso puoi conservarne una prova. Nel secondo devi ancora verificare che il significato sia corretto. Questa domanda rallenta di pochi minuti una correzione e può risparmiare molto più tempo a chi leggerà un diagramma fidandosi delle icone. La velocità dell’implementazione ha valore quando non trasferisce il costo dell’incertezza al prossimo utilizzatore.

Quando trovi un nome non riconosciuto, conserva prima l’informazione esatta. Cambiare subito l’icona nell’editor originale può risolvere la singola immagine, ma nasconde il caso che avrebbe aiutato a migliorare l’interprete. Basta annotare identificativo, tipo di controllo e differenza osservata. Se il contenuto del progetto è privato, questi dati vanno separati dal contesto aziendale prima di preparare un esempio pubblico.

Il passo successivo è cercare una corrispondenza nel catalogo fissato. Esiste un nome esatto? È un alias storico? Lo stile richiesto è disponibile come Free? Ciascuna risposta suggerisce una correzione diversa. Un nome moderno mancante dalla risoluzione indica un problema del codice o dei dati distribuiti. Un alias richiede una mappa. Uno stile assente richiede un fallback documentato oppure un limite dichiarato. Non sono tre varianti dello stesso problema.

Prima di aggiungere una regola generica, prova il nome in isolamento e controlla i nomi vicini che potrebbero essere coinvolti. La tentazione di usare una sottostringa è forte perché produce un risultato veloce. Ma una regola che riconosce troppo può introdurre un errore silenzioso: il simbolo compare e nessuno sospetta che sia quello sbagliato. Il segnaposto, almeno, chiedeva attenzione. Un’immagine plausibile può ottenere fiducia senza meritarla.

Infine verifica l’esportazione e conserva il caso nel test. La soluzione deve sopravvivere alla prossima rigenerazione del catalogo e al prossimo intervento sul renderer. Aggiorna la documentazione soltanto quando cambia il perimetro visibile all’utente: un alias in più non richiede necessariamente una nuova promessa commerciale, mentre una sostituzione di stile merita una descrizione chiara. In questo modo l’integrazione cresce per prove concrete e rimane leggibile anche a chi non ha seguito la conversazione originaria.

Il piccolo punto interrogativo è stato un buon promemoria. Un programma può sembrare quasi completo finché non incontra il nome che non conosce. Risolverlo bene significa trovare la fonte, rispettarne le condizioni, interpretare i nomi e verificare il risultato. Poi, finalmente, il desktop torna a essere un desktop. Una conquista modesta, ma molto più comoda da mettere in un diagramma di una domanda senza risposta.