Inkscape 1.5 cambia tutto: rendering riscritto ma c'è allarme sopravvivenza

Il rilascio di Inkscape 1.5 si profila come un passaggio tecnico rilevante per uno dei software di grafica vettoriale più diffusi in ambito open source. Nato nel 2003 come fork di Sodipodi e progressivamente evoluto grazie a una comunità internazionale di sviluppatori, Inkscape (download) è oggi utilizzato in contesti professionali che spaziano dal web design alla stampa tipografica. I dati di diffusione delle principali distribuzioni Linux e dei repository Windows indicano milioni di installazioni attive, con una crescita costante soprattutto tra gli utenti che cercano alternative libere a strumenti proprietari.

L’aggiornamento 1.5 introduce modifiche profonde al motore interno, nuove funzionalità per la manipolazione grafica e, parallelamente, mette in luce difficoltà organizzative che incidono sulla sostenibilità del progetto.

Refactoring del motore di rendering e filtri

Come spiega Martin Owens, principale responsabile del progetto, l’evoluzione tecnica di Inkscape si concentra soprattutto su un mastodontico lavoro di refactoring del motore di rendering, un componente che nel caso del noto programma si basa su una pipeline interna costruita attorno alle librerie Cairo e 2Geom.

L’obiettivo è rendere il codice più modulare e compatibile con le esigenze future, come l’accelerazione hardware e la gestione avanzata del colore. Il completamento del nuovo motore di filtraggio rappresenta una pietra miliare significativa: la riscrittura consente di elaborare effetti SVG complessi con maggiore coerenza rispetto alle specifiche W3C, riducendo i bug storici legati a maschere, blur e blend mode.

Il codice è già funzionante, ma l’accuratezza dell’output richiede una fase di validazione attraverso test e confronti con rendering di riferimento.

L’architettura aggiornata permette inoltre di separare meglio la fase di parsing SVG da quella di rasterizzazione, un passaggio che apre la strada a prestazioni più elevate nelle versioni successive.

Nuovi target di rendering e supporto a PNG 64 bit

Una delle novità tecniche riguarda la gestione dei cosiddetti drawing items, ossia le unità logiche utilizzate per rappresentare gli oggetti grafici a schermo.

Il refactoring di questa componente consente di migliorare il flusso di esportazione raster, introducendo un primo target in formato PNG a 64 bit. Il formato utilizza canali a 16 bit per componente colore, offrendo una profondità maggiore rispetto ai tradizionali PNG a 8 bit e risultando utile per le attività di stampa e le elaborazioni fotografiche avanzate.

La scelta del PNG a 64 bit come obiettivo iniziale è legata alla sua implementazione relativamente lineare, ma costituisce un passaggio propedeutico verso formati più complessi e verso la futura integrazione con sistemi di gestione colore più sofisticati.

La complessità del supporto CMYK

Una richiesta storica della comunità professionale riguarda il supporto nativo al CMYK.

L’attuale architettura di Inkscape, basata su un modello RGB con esportatori raster limitati a tre canali principali, rende difficile la gestione diretta dei profili di stampa. Nelle build di sviluppo è già possibile generare PDF con profili CMYK, sfruttando librerie come Poppler e Cairo, ma l’operazione richiede modifiche manuali al codice XML del documento SVG.

L’assenza di un’interfaccia grafica dedicata evidenzia la complessità del problema: integrare il CMYK implica ridefinire l’intero sistema di gestione colore, includendo profili ICC, conversioni tra spazi colore e coerenza tra rendering a schermo ed esportazione. La roadmap prevede l’introduzione progressiva di questi elementi, ma si tratta di un lavoro strutturale che richiederà più cicli di sviluppo.

Interazione e produttività: le sticky transform keys

Tra le novità lato utente spiccano le cosiddette sticky transform keys, un sistema di controllo ispirato ai workflow di Blender.

Premendo un tasto specifico e rilasciandolo, l’utente può trascinare il mouse per eseguire trasformazioni come traslazione, rotazione e scala senza mantenere premuta la scorciatoia corrispondente. Il comportamento riduce il numero di azioni necessarie e velocizza operazioni ripetitive, soprattutto su documenti complessi con molti oggetti.

L’adozione di questo schema introduce tuttavia un problema di compatibilità con le scorciatoie storiche di Inkscape. I tasti predefiniti utilizzati in Blender, infatti, coincidono con comandi già esistenti, come quelli per la creazione di rettangoli o gradienti.

Gli utenti di Inkscape dovranno quindi riconfigurare manualmente le combinazioni di tasti tramite il file preferences.xml o l’interfaccia delle scorciatoie per evitare conflitti operativi.

Restyling del dialogo Riempimento e Contorno

Il dialogo Fill and Stroke, elemento centrale per la definizione delle proprietà grafiche, è stato aggiornato per condividere il codice con il nuovo sistema di proprietà degli oggetti.

Il risultato è un’interfaccia più coerente con il resto dell’applicazione e una base di codice unificata che semplifica la manutenzione. La sincronizzazione consente inoltre di riflettere in tempo reale le modifiche tra pannelli diversi, migliorando la precisione delle regolazioni su tracciati complessi.

Crisi amministrativa e sostenibilità del progetto

Accanto ai progressi tecnici, la governance del progetto attraversa però una fase critica. L’assenza di risorse amministrative ha impedito la partecipazione al programma Google Summer of Code, una piattaforma che per anni ha garantito contributi di giovani sviluppatori volti alla maturazione di Inkscape.

Il problema non riguarda la mancanza di candidati, ma la carenza di mentori e coordinatori in grado di gestire il processo.

La difficoltà si riflette anche nella penuria di figure disponibili a condurre colloqui e supervisionare l’inserimento di sviluppatori retribuiti. Allo stesso tempo, eventi storicamente centrali per la comunità, come il Libre Graphics Meeting e il FOSDEM, non vedranno la presenza ufficiale di Inkscape per l’assenza di volontari organizzatori.

La situazione evidenzia il peso del lavoro volontario in un progetto open source di grandi dimensioni. Molti contributori storici hanno ridotto la propria partecipazione a causa di impegni professionali e condizioni economiche meno favorevoli, rendendo evidente la necessità di un modello organizzativo più strutturato e sostenibile.

Il grido d’aiuto che arriva dai vertici del progetto Inkscape non è solitario: i responsabili di FFmpeg stigmatizzavano l’uso del codice da parte delle Big Tech senza mai contribuire finanziariamente alla crescita del progetto. Pensiamo anche a Tailwind CSS che ha licenziato dipendenti nonostante l’onnipresenza del progetto, sollecitando così una sponsorizzazione diretta da parte di Google.