ai miei genitori, ai miei nonni e ad Andy K.

Transcript

ai miei genitori, ai miei nonni e ad Andy K.
ii
Indice
1 Introduzione
1
2 Contesto: what the world needs now...
11
2.1
Le immagini nel Web . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
I linguaggi coinvolti . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.1
SVG: breve descrizione strutturale . . . . . . . . . . . . . . .
13
2.2.2
VML: breve descrizione strutturale . . . . . . . . . . . . . .
16
2.2.3
Confronto tra SVG e VML . . . . . . . . . . . . . . . . . . .
19
2.2.4
GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Applicativi esistenti . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.1
Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.3.2
Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3.3
Convertitori . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
SVGmaker e VMLmaker . . . . . . . . . . . . . . . . . . . .
29
CR2V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
KVEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
CSIRO SVG Toolkit . . . . . . . . . . . . . . . . . . . . . .
31
Batik SVG toolkit . . . . . . . . . . . . . . . . . . . . . . .
32
2.4
Applicazioni di un formato grafico vettoriale . . . . . . . . . . . . . .
34
2.5
Perché realizzare un nuovo convertitore . . . . . . . . . . . . . . . .
36
2.5.1
Conversione VML – SVG . . . . . . . . . . . . . . . . . . .
36
2.5.2
Conversione in GIF . . . . . . . . . . . . . . . . . . . . . . .
38
Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
2.3
2.3.4
2.6
iii
iv
3 Descrizione ad alto livello: analyze this
3.1
Conversione tra SVG e VML . . . . . . . . . . . . . . . . . . . . . .
41
3.1.1
Metodo di traduzione: utilizzo di XSLT . . . . . . . . . . . .
42
3.1.2
Come funziona in pratica . . . . . . . . . . . . . . . . . . . .
43
3.1.3
Metodologia delle conversioni . . . . . . . . . . . . . . . . .
44
3.1.4
Da SVG a VML . . . . . . . . . . . . . . . . . . . . . . . .
46
Conversione di base . . . . . . . . . . . . . . . . . . . . . .
46
Punti “sottili” . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Problemi e limiti . . . . . . . . . . . . . . . . . . . . . . . .
56
Da VML a SVG . . . . . . . . . . . . . . . . . . . . . . . .
59
Conversione di base . . . . . . . . . . . . . . . . . . . . . .
59
Punti “sottili” . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
Problemi e limiti . . . . . . . . . . . . . . . . . . . . . . . .
66
Conversione da SVG e VML a GIF . . . . . . . . . . . . . . . . . . .
68
3.2.1
Realizzazione . . . . . . . . . . . . . . . . . . . . . . . . . .
68
3.2.2
Metodo di gestione dei documenti . . . . . . . . . . . . . . .
68
3.2.3
Punti “sottili” . . . . . . . . . . . . . . . . . . . . . . . . . .
69
3.2.4
Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
3.2.5
Risultati e problemi . . . . . . . . . . . . . . . . . . . . . . .
75
Conversione da GIF a SVG e VML . . . . . . . . . . . . . . . . . . .
76
3.1.5
3.2
3.3
4 Descrizione a basso livello: into the code
4.1
41
77
Da SVG a VML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.1.1
Elementi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.1.2
Testi (elementi text, tspan, tref e textpath) . . . . .
85
4.1.3
Trasformazioni (attributo transform) . . . . . . . . . . . . . .
86
4.1.4
Altri attributi . . . . . . . . . . . . . . . . . . . . . . . . . .
88
4.1.5
Caratteristiche non traducibili . . . . . . . . . . . . . . . . .
90
4.1.6
Caratteristiche non tradotte . . . . . . . . . . . . . . . . . . .
91
INDICE
4.2
4.3
4.4
v
Da VML a SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
4.2.1
Elementi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
4.2.2
shape – shapetype . . . . . . . . . . . . . . . . . . . . .
99
4.2.3
Gestione defs . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2.4
Trasformazioni . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2.5
Altri attributi . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2.6
Caratteristiche non traducibili . . . . . . . . . . . . . . . . . 104
4.2.7
Caratteristiche non tradotte . . . . . . . . . . . . . . . . . . . 104
Da SVG e VML a GIF . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.3.1
Funzioni per le immagini di PHP
. . . . . . . . . . . . . . . 105
4.3.2
Metodo di traduzione . . . . . . . . . . . . . . . . . . . . . . 106
4.3.3
Traduzione da SVG a GIF . . . . . . . . . . . . . . . . . . . 107
4.3.4
Traduzione da VML a GIF . . . . . . . . . . . . . . . . . . . 112
4.3.5
Caratteristiche non traducibili . . . . . . . . . . . . . . . . . 116
4.3.6
Caratteristiche non tradotte . . . . . . . . . . . . . . . . . . . 117
Da GIF a SVG e VML . . . . . . . . . . . . . . . . . . . . . . . . . 117
5 Conclusioni
119
Bibliografia
123
vi
Capitolo 1
Introduzione
Con questa tesi si è voluto realizzare un convertitore che permetta di tradurre documenti SVG in documenti VML e viceversa; inoltre questi documenti possono venire
tradotti in un formato di immagini bitmap, quale GIF.
La figura seguente mostra uno schema delle conversioni che sono state realizzate,
specificandone gli strumenti utilizzati.
Figura 1.1: Schema della conversione
1
2
SVG, Scalable Vector Graphics [FerJunJac03], è un linguaggio standard del W3C
basato su XML [BPSMY04], per rappresentare figure bidimensionali in grafica vettoriale.
VML, Vector Markup Language [MatLeeDis98], è anch’esso un linguaggio, proposto al W3C, per rappresentare figure bidimensionali in grafica vettoriale, basato su
XML.
GIF, Graphic Interchange Format, è un formato raster, cioè rappresenta un’immagine tramite una matrice che associa punti (pixel) e colori.
Analizziamo brevemente le caratteristiche dei diversi linguaggi, procedendo poi ad
una loro comparazione.
Il linguaggio SVG è nato dall’esigenza di creare uno standard comune per la rappresentazione di immagini in grafica vettoriale per il web. È stato sviluppato dal W3C,
World Wide Web Consortium, a partire dal 2001 e la versione 1.1, quella presa in considerazione per la traduzione, è diventata una Recommendation il 14 Gennaio 2003.
In seguito sono stati sviluppati dei profili per la rappresentazione di immagini su dispositivi mobili, SVG Mobile Profile [Cap03], e per l’ottimizzazione della stampa di
immagini, SVG Print [Dan03], che esulano da questa dissertazione. Attualmente si sta
lavorando alla versione 1.2, Working Draft dal 18 Marzo 2004 [Jac04].
SVG permette di gestire tre tipi di oggetti grafici:
• figure in grafica vettoriale (linee congiunte tramite rette o curve);
• immagini;
• testi.
È in sintassi XML, quindi leggibile e gestibile tramite un semplice editor di testo,
è un formato aperto, non proprietario, e si integra con gli altri standard del W3C, quali
per esempio XSLT (eXtensible Stylesheet Language Transformations) e CSS (Cascading Style Sheet). Permette di realizzare figure interattive (per cui vengono compiute
determinate azioni in base a determinati eventi, come per esempio un link ipertestuale
Capitolo 1. Introduzione
3
associato ad una figura) e dinamiche (si possono gestire delle animazioni, tramite opportuni elementi o con degli script). A quest’ultimo proposito bisogna sottolineare
che tramite il DOM, Document Object Model, è possibile interagire con linguaggi di
scripting, come JavaScript.
Come suggerisce il nome, SVG è un formato scalabile, in un duplice senso. Essendo vettoriale (ogni oggetto grafico e rappresentato da una funzione matematica e
non da una griglia di pixel) è possibile scalare e zoomare tutto o una parte del documento senza perdita di qualità. Inoltre è scalabile poiché è possibile gestirlo con una
grande varietà di applicazioni, il cui numero è in continua espansione.
Un ulteriore aspetto di rilevante importanza, riguarda l’accessibilità di questo formato. Mediante particolari elementi è possibile esprimere una descrizione di ogni parte
del documento rendendolo leggibile anche ad utenti disabili. Inoltre è possibile fare
selezioni e ricerca, nonché indicizzazioni dei testi presenti nei documenti SVG.
Per rappresentare degli oggetti SVG, ci sono vari modi. Si può creare un documento SVG stand-alone che verrà visualizzato da un browser. In alternativa si può inserire
una porzione di SVG in un documento HTML, tramite vari elementi, quali image o object, oppure tramite applet. Tramite HTML ci si può inoltre riferire ad un documento
SVG mediante l’elemento a usato per creare un link ipertestuale.
Come accennato in precedenza, essendo SVG un formato testuale è possibile scrivere documenti tramite un semplice editor. Ovviamente non è spesso conveniente,
specie per disegni complessi. Sono disponibili numerosi applicativi per ottenere ottime immagini SVG, in una maniera semplice e potente, tramite interfacce WYSIWYG. Per quanto riguarda la visualizzazione, attualmente si trovano pochi browser
nativi, un esempio è Amaya, il web browser del W3C. La maggior parte degli altri
richiede l’aggiunta di un opportuno plug-in.
SVG, come gli altri linguaggi XML per esprimere oggetti grafici, si contrappone
ai formati raster, ampiamente utilizzati per rappresentare le immagini nel web. Questi
ultimi utilizzano una corrispondenza pixel–colori per rappresentare tutti i punti dell’immagine ed essendo formati non leggibili sono risultati dei corpi estranei all’interno
4
del mondo human readable del web, in cui ogni documento è leggibile e facilmente
interpretabile. Inoltre i nuovi formati grafici XML hanno portato ulteriori benefici
che vanno dalla dimensione ridotta dei file, facilitando il download, alla possibilità di
scalare l’immagine senza perdita di qualità ed infine si integrano con altri standard:
è possibile quindi modificare, trasformare, generare oggetti grafici mediante semplici
applicazioni.
VML è stato il formato vettoriale, basato su XML, proposto da Microsoft e Macromedia al W3C, nel 1998. È usato per includere immagini all’interno di documenti HTML, specificando un opportuno namespace, attraverso il quale l’applicazione
visualizzatrice (il browser) è in grado di generare la figura.
Con questo linguaggio è possibile definire: oggetti in grafica vettoriale (figure definite mediante la congiunzione di linee, rette o curve), inclusione di immagini raster,
testi in sintassi HTML.
Essendo un’applicazione di XML, questo formato presenta molti vantaggi:
• è completamente leggibile ed editabile, anche mediante un semplice text-editor;
• si integra con HTML;
• è compatibile con numerosi standard, quali DOM e CSS. A questo proposito, va
sottolineato che utilizza il modello di posizionamento di CSS2.
VML non è mai diventato uno standard del W3C, è rimasto una Submission; per
questo non esistono molte applicazioni in grado di supportarlo. Essendo stato proposto principalmente da Microsoft è utilizzabile in molti suoi prodotti. Attualmente, e
probabilmente sarà cosı̀ per sempre, solamente Internet Explorer (dalla versione 5.0)
è in grado di visualizzare immagini VML, disponendo di un programma per il render.
Oltre a questo è possibile ottenere VML a partire da documenti definiti mediante le
applicazioni di Office 2000, come per esempio Power Point.
SVG è nato basandosi sugli altri formati vettoriali proposti al W3C, come VML
e PGML (Precision Graphics Markup Language), un formato proposto tra gli altri da
5
Adobe e ormai abbandonato. Ha estratto il meglio da ognuno di essi. Quindi, non deve
sembrare strano se SVG è un formato più completo.
SVG ammette un maggior numero di caratteristiche ed effetti, come le animazioni
o particolari filtri grafici. Consente una trattazione approfondita dei testi, permettendo la definizione della formattazione e del layout di specifiche porzioni. Inoltre è
supportato da un numero maggiore di sistemi e di applicazioni.
Va segnalato che in alcuni ambiti (sistemi Windows e applicazioni Microsoft) VML
gode ancora di alcuni vantaggi. Ha un supporto diretto nel web browser, senza la necessità di plug-in, e mediante Office è possibile salvare i grafici direttamente in formato
VML. Un ulteriore beneficio riguarda la gestione dei testi espressi in sintassi HTML:
è possibile effettuare degli “a capo” in maniera automatica; mentre in SVG devono
essere effettuati tramite opportuni posizionamenti.
GIF, è un formato per rappresentare immagini tramite bitmap. Questo significa
che le immagini sono rappresentate mediante una corrispondenza tra colori e pixel.
Formati di questo tipo, detti raster, offrono alcuni vantaggi nella rappresentazione
delle figure:
• offrono una buona resa dell’immagine, quando è rappresentata nelle sue dimensioni effettive;
• sono sostanzialmente indipendenti dal sistema, possono essere quindi visualizzato da ogni tipo di browser;
• utilizzano algoritmi di compressione per ridurre la loro dimensione;
• offrono un’ottima rappresentazione per immagini complesse, come ad esempio
le foto digitali.
Tuttavia se viene modificata la risoluzione dell’immagine, per esempio ingrandendola, la qualità appare proporzionalmente deteriorata.
Contrapposto a questo tipo di formato ci sono le immagini in grafica vettoriale; ad
esempio lo sono i formati SVG e VML, visti in precedenza. La differenza riguarda il
6
modo in cui vengono memorizzate le informazioni: associazione pixel–colori da una
parte, rappresentazione mediante funzioni matematiche dall’altra.
Utilizzare una rappresentazione in grafica vettoriale mediante linguaggi in sintassi
XML comporta notevoli vantaggi:
• scalabilità: si può ingrandire o rimpicciolire l’immagine, adattarla quindi alle
esigenze dell’utente senza perdita di qualità;
• dimensione ridotta: essendo rappresentata mediante testo, la dimensione dell’immagine risulta molto ridotta, il che comporta un risparmio di bandwidth,
quindi un aumento di velocità per effettuarne il caricamento;
• interoperabilità: essendo linguaggi in sintassi XML, quindi open standard,
possono interagire con gli altri formati standard. Questo tra l’altro comporta:
– utilizzo di CSS: si può specificare lo stile per la rappresentazione di gruppi di oggetti grafici, permettendone la variazione in un modo semplice,
cambiando le caratteristiche del CSS;
– utilizzo del DOM: tramite il Document Object Model, è possibile ottenere un comportamento dinamico ed interattivo, mediante l’utilizzo di
un linguaggio di scripting, quale JavaScript;
• generazione on-the-fly:
– è possibile ottenere immagini in sintassi SVG (o VML) a partire da altri
dati, come documenti XML o dati di un database, mediante l’adozione di
semplici fogli di stile XSLT, il che permette di generare le immagini solo
su richiesta ed in base alle proprie esigenze. Per esempio da uno stesso
documento XML si può ottenere un grafico a torta oppure un istogramma.
– è molto più semplice generare immagini rispetto ai formati raster; inoltre una volta generate, queste si adattano alle varie esigenze (risoluzione,
ecc.), mentre le figure bitmap devono essere rigenerate per ogni esigenza
dimensionale.
7
• editabilità semplificata: è possibile modificare l’immagine mediante un semplice text editor e senza particolari conoscenze; le modifiche sono inoltre molto
più semplici da effettuare: ad esempio per cambiare la dimensione di un quadrato basta modificare due numeri, mentre con i formati raster bisogna rigenerare
completamente l’immagine;
• gestione indipendente del testo: con i formati vettoriali, il testo è effettivamente testo, è editabile e ricercabile all’interno del codice, ed è effettivamente
selezionabile anche nell’immagine visualizzata;
• accessibilità: mediante l’utilizzo di opportuni elementi è possibile ottenere rappresentazioni alternative delle immagine, consentendone la fruizione anche ad
utenti con particolari deficit sensoriali;
• compatibilità con immagini raster: come ultimo aspetto, bisogna segnalare la
possibilità di includere immagini raster all’interno di questi formati, mentre il
contrario non è possibile.
Di contro si segnalano alcuni problemi derivati dall’uso di immagini vettoriali:
• la grafica vettoriale richiede un’elaborazione prima di poter essere visualizzata;
d’altra parte vista la dimensione ridotta è possibile che termini prima il processo
di elaborazione rispetto al caricamento (download) dell’immagine raster;
• immagini complesse, quali foto digitali, richiedono una rappresentazione molto
complessa utilizzando i vettori, e di norma questa rappresentazione occuperà
più spazio rispetto alla corrispondente immagine raster; tuttavia in questi casi
la scelta più conveniente è quella di includere la figura bitmap all’interno del
documento SVG (o VML);
• allo stato dell’arte SVG non ha un supporto completo da parte dei web browser
(ancor meno VML); la maggior parte di essi richiede l’aggiunta di un opportuno
plug-in.
Esistono vari applicativi (visualizzatori, editor, convertitori) per utilizzare SVG e
VML, nel capitolo 2 (in particolare nella sezione 2.3), queste soluzioni sono discusse
8
in dettaglio.
Oltre al semplice utilizzo per rappresentare immagini, SVG e VML si prestano ad
altre funzioni. Sono state sviluppare molte applicazioni che sfruttano questi formati,
ad esempio:
• generazione dinamica di immagini, come la rappresentazione di grafici a partire
da base di dati;
• rappresentazione di mappe, permettendo di effettuare zoom e collegamenti ipertestuali in una maniera semplice ed efficace;
• gestione di animazioni, in cui si contrasta lo strapotere del formato Flash, tramite
un linguaggio standard e leggibile (SVG).
In questo contesto si inserisce il nuovo progetto, un convertitore tra i formati
vettoriali SVG e VML e da questi nel formato raster GIF.
Le motivazioni che ne hanno spinto alla realizzazione sono molteplici e diverse per
ogni verso della conversione.
Per quanto riguarda VML, il fattore fondamentale è la sua non standardizzazione,
la quale implica il suo supporto esclusivo tramite sistemi Microsoft. In particolar modo
è il formato in cui vengono memorizzate le immagini nelle presentazioni di Power
Point. Da qui l’esigenza di poter ottenere disegni utilizzabili su più piattaforme, sia in
formato vettoriali (SVG) che in formato bitmap (GIF).
La conversione di SVG, d’altro canto, ha delle motivazioni più sottili, bisogna
sottolineare che pur essendo un formato standard, allo stato dell’arte non ha un pieno
supporto; basti ricordare l’esiguo numero di browser nativi. GIF, come molti altri
formati raster, ha ormai raggiunto una diffusione pressoché totale, consentendone un
suo utilizzo su ogni sistema. Convertitori tra questi formati ne esistono, e con risultati
molto buoni, tuttavia il nuovo convertitore, scritto mediante script PHP, permette un
efficiente integrazione in applicazioni web server side, richiedendo limitate risorse
da parte dell’utente ed inoltre, tramite meccanismi di caching, viene velocizzanto il
riutilizzo di immagini già convertite.
9
La conversione da SVG a VML, è stata realizzata perché, anche se VML è un
formato ormai obsoleto, sui sistemi Microsoft gode ancora di una gestione migliore; è
presente un visualizzatore integrato nel browser Internet Explorer. D’altro canto, SVG
richiede un opportuno plug-in, che allo stato attuale mostra ancora delle limitazioni.
Per completezza è stato realizzata anche un’applicazione per passare da GIF a SVG
e VML. In questo caso però si tratta di una semplice inclusione.
Nel capitolo 3, viene mostrata una descrizione ad alto livello dei convertitori realizzati. Per ognuno di essi viene specificata la tecnologia adottata, soffermandosi sul suo
utilizzo pratico, passando poi alla descrizione della metodologia che sta alla base delle
traduzioni. Inoltre, per ogni singola conversione è stato analizzato più nel dettaglio il
funzionamento, soffermandosi sui principali aspetti delicati, mostrando infine alcuni
esempi ed un elenco di problemi.
Per realizzare la conversione tra SVG e VML sono stati utilizzati due fogli di stile
XSLT, questa è sembrata la scelta migliore visto la natura dei formati, entrambi in
sintassi XML. Questi due linguaggi per rappresentare molti oggetti grafici utilizzano
elementi simili; per altri presentano una struttura totalmente diversa. Per effuttuare
una buona conversione, nel senso della rappresentazione visiva dell’immagine, spesso
questa struttura è stata sensibilmente modificata. Tuttavia si è cercato di rispettare il
più possibile l’organizzazione strutturale dei documenti.
La prima conversione realizzata è stata quella da SVG a VML. Questa traduzione
si è rivelata molto dispendiosa, dovuta al vasto dominio di SVG. È stato quindi deciso
di non tradurlo completamente. Visto che quella realizzata dovrebbe rappresentare
una prima versione del convertitore ci si è soffermati sugli aspetti principali dei due
linguaggi. Bisogna tuttavia segnalare che alcune caratteristiche non sono state tradotte
in quanto non supportate dall’altro formato (vedi sezione 3.1.4).
La seconda conversione, da VML a SVG, si è rivelata più semplice, in quanto le
caratteristiche supportate solo dal primo formato sono in numero molto più esiguo.
10
Anche in questo caso però alcuni aspetti non sono stati considerati, per scelta o per
mancanza di una corrispondenza in SVG e altri aspetti sono risultati approssimati,
sostanzialmente per una diversa gestione dei due linguaggi.
Le conversioni da SVG e VML a GIF sono state realizzate mediante due script
PHP, sfruttando un’opportuna libreria grafica che permette di creare un file in grafica
raster, e di inserirci vari elementi grafici, come ad esempio rettangoli, ellissi, path e
testi.
La metodologia alla base della traduzione è la stessa, per questo è stata descritta in
un’unica sezione (vedi 3.2) per entrambe le direzioni: è stato implementato un parser
che riconosce e gestisce opportunamente ogni elemento ed attributo incontrato.
Nella realizzazione di queste conversioni non sono stati tradotti tutte le caratteristiche dei due formati: alcune per mancanza di mezzi implementativi, cioè di parametri
nelle funzioni di PHP, altre per scelta. Quest’ultimo caso riguarda le opzioni non
tradotte nei convertitori tra SVG e VML. È sembrato opportuno avere una certa coerenza supportando le stesse caratteristiche in ogni convertitore.
Come accennato in precedenza è stata realizzata un’ultima applicazione per passare da GIF a SVG e VML. In questo caso si tratta di una semplice inclusione di
un’immagine esterna, realizzata mediante due script PHP, che creano un opportuno
documento con il riferimento (l’url) all’immagine da inserire.
Nel capitolo 4 sono state descritte più nel dettaglio le conversioni realizzate.
In conclusione con questa tesi si illustra il ruolo di rilievo della grafica vettoriale
rispetto a quella scalare, in particolar modo del formato SVG, standard del W3C che
si appresta ad avere un supporto globale. Viene motivata l’esigenza di un nuovo convertitore tra questi tipi di formati, la cui implementazione è ampiamente descritta,
spiegandone ideologie, pregi e difetti. Infine bisogna ricordare che quella realizzata è
la prima versione del convertitore, la quale non considera i due formati vettoriali nella
loro totalità, per questo si auspica una realizzazione futura di altre implementazioni
che ne migliorino le prestazioni.
11
12
Capitolo 2
Contesto: what the world needs now...
In questo capitolo verrà fatta una panoramica sull’uso delle immagini nel Web e sulla nascita di nuovi formati grafici. Successivamente verrano, in breve, descritti i tre
formati considerati per la conversione.
Verrà descritto un insieme di strumenti disponibili per gestire e operare con questi
formati e si elencheranno alcuni tipi di applicazioni inerenti.
Infine si passerà ad analizzare i motivi che hanno spinto alla realizzazione di questi
convertitori, esprimendo poi alcune considerazioni.
2.1 Le immagini nel Web
Inizialmente per presentare informazioni sul Web, visualizzate tramite browser, venivano combinati linguaggi di markup testuali (HTML prima, XML poi), con immagini
raster, cioè immagini rappresentate mediante una matrice che associa i colori ai rispettivi pixel. Questo approccio ha sempre mostrato evidenti limitazioni e incongruenze.
Innanzi tutto questo tipo di immagini sono pensate e create per essere rappresentate
ad una data dimensione (se vengono scalata si perde di qualità), quindi inserite in
un documento testuale ne forzano la rappresentazione del layout, non permettendo di
adattarsi in base alla dimensione e risoluzione dello schermo.
Oltre a questo, va ricordato l’alto consumo di bandwidth necessario per “caricare”
questi formati.
13
14
Infine, forse come motivo principale, queste immagini rappresentano degli oggetti
non leggibili, su cui non si ha alcun controllo, mentre la parte testuale può essere
visualizzata, editata, ed adattata alle proprie esigenze.
Da qui è nata l’esigenza di rappresentare le immagini in un altro modo, tramite
grafica vettoriale.
Inizialmente, nel 1998, sono stati proposti al W3C1 due linguaggi: VML (Vector
Markup Language), proposta tra gli altri da Microsoft e Macromedia [MatLeeDis98],
e PGML (Precision Graphics Markup Language), proposto da Adobe, Sun e Netscape
[AAC98].
Questi due linguaggi sono basati su XML [BPSMY04] e permettono di realizzare
immagini in grafica vettoriale bidimensionali. Sono compatibili con i principali standard quali CSS (Cascading Style Sheet) level 1 e 2 [BosWiu99] [BWLJ98] e DOM
(Document Object Model) level 1 [Woo98]. È possibile quindi inserire questo tipo di
immagini in documenti HTML o XML, che verranno gestite dalla parte client, adattandosi alle esigenze dell’utente e consentendo un effettivo risparmio di bandwidth.
Essendo in formato XML, tutto il disegno è rappresentato in maniera testuale, quindi facilmente indicizzabile, eventualmente anche da motori di ricerca. Inoltre va sottolineato che il testo è effettivamente testo e quindi è possibile effettuare ricerche e
selezioni. Un altro aspetto sull’importanza di questi formati è la possibilità di creare
immagini in maniera dinamica a partire da documenti XML, vedi [McKGri00].
A quel punto il W3C si è trovato ad un bivio, riguardo a quale linguaggio scegliere.
La soluzione adottata è stata quella di prendere il meglio da ogni formato e creare uno
standard nuovo. Da qui è nato SVG.
SVG (Scalable Vector Graphics) è il formato standard del W3C per rappresentare
immagini in grafica vettoriale in XML. Nell’Ottobre del 1998 viene creato un working
group per la creazione di questo linguaggio, che sfocia nella Recommendation della
versione 1.0, il 4 Settembre 2001 [Fer01].
1 W3C:
World Wide Web Consortium, il consorzio fondato da Tim Berners-Lee al fine di “sviluppare
protocolli comuni per migliorare l’interoperabilità e guidare l’evoluzione del World Wide Web”.
Capitolo 2. Contesto: what the world needs now...
15
Rispetto agli altri formati, presenta molte caratteristiche aggiuntive (specifica di
animazioni, gestione elaborata dei testi, ecc.). Uno dei punti chiave nella creazione di
questo linguaggio è stata l’accessibilità, cioè è stato pensato per poter essere usufruito
dal maggior numero possibile di utenti, permettendo, per esempio, di inserire nel
codice informazioni aggiuntive (metadati), per descrivere il contenuto dell’immagine.
In seguito è stata sviluppata la versione 1.1, Recommendation del 14 Gennaio 2003
[FerJunJac03], che fornisce una modularizzazione della versione precedente; questi
moduli possono essere combinati tra loro o con moduli di altre specifiche, per ottenere
sottoinsiemi od estensioni di SVG.
Da questo nascono due ulteriori specifiche, Mobile SVG Profiles [Cap03], pensate per l’applicazione di SVG a dispositivi con risorse limitate. I due profili sono i
seguenti:
• SVG Tiny: progettato per telefoni cellulari, quindi dispositivi con molte restrizioni;
• SVG Basic: realizzato per palmari (PDA).
Ogni profilo contiene una serie di moduli, e per ognuno specifica il grado di completezza (full, basic, tiny).
Un’altra specifica è rappresentata da SVG Print [Dan03], una versione di SVG
pensata per produrre documenti XML disponibili per essere stampati.
Attualmente si sta lavorando alla versione 1.2 di SVG, Working Draft del 27 Ottobre 2004 [Jac04].
2.2 I linguaggi coinvolti
2.2.1 SVG: breve descrizione strutturale
SVG (Scalable Vector Graphics) è un linguaggio per descrivere figure bidimensionali
e applicazioni grafiche in XML. Permette di realizzare immagini in grafica vettoria-
16
le scalabili, statiche o dinamiche. È una raccomandazione del W3C, e la versione
considerata per la conversione, 1.1, è datata 15 gennaio 2003.
Questo linguaggio viene usato per trattare tre tipi di elementi grafici:
• figure in grafica vettoriale (combinazioni di linee e curve);
• testo;
• immagini raster.
Le figure e i testi possono essere colorati, sia l’interno sia i bordi; i riempimenti
possono essere effettuati con colori semplici, con gradienti o con pattern. È possibile
effettuare vari tipi di trasformazioni sugli oggetti grafici, quali rotazioni o ingrandimenti.
Il contenuto di SVG può essere incluso in un documento SVG a se stante oppure
può essere incluso in un documento HTML, tramite varie opzioni (elemento object,
link con elemento a, elemento img). Inoltre SVG è compatibile con gli altri standard
del W3C, quali per esempio CSS, DOM e XSLT.
Una parte di un documento SVG consiste in un insieme di elementi contenuti in
uno o più elementi ‘svg’. L’elemento svg rappresenta un contenitore, il quale definisce
un nuovo sistema di coordinate (chiamato user space) che influenzerà tutti gli elementi
contenuti al suo interno. Contiene degli attributi per specificare la dimensione del
“contenitore” e il numero di coordinate per le ascisse e per le ordinate, in modo che
gli oggetti contenuti possano essere opportunamente posizionati mediante gli attributi
x ed y.
Per esempio se viene definito il contenitore di 10cm × 10cm e le coordinate sono
1000 × 1000, se si definisce un rettangolo di 100 × 100 questo sarà di dimensioni
effettive pari a 1cm × 1cm.
Un primo esempio di documente SVG è il seguente, la cui resa grafica è rappresentata
dalla figura 2.1:
<?xml version="1.0" standalone="no"?>
<svg width="15cm" height="10cm" viewBox="0 0 1500 1000"
17
Figura 2.1: Esempio SVG
xmlns="http://www.w3.org/2000/svg" version="1.1"
preserveAspectRatio="none">
<rect x="10" y="10" width="1480" height="980"
fill="none" stroke="blue" stroke-width="5" />
<rect x="200" y="100" width="1100" height="700"
fill="yellow" stroke="green" stroke-width="15" />
<ellipse cx="750" cy="400" rx="450" ry="200"
fill="white" stroke="blue" stroke-width="10" />

<path d="M 600 300 l 300 0 l -150
200
z"
fill="red" stroke="black" stroke-width="10" />
<text x="500" y="700" font-family="Arial"
font-size="70">Esempio SVG</text>
</svg>
18
SVG fornisce dei costrutti (elementi) per definire alcune figure di base (rettangoli, ellissi, ecc.) il cui utilizzo è molto semplice, come si evince dall’esempio: basta definire gli attributi per il posizionamento e il dimensionamento nonchè il tipo di
colorazione.
Un altro elemento di rilevante importanza è path, il quale permette di disegnare una
generica figura, specificandone i punti e i tipi di linee (con una sintassi ben precisa, ad
esempio m effettua uno spostamento, l disegna una linea).
L’elemento text, visto nell’esempio, serve per inserire un testo, specificandone la
posizione. Sono possibili gestioni complesse dei testi, gestendone in maniera diversa
varie porzioni.
Sono presenti numerosi altri aspetti di SVG, quali colorazioni (fill, stroke, opacità
e gradienti), trasformazioni (rotazioni, gestione di scale, ecc.), raggruppamenti (elemento g), animazioni e interattività ed inserimento di immagini esterne (raster). Per
maggiori dettagli si rimanda a [FerJunJac03].
2.2.2 VML: breve descrizione strutturale
VML (Vector Markup Language) è un’applicazione XML per rappresentare immagini
in grafica vettoriale. È stato proposto dalla Microsoft al W3C, nel Maggio del 1998, ed
è tuttora una submission. È compatibile con CSS1 e CSS2, anzi, si basa su CSS2 per
determinare il layout degli elementi grafici ed è supportato da Internet Explorer (dalla
versione 5.0) e da vari componenti di Office 2000 (Excel, PowerPoint, Word).
Questo linguaggio si può paragonare all’HTML: “VML supporta il markup per informazioni di grafica vettoriale nello stesso modo con cui HTML supporta il markup
per informazioni testuali” [MatLeeDis98]. VML è scritto in sintassi XML, come
HTML è stato scritto usando la sintassi di SGML.
Da notare che documenti VML veri e propri (stand-alone) non esistono, gli oggetti
grafici di VML sono inclusi all’interno di documenti HTML, utilizzando un opportuno
namespace, il quale fa in modo che il browser (IE), possa chiamare un programma per
visualizzare la parte VML (in IE5 è installato il programma VMLRender).
Per scrivere (o meglio disegnare) oggetti grafici in VML, oltre alla scrittura ma-
19
Figura 2.2: Esempio VML
nuale tramite editor testuale, si può utilizzare Office 2000, il quale permette di salvare
i documenti in formato HTML, nei quali, le immagini saranno rappresentate in sintassi
VML, vedi [Har04].
VML permette di definire un certo numero di elementi, non necessariamente inclusi in un contenitore, per rappresentare le varie figure. Sono tuttavia presenti alcuni elementi contenitori (shape e group) che permettono di raggruppare varie figure
definendo un nuovo sistema di coordinate, specificandone dimensioni (tramite le proprietà width ed height dell’attributo style) e numero di coordinate (tramite l’attributo
coordsize).
Vediamo ora un esempio di immagine in formato VML, la cui resa grafica è mostrata dalla figura 2.2:
<?xml version="1.0"?>
<HTML xmlns:v="urn:schemas-microsoft-com:vml"
xmlns="http://www.w3.org/1999/xhtml">
20
<HEAD>
<OBJECT id="VMLRender" classid="CLSID:..."></OBJECT>
<STYLE>v\:* {BEHAVIOR: url(#VMLRender)}</STYLE>
</HEAD>
<BODY>
<v:rect style="position: absolute; left: 10; top: 10;
width: 10cm; height: 10cm;" strokecolor="green"
fillcolor="green" strokeweight="10"
>
<v:fill on="false" />
</v:rect>
<v:shapetype id="t1" strokecolor="red"
fillcolor="yellow" strokeweight="5"
path="M 200,500 L 600,500 e" >
<v:textpath style="font-family: Arial;
font-size: 30;" on="true"
string="Esempio VML"
/>
</v:shapetype>

<v:shape type="#t1" style="position: absolute;
width: 500; height: 500;" coordsize="1500 1500">
<v:path textpathok="false"
v="m 450,250 L 700,250 L 575,500 x e"
/>
</v:shape>

<v:shape type="#t1" style="position: absolute;
width: 500; height: 600;"
fillcolor="green" coordsize="1000 1000">
<v:stroke on="false" />
<v:path textpathok="true" />
</v:shape>
<v:group style="position: absolute; width: 15cm;
height: 10cm" coordsize="1500 1000">
21
<v:oval style="position: absolute; left: 150;
top: 150; width: 700; height: 400;">
<v:fill on="true" color="red" opacity="0.2" />
<v:stroke on="true" color="black" weight="2.5" />
</v:oval>
<v:rect style="position: absolute; left: 100;
top: 100; width: 800; height: 500;"
strokecolor="blue" strokeweight="5">
<v:fill on="false" />
</v:rect>
</v:group>
</BODY>
</HTML>
VML dispone di vari elementi per definire alcune figure di base (rettangoli, ellissi,
ecc.), le quali tramite l’attributo style, vengono posizionate e dimensionate. Queste figure, come ogni altro elemento, possono essere raggruppate tramite l’elemento group.
Quest’elemento mediante width e height e l’attributo coordsize, definisce una regione
in cui rappresentare gli oggetti contenuti ed un sistema di coordinate che influenza tutti
i valori degli elementi.
Un altro elemento di notevole importanza è shape usato per creare un figura generica. Presenta una serie di attributi per specificare il posizionamento e il dimensionamento, tra i quali coordsize, che definisce un nuovo sistema di coordinate. Al suo interno
può contenere dei path, dei testi (o semplici in sintassi HTML, o testi inseriti in path),
oppure riferimenti ad immagini raster esterne. Un elemento analogo è shapetype, che
svolge la medesima funzione, solo che non visualizza il contenuto, può essere solo
richiamato da un’altro elemento shape (il quale erediterà le proprietà, sovrascrivendo
eventuali valori).
Per avere informazioni sulle restanti proprietà (fill, stroke, ecc.) o per ulteriori
dettagli si rimanda a [MatLeeDis98] oppure a [Mic98a].
22
2.2.3 Confronto tra SVG e VML
Dopo l’analisi dei due linguaggi, si può passare ad effettuarne un confronto, in relazione ai tool che li supportano, alla struttura dei documenti e al tipo di figure realizzabili.
Innanzi tutto va rilevato che SVG è stato sviluppato dopo che VML è stato proposto
al W3C come standard per rappresentare disegni in grafica vettoriale; quindi ha potuto
beneficiare dell’altro linguaggio. Tuttavia la strutturazione dei documenti è simile solo
in parte.
Si può affermare che SVG è più rigido nella sua struttura, mentre VML è più
flessibile, si possono paragonare ad XML e ad HTML, in cui il primo dev’essere ben
formato, mentre il secondo viene comunque visualizzato dai browser. Va ricordato che
il codice VML è incluso in un documento HTML, e che la sua integrazione è strutturalmente evidente, in quanto entrambi si basano su CSS per esprimere le proprietà
dei vari elementi.
In SVG tutto il contenuto è racchiuso in un elemento svg che funge da contenitore
e dimensiona la figura e tutti i successivi oggetti grafici definiti. Ogni oggetto grafico
dispone di uno specifico elemento per rappresentarlo, tutte le proprietà sono specificate tramite attributi ed è supportata un’ereditarietà completa sugli attributi mancanti.
Gli elementi possono essere raggruppati in modo da applicare gli stessi effetti ad un
certo numero di oggetti. Sono disponibili molti tipi di effetti quali trasformazioni,
implementate con un opportuno attributo od effetti particolari, quali per esempio gradienti o filtri, definibili separatamente e richiamati tramite riferimento. Anche i testi
sono definiti tramite un semplice elemento che ne specifica le caratteristiche ed il contenuto. Infine tutti gli elementi possono essere definiti in un opportuno contenitore ed
essere richiamati più volte nel documento.
D’altro canto VML è molto più verboso ed ha una struttura meno coerente. Non
necessita di un elemento contenitore come radice, tuttavia può essere realizzato tramite
raggruppamento, permettendo di specificare un parziale dimensionamento e posiziona-
23
mento; parziale in quanto le figure occuperanno sempre tutto lo spazio a disposizione
(tutta la finestra del browser) e non è possibile fare clipping (cioè impedire la visualizzazione all’esterno di un determinato perimetro) degli oggetti grafici. Molte delle
figure esprimibili, hanno uno specifico elemento per crearle, tranne alcune che devono
essere inserite e gestite in modo opportuno, con l’elemento shape. Quest’elemento specifica una figura, utilizzando path, testi o immagini esterne; la scelta su quale
oggetto rappresentare si basa su attributi presenti negli elementi figli. È presente un
elemento, shapetype, che permette di definire delle figure da richiamare più volte nel
documento, ma queste figure sono solo di tipo shape, non permettendo di definirne altre quali rettangoli o ellissi. Per quanto riguarda l’ereditarietà: vengono ereditati solo
i valori di dimensionamento, mentre le proprietà grafiche, quali fill e stroke, no.
Come ultimo aspetto passiamo agli effetti grafici e alle trasformazioni. Non esistono attributi specifici per realizzare trasformazioni, si realizzano o tramite proprietà
CSS (rotation) o dimensionando opportunamente gli altri attributi. Inoltre sono presenti un limitato insieme di attributi, non utilizzabile da tutti gli elementi per specificare
effetti grafici. Infine è molto più verboso, per rappresentare le stesse caratteristiche di
SVG richiede un maggior numero di elementi ed attributi.
Per quanto riguarda gli applicativi che supportano i due formati, bisogna notare la
maggiore influenza di SVG. VML è sopportato principalmente dai prodotti Microsoft,
IE ed Office 2000, che permettono di visualizzarlo ed editarlo. SVG non è supportato
direttamente dai browser, richiede l’aggiunto di opportuni plug-in, come l’Adobe SVG
Viewer; tuttora è completamente supportato solo da IE, ma molti altri prodotti si stanno predisponendo al suo utilizzo, come per esempio una versione di Mozilla, Croczilla
[Moz05], che ne supporta una parte. Sono inoltre presenti numerosi tool per editare
o convertire immagini in formato SVG, mentre VML sembra non essere considerato
dalle case produttrici di software, visto che non è uno standard e non sembra che lo
diverrà mai. Per maggiori dettagli su vari tool specifici si rimanda a 2.3.
Veniamo ora ai tipi di figure ed effetti supportati dai due linguaggi. VML presenta un esiguo numero di caratteristiche non supportate dall’altro linguaggio, quali la
24
possibilità di definire l’ordine di annidamento delle figure, l’utilizzo di funzioni matematiche per calcolare determinati valori, alcune caratteristiche dei path e la definizione
semplificata di archi e curve. Le caratteristiche esclusive di SVG, d’altro canto sono
in numero maggiore. Abbiamo una lunga lista di effetti grafici (filtri, clipping, ecc.),
la possibilità di definire animazioni, ed alcuni tipi di trasformazioni. Una nota a parte
merita la rappresentazione dei testi, in cui VML mostra maggiormente i suoi limiti,
permettendo una semplice definizione in stile HTML o la rappresentazione su path.
Con SVG è possibile inserire i testi in qualsiasi posizione, gestire sottotesti, od addirittura ogni singolo carattere, in modo indipendente.
Anche a livello accademico si nota il supporto maggiore di SVG, in quanto è
l’unico linguaggio vettoriale ampiamente descritto, analizzato ed implementato. Al
proposito basta pensare alla conferenza annuale su SVG, SVG Open [SVKHKP05], e
agli svariati siti Internet specifici, tra i quali si segnalano: svg-cafe [Php02], svg.org
[Gus05] e svg-wiki [Svg05].
In conclusione si può affermare che SVG è più chiaro e più completo. È più facile
da imparare ed è maggiormente considerato e implementato.
2.2.4 GIF
Lo standard GIF (Graphic Interchange Format), è un formato grafiche che rappresenta le immagini tramite bitmap, cioè tramite una matrice che associa ad ogni pixel i
rispettivi colori. È stato sviluppato, alla fine degli anni 80 da CompuServe, con l’intenzione di definire un protocollo per la trasmissione on-line (platform-independent)
e lo scambio di immagini raster. È ottimizzato per rappresentare le immagini ad una
data dimensione, scalandole si perde di qualità. Questo formato inoltre è ampiamente
usato per rappresentare disegni animati.
Data la diffusione e la conoscenza di GIF, si è preferito non soffermarsi troppo
sulla sua descrizione e sugli strumenti di gestione disponibili.
25
2.3 Applicativi esistenti
In questa sezione vengono elencati i principali programmi di gestione di SVG e VML,
suddivisi in categorie. Batik, visto il ruolo importante che svolge, in quanto sembra
essere lo strumento più usato e più completo per la gestione di SVG, viene descritto
separatamente.
2.3.1 Viewer
VML
Essendo VML solo una Submission del W3C, quindi non uno standard, i prodotti che
lo supportano sono pochi. Dal momento che è un linguaggio proposto dalla Microsoft,
è supportato dai prodotti Microsoft. L’unico visualizzatore attualmente presente, e
probabilmente resterà unico, è Internet Explorer, dalla versione 5. In questo browser
è installato un programma, VMLRender, che permette di visualizzare immagini in
formato VML.
Per poter usare VML si deve inserire il codice in un documento HTML, specificando nell’intestazione il namespace
xmlns:v = "urn:schemas-microsoft-com:vml"
e le seguenti informazioni:
<HEAD>
<OBJECT id="VMLRender"
classid="CLSID:10...">
</OBJECT>
<STYLE>
v\:* {BEHAVIOR: url(#VMLRender) }
</STYLE>
</HEAD>
In questo modo viene segnalato al browser di “passare” tutti gli oggetti con namespace v, al VMLRender che provvederà alla loro effettiva visulizzazione. Per maggiori
dettagli si rimanda a [Mic98a].
26
SVG
Per visualizzare un documento SVG, oltre all’utilizzo di appositi applicativi, che permettono di effettuare operazioni più complesse, come editing e conversioni, per i quali
si rimanda alle sezioni successive, la soluzione più semplice ed intuitiva è l’utilizzo di
un web browser. SVG è nato con lo scopo di rappresentare le immagini in un formato
coerente con XML, per utilizzarle in applicazioni web, quindi è auspicabile che queste
applicazioni web, di norma i browser, possano rappresentare la grafica di SVG.
Sfortunatamente di browser che supportano nativamente SVG ce ne sono pochi, il
più importate è Amaya (vedi sezione 2.3.2), gli altri di norma richiedono l’aggiunta di
opportuni plug-in.
I principali plug-in disponibili sul mercato sono i seguenti:
Adobe SVG Viewer: questo plug-in, attualmente alla versione 3.0, è disponibile per
sistemi Windows (da 95) e Macintosh (dalla versione 8.6), per i browser Internet
Explorer (dalla versione 5) e Netscape Navigator o Communicator (dalla versione 4.5 alla 4.78, la versione 6 non è supportata). Sono supportate la maggior
parte delle caratteristiche di SVG con prestazioni molto buone, tuttavia presenta una fondamentale limitazione, riguardo alla mancanza dell’attivazione della
barra di scorrimento, nel caso in cui l’immagine “esca” dai bordi dello schermo.
Per maggiori informazioni si rimanada a [Ado05].
Corel SVG Viewer: oltre a servire per la visualizzazione di immagini SVG nei browser, è una delle componenti chiave del Corel Smart Graphics Studio (ambiente
di sviluppo per creare grafici in SVG da documenti XML). È stato sviluppato
per sistemi Windows (da NT) e si applica ad Internet Explorer (dalla versione
5.5) e a Netscape Navigator o Communicator (nelle versioni 4.79 o 7.02). Per
maggiori informazioni vedi [Cor03].
Per quanto riguarda l’ambiente Linux/Unix, c’è da segnalare il progetto KSVG,
integrato nell’ambiente KDE, dalla versione 3.2, il quale permette la visualizzazione
di immagini in formato SVG, tramite il web browser Konqueror. La versione attuale di
questo plug-in non è da considerarsi completa, molti aspetti del linguaggio sono ancora esclusi, specialmente l’integrazione con altre tecnologie; per ulteriori informazioni
27
si rimanda a [BuiZim04].
Anche Mozilla presenta un’implementazione di SVG. A differenza dell’utilizzo di
plug-in, quella proposita è un’implementazione nativa. Non è integrata nella release
ufficiale di Mozilla, ma è disponibile nel Mozilla CVS repository.
Allo stato dell’arte non sono molte le caratteristiche supportate, manca completamente la gestione delle animazioni e degli effetti grafici, ed è presente una gestione semplificata dei testi; gli elementi basilari tuttavia sono gestiti. Informazioni
supplementari possono essere trovate in [Moz05].
2.3.2 Editor
Per quanto riguarda gli applicati per editare documenti SVG o VML, si deve ricordare
che essendo formati XML, sono leggibili e quindi per poter essere creati si può usare
un semplice text editor. Questa soluzione è accettabile per la creazione di immagini
semplici, in cui sono presenti pochi oggetti od elementi basilari.
La realizzazione di disegni più complessi, per esempio con curve di Bézier, consistenti di particolari effetti grafici (ombreggiature, ecc.) presenta la necessità di uno
strumento WYSIWYG, che permetta di disegnare in maniera semplice le figure (senza
specificare il markup) e ottenere da esse il corrispondente codice.
Di seguito sono presentati alcuni tra i più significativi editor presenti sul mercato.
VML
Per la gestione di VML, come affermato in precedenza, sono presenti un numero esiguo di applicativi, la maggior parte dei quali di proprietà di Microsoft. Di seguito sono
presentati i due strumenti maggiormente utilizzati:
Microsoft Office 2000: gli applicativi Word, Excel e PowerPoint supportano VML. È
possibile convertire le immagini create con questi programmi in formato VML
(inserito in un documento HTML).
Per fare questo bisogna specificare nelle impostazioni che si desidera utilizzare
28
VML come formato per rappresentare le immagini nei browser. Salvando poi il
documento in formato Web si otterrà il documento VML (vedi [Har04]).
Va ricordato che vengono convertite solo le immagine generate tramite gli appositi strumenti di disegno di questi programmi; quindi Office non rappresenta un convertitore, ma un semplice editor che tuttavia una volta generato il
documento VML, dà la possibilità di modificarlo esclusivamente a livello di
codice.
Microsoft VML Generator: questo prodotto è quanto di meglio sia presente sul mercato per realizzare da zero documenti VML [Mic98b].
Figura 2.3: VML Generator
Presenta una semplice interfaccia grafica suddivisa in quattro sezioni: la barra
di comandi, un pannello di opzioni (che permette di inserire elementi ed attributi, anche se in minima parte), una schermata in cui appare il codice (editabile)
dell’immagine ed una porzione che mostra un’anteprima dell’immagine.
Non è un grande prodotto, in quanto molti elementi non sono supportati (sono
da inserire manualmente), tuttavia è uno dei pochi disponibili ed è freeware.
29
SVG
“Gli editor sono un mattone per il successo di SVG” [HauWen04].
Sono presenti numerosissimi editor per SVG, tra i quali bisogna distinguere tra
quelli nativi, cioè quelli che hanno come scopo principale produrre immagini SVG e
gli altri, che hanno aggiunto SVG alla lista dei formati supportati. Questi ultimi “non
supportano il contenuto SVG ad un livello che chiunque sia coinvolto in uno sviluppo
a livello di codice possa trovare accettabile” [Edw02].
A seguire saranno presentati alcuni tra i più importanti editor nativi e verrà presentata una breve descrizione di Adobe Illustrator, un applicativo in grado di gestire
oggetti SVG.
Amaya: è il web browser ed editor del W3C [Vat04], [Vat05]. Serve sia per visualizzare pagine web sia per crearle. Inizialmente supportava HTML e CSS, in seguito è stato esteso per supportare XML e le sue applicazioni com MathML e SVG.
Supporta alcuni tipi di animazioni e alcune figure vettoriali di base. Tuttavia non
è molto usabile, ma è open source.
Jasc WebDraw: è stato uno dei primi editor nativi di SVG [Edw02]. Supporta tutte le
caratteristiche di SVG tramite un’interfaccia semplice ed efficace. È un prodotto
commerciale ed è disponibile solo per sistemi Windows.
Figura 2.4: WebDraw
30
Sono presenti tre ambienti di sviluppo: il primo presenta una finestra WYSIWYG, in cui è possibile inserire le varie figure mediante opportune palette,
specificando eventualmente animazioni e complessi effetti grafici in una maniera
molto semplice ed intuitiva.
Il secondo ambiente è rappresentato dal codice sorgente dell’immagine creata,
editabile e con un correttore automatico in grado di rilevare eventuali errori.
Infine è disponibile una preview per visualizzare l’immagine comprensiva delle
animazioni.
Quindi un buon prodotto, semplice da usare e molto potente.
Sodipodi: è un editor open source nativo per SVG basato su GTK, il toolKit di GIMP
[Kap03].
Figura 2.5: Sodipodi
Presenta un interfaccia simile a quella di molti programmi grafici di Linux, con
varie palette e finestre di dialogo ed una finestra di editing in cui poter disegnare.
Inoltre è possibile accedere e modificare il codice SVG.
Offre grandi prestazioni per la realizzazione di path, in special modo nella gestione delle curve di Bézier. D’altra parte la versione attuale presenta delle limi-
31
tazioni in quanto non sono supportate molte delle caratteristiche fondamentali di
SVG, quali ad esempio le animazioni.
Adobe Illustrator: questo programma permette di creare immagini ed esportarle in
formato SVG, specificando varie opzioni, come l’utilizzo di fogli di stile, o il
livello (inteso come ordine di visualizzazione) degli elementi; supporta un gran
numero di caratteristiche, tra le quali l’interattività, ed è abbastanza agevole da
utilizzare.
Come ricordato in precedenza, non è un editor nativo, e questo si vede. Innanzi
tutto, tutti gli oggetti vettoriali vengono convertiti in path, quindi si perde la
definizione di elementi quali rettangoli od ellissi. Molte caratteristiche, come
ombreggiature e gradienti, non sono direttamente supportate ma vengono trattare
come oggetti raster inseriti nel file SVG.
Per maggiori dettagli si rimanda a [Ado01].
2.3.3 Convertitori
Attualmente è disponibile una lunga serie di applicativi per gestire conversioni di formati, riguardanti SVG, per VML il numero è molto più esiguo. Queste applicazioni
permettono per esempio di trasformare documenti PDF o SWF in formato SVG. Tuttavia si è preferito privilegiare la descrizione di programmi che traducono formati
grafici.
In questa sezione saranno presentati alcuni tra i principali convertitori per convertire immagini raster in grafica vettoriale e viceversa; la maggior parte si riferisce esclusivamente al formato SVG. Oltre a questi sono presentati due applicativi per ottenere
documenti SVG o VML da qualsiasi input.
SVG MAKER e VML MAKER
Questi due programmi [Sof04] [Sof02], realizzati da Software Mechanics, rappresentano delle stampanti virtuali.
32
Sono realizzati esclusivamente per sistemi Windows (dal 95) e consento di convertire in SVG o VML qualsiasi documento stampabile.
L’idea di base è la seguente: se dal documento sorgente si riescono ad estrarre
delle informazioni (sul testo o sulle figure) queste sarranno rappresentate tramite gli
opportuni elementi, tutto il resto viene convertito in un’immagine raster da includere
nel documento VML o SVG. Quindi i file ottenuti possono contenere path (nel caso di
VML solo linee), testi o immagini raster.
Questi due programmi sono compatibili con molte applicazioni esistenti, cioè sono
ottimizzati per interpretare le informazioni contenute in queste applicazioni. Per esempio alcuni tra i formati supportati sono: PDF, CAD e i documenti prodotti da
Office.
Nel dettaglio:
• la versione attuale di VMLmaker è del Giugno 2002, non è molto funzionale,
sopporta limitatamente la gestione dei testi (realizzati tramite applicazioni di
Office), mentre tutto il resto è convertito in bitmap;
• SVGmaker, attualmente alla versione 2.0, datata Novembre 2004, è dotato di
una potenza maggiore, supporta in larga misura Acrobat, CAD e Office, cioè è
in grado di riconoscerne i testi e rappresentarli ottimamente, e riconosce molti
elementi grafici, rappresentati tramite path.
Nel complesso VMLmaker non sembra dare risultati accettabili, mentre SVGmaker appare un valido prodotto. Il documento creato è abbastanza limitato, in sostanza
tutto è rappresentato tramite path, ma la gestione dei testi è veramente buona.
CR2V
CR2V, Celinea Raster to Vector converter, è un progetto, sviluppato in C++, nato per
“convertire fotografie e disegni in una formato vettoriale puro e leggero” [Sia03a].
Consente di convertire immagini in formato BMP, TIFF, PNG, JPEG e GIF in
SVG. Presenta una buona gestione dell’immagine di partenza, rappresentandola completamente tramite path, i quali sono molto precisi, e “a differenza di altri program-
33
mi di tracing, semplifica l’immagine generata rimuovendo dettagli insignificanti ed
estraendo l’essenza dell’immagine”.
Va sottolineato che l’immagine di partenza viene gestita completamente tramite
path, quindi eventuali testi verranno anch’essi trattati come path; anche se la resa
grafica è ottimale: si perde il testo, inteso come leggibilità e ricerca all’interno del
documento. Permette di specificare il livello di dettaglio con cui rappresentare l’immagine di partenza, portando quindi ad un incremento della qualità del disegno e
coseguentemente all’aumento della dimensione del file.
Attualmente CR2V è disponibile come funzione chiave di Vector Eye, un programma per convertire immagini raster in formato vettoriale, dotato di un’interfaccia grafica
semplice da usare [Sia03b].
Questo programma è disponibile solo per sistemi Windows.
KVEC
Questo prodotto, della ditta tedesca KK-Software [KKS04], permette di convertire
immagini raster in grafica vettoriale e per alcuni formati, come SWF (il formato di
Macromedia Flash), supporta anche la conversione inversa.
Non è molto buono per quanto riguarda l’usabilità, in quanto viene eseguito esclusivamente mediante linee di comandi, non presentando un interfaccia grafica. Per
quanto riguarda le conversioni verso il formato SVG, non mostra buoni risultati. La
traduzione non è molto buona e precisa e la dimensione del file risulta eccessivamente
grande. Il file SVG creato è composto da path formati esclusivamente da linee rette.
A suo favore va ricordato che funziona praticamente su tutti i sistemi.
CSIRO SVG TOOLKIT
CSIRO SVG Toolkit [Csi02] rappresenta una collezione di utility per effettuare varie
operazioni con i documenti SVG. Contiene un viewer, un’implementazione del DOM
di SVG ed è in grado di convertire immagini SVG in vari formati raster.
34
È un applicazione open source basata su tecnologia Java. L’ultima versione (12
Marzo 2002) supporta le principali caratteristiche di SVG, ad esclusione degli effetti
grafici (filtri) e presenta una gestione limitata dei testi.
Attualmente è da considerarsi un prodotto obsoleto, soppiantato dal toolkit di Batik
vedi 2.3.4.
2.3.4 Batik SVG toolkit
Batik è uno strumento basato su tecnologia Java per applicazioni o applet che vogliono
usare immagini in formato SVG per vari scopi, come visualizzazione, generazione e
manipolazione.
Lo scopo di questo strumento è quello di dare agli sviluppatori un insieme di moduli da poter usare (o meglio integrare) nelle loro applicazioni per supportare e gestire
immagini in formato SVG.
È stato sviluppato a partire dall’estate 2000 dalla Sun Microsystems e da altre
organizzazioni; l’attuale versione 1.5.1 è dell’estate 2003. È un prodotto open source
ed è possibile ottenere i file sorgenti dal sito di Apache (http://xml.apache.org/batik).
A RCHITETTURA
Batik si struttura in tre moduli:
• Applications: illustra le funzionalità che Batik offre;
• Core: contiene i moduli per manipolare, generare, creare, convertire e visualizzare contenuti SVG;
• Low Level: contiene moduli usati internamente dal modulo Core; non sono
direttamente usati dagli sviluppatori.
TOOL
E APPLICAZIONI
Di seguito vengono elencate alcune applicazioni, disponibili con la distribuzione di
Batik:
35
Figura 2.6: Utilizzo di Batik
• Squiggle SVG Browser: browser che permette di visualizzare documenti SVG.
Consente di visualizzare il codice sorgente, l’albero del documento, consente di
effettuare rotazioni dell’immagine, ingrandimenti e restrizioni;
• SVG Rasterizer: è un utility che consente di convertire documenti SVG in un
formato raster (JPEG, PNG, o TIFF);
• SVG Font Converter: permette di convertire font True Type in font SVG, in
modo da rendere l’immagine SVG indipendente dai font supportati dai vari
sistemi.
E SEMPI
DI PROGETTI E PRODOTTI CHE LO UTILIZZANO
Sono presenti tantissimi progetti e prodotti che utilizzano Batik, di seguito ne vengono
elencati alcuni:
• Progetto Apache FOP: usa Batik per trattare immagini SVG. Permette di convertire file SVG in PDF;
36
• Progetto Apache Cocoon: usa Batik per rasterizzare immagini SVG;
• XWeb: usato per creare siti Web in maniera automatica da documenti XML, usa
Batik per convertire SVG in immagini raster;
• XML svg2image: classe PHP che traduce documenti SVG in JPEG o PNG.
In conclusione questo toolkit rappresenta un ottimo prodotto, attualmente il migliore,
per chi intende sviluppare applicazioni utilizzando SVG. Dispone di un convertitore
che permette di ottenere immagini pressoché perfette.
Per maggiori riferimenti sull’utilizzo o su come sviluppare applicazioni con Batik
si rimanda rispettivamente a [DewHar02] e [Kor02].
2.4 Applicazioni di un formato grafico vettoriale
Oltre al semplice utilizzo per rappresentare immagini nel web, i formati vettoriali
XML, si prestano ad una molteplicità di altri usi. Di seguito vengono elencate applicazioni per cui SVG (ed eventualmente anche VML) si dimostrano dei punti di
forza:
• Generazione dinamica di immagini: in molti casi può nascere la necessità di
utilizzare delle immagini, o meglio dei grafici, per meglio rappresentare dei valori numerici. Per esempio, in [Asm03], viene mostrata la necessità di una banca
di rappresentare dei grafici (a torta) per mostrare vari tipi di dati memorizzati in
documenti XML. Utilizzando un foglio di stile XSLT è possibile ottenere grafici
in SVG in una maniera molto semplice.
Un altro esempio è rappresentato da [BGLS03], in cui vengono mostrate applicazioni in ambito scientifico di SVG. Tramite alcuni dispositivi vengono recuperate informazioni, in tempo reale (per esempio riguardo alla meteorologia) e viene mostrato come generare on-the-fly grafici e immagini in SVG, in
quanto “i dati numerici possono essere compresi più facilmente se rappresentati
graficamente in un opportuno contesto”.
Altri esempi sono dati da [GebGal00], [FroHar02] e [Mor04].
37
• Rappresentazione di Mappe: molto diffusa e importante è la rappresentazione
delle cartine geografiche in rete. Con il tradizionale approccio, tramite immagini
raster, si presentavano numerosi problemi:
– l’immagine era pressoché statica, non permettendo interazioni;
– la scalabilità era concessa ma degradando la qualità; servivano lunghi tempi di attesa per generare le mappe dal server;
– ogni mappa veniva generata in base alle esigenze degli utenti, non permettendo una scalabilità, nel senso di utenti che utilizzano simultaneamente la
stessa cartine.
Tramite l’utilizzo di SVG (ed in parte con VML) questi problemi vengono risolti.
Le informazioni vengono memorizzate in un database e si creano le cartine onthe-fly, permettendone l’utilizzo simultaneo. Inoltre, con SVG, è possibile effettuare ingrandimenti e riduzioni senza perdita di qualità. È anche possibile
associare degli eventi alle immagini, in modo da riuscire per esempio, cliccando
sul nome di una città, a far comparire una schermata con delle statistiche.
Inoltre, tramite l’utilizzo di elementi quali defs e use, che permettono di definire
una figura una volta sola e di richiamarla più volte nel documento, è possibile
ottimizzare la rappresentazione delle mappe, definendo i simboli separatamente
e richiamandoli nei punti opportuni.
Per maggiori dettagli sulla rappresentazione delle mappe si rimanda ai lavori di
[NeuWin01] e [Zas00].
• Trasformazioni inter–media: SVG può essere usato per rappresentare graficamente informazioni testuali. Ad esempio in [JBMOW03] viene mostrato come
convertire i seguenti formati:
– MusicXML: formato XML per rappresentare musica (definizione di spartiti);
– BioML: descrive informazioni biomolecolari (rappresentazioni del dna);
38
– CALCS: formato per memorizzare informazioni su acquisti, da cui si possono creare grafici di vario tipo.
• Animazioni: tramite SVG si possono realizzare complesse animazioni grafiche,
sullo stile di Macromedia Flash. Quest’ultimo formato, per quanto diffuso, ha
dalla sua alcuni svantaggi:
– è un formato proprietario;
– è binario, non si può leggere il codice;
– non si integra con gli altri standard.
D’altra parte, la programmazione in Flash è in uno stato più evoluto e dispone
di molti più strumenti che ne facilitano la gestione. Tuttavia, SVG è ancora
relativamente giovane ed è auspicabile che possa diventare la tecnologia per animazioni del futuro. In quest’ambito va segnalato lo sviluppo di animazioni per
applicazioni mobili [And04].
Per maggiori dettagli su un confronto tra Flash e SVG si rimanda a [HUNW04].
2.5 Perché realizzare un nuovo convertitore
2.5.1 Conversione VML – SVG
A questo punto della dissertazione dovrebbe sembrare ovvio il motivo per cui convertire immagini VML in SVG, il dubbio dovrebbe venire per la conversione inversa!
Prima di analizzare quest’ultimo aspetto, vengono riportate le motivazioni che
spingono al passaggio da VML a SVG:
• innanzi tutto non esiste in commercio un tale convertitore, e i convertitori, per
quanto poco possano servire, sono sempre strumenti necessari, da usare all’evenienza;
• SVG è un formato standard, l’attuale versione è una Recommendation del
W3C, mentre VML è rimasto una proposta. Questo vuol dire che le aziende spe-
39
cializzate si sono dedicate al supporto di SVG, non sprecando tempo e risorse
per un formato che non offre garanzie;
• per il motivo precedente, si può affermare che SVG è supportato da molte più
applicazioni e da molti più ambienti, mentre VML è utilizzabile esclusivamente
con sistemi Microsoft;
• la sintassi di SVG è molto più semplice ed intuitiva, permette un editing manuale più agevole;
• alcuni applicativi di Office 2000 (Word, Excel, PowerPoint), permettono di “salvare” le immagini in formato VML. Con il convertitore si possono tradurre
quindi documenti di Office in un formato standard.
Passiamo ora ad analizzare gli aspetti per cui realizzare il convertitore da SVG a
VML:
• anche in questo caso convertitori non ne esistono, quindi può risultare utile;
• i plug-in esistenti mostrano delle limitazioni, per esempio, tramite l’Adobe SVG
Viewer, visualizzando un’immagine SVG su un browser, l’eventuale area che
“esce” dallo schermo non viene visualizzata, o meglio, non viene inserita una
barra di scorrimento per permetterne una visione completa;
• possono esserci applicazioni che utilizzano esclusivamente VML come formato
grafico vettoriale;
• VML permette una gestione di testi in sintassi HTML, quindi, permette di definire
paragrafi e altri costrutti più complessi, come le tabelle. SVG non ha una gestione di questo tipo; la limitazione più forte riguarda la mancanza di un comando per definire l’“a capo”, realizzabile esclusivamente mediante un opportuno
posizionamento.
40
2.5.2 Conversione in GIF
Il formato GIF, come d’altronde molti altri formati raster, è allo stato dell’arte universalmente accettato, sia dalle applicazioni grafiche sia dai web browser. Come è stato
specificato in precedenza ha dalla sua molti svantaggi (non scalabile, dimensione consistente, ecc.) tuttavia gode di un enorme diffusione.
Di seguito sono riportate alcune motivazioni che hanno spinto alla realizzazione
dei convertitori da SVG a GIF e da VML a GIF.
Per quanto riguarda la prima conversione (da SVG a GIF), bisogna notare che SVG
è uno standard aperto e probabilmente passerà ancora molto tempo prima di un suo
supporto globale; per il momento però funziona solo su alcuni sistemi e con particolari
strumenti (vedi plug-in di Adobe), quindi può rendersi necessaria una sua conversione
per poter visualizzare l’immagine in ogni ambiente.
Convertitori di questo formato ne esistono, alcuni anche ottimali, come Batik, che
traduce perfettamente l’immagine da SVG in un formato raster (supporta PNG, JPEG
e TIFF); attualmente non supporta GIF, ma è prevista una sua futura integrazione.
Il nuovo convertitore non ha una rappresentazione ottimale, tuttavia è ad un livello
più che buono ed è stato realizzato per ragioni di completezza, per permettere cioè di
poter passare da uno qualsiasi dei tre formati ad un altro. Inoltre, essendo realizzato
con uno script PHP, è possibile integrarlo in applicazioni web server side, in modo da
limitare le risorse richieste dall’utente, fornendo la possibilità di ottimizzare le conversioni utilizzando meccanismi di caching.
Per la conversione da VML a GIF, si segnala che convertitori di questo tipo (da
VML a immagini bitmap) non sembrano esistere. Questo appare abbastanza normale
vista la non standardizzazione e il disuso del formato. In ogni caso è un formato valido
e in certi ambiti è ancora utilizzato, in particolar modo nei sistemi Windows. Da questo
appare ancora più evidente rispetto all’altro formato la necessità di una traduzione in
formato raster.
41
In conclusione si può affermare che una conversione dal formato VML è necessaria in quanto questo linguaggio è ormai obsoleto e supportato da un numero esiguo
di applicazioni. D’altro canto SVG è nel pieno del suo sviluppo, ma non ha ancora
raggiunto un supporto completo. La conversione in GIF permette di ottenere quindi,
un’immagine che sarà sicuramente accettata da ogni sistema.
2.6 Conclusioni
In questo capitolo sono stati introdotti e descritti i formati grafici vettoriali, mettendone
in evidenza i pregi rispetto ai tradizionali formati bitmap. Sono stati descritti i formati
più “popolari” SVG e VML, ed è stato mostrato come il primo abbia ormai superato
per diffusione e uso il secondo.
Sono stati visti alcuni applicativi per gestire questi linguaggi ed alcune possibili
applicazioni. Infine è stata motivata la realizzazione del nuovo convertitore.
Infine si segnala che quella realizzata è una prima versione dei traduttori, in cui si
considerano solo le caratteristiche principali dei vari linguaggi, escludendone completamente altre, ottenibili in future versioni. Nel capitolo successivo verranno descritte
più nel dettaglio le conversioni realizzate.
42
Capitolo 3
Descrizione ad alto livello: analyze this
In questo capitolo vengono descritti i traduttori realizzati. Due di essi permettono di
trasformare un documento scritto in sintassi SVG in uno scritto in sintassi VML e
viceversa. Sono stati realizzati mediante l’utilizzo di fogli di stile XSLT. Altri due
convertitori permettono di tradurre un documento SVG in un’immagine GIF e un
documento VML anch’esso in un immagine GIF, realizzati mediante script PHP.
Inoltre è stata creata un’applicazione per otterere file SVG e VML da GIF, realizzata in PHP tramite una semplice inclusione di immagini.
In questo capitolo verranno descritte le traduzioni realizzate specificando gli strumenti utilizzati, le ideologie alla base di ognuna di esse, i pregi e i difetti. Infine
verranno mostrate alcuni esempi di conversione.
3.1 Conversione tra SVG e VML
In questa sezione si illustrerà lo strumento di conversione utilizzato, XSLT, con le
motivazioni che hanno spinto al suo utilizzo. Verranno descritti poi i principi seguiti,
passando poi alla descrizione vera e propria delle conversioni, analizzandone gli aspetti
fondamentali, mostrando numerosi esempi e descrivendo alcune caratteristiche escluse
dalle trasformazioni.
43
44
3.1.1 Metodo di traduzione: utilizzo di XSLT
Per effettuare queste conversioni si sarebbero potuti usare molti metodi, come script
PERL, script PHP, od applicazioni Java, come espresso in [Jol03] e in [PMEB01]. Tuttavia, vista la natura dei documenti di partenza (linguaggi basati su XML), la soluzione
migliore è parsa quella di utilizzare un foglio di stile XSLT.
In [Man02] viene analizzato un metodo per convertire vari formati grafici in SVG.
L’idea base è la seguente: ogni applicazione ha una propria semantica per rappresentare le immagini, che differisce da quella di SVG. Quindi si suddividono i formati
grafici in domini applicativi (presentazioni, modellazione 3D, ecc.) e si analizzano le
caratteristiche di ciascun dominio. Si passa poi a tradurre ogni dominio in una struttura comune (un formato XML intermedio), da questa si passerà poi alla conversione
in SVG tramite XSLT.
Questo metodo appare valido per la conversione di molteplici formati in SVG. Tuttavia nello specifico (come il convertitore realizzato) appare migliore e più semplice
una trattazione ad hoc, gestita mediante una conversione diretta. Questo è dovuto al
fatto che utilizzando una metodologia generale non ci si può soffermare sulle particolarità di un dato linguaggio e quindi si perdono molte possibili ottimizzazioni. Per
esempio SVG e VML hanno varie caratteristiche rappresentate mediante la stessa sintassi, il che comporta una conversione diretta. Oltre a questo appare del tutto inutile
passare ad un formato intermedio quando si può andare direttamente al formato finale,
senza perdere alcun beneficio.
XSLT (eXtensible Stylesheet Language Transformations) è un linguaggio per trasformare documenti XML in altri documenti XML, la versione 1.0 è una Recommendation del W3C, datata 16 Novembre 1999 [Cla99].
Sostanzialmente le trasformazioni sono definite mediante regole o template che
indicano quale oggetto del documento sorgente dev’essere processato per produrre il
documento di output.
Questo linguaggio è apparso un ottimo strumento da utilizzare per le conversioni,
in quanto:
Capitolo 3. Descrizione ad alto livello: analyze this
45
• è dichiarativo ed è scritto anch’esso in sintassi XML;
• è un formata standard, gestibile da ogni sistema che supporta XML;
• è completamente compatibile con i formati XML, quindi SVG e VML;
• è compatibile con molti altri standard del W3C, come XPath, il quale permette
di effettuere complesse selezioni all’interno della struttura dei documenti;
• è relativamente semplice.
Tuttavia presenta alcune limitazioni che rendono più complesso il suo utilizzo:
• non permette di aggiornare le variabili e l’iterazione, quindi richiede la ricorsione, il che implica un incremento nella complessità;
• è difficile estrarre e gestire valori espressi in stringhe di testo.
Comunque, basandosi sui lavori di [FroHar02], [Asm03], [BGLS03] e [ManFul01],
che mostrano degli esempi concreti di utilizzo di questo linguaggio, e sulla propria
esperienza personale è stato deciso di utilizzare questo strumento di conversione.
3.1.2 Come funziona in pratica
Sono stati realizzati due fogli di stile, svg2vml.xsl e vml2svg.xsl, mediante i quali
vengono realizzate le conversioni.
Per poterli utilizzare devono essere inclusi nei documenti sorgente, mediante un’opportuna processing-instruction:
<?xml-stylesheet type="text/xsl" href="vml2svg.xsl"?>
Successivamente, mediante un’opportuna applicazione, quale xsltproc, si forza
l’applicazione del foglio di stile.
A livello di interfaccia grafica, per permettere un utilizzo pratico, nonché semplificato, dei convertitori, sono state create alcune pagine HTML. Attraverso questi
documenti, che sfruttano degli script PHP, si può inserire l’url di un’immagine SVG
(o VML) ed ottenere nella stessa schermata sia l’immagine di partenza, sia quella
convertita.
46
3.1.3 Metodologia delle conversioni
I due linguaggi (SVG e VML) hanno una struttura molto simile, cioè entrambi offrono,
per esempio, la possibilità di utilizzare elementi “contenitori” per dimensionare e posizionare vari oggetti grafici; oppure hanno attributi simili per esprimere i colori delle
figure. Tuttavia per alcuni aspetti, come si vedrà meglio in seguito, presentano una
struttura molto diversa.
Per convertire una componente grafica da un formato all’altro si è cercato innanzi
tutto di mantenere inalterata la struttura del primo documento, trasferendola nel secondo; se, per esempio, nel documento sorgente si ha un gruppo con all’interno due
elementi di figure, si cercherà di ottenere nell’altro documento un gruppo con due
elementi di figure. Tuttavia, non sempre è possibile realizzare una corrispondenza
cosı̀ netta: per ottenere la stessa figura, a livello di rendering, in molti casi bisogna
cambiare sostanzialmente o lievemente la struttura del documento. Quindi, si è dovuto
scegliere se mantenere una coerenza strutturale tra i due file o una coerenza visuale, e
naturalmente è stata scelta questa seconda opzione.
Un caso evidente di modifica della struttura del documento è rappresentato dalla
gestione dei testi. In SVG è possibile definire un elemento per rappresentare un testo,
al cui interno sono presenti altri elementi per posizionare in maniera diversa porzioni di
testo. VML non permette questa gestione dei testi, quindi, ogni singolo pezzo di testo
è stato inserito in un opportuno elemento textpath, perdendo la struttura e la linearità
del testo.
Un altro esempio è rappresentato dalle corrispondenze use–defs e shape–shapetype,
rispettivamente di SVG e VML, le quali non è stato possibile mantenere nei documenti
generati, come ampiamente descritto nelle successive sezioni.
Inoltre, i file convertiti sono stati ottimizzati per eventuali conversioni inverse. Per
esempio sono state tradotte e opportunamente inserite negli elementi le proprietà di
styling.
In pratica, per realizzare le traduzioni, si è cercato di ottenere una figura il più
possibile simile a quella di partenza, cercando di mantenere inalterata la struttura del
documento e si è cercato di ottimizzare i documenti per semplificare eventuali conver-
sioni inverse.
Riassumendo, quindi, la priorità delle proprietà delle conversioni è la seguente:
1. coerenza visuale;
2. coerenza strutturale;
3. ottimizzazione per conversioni inverse.
47
48
3.1.4 Da SVG a VML
In questa sezione verrà presentata la prima conversione, spiegandone brevemente il
funzionamento, mostrando alcuni esempi che rappresentano gli aspetti più “problematici” ed elencando le principali limitazioni di questo traduttore. Ricordiamo che questa
conversione è stata realizzata mediante un foglio di stile XSLT (svg2vml.xsl).
C ONVERSIONE
DI BASE
Un documento SVG è rappresentato nella seguente forma: c’è un elemento svg che
racchiude tutti gli oggetti grafici e che imposta le dimensioni dell’immagine ed un sistema di coordinate usato per posizionare le figure. Da questo viene creato un documento HTML, al cui interno sono presenti gli elementi di VML, racchiusi in un elemento
group che funge da contenitore e che imposta le dimensioni e le coordinate.
Nella traduzione si scorre tutto l’albero del documento sorgente e per ogni elemento si procede ad un’opportuna traduzione. SVG e VML hanno molti attributi che
rappresentano le stesse caratteristiche (gestione di colori, dimensione di font, ecc.)
che tuttavia hanno un diverso valore di default; quindi per ogni elemento di SVG, se
presenta queste proprietà, si procede alla conversione (cioè al cambiamento di nome
dell’attributo), altrimenti si inseriscono ugualmente nell’elemento VML, ma con il
valore di default usato da SVG; il documento risultante presenterà quindi molti più
attributi di quello di partenza, dovuti al fatto del diverso uso dei valori di default.
Un altro aspetto riguarda gli elementi di SVG che non richiedono determinate proprietà, in quanto le ereditano, mentre in VML bisogna impostarle (è il caso per esempio dei gruppi). Per gestire queste situazioni, bisogna scorrere l’albero del documento
dall’elemento corrente, all’indietro, cercando le opportune proprietà negli elementi
precedenti.
P UNTI “ SOTTILI ”
La maggior parte degli elementi e degli attributi di SVG presentano una corrispondenza
abbastanza lineare con elementi di VML; in questi casi la conversione si è basata su
49
una semplice traduzione di nomi più opportuni aggiustamenti. Altri aspetti, riportati
di seguito, hanno richiesto una gestione più complessa:
dimensioni: SVG e VML trattano i valori delle dimensioni in modo diverso. Tutti i
valori possono essere espressi con unità di misura oppure senza, in quest’ultimo
vengono considerati in pixel. In SVG, tranne i valori del primo elemento svg,
che servono per dimensionare la figura e specificare il sistema di coordinate (con
l’attributo viewBox), tutti i valori vengono processati nel seguente modo:
1. vengono convertiti dal valore con unità di misura al valore senza. Ad
esempio: 10cm viene convertito in 354 (che rappresenta il valore in pixel).
2. il valore ottenuto viene rappresentato in proporzione al sistema di coordinate utilizzato.
3. se all’interno di un elemento contenitore che definisce un sistema di coordinate, è presente un altro elemento con tali caratteristiche, gli elementi
successivi saranno influenzati da entrambi gli elementi.
VML differisce da SVG per due questioni:
1. i valori espressi con l’unità di misura, vengono convertiti con un’altra
proporzione.
2. alcuni attributi (stroke-width, font-size) non vengono influenzati dal sistema di coordinate.
Per queste ragioni, durante la traduzione bisogna forzare una conversione dei
valori e per alcuni attributi bisogna calcolare il valore scalato in base ai vari
sistemi di coordinate definiti.
gestione style: in SVG molte proprietà possono essere definite tramite l’attributo o
l’elemento style, con opportuni selettori (vedi [BWLJ98]). Anche VML ammette la gestione di style, tuttavia i nomi delle proprietà differiscono tra i due
linguaggi. Le proprietà definibili in style, sono principalmente quelle riguardanti
50
i testi (font-size, ecc.) e riguardanti i colori (fill, stroke, ecc.). Queste caratteristiche vengono gestite ad hoc in quanto VML non ammette ereditarietà: per ogni
elemento vengono cercate le varie proprietà nel seguente ordine:
1. viene cercato il corrispondente attributo all’interno dell’elemento stesso;
2. si controlla il contenuto di un eventuale attributo style;
3. in base ai valori degli attributi id e class, oppure basandosi sul nome dell’elemento, si cercano le proprietà all’interno di elementi style, controllandone i selettori;
4. per le proprietà mancanti si ripetono i primi tre passi per gli elementi ancestor, finché non si trovano tutte le caratteristiche o non si giunga alla radice
del documento. In quest’ultimo caso le proprietà si impostano con i valori
di default.
Di seguito viene mostrato un esempio, semplificato, su come vengono gestite le
varie proprietà:
SVG:
<style type="text/css">
<![CDATA[
rect {stroke: blue; stroke-width: 3;}
.classe {fill:red; fill-opacity: 1;}
]]>
</style>
<g fill-opacity="0.5" stroke-opacity="0.3"
stroke-width="5" fill="blue">
<rect class="classe"
x="300" y="100" width="400" height="200"
style="fill-opacity: 0.7;"
stroke="black" />
</g>
51
VML:
<v:group ...>
<v:rect style="left:300; top:100;
width:400; height:200;"
class="classe">
<v:stroke color="black" opacity="0.3" width="3" />
<v:fill color="red" opacity="0.7" />
</v:rect>
</v:group>
path: entrambi i linguaggi hanno un elemento per definire i path. Questi sono espressi
nella forma:
comando valori
in cui comando rappresenta il tipo di percorso (linea retta, curva, arco, ecc.) e
valori rappresentano i punti o i parametri per disegnare la linea. Sfortunatamente
i due formati utilizzano una sintassi diversa (diverso nome del comando o diversa
gestione dei valori) e dal momento che sono memorizzati in un attributo, cioè in
una stringa di testo, la loro estrazione e traduzione risulta piuttosto difficile e non
sempre realizzabile. Comunque sono stati tradotti il maggior numero possibile
di path, mentre i restanti sono stati approssimati. Ad esempio, il seguente path:
M 0,0 L 100,200 C 100,100 250,100 250,200
S 400,300 400,200
tramite M viene effettuato uno spostamento al punto (0,0), con L viene tracciata
una linea, con C, una curva di Bézier, con S, viene tracciata una seconda curva
basandosi sui valori della prima curva. I primi tre comandi hanno una corrispondenza in VML, S no. Per tradurre quest’ultimo comando si dovrebbero prendere
il terzultimo e quartultimo valore della curva precedente (se è presente una curva precedente); vista la complessità di queste estrazioni, oltre al fatto che non si
può sapere a priori se il comando S segue il comando C, la gestione viene approssimata, prendendo gli ultimi due valori del comando precedente. Il risultato
della traduzione è il seguente:
52
m 100 200 C 100,100 250,100 250,200
C 250 200 400,300 400,200 e
Graficamente il risultato è il seguente (figura 3.1):
Figura 3.1: path
testi: in SVG è presente un elemento (text) per definire i testi, al suo interno può
contentere altri elementi (tspan, tref, textPath) per rappresentare e posizionare in
modo diverso porzioni di testo. Ad esempio:
<text x="200" y="150" fill="blue" >
You are
<tspan dy="-20" fill="red">not</tspan>
a banana.
</text>
il risultato è espresso dalla figura 3.2.
Figura 3.2: text con tspan
53
In VML i testi si possono esprimere in due modi: o lungo un path, oppure testi
semplici in sintassi HTML. Quindi per effettuare una traduzione corretta, la
soluzione adottata prevede di suddividere il testo in tante parti (ogni porzione
di text prima e dopo un elemento ed il testo degli altri elementi) e creare un
path per rappresentare ognuna di esse. Per tradurre l’esempio precedente, l’applicazione crea tre path, due per rappresentare il testo prima e dopo l’elemento
tspan e un altro per rappresentare il testo di tspan.
trasformazioni: in SVG è presente un attributo che permette di effettuare trasformazioni quali traslazioni, rotazioni o cambiamenti di scala. In VML non è presente una tale caratteristica. Per realizzare la conversione, in presenza di ogni
attributo di trasformazione, viene creato un elemento contenitore (un gruppo)
per impostare la trasformazione.
Ad esempio, per scalare (dimezzare) un rettangolo, si crea un gruppo, impostando le coordinate col doppio di quelle definite, in modo che la figura inserita
all’interno risulti dimezzata, pur esprimendo le stesse dimensioni. Di seguito
riportiamo un frammento SVG e la corrispondente traduzione VML.
SVG:
<svg width="14cm" height="14cm" viewBox="0 0 2400 2400">
<rect transform="scale(0.5)"
x="300" y="100" width="400" height="200"
stroke="black" fill="green" />
</svg>
VML:
<v:group style="left:0; top:0; width:14cm; height:14cm;"
coordorigin="0 0" coordsize="2400 2400">
<v:group style="left:0; top:0; width:2400; height:400"
coordorigin="0 0" coordsize="4800 4800">
width:400; height:200;">
54
<v:stroke on="true" color="black" />
<v:fill on="true" color="black"/>
</v:rect>
</v:group>
</v:group>
use – defs: SVG presenta un elemento contenitore (defs) per definire elementi da richiamare in seguito nel documento, richiamati tramite l’elemento use. Il codice
seguente mostra come possano essere usati questi due elementi per definire, ad
esempio, due rettangoli con dimensioni uguali ma colori diversi:
<defs>
<rect id="MyRect" width="100" height="50" />
</defs>
...
<use x="20" y="10"
xlink:href="#MyRect"
fill="green" />
<use x="20" y="100"
xlink:href="#MyRect"
fill="red" />
In VML è presente un elemento analogo (shapetype), richiamato dall’elemento
shape, tuttavia non supporta tutti gli elementi. Per esempio in shapetype non
si può definire un rettangolo, o qualsiasi altra figura predefinita. Quindi, per la
gestione, si ignorano gli elementi defs e, ad ogni use, si va a prelevare l’elemento riferito. Questo comporta una ridondanza di codice, ma pare essere l’unica
soluzione possibile.
Per una maggiore descrizione su questa traduzione si rimanda alla sezione 4.1.
55
E SEMPI
Sono presentati due esempi che mostrano sia le potenzialità, sia alcuni limiti del convertitore.
Il primo esempio (figura 3.3 e conversione in figura 3.4) mostra trasformazioni
(rotazione dei rettangoli e ridimensionamento delle stelle), gestione dei gradienti, sfumature (gestite tramite opacità), testi inseriti in path e testi con spostamenti.
Nel secondo esempio (figura 3.5 e conversione in figura 3.6) sono mostrate alcune
figura di base (nella griglia), dei testi con rotazioni, inseriti in path e testi con una
diversa gestione di colori e dimensioni (utilizzando tspan). Inoltre sono mostrati numerosi path, in cui si possono vedere alcune differenze di rappresentazione, dovute ad
approssimazioni.
56
Figura 3.3: Esempio SVG 1
Figura 3.4: Conversione in VML della figura 3.3
Figura 3.5: Esempio SVG 2
Figura 3.6: Conversione in VML della figura 3.5
57
58
P ROBLEMI
E LIMITI
In questa sezione sono riportati i principali problemi di questa traduzione, suddivisi in
tre categorie.
Inizilmente verranno elencate le caratteristiche tradotte mediante approssimazioni;
successivamente si descriveranno le caratteristiche non tradotte per mancanza di una
corrispondenza nell’altro linguaggio.
Infine vengono presentate le principali caratteristiche che non sono state tradotte
per scelta, indipendentemente dal fatto che fossero traducibili o meno. Per realizzare
questo primo convertitore si è dovuto limitare il campo d’azione dei linguaggi, vista la
vastissima gamma di opzioni: è stato deciso di convertire le principali caratteristiche.
Per un elenco più dettagliato si rimanda alle sezioni 4.1.5 e 4.1.6.
I due linguaggi sono molti simili riguardo alla rappresentazione di alcuni oggetti grafici; tuttavia, in alcuni casi, utilizzano una sintassi molto diversa, rendendo la
traduzione non sempre possibile. In questi casi sono state ottenute delle approssimazioni. Di seguito sono mostrati alcuni elementi tradotti parzialmente:
path: come visto in precedenza alcuni tipi di path non vengono tradotti correttamente
(per problemi di gestione della stringa in cui è contenuto il path), quindi vengono
rappresentati con un’approssimazione. Si rimanda alle figure 3.5 e 3.6 per un
esempio.
testi: nella gestione dei testi sono presenti le maggiori differenze tra i due formati,
rendendo molto complessa la traduzione; questo comporta una rappresentazione
in parte approssimata. Inoltre sono presenti in entrambi i linguaggi alcune proprietà, che pur rappresentando la stessa funzione, vengono gestite in maniera
diversa. Di seguito sono elencati i principali aspetti dei testi gestiti con approssimazioni:
• rappresentando ogni porzione di testo tramite un path si possono presentare
problemi di posizionamento. Questo è dovuto al fatto che per stabilire la
posizione di ogni testo bisogna calcolare il numero di caratteri dei testi
59
precedenti e la dimensione del font; visto che i caratteri non occupano tutti
lo stesso spazio, risulta di conseguenza un posizionamento approssimato.
• i testi nei path in SVG vengono allineati a sinistra, mentre in VML vengono
allineati al centro del path.
• in SVG, quando si rappresenta un testo in un path, se il testo è più lungo,
viene troncato; in VML esce dal path e viene visualizzato completamente.
Come ricordato in precedenza, quella realizzata è una prima versione del convertitore, per cui non tutte le caratteristiche dei formati sono state considerate; di seguito
sono riportate le principali:
animazioni: non hanno un supporto diretto in VML, per ottenerle si deve integrare il
codice VML con un linguaggio di scripting;
testi: non sono supportate la gestione dell’orientazione del testo e i valori multipli
degli attributi x e y (che permettono di posizionare l’i-esimo carattere nella
specifica coordinata);
filtri: SVG permette una gestione molto approfondita, mentre VML ne ammette solo
un sottoinsieme.
SVG è un linguaggio più completo di VML, in quanto permette di definire varie
caratteristiche non ottenibili nell’altro formato; le principali sono le seguenti:
clipping: in SVG è possibile specificare se far vedere o meno le porzioni di immagine che “escono” dal contenitore (per default non vengono visualizzate). In
VML questa caratteristica non è supportata, in quanto le figure vengono sempre
mostrate nella loro interezza.
attributo preserveAspectRatio: tramite questo attributo è possibile far mantenere le
proporzioni alle figure indipendentemente dal sistema di coordinate definito, oppure specificare come debbano essere scalate. In VML una tale caratteristica non
è definibile.
60
trasformazioni: SVG permette di definire alcuni tipi di trasformazioni non supportate
da VML, quali matrix (specifica la matrice di trasformazione da applicare ai vari
attributi), skewX e skewY (usati per inclinare le immagini, in orizzontale o in
verticale).
61
3.1.5 Da VML a SVG
In questa sezione verrà illustrata la conversione da VML a SVG, spiegandone brevemente il funzionamento e soffermandosi sulle diversità rispetto all’inversa. Verranno
descritti alcuni punti sottili, riguardo la traduzione di varie caratteristiche; si mostreranno un paio di esempi, per illustrare la potenzialità ed alcune limitazioni del traduttore e verranno descritte le caratteristiche non tradotte perfettamente (dal punto di vista
visivo).
C ONVERSIONE
DI BASE
In VML gli oggetti grafici rappresentati non necessitano di essere definiti all’interno
di un elemento contenitore; tuttavia, tramite l’elemento group è possibile raggruppare vari elementi, definire un opportuno dimensionamento e definire un sistema di
coordinare che influenzi tutti gli oggetti contenuti.
Il linguaggio SVG richiede un elemento contenitore principale, quindi per la traduzione si crea quest’elemento, dimensionato come lo schermo (100%) e senza sistema
di coordinate. Va ricordato che in VML non è possibile specificare la dimensione
dell’immagine, al di fuori della quale eventuali elementi non saranno rappresentati:
questa occuperà, al minimo, tutto lo schermo; eventualmente è possibile far aumentare
la dimensione, specificando oggetti di dimensione maggiore della risoluzione dello
schermo.
Un altro aspetto da considerare è l’attributo style. In VML style ha un ruolo fondamentale poiché contiene tutte le proprietà di posizionamento e dimensionamento. In
SVG le stesse proprietà sono definite tramite un opportuno attributo; quindi per realizzare la conversioni, si devono estrarre tutte le proprietà contenute in style e inserirle
nei corrispondenti attributi.
P UNTI “ SOTTILI ”
In questa sezione vengono presentate le principali caratteristiche di VML che richiedono una traduzione non immediata in SVG, cioè richiedono una gestione particolare
e a volte complessa. In particolare:
62
elementi shape e shapetype: in VML, tramite shapetype, si può definire una figura
da richiamare successivamente nel documento. Tramite shape, si può definire
una figura nuova o riferirsi ad una definita con shapetype; in quest’ultimo caso
verranno ereditati tutti i parametri non specificati.
SVG ha un comportamento opposto rispetto a VML: presenta anch’esso una
carripondenza analoga, ottenuta mediante gli elementi defs e use; in questo
caso però tutte le proprietà definite in use vengono sovrascritte dall’elemento
richiamato. Per questo motivo si gestiscono i riferimenti shape – shapetype onthe-fly: per ogni elemento shape si cercano eventuali elementi riferiti e da questi
si estraggono solo le proprietà che non sono già state definite.
Nell’esempio che segue, viene mostrato questo riferimento; in questo caso viene
creato il path con id path-shape, con riempimento verde e bordi rossi:
<v:shapetype id="s1" strokecolor="red" fillcolor="blue">
<v:path
id="path-shape"
v="m 40,40 L 40,530 530,530 x e"
/>
</v:shapetype>
<v:shape type="#s1" style="width:500; height:500;">
<v:path id="path-shape"
v="m 240,240 L 530,40 530,530 x e"
/>
<v:fill on="true" color="green" />
</v:shape>
fill e stroke: per definire le proprietà di painting VML mette a disposizione degli
attributi (fillcolor, strokecolor, ecc.) e degli elementi (fill, stroke), in cui le
proprietà definite negli elementi hanno priorità. SVG ha a disposizione solo
attributi.
Per effettuare la conversione, per ogni elemento, si cercano eventuali elementi
figli fill e stroke e si impostano le proprietà definite; successivamente si cercano
le proprietà negli attributi dell’elemento, gestendo solo quelle che non sono già
state impostate. Di seguito viene mostrato un esempio di gestione di queste
proprietà:
63
VML:
width:400; height:200;"
fillcolor="green"
strokecolor="red"
opacity="0.3">
<v:stroke color="black" weight="10" />
<v:fill color="black" opacity="0.5" />
</v:rect>
SVG:
<rect x="300" y="100"
width="400" height="200"
stroke="black"
stroke-width="10"
stroke-opacity="0.3"
fill="black"
fill-opacity="0.5">
</rect>
Va sottolineato inoltre che in VML le proprietà di painting non vengono mai
ereditate (tranne nella gestione di shape e shapetype).
testi: i testi in VML possono esssere di due tipi: testi inseriti in un path o testi in
formato HTML (elemento textbox). Nel primo caso la traduzione non presenta problemi; nel secondo ogni tag HTML è trasformato in un elemento tspan,
mantenendo la formattazione del testo.
Di seguito viene mostrato un esempio di un testo definito tramite textbox e di
come viene convertito in SVG:
64
VML:
<v:textbox>
<div style="color:green; font-family:Times;
font-size:25;">Parole
<i>in italic</i> <b>in bold</b>
<i style="color:blue;"> ed in blu</i>
</div>
</v:textbox>
SVG:
<text>
<tspan font-size="25" font-family="Times"
fill="green">Parole
<tspan font-style="italic">in italic</tspan>
<tspan font-weight="bold">in bold</tspan>
<tspan fill="blue"
font-style="italic">ed in blu</tspan>
</tspan>
</text>
gestione “defs”: in SVG alcuni elementi (ad esempio i gradienti, oppure i path usati
per rappresentare i testi), vanno definiti all’inizio del documento, in un elemento
defs, per poi essere richiamati opportunamente. VML definisce le stesse caratteristiche direttamente nell’elemento opprotuno (tramite attributi). Per gestire
queste situazioni, la prima operazione, dopo aver creato l’elemento svg contenitore, è la ricerca di tutti i path e tutti i gradienti presenti nel documento VML;
ognuno di questi elementi è inserito in un elemento defs, in modo da consentirne
una gestione corretta.
65
E SEMPI
A seguire vengono mostrati due esempi riguardanti la conversione, in cui si può notare
la potenza del convertitore ed alcuni limiti.
Il primo esempio (figura 3.7 e conversione in figura 3.8) mostra molti aspetti di
VML: le curve (in alto a sinistra) tradotte tramite path, gli archi (in alto a destra) anch’essi tradotti con path ed in parte approssimati. Vengono mostrate figure ruotate
(rettangoli arrotondati e path) e sfumate (mediante la definizione della proprietà di
opacità); inoltre sono presenti dei testi, sia in sintassi HTML (curve), sia inseriti in
path, in cui appare evidente una differenza da rappresentazione tra i due linguaggi:
VML inserisce il testo nel path, SVG sopra il path.
Nel secondo esempio (figura 3.9 e conversione in figura 3.10), sono state gestite
molte figure tramite l’utilizzo degli elementi shapetype (stelle e fulmini), richiamati
con shape, cambiandogli di dimensione. Sono stati utlizzati numerosi path (casa,
alieno e nuvole). Inoltre sono presenti testi nei path e testo definito tramite textbox
(help!), in cui si può notare una differenza di gestione tra i due linguaggi. Altri aspetti
mostrati sono l’utilizzo di linee tratteggiate e l’uso del gradiente (colore delle nuvole).
66
Figura 3.7: Esempio VML 1
Figura 3.8: Conversione in SVG della figura 3.7
Figura 3.9: Esempio VML 2
Figura 3.10: Conversione in SVG della figura 3.9
67
68
P ROBLEMI
E LIMITI
La conversione tra VML e SVG non è risultata completa ed esaustiva, in quanto: alcune caratteristiche non sono state tradotte, altre non sono state tradotte correttamente
ma solo approssimate ed altre ancora appaiono intraducibili. Di seguito vengono presentati i principali aspetti che rientrano in queste categorie.
Alcune caratteristiche di VML presentano una gestione diversa rispetto alle corrispondenti caratteristiche di SVG, in questi casi è stata ottenuta una rappresentazione
approssimata:
archi: VML presenta, a differenza di SVG, un elemento specifico per rappresentare
gli archi. La traduzione viene effettuata tramite path, ma per ragioni di complessità della traduzione, gli archi vengono approssimati con quarti di ellisse, cioè
un arco che va da 10 a 140 gradi verrà rappresentato da 0 a 180 gradi;
path: come specificato nella sezione precedente (3.1.4), SVG e VML hanno un modo
diverso di rappresentare alcuni path, rendendo la traduzione molto complessa.
In questi casi si è optato per rappresentarli con approssimazioni;
dimensioni: alcune dimensioni (bordi e testi) non vengono influenzate dal sistema di
coordinate definito. In SVG, anche modificandone i valori, non si riesce a non
far modificare la loro rappresentazione: testi e bordi vengono sempre deformati
(schiacciati o allargati) in base ai valori di dimensionamento specificati.
Come specificato nella sezione precedente, non sono state tradotte tutte le caratteristiche dei due linguaggi (vista la vastità dei loro domini), tra di esse vanno ricordate
le seguenti:
shadow: usato per rappresentare ombreggiature;
testi: in textbox sono rappresentati i testi con sintassi HTML. Sono stati gestiti solo
alcuni tag (quelli principalmente inerenti alla rappresentazione dei testi).
Un esiguo numero di caratteristiche di VML non hanno una controparte nell’altro
formato, di seguito sono mostrate quelle principali:
69
elemento formulas: usato per definire delle formule matematiche, calcolate sulla base
del valore di opportuni attributi o basandosi sul valore di altre formule;
z-index: usato per specificare l’ordine di visualizzazione delle figure.
Per maggiori dettagli si rimanda alle sezioni 4.2.6 e 4.2.7.
70
3.2 Conversione da SVG e VML a GIF
In questa sezione vengono presentate sia la conversione da SVG a GIF, sia quella
da VML a GIF, in quanto si basano sugli stessi principi. Verrà brevemente descritto il metodo mediante il quale sono state realizzate (utilizzo di funzioni grafiche in
script PHP), successivamente si passerà ad analizzare alcune caratteristiche che hanno
richiesto una trattazione non banale. Infine verranno mostrati alcuni esempi e saranno
elencati i principali problemi di questi convertitori.
3.2.1 Realizzazione
Le conversioni sono state implementate mediante l’utilizzo di due script PHP, utilizzando un’opportuna libreria grafica, contenente funzioni di gestione di immagini.
Tramite queste funzioni è possibile creare un’immagine GIF, specificandone le dimensioni, inizialmente vuota (bianca) e in seguito inserirci oggetti grafici (figure, testi
o altre immagini raster). La parte più complessa riguarda la gestione della dimensione degli oggetti, in quanto vengono influenzati da tutti gli elementi contenitori (svg,
group, ecc.) precedenti. Quindi per ogni dimensione (di una dato elemento) è stato
necessario calcolare i valori di dimensionamento di tutti gli elementi precedenti.
A differenza delle altre conversioni, in cui si riusciva, con semplicità, a gestire la
struttura (l’albero) del documento e si avevano problemi nella gestione di stringhe, in
questa si gestiscono “semplicemente” molti aspetti complessi, ma si perde la struttura
del documento. Come vedremo in dettaglio nel seguito non è banale da un elemento
riferirsi agli elementi precedenti (per gestire, ad esempio, l’ereditarietà).
Passando agli aspetti pratici, sono stati realizzati, come accennato in precedenza,
due script (svg2gif.php e vml2gif.php), ai quali viene passato come argomento l’url di
un file e restituiscono l’immagine GIF.
3.2.2 Metodo di gestione dei documenti
Per realizzare questo convertitore è stato implementato un parser, il quale scandisce
tutto il documento e riconosce ogni elemento mediante l’apertura e la chiusura di
71
tag. Per ogni oggetto viene tenuta traccia del livello di annidamento e dei parametri
contenuti (rappresentati dai vari attributi o sottoelementi). Risulta molto importante
sapere la posizione in cui si trova un oggetto all’interno della struttura del documento
perché, in questo modo, è possibile posizionarlo correttamente basandosi sugli attributi
di dimensionamento degli elementi precedenti.
Quando si riconosce la fine di un elemento grafico (tag chiuso) si procede alla
sua inclusione nell’immagine GIF. Ogni elemento richiede tre tipi di informazioni per
poter essere rappresentato: colori (per i bordi e per il riempimento), dimensioni e
posizionamento.
Le informazioni sui colori possono essere contenute nell’elemento stesso oppure
vengono ereditate dagli elementi precedenti. Come accennato in precedenza, viene
tenuta traccia di ogni elemento e dei rispettivi attributi; in questo modo è sempre
possibile recuperare informazioni sugli elementi precedenti.
Per effettuare posizionamenti e dimensionamenti, oltre a utilizzare gli attributi dell’elemento considerato, vengono considerati gli opportuni attributi di tutti gli elementi
precedenti, in quanto ogni figura viene influenzata da ogni elemento che la contiene.
Il motivo per cui è stato deciso di utilizzare un parser per gestire i documenti (SVG
e VML) è la propria esperienza nella creazione ed implementazione di parser.
3.2.3 Punti “sottili”
In questa sezione sono elencati gli aspetti della conversione che hanno richiesto una
particolare attenzione.
attributi di painting: per quanto riguarda la gestione di questi attributi (fill, stroke,
ecc.), la conversione da SVG non presenta problemi, in quanto o sono specificati
nell’elemento che viene gestito, oppure vengono ereditati dagli elementi precedenti. VML invece permette di specificare queste proprietà sia tramite attributi,
sia tramite elementi; quindi, quando si gestisce un oggetto, prima si cercano gli
attributi, tenendone traccia, poi, continuando a scorrere il documento, si controlla l’eventuale presenza degli elementi, ed eventualmente si sovrascrivono i valori
72
precedenti. Infine, giunti alla fine dell’oggetto si procede all’effettiva inclusione
nell’immagine GIF.
bordi: nelle funzioni per la gestione delle immagini di PHP, non è possibile specificare la dimensione delle figure, quindi bisogna in qualche modo cercare di
forzarla. Per fare questo, per ogni figura (rettangolo, ellisse o altro), dopo aver
recuperato le informazioni sulla dimensione del bordo, si procede alla creazione
di tante figure sovrapposte, di dimensioni via via crescenti, in modo da simulare
la presenza dello spessore del bordo.
dimensioni: ogni elemento che rappresenta una figura avrà degli attributi per specificarne le dimensioni. Queste dimensioni per essere rappresentate nell’immagine
GIF devono essere scalate in base alle dimensioni degli elementi contenitori ed
ai sistemi di coordinate definiti. Questa conversione è realizzata tramite due pile:
una che memorizza le dimensioni e l’altra il numero di coordinate contenute in
ogni elemento.
Per ogni oggetto si scorrono le due pile, moltiplicando tra loro tutti i rapporti tra
dimensione e scala e gestendo gli opportuni livelli in cui si trovano.
gestione use–defs (SVG): in SVG tramite l’elemento defs si definiscono elementi da
richiamare successivamente. Tramite l’elemento use si richiamano tali elementi.
La gestione di questa connessione avviene nel modo seguente: ogni volta che si
incontra un elemento defs, il suo contenuto viene memorizzato in una struttura e
non viene gestito. Ogni use viene considerato come se fosse un elemento di raggruppamento, quindi si impostano i valori di dimensionamento e posizionamento e si passa a cercare l’elemento riferito all’interno della struttura che mantiene
il contenuto di defs. Quando si trova, viene gestito come se fosse contenuto nel
livello corrente, cioè come se fosse contenuto all’interno di use.
gestione shape–shapetype (VML): in VML shapetype definisce una figura da richiamare successivamente nel documento, shape la richiama ridefinendone eventualmente delle caratteristiche.
73
La gestione è simile a quella precedente (il contenuto di shapetype viene mantenuto in una struttura e gestito ad ogni riferimento). Tuttavia shape e shapetype
possono definire gli stessi attributi e si deve dare priorità a quelli di shape. Nella
loro gestione, ad ogni shape si memorizzano tutte le caratteristiche in una struttura, specificando se si tratta di valori effettivamente definiti o valori di default.
Giunti alla fine di quest’elemento, si controlla l’eventuale elemento shapetype
riferito, sovrascrivendo quelle proprietà che erano state impostate coi valori di
default.
testi (SVG): i testi in SVG sono contenuti nell’elemento text, il quale a sua volta
può contenere elementi per definire porzioni di testo formattate e posizionate in
maniera diversa.
Per la gestione si utilizza una struttura, in cui vengono memorizzate tutte le
porzioni di testo (contenuto di text prima e dopo gli elementi interni e testo
degli altri elementi), tenendo traccia del loro posizionamento relativo e delle
informazioni sulla rappresentazione (font, colori, ecc.).
Il testo viene effettivamente inserito nell’immagine GIF quando si giunge alla fine dell’elemento text. La gestione è la seguente: ogni porzione di testo
viene posizionata basandosi sulla lunghezza dei testi precedenti (e su eventuali
posizionamenti relativi) e rappresentata mediante gli opportuni colori e font.
Alcune considerazioni aggiuntive:
• elemento tref : quest’elemento permette di richiamare dei testi definiti in
defs. Questa situazione viene trattata come nel caso della gestione di use:
si cerca il testo in defs e lo si considera inserito al posto di tref.
• elemento textPath: nella conversione in GIF non vengono inseriti i testi nei
path, in quanto la gestione sarebbe molto complessa; ci si limita a scriverli
orizzontalmente partendo dal punto iniziale del path.
testi (VML): in VML i testi sono di due tipi:
74
• testi inseriti in path: come nel caso di testi SVG, vengono visualizzati in
orizzontale a partire dal punto di inizio path.
• testi in formato HTML: gestiti come i testi di SVG. Tramite una struttura
si memorizzano le informazioni associate ad ogni porzione di testo (testi
compresi tra due tag) e in fase di visualizzazione si posizionano i testi
considerando la lunghezza dei testi già considerati.
3.2.4 Esempi
In questa sottosezione sono mostrati due esempi di conversione in GIF, che mostrano
tutti gli aspetti visti in precedenza. Il primo realizzato partendo da un file SVG, il secondo con un documento VML.
Il primo esempio (figura 3.11 e conversione in figura 3.12), mostra una conversione
da SVG a GIF. Molti elementi sono tradotti correttamente, i path, le figure predefinite
(ellissi, rettangoli), la gestione delle variazioni di scala (stelle), ottenute mediante vari
elementi use riferiti alla stessa stella, applicandogli delle trasformazioni. I testi (sia
semplici, sia complessi, cioè definiti con l’utilizzo di tspan) sono tradotti correttamente. Infine sono presenti alcune caratteristiche che non trovano una corrispondenza
come l’opacità e le rotazioni.
Il secondo esempio (figura 3.13 e conversione in figura 3.14), mostra una conversione da VML a GIF. Sono presenti numerose caratteristiche tradotte correttamente,
i vari path (gatto e nuvole), gli archi e le curve. È supportata la gestione di shape e
shapetype (è presente una definizione della stella e del fulmine, richiamata più volte).
Inoltre sono mostrate alcune caratteristiche non supportate: i gradienti (nuvole), i testi
nei path (approssimati, inserendo il testo nel punto iniziale dei path) e appare evidente
l’approssimazione dei bordi.
Figura 3.11: Esempio SVG
Figura 3.12: Conversione in GIF della figura 3.11
75
76
Figura 3.13: Esempio VML
Figura 3.14: Conversione in GIF della figura 3.13
77
3.2.5 Risultati e problemi
La traduzione in GIF non è da considerarsi completa; molte caratteristiche di SVG
e VML non sono state tradotte, alcune per mancanza di mezzi implementativi (cioè
mancanza di funzioni od opzioni nella libreria grafica di PHP), altre per scelta, altre
ancora sono state approssimate. Nel seguito sono esposte le principali caratteristiche
che non presentano una traduzione precisa in GIF.
Per ragioni di coerenze si è scelto di non tradurre le caratteristiche non supportate
dagli altri convertitori (tra SVG e VML).
Alcune caratteristiche sono state tradotte tramite approssimazioni; le principali
sono le seguenti:
bordi: i bordi sono approssimati mediante sovrapposizione di figure con perimento
sempre maggiore, in modo da simulare lo spessore. Non pare che questa rappresentazione differisca dall’immagine di partenza. Alcune caratteristiche dei
bordi, come l’arrotondamento e la dimensione dei punti di congiunzione non
sono supportate da PHP, quindi tutti i bordi sono rappresentati sempre in maniera
semplice (normali linee rette).
path: quasi tutti i path sono stati rappresentati correttamente, a differenza di alcuni
(archi), che richiedevano una gestione molto complessa, rappresentati mediante
linee rette.
Molte altre caratteristiche non sono state tradotte, in quanto non traducibili, o
perché mancavano le funzioni nella libreria grafica di PHP o perché troppo complesse per essere realizzate. Tra queste le opzioni maggiormente significative senza
traduzione sono le seguenti:
gradienti: non supportati da PHP, viene rappresentato un solo colore del gradiente;
opacità: non supportata da PHP, i colori con specifici attributi di opacità vengono
rappresentati con il colore naturale;
rotazioni: non supportate da PHP, gli elementi che presentano rotazioni, vengono
posizionati nella posizione specificata, senza applicare la rotazione;
78
testi inseriti nei path: la gestione sarebbe troppo complessa (calcolare la dimensione
di ogni testo, calcolare la lunghezza del path! e posizionare ogni carattere nel
testo in un punto equispaziato! del path). I testi nei path sono rappresentati in
orizzontale, posizionati nel punto iniziale del path.
Come visto finora, alcune caratteristiche non sono state tradotte per scelta, altre
per mancanza di mezzi. Comunque va ricordato che quella realizzata è una prima
versione del convertitore, per la quale sono state gestite le funzioni principali dei due
formati, lasciando aperta la strada per eventuali aggiornamenti futuri. A tal proposito
va segnalata la possibilità di estendere il convertitore permettendo la traduzione in altri
formati raster (JPEG e PNG), mediante il semplice cambiamento nomi di funzioni.
3.3 Conversione da GIF a SVG e VML
I formati grafici vettoriali permettono, come visto nell’introduzione, di includere un’immagine raster. Questa è stata la soluzione adottata per la conversione da GIF a SVG e
VML.
Si sarebbe potuto effettuare una traduzione effettiva, creando un documento (SVG
o VML) con un elemento (un rettangolo) per ogni pixel del GIF, come espresso nel
lavoro di [ByrLys04]. Questa soluzione, oltre a non essere elegante e permettere
un’“effettiva” manipolazione del disegno, non è funzionale, a detta degli stessi autori,
perché:
• il file prodotto risulta più grande di quello di partenza, di circa due volte e mezzo;
• il tempo per visualizzare il documento diventava molto elevato.
Capitolo 4
Descrizione a basso livello: into the
code
4.1 Da SVG a VML
In questa sezione vengono descritti i vari elementi e le varie caratteristiche di SVG
e il modo con cui sono state tradotte, ove possibile, in VML. Inizialmente vengono
presentati tutti gli elementi di SVG, descrivendone brevemente il significato e l’utilizzo, passando poi ad illustrare come sono stati convertiti. Successivamente vengono
descritte le altre caratteristiche basilari di SVG: la gestione dei testi, le trasformazioni
(traslazioni, rotazioni, ecc.) e gli attributi più importanti. Alla fine verranno presentate nel dettaglio tutte le caratteristiche non tradotte, suddividendole in due categorie:
quelle che non possono essere convertite in quanto non supportate dall’altro formato e
quelle non convertite per scelta.
Lo scopo di questo capitolo è quello di creare un vero e proprio manuale che permetta, leggendo la sezione di ogni elemento o di ogni proprietà, di capire come è stata
realizzata la traduzione.
79
80
4.1.1 Elementi
In questa sottosezione sono presentati tutti gli elementi di SVG, spiegando il loro
utilizzo e come è avvenuta la conversione in VML.
svg
Nei documenti SVG viene rinchiuso tutto in un elemento svg, quindi nella conversione
si vuole cercare di ottenere un elemento che contenga tutto il resto. In VML ci sono
tre elementi contenitori (group, shape e shapetype), dei quali quello più appropriato
è group; quindi tutto il contenuto del documento SVG verrà inserito (dopo opportune
conversioni) in un elemento group, il quale a sua volta è inserito in un documento
HTML, come unico tag all’interno di body.
La conversione tra i due elementi è pressoché immediata, gli attributi x, y, width
e height vengono tradotti nell’attributo style come valori di left, top, width e height.
L’attributo viewBox (contenente quattro valori) viene suddiviso negli attributi coordorigin e coordsize. Se viewBox non è presente bisogna comunque mettere gli attributi
coordorigin e coordsize, in questo caso vengono impostati coi valori di x, y, width,
height, tradotti in pixel, se non sono presenti, x e y corrispondono a 0 e width e height
a 100%.
Il problema si presenta nella traduzione dell’elemento preserveAspectRatio, che
serve per mantenere le proporzioni delle figure indipendentemente dal sistema di coordinate usato (definito tramite l’attributo viewBox). Cioè, se abbiamo, per esempio, un rettangolo di 400x400 e viewBox definisce le dimensioni con 400x200, senza
PreserveAspectRatio (o meglio, impostato a none) il rettangolo risulterà schiacciato; con PreserveAspectRatio il rettangolo risulterà un vero e proprio quadrato ma di
dimensione 200x200. VML non supporta operazioni di questo tipo.
Inoltre SVG dà la possibilità di fare clipping della figura, cioè tutto quello che
sta al di fuori della regione definita da viewBox non viene visualizzato (salvo diversa
specificazione, attributo overflow); in VML non c’è la possibilità di definire questa
opzione.
Capitolo 4. Descrizione a basso livello: into the code
81
Note: traduzione esaustiva tranne per l’attributo preserveAspectRatio (non traducibile) e la possibilità di fare clipping (anch’essa non traducibile).
g
Quest’elemento rappresenta un contenitore di figure. La traduzione in VML è abbastanza immediata: si usa l’elemento group, che svolge il medesimo ruolo, l’unica
differenza è che mentre g non ha attributi per definire dimensioni e posizioni, l’elemento group richiede (se non sono presenti non visualizza il contenuto!) attributi di
posizionamento e dimensionamento (attributo style con all’interno top, left, width e
height). Per fare questo si impostano i valori di left e top a 0, mentre width e height
si impostano con i valori di viewBox del primo (partendo dall’elemento corrente e
risalendo verso la radice) elemento ancestor che ha tale attributo.
Più complesso è il caso in cui è presente l’attributo transform (che serve per effettuare delle trasformazioni: shift, rotazioni, modifiche della scala, ecc.), tradotto
creando un gruppo per ogni operazione di trasformazione, contenente opportuni valori
di posizionamento, dimensionamento e di coordinate.
defs
Rappresenta un contenitore di elementi che non vengono direttamente visualizzati, ma
che sono richiamati in altre parti del documento (per esempio tramite l’elemento use).
La traduzione (l’unica possibile) consiste nell’ignorare del tutto questo elemento
e nel trattare il suo contenuto man mano che viene richiamato da altri elementi. Per
esempio, quando un elemento use chiama un elemento contenuto in defs, si gestisce
quest’ultimo elemento on-the-fly. Quindi se per esempio si hanno 10 elementi use
che richiamano lo stesso rettangolo, nel documento VML si avranno i 10 elementi use
ognuno dei quali conterrà un elemento rettangolo. Il problema in questa traduzione
viene dai valori ereditati. Se un elemento definito in defs non dichiara alcuni attributi,
di norma questi dovrebbero essere ereditati (dall’attributo chiamante), però usando
questa tecnica, gli elementi ancestor dell’attributo chiamato vengono considerati defs
e i suoi precedenti e non use. Sembra che non ci sia soluzione a questo problema perché
82
quando viene trovato use, si crea un elemento group con sottoelementi che definiscono
le varie proprietà (fill, stroke o altro), poi si cerca il corrispondente elemento riferito e
lo si inserisce all’interno del gruppo. Il problema viene dal fatto che quest’elemento
NON erediterà nessun attributo da group; questa è una caratteristica di VML e credo
non ci si possa fare niente.
In “teoria” un soluzione più semplice e ragionevole ci sarebbe. Si definisce il
contenuto di defs in vari elementi shapetype e quando viene trovato use si crea un
elemento shape che richiama un elemento shapetype. Il problema viene dal fatto che
in defs posso definire di tutto, per esempio un rettangolo (elemento rect), mentre in
shapetype non posso definire tutto ma solo path e testi e quindi questa traduzione non
è fattibile.
Note: non vengono ereditati gli attributi.
symbol
Più o meno svolge lo stesso ruolo di defs, la traduzione è quindi analoga.
use
Quest’elemento è usato per riferirsi ad altri elementi (definiti in defs oppure symbol,
ma potrebbe riferirsi anche a elementi svg).
La traduzione si svolge nel modo seguente (vedi defs): si crea un elemento group
con gli attributi di use (opportunamente tradotti) e si cerca in defs l’elemento con id
uguale all’attributo href. Se viene trovato si chiama il template che gestisce quell’elemento, che quindi verrà inserito all’interno di group. In questo caso non vengono
ereditati i valori da use o dagli elementi precedenti.
desc e title
Rappresentano una descrizione all’interno del documento, non vengono visualizzati,
servono solo per migliorare la leggibilità interna. Title viene tradotto nell’attributo
title. Desc viene trodotto come commento.
83
image
Inserisce un’immagine esterna in un rettangolo definito dai suoi attributi. Per la traduzione si crea un elemento image con l’attributo src uguale all’attributo href. Può
contenere l’attributo transform, che viene gestito inserendo l’elemento image in tanti
gruppi quanti sono gli elementi in transform, ognuno opportunamente gestito. Problemi invece riguardano la rappresentazione dell’attributo preserveAspectRatio, che non
appare traducibile.
style (elemento e attributo)
Quest’elemento, usato per definire proprietà di stile, crea grossi problemi, in quanto
definisce le proprietà usando i nomi degli attributi di SVG; quindi, se viene tradotto
in un elemento style con contenuto uguale, gli elementi di VML erediteranno degli
attributi che non saranno utilizzabili. Soltanto una minima parte di attributi ha lo stesso
nome sia per VML che per SVG.
Inoltre alcuni attributi usati da SVG in VML vengono definiti all’interno dell’ attributo style, il che crea ulteriori problemi perché, ereditando gli attributi con style,
questi verranno trattati come attributi separati e quindi VML non sarà in grado di
gestirli.
La soluzione adottata è stata la seguente:
• Per alcune proprietà (fill, stroke, font, ecc.) si cercano i valori prima all’interno
dell’elemento; se non sono presenti si cerca in un eventuale attributo style all’interno dell’elemento. Se non è presente si cerca negli elementi style (controllando
opportunamente i selettori, in base a class, id e al nome dell’elemento) se sono
presenti queste proprietà. In caso negativo vengono cercate ricorsivamente negli
elementi ancestor e se da nessuna parte vengono trovate si impostano coi valori di default. Questa soluzione risolve anche il problema dell’attributo style di
VML, in quanto le proprietà di font vengono cercate e inserite tutte all’interno
dell’attributo style.
• Le altre proprietà per il momento non vengono gestite (non essendo di fondamentale importanza), comunque è possibile effettuare una traduzione analoga.
84
path
Questo elemento crea una figura (disegnando le linee esterne), specificando il perimetro
punto per punto. Anche VML presenta un elemento path con la medesima funzione;
tuttavia la traduzione è molto problematica perché i due elementi hanno due modi in
parte diversi per rappresentare i vari tipi di linee (linee rette, curve, archi, ecc.).
Ogni istruzione è formata da una o più lettere, che rappresentano il tipo di operazione (ad esempio: m, move; a, arc), seguita da un certo insieme di punti (o parametri).
Tutte queste istruzioni sui collegamenti fra punti sono contenute in un attributo (d per
SVG, v per VML), alcune istruzioni sono identiche fra i due linguaggi (m: move,
l: line). Altre, oltre ad avere nomi diversi, trattano gli argomenti in modo diverso,
oppure richiedono un diverso numero di valori, il che rende difficile la traduzione,
non consentendo un semplice cambio di nome per i comandi. Inoltre certe istruzioni
elaborano i valori di punti precedenti (se presenti): quindi, per la traduzione bisogna
effettuare complesse operazioni di estrazione di valori all’interno dell’unica stringa,
rappresentata dal valore dell’attributo.
Più in dettaglio: i path sono definiti in questa forma: “nome-comando insieme-divalori”, per esempio “M 10 10 L 50 10” effettua uno spostamento nel punto 10,10 e
a partire da lı̀ disegna una linea fino al punto 50,10. SVG e VML definiscono molte
istruzioni in maniera simile (stesso nome per l’istruzione o simile, stesso numero di
argomenti), però ci sono alcune istruzioni (abbreviazioni di altre istruzioni) che mette
a disposizione SVG che non hanno una corrispondenza diretta in VML.
Per esempio entrambi i linguaggi hanno il comando c (curve) che richiede sei
parametri e serve per disegnare una curva. SVG ha anche il comando s (smooth curve),
anch’esso serve per disegnare una curva , ma richiede solo quattro punti, gli altri due
vengono presi dalla riflessione degli ultimi due punti della curva precedente (se è presente). In pratica serve per disegnare una seconda curva, risparmiandosi di scrivere
due valori. Per tradurlo in VML bisogna usare il comando c, però bisogna riuscire a
recuperare i due valori mancanti. Questo non è molto semplice perché si dovrebbero
andare a vedere i valori precedenti a c (il terzo e quarto valore di sei) che potrebbero
eventualmente non essere presenti se il comando precedente non è c.
85
La traduzione è stata effettuata per il maggior numero possibile di operazioni, alcune sono tradotte correttamente (effettuando vari aggiustamenti), altre invece vengono approssimate (in quanto troppo complesse per venire tradotte o non supportate).
La tabella 4.1 presenta la lista dei comandi di path di SVG e il modo in cui sono
stati tradotti in VML, specificando il nome del comando usato.
Comando
M
m
Z, z
L
l
H
h
V
v
C
c
S
s
Q
q
T
t
A
a
Descrizione
move to (assoluto)
move to (relativo)
close path
line to (assoluto)
line to (relativo)
horizontal line to (assoluto)
horizontal line to (relativo)
vertical line to (assoluto)
vertical line to (relativo)
curve to (assoluto)
curve to (relativo)
smooth curve to (assoluto)
smooth curve to (relativo)
quadratic Bézier curve to (assoluto)
quadratic Bézier curve to (relativo)
smooth quadratic Bézier curveto (assoluto)
smooth quadratic Bézier curveto (relativo)
elliptical arc (assoluto)
elliptical arc (relativo)
Traduzione
corretta (M)
corretta (t)
corretta (x)
corretta (L)
corretta (r)
corretta (L)
corretta (r)
corretta (L)
corretta (r)
corretta (C)
corretta (v)
approssimata (C)
approssimata (v)
approssimata (qb)
approssimata (r)
approssimata (L)
approssimata (r)
approssimata (L)
approssimata (r)
Tabella 4.1: Traduzione path da SVG a VML
Note: traduzione molto complessa (molte operazioni trattano gli argomenti in
maniera diversa e in un diverso numero, richiedendo complesse operazioni di estrazioni di sottostringhe.
figure predefinite: rect, circle, ellipse, line, polyline e polygon
La traduzione di queste figure è abbastanza semplice (tranne nel caso del rettangolo
con angoli arrotondati), in quanto per ogni elemento di SVG c’è un corrispondente
86
elemento di VML, tranne nel caso di polygon e circle, ma questi ultimi vengono
considerati un caso particolare di polyline e ellipse.
Un po’ diverso è il caso di rect. Ci sono due tipi di rettangoli, quello normale
(traduzione immediata) e quello con gli angoli arrotondati. Per quest’ultimo ci sarebbe
una traduzione naturale nell’elemento di VML roundrect, però questo non gestisce la
parte arrotondata nello stesso modo del rect di SVG (roundrect ha un solo attributo che
definisce la percentuale della dimensione del rettangolo da arrotondare, rect invece
definisce due raggi di ellisse per le x e per le y). Quindi per effettuare una traduzione
corretta bisogna disegnare il rettangolo tramite l’elemento path.
Note: tranne per il rettangolo con angoli arrotondati, tradotto tramite path, ogni
elementi di SVG ha un corrispondente elemento in VML.
gradient
Questo elemento serve per creare effetti di sfumature tra vari colori. SVG usa un
elemento per specificare le proprietà di gradient (inserito in defs), mentre VML utilizza alcuni attributi (nell’elemento fill). Innanzi tutto c’è da sottolineare il fatto che
in VML stroke non supporta gradient e quindi non si riesce ad effettuare una conversione. Quindi si può usare il gradiente solo per fill. Anche qui ci sono dei problemi.
I gradienti sono di due tipi: lineare e radiale. Quello lineare non presenta problemi.
Quello radiale (pur essendo supportato da entrambi i linguaggi) presenta delle differenze: SVG lo gestisce con cerchi concentrici, mentre VML con rettangoli concentrici.
Non sembra che si sia modo per avere lo stesso tipo di gradiente. Ultimo problema:
SVG permette di specificare un valore di opacità per ogni colore del gradient, VML
non lo supporta.
Note: ci sono alcune differenze tra i due linguaggi: stroke non supporta gradient
e i gradienti radiali vengono rappresentati in modi diversi.
a
Usato per creare link ipertestuali. Conversione banale, basta un cambio di nome.
87
4.1.2 Testi (elementi text, tspan, tref e textpath)
Questi elementi servono per scrivere del testo con vari effetti grafici. Qui appare evidente in maniera maggiore rispetto agli altri elementi la differenza tra SVG e VML.
SVG si sbizzarrisce nel definire tanti possibili effetti per rappresentare testi, mentre
VML definisce due elementi comprensivi di poche opzioni. Quindi per effettuare
una traduzione soddisfacente (una traduzione precisa sembra irrealizzabile), bisogna
suddividere il testo in tante parti e gestirle separatamente.
Nel dettaglio: l’elemento text (senza figli) è tranquillamente traducibile mediante
l’elemento textpath di VML (inserito all’interno di shapetype, che dovrà contenere un
path per rappresentare il testo). Per fare questo bisogna calcolare la lunghezza del
testo, moltiplicare per la dimensione del font e selezionare un path (una linea retta in
questo caso) con questa lunghezza in cui inserire il testo. L’unico problema con questo
elemento viene dagli attributi x e y, che rappresentano le coordinate di posizionamento. Questi attributi possono contenere un singolo valore (semplice) o valori multipli
(ogni valore rappresenta la posizione dell’i-esimo carattere); quest’ultimo caso risulta
problematico e non è stato considerato.
Le cose si complicano se text contiene tspan o tref. Questi elementi rappresentano
dei blocchi di testo da inserire all’interno di text (un paragone si può fare con i tag b e i
di HTML). La differenza tra i due è che il primo definisce al suo interno il testo, mentre
il secondo contiene un link ad un testo definito esternamente (all’interno dell’elemento
defs). Questi elementi (come text) contengono attributi di posizionamento (x e y:
posizionamento assoluto) e attributi di offset (dx e dy: posizionamento relativo alla
posizione corrente del testo). Il problema deriva dal fatto che il testo contenuto in text
viene influenzato da questi elementi: i caratteri posizionati dopo uno di questi elementi
verranno visualizzati (logicamente) successivamente ai caratteri di tspan o tref. Quindi,
per gestire questa situazione, bisogna considerare ogni singola parte del testo, cioè,
ogni frammento di text che precede o segue tspan/tref e ogni testo di tspan e tref.
Ognuna di queste parti viene posizionata considerando la lunghezza e le coordinate
delle parti precedenti. Queste operazioni risultano molto complesse ma tuttavia sono
realizzabili, con risultati soddisfacenti.
88
L’elemento text può inoltre contenere textPath che inserisce un testo all’interno di
un path. Quest’elemento influenza in parte il testo che lo segue, comportandosi come
se ci fosse uno spostamento nel punto 0,0.
Altri problemi derivano dalla gestione degli attributi (font-size, font-family, ecc.).
Molti attributi vengono gestiti molto semplicemente effettuando una traduzione di nomi; alcuni attributi non sono proprio gestiti da VML (font-stretch), altri rivelano problemi imprevisti. Questo è il caso di font-size, apparentemente facile da tradurre, rivela
invece dei problemi (risolvibili). Per quest’attributo non basta fare una copia del valore, bisogna anche effettuare un ridimensionamento, in quanto, in VML, il valore di
quest’attributo non viene influenzato dagli attributi di dimensionamento (width, height
e coordsize).
Un ulteriore problema (forse senza soluzione) deriva dalle decorazioni (sottolineature, ecc.) che pur essendo supportate da entrambi i linguaggi vengono gestite in
maniera diversa.
Con questa gestione del testo (considerare ogni singola parte di text fra i vari
tspan, tref e textpath) la traduzione non viene perfetta ma approssimata perché, per
posizionare ogni porzione di testo, si calcola la lunghezza del testo precedente e si
moltiplica per la dimensione del font, ma a seconda delle varie font-family, la dimensione dei singoli caratteri risulta diversa: una i occupa meno spazio di una m,
quindi calcolando le lunghezze si aggiunge un valore di aggiustamento (il 10% della
stringa), in questo modo, il testo risultate potrà risultare più o meno spaziato ma le
frasi dovrebbero essere equamente spaziate e non sovrapposte.
Note: la traduzione è molto complessa, bisogna gestire ogni singolo pezzo di testo
perdendo la struttura sequenziale del testo originale. Inoltre molte caratteristiche non
sono traducibili.
4.1.3 Trasformazioni (attributo transform)
Quest’attributo serve per effettuare delle trasformazioni che possono essere di sei tipi:
translate, scale, rotate, matrix, skewX e skewY.
In VML non c’è un corrispondente attributo che svolge le medesime funzioni,
89
quindi la traduzione viene effettuata creando un gruppo per ogni operazione di trasformazione, impostando opportunamente i suoi parametri e copiando all’interno della
catena di gruppi il contenuto dell’elemento che aveva l’attributo transform. Alcune
trasformazioni sono realizzabili (translate, scale, rotate), altre sembrano irrealizzabili
(matrix, skewX, skewY).
SkewX e skewY rappresentano un’inclinazione delle immagine sull’asse delle x e
delle y: in VML non sembra esserci nessun modo per far inclinare un’immagine.
Matrix specifica una matrice di trasformazione: ogni trasformazione può essere
considerata come una matrice con opportuni valori da applicare ai valori di x e y
dell’elemento da trasformare. Anche questa trasformazione non si riesce a tradurre.
Rotate sembrerebbe facilmente traducibile, in quanto VML ammette l’attributo rotation, quindi potrebbe essere una traduzione 1–1. Invece questa traduzione presenta
dei problemi perché SVG considera la rotazione a partire dall’angolo in alto a sinistra,
mentre VML a partire dal centro della figura; quindi per effettuare la traduzione si
deve prima effettuare uno spostamento, poi effettuare la rotazione. Inoltre SVG permette di specificare il punto rispetto a cui fare la rotazione, ma in questo caso non ci
sono particolari problemi perché questa trasformazione corrisponde ad effettuare: uno
spostamento (translate verso i due punti), la rotazione ed un altro spostamento (rispetto
all’inverso dei dui punti) e quindi ci si riconduce a dover tradurre due spostamenti ed
una rotazione normale.
Scale e translate sono facilmente traducibili (c’è un punto sottile da considerare:
se scale vale 0 tutte le trasformazioni non vengono considerate).
Per translate viene creato un gruppo con i valori di x e y impostati con i due valori
di translate (se non sono presenti valgono 0). Bisogna considerare che i valori vengono sempre considerati in user unit: se un valore presenta l’unità di misura, questa
dev’essere ignorata.
Per convertire scale si crea un gruppo con x e y impostati a 0 e si usano gli attributi
coordorigin (0,0) e coordsize (impostato col valore precedente diviso per il valore di
scale). In questo modo, riducendo o aumentando il numero di coordinate, gli elementi
contenuti all’interno del gruppo verranno automaticamente aumentati o diminuiti proporzionatamente. Un altro aspetto da considerare riguarda i valori di width e height
90
dei vari gruppi, che vanno impostati con i valori di coordsize dell’ultimo elemento ancestor. Quindi se è presente una trasformazione di tipo scale, i valori di width e height
dei gruppi andranno impostati con i nuovi valori di coordsize.
Note: gestite solo alcune trasformazioni (scale, translate e rotate), le altre sono
intraducibili (skewX, skewY, matrix).
4.1.4 Altri attributi
Dimensioni
Tutte le unità di misura (ad eccezione di quelle definite nell’elemento svg) vengono
tradotte, tramite un opportuno template, in user unit (che corrisponderebbero alle
dimensioni in pixel).
Lasciando il valore con la sua unità di misura la visualizzazione risulta errata.
Questo è dovuto alla presenza degli attributi coordsize che fanno in modo che le dimensioni effettive non corrispondano più alle dimensioni reali. Con una conversione
di questo tipo (esprimendo ogni valore in pixel) si risolve il problema, mantenendo le
dimensioni nella misura corretta.
Nel caso siano presenti valori percentuali si cerca il valore a cui corrispondono e
vengono opportunamente tradotti.
Attributi comuni
SVG presenta vari attributi comuni a molti elementi, suddivisi in varie classi. La loro
gestione è molto diversa: per alcuni basta una semplice traduzione di nome, per altri
sembra che una traduzione sia irrealizzabile. Non sono stati gestiti tutti, solo quelli
principali.
Attributi ereditati
Molti attributi di SVG, se non specificati, ereditano il valore dagli elementi ancestor.
Per fare in modo che anche nella traduzione in VML avvenga questo bisogna forzare la
ricerca negli attributi precedenti. Non può essere lasciata automatica (cioè senza met-
91
tere l’attributo) perché molte volte gli attributi dei due linguaggi hanno nomi differenti
e perché il valore di default (nel caso che nessun ancestor abbia l’attributo) per i due
linguaggi è diverso. Ci sono attributi che presentano delle difficoltà maggiori (opacity:
il valore dell’attributo è dato dalla moltiplicazione del valore dell’elemento corrente e
tutti gli elementi precedenti), ma tutto sommato la traduzione non presenta difficoltà.
Proprità stoke e fill
Le proprietà per definire il tipo di bordo e il riempimento delle figure sono definite
da una serie di attributi (stroke, fill, stroke-width, stroke-opacity, fill-opacity, ecc.).
VML, dal canto suo, gestisce queste caratteristiche definendo due elementi: stroke e
fill, i quali possono essere utilizzati da quasi tutti gli altri elementi. La traduzione non
comporta grossi problemi, si riduce ad una conversione di nomi; tuttavia ci sono alcuni
intoppi.
Innanzi tutto ci sono caratteristiche che sono supportate solo da SVG (fill-rule: per
specificare il tipo di riempimento in figure definite tramite path). Un altro problema
riguarda le dimensioni di stroke (stroke-width): anche qui, come per le dimensioni del
testo, copiare lo stesso valore di SVG in VML comporta una modifica della dimensione del bordo, quindi bisogna effettuare dei ridimensionamenti. L’ultimo problema
riguarda i valori ereditati (sia per stroke che per fill): se l’elemento è definito all’interno di defs e non presenta proprietà di bordo/riempimento, queste potrebbero essere
definite dall’elemento che lo utilizzerà, però non si riesce a farle ereditare.
Note: traduzione non completa; inoltre non vengono ereditate le propriet à per
elementi richiamti da defs.
Attributi di opacità
Sia SVG che VML prevedono l’utilizzo di uno o più attributi per definire l’opacità
(SVG permette di definire anche se l’opacità si riferisce ai bordi o al riempimento). Per
effettuare la traduzione bisogna considerare tutti gli attributi di opacità e moltiplicarli
per gli attributi degli elementi ancestor, in quanto SVG, a differenza di VML, considera
92
il valore di opacità di ogni elemento come il prodotto delle opacità di tutti gli elementi
precedenti.
4.1.5 Caratteristiche non traducibili
In questa sezione sono presentate tutte le caratteristiche di SVG che non possono essere
tradotte in quanto non supportate da VML.
Elemento pattern
Permette di specificare degli oggetti da utilizzare come riempimento o come bordo. A
differenza di gradient, VML supporta quest’attributo (SVG lo tratta come elemento,
VML come attributo) anche per stroke. La traduzione sembrerebbe fattibile (basta
inserire l’id della figura da visualizzare), ma in realtà sembra non essere supportato, in
quanto VML ammette come pattern solo una figura esterna.
Elemento mask
Definisce una maschera per comporre oggetti col background. Non traducibile.
Filter Effects (elemento filter e elementi associati)
Serve per creare complessi effetti grafici, non supportati da VML. Di seguito viene
riportato l’elenco completo degli elementi: filter, feBlend, feColorMatrix, feComponentTransfer, feComposite, feConvolveMatrix, feDiffuseLighting, feDisplacementMap,
feDistantLight, feFlood, feFuncA, feFuncB, feFuncG, feFuncR, feGaussianBlur, feImage, feMerge, feMergeNode, feMorphology, feOffset, fePointLight, feSpecularLighting, feSpotLight, feTile, feTurbulence.
Elemento script
Non supportato.
93
Animazioni (elemento animate ed elementi associati)
Non supportate. Elenco completo degli elementi: animate, animateColor, animateMotion, animateTransform, cursor, mpath, set.
Elemento clipPath
Serve per realizzare un path con cui effettuare un clipping. Non supportato.
Altre
Inoltre non è stato tradotto l’attributo preserveAspectRatio, le priorietà di clipping e le
trasformazioni di tipo matrix, skewX e skewY come descritto in precedenza.
4.1.6 Caratteristiche non tradotte
Vengono di seguito presentate varie caratteristiche di SVG, che essendo traducibili o
meno, non sono state prese in considerazione per questa prima versione del convertitore.
Elemento marker
Quest’elemento inserisce delle figure (definite tramite path) nei vertici di alcuni elementi (path, line, polyline, polygon). Queste figure possono essere inserite nel punto
iniziale, nel punto finale o in tutti i vertici intermedi.
Caratteristiche riguardanti i testi
Per quanto riguarda i testi, sono state considerate e tradotte molte caratteristiche,
tuttavia alcune sono state tralasciate, eccone un elenco:
• elementi per definire/gestire nuovi font (elementi font, glyph e altri);
• orientamento del testo, sono stati gestiti solo i testi scritti in orizzontale;
94
• gestione valori multipli di x, y (anche dx e dy): permettono di posizionare ogni
carattere in base all’i-esimo valore di x e y;
• tspan, tref complessi (con all’interno altri tspan, tref).
Per maggiori informazioni viene presentato un elenco di tutti gli elementi non tradotti:
altGlyph, altGlyphDef, altGlyphItem, definition-src, font, font-face, font-face-format,
font-face-name, font-face-src, font-face-uri, glyph, glyphRef, hkern, missing-glyph,
vkern.
Elemento color-profile
Serve per definire un nuovo profilo per rappresentare un colore.
Elemento foreignObject
Serve per includere un oggetto esterno.
Elemento metadata
Serve per includere metadati.
Elemento switch
Serve per specificare un rappresentazione alternativa a seconda della capacità di un
dato user agent.
95
4.2 Da VML a SVG
In questa sezione viene descritta la struttura (e gli elementi) di VML e il modo con
cui è stata tradotta in SVG. Come per la conversione precedente, questo sottocapitolo
è stato organizzato in forma di manuale. Vengono descritto tutti gli elementi di VML,
specificando come sono stati convertiti; si passa poi a descrivere alcuni aspetti particolari (ad esempio la gestione di defs) ed i principali attributi. Infine si analizzeranno le
caratteristiche che non sono state tradotte.
Innanzi tutto va sottolineato che un documento VML vero e proprio non esiste,
il codice VML (cioè i tag) è inserito all’interno di un documento HTML, usando un
apposito namespace. SVG invece è un tipo di documento XML vero e proprio, in cui
tutto il contenuto è racchiuso in un elemento svg.
Per la conversione sono stati esclusi tutti i tag di HTML, in quanto non fanno parte
della vera e propria “grafica” del documento e per effettuare una traduzione completa si
dovrebbe (o potrebbe) creare un nuovo documento HTML, con la parte HTML identica
e sostituendo alla parte VML un tag object che include un documento SVG.
Nella conversione per prima cosa è stato creato un elemento svg (contenitore) con
dimensioni pari allo schermo (width e height impostati a 100%) che conterrà tutti gli
altri elementi grafici. Questa soluzione si è resa necessaria per due motivi:
• Il primo consiste nel fatto che SVG richiede che tutto il contenuto sia raggruppato all’interno di uno o più tag svg, mentre VML non ha un tag contenitore obbligatorio, quindi si deve forzare in qualche modo la creazione di questo elemento.
Per esempio, se il documento VML conterrà un solo elemento rect, la traduzione
“naturale” creerebbe un documento SVG con un solo elemento rect senza creare
il “contenitore” svg e quindi il rettangolo non verràebbe visualizzato).
• Il secondo motivo riguarda l’uso dell’elemento defs. Quest’elemento (di SVG)
rappresenta un contenitore che contiene tutti quegli elementi che saranno richiamati più volte nel documento (il suo contenuto non viene visualizzato direttamente, può solo essere richiamato).
Quest’elemento viene posto all’interno di questo primo tag svg, in modo che il
96
suo contenuto possa essere tranquillamente richiamato da ogni altro elemento.
Senza questa soluzione si dovrebbero creare tanti elementi defs, i quali probabilmente conterrebbero gli stessi elementi, portando ad una ripetizione, poco
elegante, del codice.
4.2.1 Elementi
In questa sezione vengono descritti tutti gli elementi di VML ed il modo in cui sono
stati convertiti in SVG.
group
Quest’elemento rappresenta un contenitore, cioè può contenere qualsiasi altro elemento. La traduzione naturale in SVG sarebbe tramite l’elemento g (anch’esso rappresenta
un gruppo), tuttavia non è possibile per alcune piccole differenze. L’elemento group
può (anzi deve) contenere degli attributi di posizionamento e dimensionamento (top,
left, width e height), se non sono presenti il contenuto non verrà visualizzato; nell’elemento g di SVG invece attributi di posizionamento/dimensionamento non sono
ammessi.
Inoltre group può contenere gli attributi coordorigin e coordsize per ridimensionare il suo contenuto. In SVG questi si traducono con l’attributo viewBox, ma anche
in questo caso l’elemento g non lo supporta. Quindi group è stato tradotto con un
elemento svg, che in linea di principio (ma anche in pratica) svolge le stesse funzioni
(cioè di contenitore).
path (elemento ed attributo)
Quest’elemento può essere presente solo in shape o shapetype e contiene un path
che può essere visualizzato direttamente o usato per rappresentare un testo. Oltre a
quest’elemento shape e shapetype possono definire l’attributo path che contiene anch’esso un path. La differenza tra l’utilizzo dei due è che l’elemento path permette di
definire più caratteristiche.
97
La traduzione è abbastanza naturale: si utilizza l’elemento path di SVG che presenta le medesime caratteristiche. Un problema è dovuto al fatto che utilizzano una
diversa notazione per rappresentare i vari tipi di linee, non sempre traducibile mediante
un cambio del nome del comando.
• Sintassi dei path: i path sono espressi mediante un nome di comando seguito
da uno o più punti. Per esempio: “M 0,0” si sposta nel punto 0,0 “L 10,10”
crea una linea dal punto corrente fino al punto specificato (da 0,0 a 10,10), “L
10,10, 20,20”, crea due linee una dal punto corrente a 10,10 e una da 10,10 a
20,20. È presente un comando particolare, X, che permette di chiudere il path,
disegnando una linea dall’ultimo punto considerato fino al punto iniziale.
• Traduzione: in SVG i path sono rappresentati alla stessa maniera, molti comandi
hanno la stessa forma e lo stesso nome, altri hanno un nome diverso (per la
traduzione basta una semplice traduzione di lettere). Infine ci sono comandi
che hanno una diversa gestione, cioè utilizzano un diverso numero di punti ed
eventualmente si basano su punti precedenti, o su altre considerazioni. Per alcuni
di questi comandi si è realizzata una traduzione equivalente lavorando un po’ sui
valori del comando. Altri comandi sono stati tradotti con un’approssimazione.
Alcuni non sono traducibili, per esempio nf, ns: servono per segnalare che da
quel punto del path in avanti non bisogna effettuare il riempimento o disegnare
il bordo (non c’è un modo per fare la stessa cosa in SVG).
L’elemento path inoltre presenta vari attributi (alcuni per segnalare se visualizzare
il testo o il path, altri per impostare il rettangolo in cui inserire la textbox). Ci sono
alcuni attributi che non sono stati gestiti (per esempio l’inserimento di frecce nel path),
comunque non di fondamentale importanza.
La tabella 4.2 mostra l’elenco dei vari comandi ammessi da VML per rappresentare
dei path e la corrispondente traduzione in SVG, specificando se è stata realizzata
correttamente o approssimata e il nome del comando usato.
Note:
• alcuni path tradotti con approssimazioni, alcune caratteristiche non traducibili;
98
Comando
m
t
l
r
c
v
x
e
ae
al
at
ar
wa
wr
qx
qy
nf
ns
Descrizione
move to (assoluto)
move to (relativo)
line to (assoluto)
line to (relativo)
curve to (assoluto)
curve to (relativo)
close path
end path
angle ellipse to
angle ellipse
arc to
arc
clockwise arc to
clockwise arc
elliptical qaudrant x
elliptical qaudrant y
no fill
no stroke
Traduzione
corretta (M)
corretta (m)
corretta (L)
corretta (l)
corretta (C)
corretta (c)
corretta (Z)
corretta ( )
approssimata (L)
approssimata (M)
approssimata (l+l+l+l+l)
approssimata (m+l+l+l+l)
approssimata (l+l+l+l+l)
approssimata (m+l+l+l+l)
approssimata (Q)
approssimata (Q)
non supportata
non supportata
Tabella 4.2: Traduzione path da SVG a VML
• non tutti gli attributi tradotti/traducibili.
fill e stroke (elementi e attributi)
In VML ci sono due elementi (fill e stroke) per specificare le proprietà del riempimento
e del bordo delle figure (oltre all’utilizzo dei semplici attributi fill e stroke). In presenza
sia dell’elemento che dell’attributo corrispondente, ad esempio:
<rect fillcolor="black">
<fill color="red" />
</rect>
ha la precedenza l’elemento, che sovrascriverà le proprietà specificate in precedenza (nell’esempio il rettangolo viene riempito di rosso). In SVG ci sono solo gli attributi
fill e stroke.
99
La rraduzione si svolge nel modo seguente: per ogni elemento si impostano le
proprietà di painting cercando prima gli elementi fill e stroke. Se non ci sono si cercano
gli attributi all’interno dell’elemento; se neanch’essi sono presenti si impostano le
proprietà di default.
Da notare che non si cercano queste proprietà negli elementi precedenti perché
in VML non c’è nessun modo di far ereditare questi valori (ogni elemento non può
“passare” questi valori ai figli, eccezion fatta per shapetype–shape, che prevedono una
gestione ad hoc).
Questi due elementi presentano vari attributi (per rappresentare semplici colori,
gradienti e altro) di cui è stata gestita la maggior parte, tralasciandone alcuni di dubbia
traducibilità.
Note: traduzione non completa ma abbastanza esaustiva.
textbox
Quest’elemento può essere contenuto all’interno di shape o shapetype e serve per inserire del testo. Il contenuto di questo elemento può essere testo semplice oppure
testi inserito in tag HTML. La “scatola” in cui viene rappresentato il testo è definita
dall’attributo textboxrect espresso all’interno di un elemento path (figlio di shape o
shapetype).
La traduzione di quest’elemento è semplificata, in quanto non vengono gestiti tutti
i tag HTML (per esempio possono essere definite delle tabelle, ma quest’opzione è
molto difficile da rappresentare in SVG, se non impossibile). Sono stati considerati
gli elementi in qualche modo riferiti al testo; quindi sono stati tradotti i tag b ed i
che hanno un ruolo importante per quanto riguarda il testo e l’attributo style, che anch’esso influisce la rappresentazione del testo. Oltre a questi viene gestito il tag id per
effettuare collegamenti ipertestuali.
Note: textbox richiederebbe una gestione di HTML, fatta solo in parte.
100
textpath
Quest’elemento può essere contenuto all’interno di shape o shapetype e serve per inserire un testo all’interno di un path. Per poter essere rappresentato serve all’interno
dell’elemento path (figlio di shape o shapetype) l’attributo textpathok impostato a true:
in questo modo non viene visualizzato il path e si visualizza il testo.
La traduzione viene effettuata mediante un elemento textpath (contenuto all’interno di un elemento text), quest’elemento contiene un attributo (href) per riferirsi
al path. Questo path, come specificato in precedenza, viene inserito nell’elemento
defs. Textpath presenta varie caratteristiche per la rappresentazione del testo, come
il ridimensionamento del testo per inserirlo completamente nel path (si rimpiccolisce
il testo dimensionandolo in base alla lunghezza del path): questa caratteristica non è
traducibile in SVG.
Inoltre textpath, tramite l’attributo style, permette di definire varie proprietà sul
testo: font-style, font-family, ecc. Di queste sono state considerate solo quelle fondamentali, tralasciandone alcune di minor importanza (e forse non gestibili).
Problemi con la traduzione:
• in SVG il testo viene deformato in base al valore di viewbox, in VML il testo non
viene condizionato da coordsize;
• il testo nei path, in SVG viene allineato a sinistra, in VML viene centrato nel
path;
• textpath: in VML se il testo è più lungo del path, viene visualizzato “fuori”,
mentre in SVG viene troncato;
• non tradotte tutte le proprietà (quelle fondamentali si).
imagedata e image
L’elemento imagedata serve per inserire un’immagine esterna. Può essere contenuto
solo all’interno di shape o shapetype. Si traduce con l’elemento image di SVG che
serve anch’esso per inserire immagini esterne.
101
L’elemento image, svolge lo stesso ruolo, solo che viene inserito esternamente a
shape/shapetype. La traduzione si effettua anche in questo caso con l’elemento image.
Note: image e imagedata supportano molti attributi per la definizione della figura
(contrasto, luminosità, scala di grigi, ecc.) che non sono considerati nella traduzione.
Figure predefinite: rect, roundrect, line, polyline, curve, oval e arc
Questi elementi sono banalmente traducibili in corrispondenti elementi SVG, con alcune eccezioni. Per gli elementi curve e arc non ci sono corrispondenti elementi,
quindi vengono rappresentati creando un path.
Da notare che arc permette di definire l’angolo di inizio e di fine dell’arco, mentre
(per semplicità) il path creato da SVG può essere rappresentato solo mediante quarti di
arco. Per esempio: se viene definito un arco che va da 20 a 130 gradi, in SVG si otterrà
lo stesso arco (nel senso di dimensioni) ma verrà rappresentato da 0 a 180 gradi.
Note: traduzione in parte approssimata (arc).
4.2.2 shape – shapetype
L’elemento shape serve per creare delle figure, tramite: path, testi o inserimento di immagini. È l’unico elemento di VML (assieme a shapetype) che supporta i path e i testi.
Inoltre (tramite l’attributo type) si può riferire ad un altro elemento che serve per creare
figure (shapetype), ridefinendone, eventualmente, alcune proprietà e caratteristiche.
L’elemento shapetype è identico a shape tranne per il fatto che il suo contenuto non
viene visualizzato, può essere solo richiamato. Serve per definire figure che saranno
riusate più volte nel documento.
Traduzione:
• Primo approccio:
– La traduzione naturale di questi due elementi è quella di rappresentare
shapetype come un elemento svg inserito all’interno di defs (in modo che
non venga visualizzato e possa essere richiamato); mentre shape viene anch’esso rappresentato con un elemento svg: nel caso si riferisca ad uno
102
shapetype, si utilizza l’elemento use per effettuare il riferimento (use permette di richiamare un elemento definito all’interno di defs).
– Problema: quando sia shape che shapetype definiscono gli stessi elementi o attributi, VML da precedenza alle caratteristiche definite in shape.
Usando la traduzione svg + use, svg definisce le caratteristiche di shape,
use richiama shapetype sovrascrivendo le proprietà già definite, quindi
in questo modo, si da precedenza a shapetype. Quindi pur essendo una
traduzione che rispetta la struttura del documento presenta forti differenze
di rappresentazione e di conseguenza è stata scartata.
• Soluzione finale: si traduce l’elemento shape con un elemento svg, ricercando
eventualmente un elemento shapetype a cui ci si riferisce e combinando appropriatamente le caratteristiche dei due elementi. In questo modo in defs non ci
sarà più la definizione di una figura: ogni shapetype presente è come se venisse
copiato in ogni elemento che lo richiama (in pratica non viene copiato del tutto,
si tengono solo le caratteristiche non presenti nel shape chiamante).
4.2.3 Gestione defs
Come accennato precedentemente, all’interno del primo elemento svg viene creato
l’elemento defs, che conterrà tutti gli elementi richiamati all’interno del documento.
Nel dettaglio:
• Textpath:
– Descrizione: in VML l’elemento textpath (che può essere contenuto esclusivamente in shape o shapetype) rappresenta un testo scritto all’interno di
un path. Questo path verrà determinato dall’ultimo elemento (o attributo)
path contenuto nell’elemento shape (o shapetype).
In SVG, per inserire un testo in path, si utilizza l’elemento textpath (all’interno di un elemento text). Quest’elemento contiene un riferimento ad un
elemento path (che contiene, naturalmente, il path). Il path (visto che è un
103
elemento che non verrà rappresentato direttamente ma a cui ci si riferisce)
verrà inserito nell’elemento defs.
– Realizzazione: per ogni elemento textpath contenuto nel documento VML
si crea un elemento path. Innanzi tutto bisogna impostare il valore di id.
Per fare in modo che sia univoco lo si eguaglia al numero di elementi che
precedono textpath, più la stringa path (ad esempio se textpath ha 5 elementi precedenti si avrà id=path5). Poi da textpath si risale al padre. Se ha
l’attributo/elemento path si utilizza questo valore; se è un elemento shape
con attributo type si cerca l’elemento shapetype a cui si riferisce e si cerca
il path in quest’elemento.
– Nota: viene creato un elemento path per ogni shape che presenta l’attributo
path. Inoltre viene creato un elemento path anche per ogni shape con type,
indipendentemente dal fatto che l’elemento shapetype riferito contenga o
meno un attributo path. Quest’ultimo caso serve per gestire i path eventualmente creati in shapetype: in questo modo, però, potrebbero essere definiti
dei path vuoti e inutilizzati, ma è un compromesso ragionevole per essere
sicuri di coprire tutti i casi possibili.
• Gradient:
– Descrizione: in VML l’elemento fill (e solo lui!) permette di definire un
gradiente (mediante l’attributo type impostato a gradient o gradientradial).
Una volta impostato type, vengono considerati altri attributi di fill che
specificano le caratteristiche del gradiente (attributi: angle, colors, color,
color2, focusposition, ecc.).
In SVG il gradiente viene definito tramite gli elementi linearGradient o
radialGradient, che sono esclusivamente definiti all’interno di defs e sono
poi richiamati tramite attributo href.
– Realizzazione: per ogni elemento fill, con attributo type impostato a gradient o gradientradial, viene creato un elemento linearGradient o radialGradient, gestendolo considerando i vari attributi dell’elemento fill. Per l’id si
104
utilizza o l’id presente in fill oppure (come nel caso textpath) si utilizza un
valore univoco dato dal numero di elementi precedenti.
• Pattern: come per gradient, viene creato un elemento pattern per ogni fill che
contengono l’attributo type uguale a frame (caso type = pattern)
• Shapetype: non considerato. Vedi elemento shape.
4.2.4 Trasformazioni
A differenza di SVG, che presenta un attributo per definire le varie trasformazioni,
VML non presenta un tale attributo. Tuttavia anche in VML è possibile effettuare le
principali trasformazioni (rotate, scale e translate).
Per effettuare la rotazione si utilizza la proprietà rotation all’interno di style (che
effettua una rotazione rispetto al centro della figura). La traduzione in questo caso è
realizzabile molto semplicemente: viene creato un gruppo con transform che include
la proprietà rotate. Rotate di SVG ruota la figura rispetto all’angolo in alto a sinistra della figura, quindi si comporta diversamente rispetto a VML, tuttavia supporta
due parametri che indicano il punto rispetto al quale effettuare la rotazione, rendendo
ottenibile una trasformazione equivalente.
Per effettuare operazioni di scale non è presente nessun attributo specifico in VML:
si eseguono semplicemente utilizzando i valori di coordsize per rimpicciolire o ingrandire le figure (equivalenti a viewBox di SVG). Anche per le traslazioni non ci
sono attributi specifici: per effettuarle si crea un gruppo impostando opportunamente i
valori di top e left.
4.2.5 Altri attributi
Dimensioni
Tutte le dimensioni di VML sono gestite in modo appropriato traducendole, senza
unità di misura (e senza percentuali), nei corrispondenti valori.
105
Ci sono alcune considerazioni da fare riguardo alla dimensione dei font e dei bordi.
Per quanto riguarda i testi: qualunque sia la dimensione delle figure e i ridimensionamenti effettuati da coordsize, il valore di font-size non ne viene influenzato, è un valore
“assoluto”. Per ottenere una traduzione in SVG, in cui il testo è influenzato dai dimensionamenti, bisogna effettuare varie traduzioni in base alle dimensioni degli elementi
che contengono il testo (considerando gli attributi coordsize, width e height).
Per i bordi il discorso è analogo, quindi avranno la stessa dimensione sia per la
larghezza sia per l’altezza, non facendosi influenzare da coordsize. In SVG, invece,
i bordi possono avere una diversa rappresentazione per l’altezza e per la larghezza in
base ai valori di viewBox: cioè un rettangolo può avere i bordi più larghi ai lati verticali
rispetto a quelli orizzontali. Questa differenza non può venire gestita nella traduzione.
Attributi comuni
Quasi tutti gli elementi di VML presentano una serie di attributi comuni che si dividono
in due categorie: core e shape.
Gli attributi core forniscono informazioni strutturali della figura (dimensionamenti,
scale, ecc.), oltre ad avere attributi quali id, class, href. Questi attributi sono più o meno
traducibili con una nota a parte per style, descritto nel dettaglio in seguito.
Gli attributi shape invece forniscono informazioni sulla resa grafica della figura
(colori interni ed esterni, opacità, ecc.): anche questi sono facilmente traducibili.
Note: questi attributi comuni sono stati tradotti quasi tutti, escludendo alcuni non
di fondamentale importanza.
Attributo style
Molte proprietà in VML sono inserite nell’attributo style (left, top, width, height,
ecc.): per effettuare una corretta traduzione devono essere estratti e convertiti in appropriati attributi. Quest’operazione non presenta grosse difficoltà, tuttavia non tutte
le caratteristiche di style sono state tradotte.
Ci sono alcune proprietà che non sono traducibili (z-index: indica l’ordine delle
106
figure, nel senso di quale visualizzare a livello più alto, quale mettere sotto, ecc.), altre
invece non sono state tradotte in quanto di minore importanza.
Note: non tutte le proprietà tradotte/traducibili.
VML presenta alcune caratteristiche che non trovano una corrispondeza in SVG, le
quali sono mostrate nel seguito con una breve descrizione.
Elemento fourmulas (e f): non gestibile. Serve per definire delle formule matematiche il cui valore verrà calcolato in base al valore dell’attributo adj. Il problema
non è tanto calcolare le formule, ma riuscire a riferirsi alle formule già definite,
in quanto ogni formula ogni formula può riferirsi a valori di formule precedenti.
Elemento handles (e h): non è da tradurre. Serve per effettuare modifiche dell’immagine all’interno di Office.
Proprietà z-index: serve per definire l’ordine di visualizzazione (sovrapposizione)
degli elementi.
Di seguito sono elencati gli elementi e gli attributi che non sono stati gestiti (i quali
potrebbero essere traducibili o meno) nella realizzazione del convertitore.
Elemento background: serve per specificare il background dell’immagine.
Elemento shadow: serve per definire degli effetti di ombreggiatura.
Attributi comuni: adj, visibility, z-index, flip, position, chromakey, wrapcoords.
Attributi di path: limo, shadowok, arrowok.
Attributi di stroke: startarrow, startarrowwidth, startarrowlength, endarrow, endarrowwidth, endarrowlength.
Attributi di imagedata e image: gain, blacklevel, gamma, grayscale, bilevel.
107
4.3 Da SVG e VML a GIF
Le conversioni da SVG e VML a GIF sono state realizzate mediante l’utilizzo di due
script PHP, sfruttano la libreria grafica di questo linguaggio che mette a disposizione
diverse funzioni per creare e gestire delle immagini raster.
Per ottenere un utilizzo effettivo di questi script (con un pieno supporto di tutti gli
elementi grafici) è necessario installare PHP dalla versione 4.1.0. Inoltre è necessario
installare la libreria GD, nella versione inferiore alla 1.6 (con un supporto esclusivo del
formato GIF), oppure, per supportare anche gli altri formati raster, serve una versione
superiore alla 2.0.28.
Tutto il codice è stato scritto e testato utilizzando la versione 4.3.8 di PHP, con la
libreria GD nella versione 2.0.
4.3.1 Funzioni per le immagini di PHP
In questa sezione verranno descritte brevemente le funzioni di PHP (PHP Hypertext
Preprocessor) utilizzate per la creazione dell’immagine GIF; per maggiori riferimenti
si rimanda a [Bak05].
Per creare una nuova immagine si utilizza la funzione imagecrate, la quale permette
di allocare l’immagine, specificandone le dimensioni e restituisce un identificatore che
verrà utilizzato nelle successive funzioni per inserire le varie figure o caratteristiche
nell’immagine. Per visualizzarla verrà utilizzata la funzione imagegif che visualizza
l’immagine creata (eventualmente la può memorizzare in un file).
All’inizio della gestione della figura viene utilizzata la funzione imagecolorallocate che permette di allocare i colori che saranno utilizzati dalle altre funzioni,
restituendo un identificatore per ogni colore. Questi identificatori verranno usati come
parametri nelle varie funzioni per specificare i colori di riempimento o del bordo delle
figure. Solo i colori allocati possono essere utilizzati.
Per creare le varie figure si utilizzano una serie di funzioni che permettono di
creare rettangoli, disegnandone i bordi (imagerectangle) oppure colorandone la superficie (imagefilledrectangle). Si possono creare ellissi (imageellipse, imagefilledellipse), linee (imageline), archi (imagearc, imagefilledarc) e poligoni (imagepolygon,
108
imagefilledpolygon). A queste funzioni vengono passati come parametri, oltre all’identificatore dell’immagine, i punti in cui disegnare la figura, le dimensioni e i colori
(allocati in precedenza).
Per rappresentare i testi viene utilizzata la funzione imagettftext, che prende in
input le coordinate di posizionamento, il font (passato come url), la dimensione e i
colori.
Infine, le ultime funzioni utilizzate sono quelle per l’inserimento di un’immagine
esterna. Si utilizza la funzione imagecreatefromjpeg (o imagecreatefromgif oppure
imagecreatefrompng) per includere l’immagine, ottenendo un identificatore. Successivamente, tramite imagecopyresized, si inserisce la nuova immagine all’interno di
quella che si sta creando, dimensionandola opportunamente.
4.3.2 Metodo di traduzione
La traduzione si svolge in tre fasi: una prima fase in cui viene modificato il file originario, adattandolo alle proprie esigenze (per esempio si tolgono le parti inutili e si
cambiano i namespace); successivamente si analizza tutto il documento impostando la
figura finale. Infine si procede alla visualizzazione dell’immagine GIF.
La fase fondamentale è la seconda, nella quale viene scandito tutto il file. Per prima
cosa viene cercato il primo elemento, il quale fornirà le informazioni sulla dimensione
dell’immagine. Quindi l’applicazione crea un file GIF vuoto con le dimensioni specificate. Successivamente si effettua il vero e proprio parser del documento: per ogni
elemento incontrato (ad eccezione dei contenitori) viene creato un’opportuna figura
(dimensionata e colorata in base agli specifici attributi) da inserire nel GIF.
La struttura dei documenti viene analizzata gestendo i vari livelli di annidamento
degli elementi (tramite una variabile globale). Ad ogni tag aperto si incrementa il
livello e ad ogni tag chiuso si decrementa. Per ogni livello si mantengono determinate
informazioni (dimensionamenti, colori, font e altro) che potranno essere ereditate dai
livelli successivi.
Per mantenere informazioni sui vari attributi e sul livello in cui sono presenti questi
109
attributi si utilizzano una serie di pile, in modo che, in ogni livello di annidamento in
cui ci si trova, si possa sempre recuperare le informazioni sugli elementi ancestor. Le
pile sono della forma: [valore, livello]. Per ogni tag chiuso (</nome> o <nome/>)
oltre a diminuire il livello corrente, vengono svuotati dale pile tutti i valori riferiti a
quel livello.
Un punto sottile della traduzione è rappresentato dalla gestione dei bordi. SVG
e VML permettono di definire lo spessore dei bordi delle figure, mentre con le funzioni di PHP non è possibile farlo: quindi si è utilizzato una specie di trucchetto. Per
rappresentare un bordo di una data dimensione, si disegnano tante figure sovrapposte
di perimetro sempre maggiore (con incrementi di piccole dimensioni) creando cosı̀
l’illusione di un unico perimetro con un bordo di una specifica dimensione.
4.3.3 Traduzione da SVG a GIF
Questa traduzione è stata realizzata mediante l’utilizzo di uno script php (svg2gif.php)
a cui viene passato l’url del file da tradurre e visualizza il GIF creato. In questa sezione
verrà illustrato il funzionamento del programma principale dello script e verranno
descritte le funzioni utilizzate.
MAIN PROGRAM
Viene aperto il file e copiato in un file temporaneo, il quale verrà letto più volte (si
scorre dall’inizio alla fine) effettuando delle modifiche.
prima scansione: vengono gestiti i seguenti aspetti:
• vengono memorizzati eventuali riferimenti a CSS esterni;
• si modifica il file in modo da avere un solo tag per ogni riga;
• si eliminano tutti i tag superflui (dichiarazioni iniziali e commenti su una
riga);
• si elimina l’eventuale namespace di SVG da ogni tag.
110
seconda scansione: vengono gestite le entità (ogni entità viene sostituita con il rispettivo valore).
terza scansione: gestione di eventuali CSS esterni (inseriti nel file).
quarta scansione: si gestisce style. Vengono inserite in ogni elemento con id e class
le proprietà di style opportune (definite nell’elemento style). Vengono gestite
inoltre le proprietà di style che si riferiscono ai nomi degli elementi.
quinta scansione: viene estratto il contenuto dell’attributo style di ogni elemento e
vengono gestiti i colori (si considerano tutti i colori che verranno utilizzati in
modo da poterli allocare).
In seguito viene gestito il file creato. Per prima cosa si impostano (si azzerano)
le variabili globali (le pile): sostanzialmente si inseriscono i valori di default (livello
impostato a –1 e valore uguale al valore di default).
Successivamente si scorrono tutte le righe del file:
• si ci si trova all’interno di un commento, non si considera il contenuto;
• se ci si trova dentro defs, si inserisce il contenuto nella struttura gestione defs;
• in presenza del primo tag svg, si imposta la dimensione dell’immagine GIF, si
allocano tutti i colori (ricavati in precedenza) e si crea l’immagine;
• per ogni riga si invoca la funzione gestione file.
Alla fine del file si visualizza l’immagine creata.
FUNZIONI
Per effettuare la gestione del documento SVG è stata utilizzata una specifica funzione
(gestione file), la quale analizza ogni riga del file ed in base agli elementi ed attributi
incontrati crea i vari oggetti grafici nell’immagine finale.
gestione file: funzione principale, gestisce ogni riga del file. Di seguito vengono
descritti i vari aspetti considerati.
111
1. Gestione livello: per ogni tag aperto <nome> si incrementa il livello. Per
ogni tag chiuso </nome> si decrementa. Con tag del tipo <nome /> si incrementa il livello, si gestisce il contenuto e si decrementa. Ogni volta che
si decrementa un livello vengono controllate tutte le pile ed eventualmente
si tolgono dei valori.
2. Variabili perc x, perc y: in base ai precedenti valori di width, height e
viewBox si impostano due variabili che rappresentano i valori a cui eventuali valori espressi in percentuale si riferiscono.
3. Gestione testo: quando si entra in una regione di testo (<text> ...) si
imposta la variabile in text a 1, in modo che non vengano gestite altre
caratteristiche, concentrandosi solo sul testo, cioè non modificando le varie
pile.
• Ogni parte di testo, text semplice: un solo testo. text con tspan e tref:
viene diviso il testo in tante porzioni. Ad esempio:
<text>
parte 1
<tspan> parte 2 </tspan>
parte 3
</text>
In questo caso si avranno tre porzioni di testo. Queste parti non vengono visualizzate al momento, ma alla fine della gestione di text. Vengono gestite singolarmente e memorizzate in un array multidimensionale (che contiene informazioni sul posizionamento, font, colori,
ecc.).
• Quando si giunge alla fine del testo (</text>) si visualizzano tutte le
parti di testo considerate. Ogni parte viene posizionata considerando
la posizione raggiunta dalle parti di testo precedenti. Ad esempio:
<text>
ciao
<tspan> fine </tspan>
</text>
112
viene scritto ciao. Per scrivere fine, ci si sposta dalla posizione di
inizio testo di quattro volte la lunghezza del font di ciao (più eventuali
aggiustamenti, dovuti al fatto che i caratteri sono più o meno spessi,
una i occupa meno spazio di una m).
• Nota: sono gestiti solo tre tipi di font (times, verdana, arial), ognuno
ha un diverso tipo di aggiustamento.
• textpath: si deve cercare il path all’interno di defs (gestione defs: è
presente un array, contenuto defs, che contiene tutte le righe presenti
in defs). Da notare che il path potrebbe non essere contenuto in defs:
in questo caso non viene gestito.
• tref: come per textpath si deve cercare il testo in defs.
4. Gestione viewBox: in presenza di quest’attributo, si aggiornano le variabili (array) per la conversione. Ha quattro valori: i primi due vengono
considerati come se fossero due traslazioni.
5. Gestione transform: si estrae il contenuto e si aggiunge alle variabili di
conversione (translate e scale). Alcune trasformazioni non sono gestibili
(rotate, skewX, skewY e matrix).
6. Valori di font family, font size e text-anchor: vengono mantenute delle pile
anche per questi valori (array multidimensionali, con valore e livello) in
modo da poterli usare come valori “di default” nel caso text non contenga
questi attributi.
7. Fill e stroke: anche per fill e stroke è presente una pila.
8. Figure predefinite: si chiama la funzione predef.
9. x, y, width e height: x e y vengono aggiunte alle traslazioni. Width e height
vengono inserite in una pila (servono per la gestione di viewbox).
10. image: si estrae l’url dell’immagine e in base all’estensione si crea un’immagine opportunamente dimensionata (formati supportati: JPEG, PNG,
GIF) e la si inserisce nel GIF.
11. Gestione use: l’elemento use si riferisce (o almeno cosı̀ dovrebbe) ad un
113
elemento contenuto in defs. Per la traduzione si cerca l’elemento in defs
(array contenuto defs). Una volta trovato si gestisce il contenuto di defs
(fino alla fine dell’elemento) come se fosse inserito al posto di use. Per
fare questo si richiama la funzione gestione file per ogni riga di defs.
12. Gestione path: vengono estratti tutti i comandi e i rispettivi valori dall’attributo d di path e si inseriscono in un array multidimensionale, chiamando
poi la funzione visualizza path.
La funzione principale necessità di alcune funzioni di libreria per gestire nello specifico vari aspetti della traduzione. Di seguito sono riportate tutte le funzioni
utilizzate:
carica colori: alloca tutti i colori presenti, nella forma #rrggbb o rgb(rr,gg,bb), e
alloca i principali colori con nome (black, white, ecc.)
converti: converte il valore in base all’unità di misura, restituisce un numero.
conversione: imposta gli attributi di conversione (translate x e y, scale x e y, viewBox
x e y) da applicare in un determinato livello.
Sono presenti tre pile, implementare mediante una serie di array (viewbox x,
viewbox y, n viewbox, viewbox livello, ecc.) che contengono tutti i viewbox,
translate e scale incontrati, più il livello in cui sono state incontrate (inteso come
livello di annidamento dei tag).
Viene invocata in un certo livello e calcola tutte le “trasformazioni” dei livelli
precedenti, cioè quelle da applicare.
gestione angoli: calcola i valori di seno e coseno in base ai valori dei “lati” per rappresentare delle line. Serve per fare in modo che le linee oblique abbiamo uno
spessore equivalente a quelle orizzontali e verticali.
calcola inverso: usata nell’ambito della gestione degli angoli.
bezier3 – cubicbezier: servono per calcolare i punti delle curve di bezier.
114
gestione attributi testo: cerca e imposta gli attributi del testo (font family, font size,
x, y, dx, dy, ecc.)
predef: gestisce le figure predefinite (rect, ellipse, circle, polygon e polyline), considerando i valori di posizionamento (x, y, width, height, ecc.), le conversioni e
i colori (fill e stroke).
gestione roundrect: roundrect viene gestito come un path: si impostano i vari parametri del path e si chiama la funzione per visualizzare il path.
visualizza path: gli viene passato un path (un array multidimensionale con tutti i
comandi del path e i rispettivi valori).
• ogni comando viene tradotto in una serie di punti che poi verranno visualizzati come linee congiunte. Quando nel path si incontra un comando di
inizio nuovo path (M) o si arriva alla fine del path si chiama una funzione
che visualizza il segmento di path fin qui considerato.
• alcuni path vengono approssimati (solo quelli relativi ad arc).
• per le curve si calcolano i punti con le funzioni di bezier.
visualizza segmento path: gli viene passato un path, inteso come semplice array di
punti, e viene visualizzato (in base ai parametri di stroke e fill). Anche qui è
presente la gestione degli angoli.
4.3.4 Traduzione da VML a GIF
Anche questa traduzione è stata realizzata mediante l’utilizzo di uno script PHP a cui
viene passato l’url del file VML e visualizza il GIF creato (vml2gif.php). Di seguito
viene specificato il funzionamento del programma principale e delle varie funzioni
utilizzate.
MAIN PROGRAM
Viene copiato il file passato in input in un file temporaneo (in modo da poterlo modificare) e si scorre interamente più volte.
115
prima scansione: si modifica il file in modo da ottenere un tag per ogni riga, questo
per semplificare la gestione successiva. Si tolgono i tag inutili (dichiarazioni
iniziali e commenti su una riga). Viene impostato il namespace dei tag VML (v)
e si inserisce un namespace (x) a tutti gli altri tag (elementi HTML).
seconda scansione: vengono gestiti i colori: si cercano tutti i colori che saranno
utilizzati nel documento in modo da poterli allocare.
Una volta impostato il nuovo file, si inizializzano alcune variabili globali (con i
valori di default) ed eventuali pile.
Successivamente viene eseguito un ciclo per scorrere tutto il file:
• se viene trovato un commento si tralascia;
• se viene trovato un elemento shapetype lo si inserisce (ogni riga) nell’array
contenuto shapetype;
• quando viene incontrato il primo elemento di VML, si cercano gli attributi di
dimensionamento e si crea l’immagine GIF;
• per ogni riga del file viene invocata la funzione gestione file.
Arrivati alla fine del file si visualizza l’immagine GIF creata.
FUNZIONI
In questa sezione vengono descritte tutte le funzioni utilizzate per la creazione dell’immagine GIF. Tramite la funzione gestione file si gestisce tutta la struttura del
documento VML, utilizzando alcune funzioni di libreria descritte successivamente.
gestione file: vengono gestiti gli aspetti di seguito riportati.
1. Livelli: vengono gestiti i livelli, incrementando la variabile livello per ogni tag aperto e decrementandola ad ogni tag chiuso ed eventualmente si
svuotano delle pile.
116
2. Variabili perc x, perc y: queste variabili contengono il valore a cui eventuali valori espressi in percentuale si riferiscono.
3. Elemento group: si gestisce quest’elemento, cercando i valori top e left
all’interno dell’attributo style e l’attributo coordorigin per impostare le
traslazioni. Si cercano poi i valori di width e height e coordsize per impostare le pile per il dimensionamento.
4. Figure predefinite: per ogni figura si chiama la funzione predef che imposta i vari parametri della figura. Quando si trova il tag di fine elemento si
procede alla visualizzazione. Questa procedura è necessaria in quanto gli
elementi delle figure possono contenere gli elementi fill e stroke che reimpostano i colori, eventualmente definiti tramite attributi; quindi solo alla
fine dell’elemento si possono sapere i colori da utilizzare.
Nota: roundrect e curve vengono gestiti come se fossero dei path, chiamando l’opportuna funzione.
5. gestione elementi stroke e fill: per questi elementi vengono gestiti gli opportuni attributi. Si controlla se questi elementi sono contenuti all’interno di una figura predefinita o all’interno di shape, impostando (o meglio
sovrascrivendo) le varie proprietà di painting, visto che i valori degli elementi fill e stroke hanno priorità rispetto ai rispettivi attributi (contenuti
negli elementi ancestor).
6. Gestione elemento shape: vengono impostati i valori di default (in un array
multidimensionale), poi si chiama la funzione per la gestione degli attributi
(shape), e si imposta una variabile contenente l’eventuale attributo type.
Una volta giunti alla fine dell’elemento shape, si gestisce l’eventuale riferimento a shapetype. Poi, in base ai vari attributi ed elementi incontrati
(inseriti nell’array), si procede alla visualizzazione di immagini esterne,
path e testi (definiti sia tramite path, sia tramite textbox).
7. Gestione elemento path: per quest’elemento, si controlla se è contenuto all’interno di shape (può essere solo in shape o shapetype). Si chiama la funzione per la sua gestione (path) che inserisce il path nell’ar-
117
ray che mantiene le informazioni su shape, gestendo poi gli altri attributi
(impostazione textboxrect, ecc.).
8. Gestione elemento textpath: anche per quest’elemento si controlla se è
contenuto in shape. Si procede poi alla ricerca e all’impostazione dei valori
riguardanti informazioni sul testo (valore della stringa, font-family, fontsize, ecc.).
9. Gestione elemento textbox: quest’elemento è più complesso da gestire,
in quando può contenere tag HTML. Si suddivide il testo in tante parti
(ogni porzione del testo prima e dopo un tag); per ognuna si impostano i
valori del font e dei colori. Tutte queste informazioni vengono memorizzati
nell’array per la gestione di shape.
10. Gestione elemento imagedata: si ricerca l’url e si memorizza nell’array
shape. L’immagine verrà inserita nella fase di visualizzazione si shape.
11. Gestione elemento image: si preleva l’url e si cerca di creare l’immagine
riferita inserendola nel GIF, opportunamente dimensionata.
Di seguito sono riportate le funzioni di libreria utilizzate dalla funzione principale.
Alcune, essendo identiche nel convertitore da SVG a GIF, sono state semplicemente
elencate.
Funzioni identiche a quelle definite in SVG: carica colori,calcola inverso, converti,
conversione, gestione angoli, bezier3 e cubicbezier.
predef: gestisce le figure predefinite (rect, roundrect, oval, line, polyline, arc, curve
e image). Calcola i valori di dimensionamento (width, height, eventuali punti,
ecc.) e i colori ed imposta i valori nell’array multidimensionale predef.
Nb: non visualizza le figure (a differenza della rispettiva funzione in svg2gif),
imposta solo i parametri.
shape: gestisce l’elemento shape. Anche in questo caso non visualizza la figura
ma imposta i valori dell’array shape. Cerca informazioni di dimensionamento e posizionamento (left, top, width, height, coordorigin e coordsize), gestisce
118
l’eventuale attributo path (chiamando la funzione path) e gestisce i colori (fill e
stroke).
shapetype: svolge un ruolo simile a shape. Questa funzione verrà richiamata tante
volte quanti sono gli elementi shape che si riferiscono a shapetype. Imposta i
valori solo se non sono già stati impostati dal shape che lo ha invocato. Tutto il
contenuto di shapetype dall’inizio dell’elemento alla fine è contenuto in un array (contenuto shapetype), il quale viene considerato completamente. In questa
funzione si impostano esclusivamente i valori della figura che non sono già stati
impostati; eventualmente, se anche in questo elemento non si trovano gli opportuni attributi, si lasciano i valori di default. Ci sono opportuni campi dell’array
shape che segnalano se l’attributo è da aggiornare oppure no (se è affermativo
significa che contiene i valori di default).
path: riceve in input un path (una stringa con nomi di istruzioni e valori) e li suddivide in un array multidimensionale (implementato tramite l’utilizzo di una parte
dell’array shape, in quanto solo shape può contenere dei path).
visualizza path: gestisce il path, traducendo ogni istruzione in un insieme di punti
che verranno utilizzati per rappresentare il path, mediante linee congiunte. Per
ogni comando di inizio path (m o t), fine path (e) o comandi di gestione colore (nf, ns: da questo punto in poi non colorare più l’interno/i bordi del path)
viene visualizzata la porzione di path fin qui considerata, tramite la funzione
visualizza segmento path. I path che rappresentano curve vengono approssimati
tramite le funzioni di bezier. I path vengono tutti rappresentati correttamente
tranne quelli relativi ad archi che vengono approssimati con delle linee.
Molte caratteristiche di SVG e VML non sono state tradotte per la mancanza di funzioni (o opzioni) nella libreria grafica di PHP. Di seguito viene presentata la lista, tutte
le opzioni si riferiscono sia a SVG che a VML:
• collegamenti ipertestuali;
119
• gradienti;
• opacità;
• rotazioni;
• pattern;
• proprietà di stroke: miterlimit, joinstyle, endcap, dashstyle;
• proprietà dei font: font-weight, font-style, text-decoration.
Inoltre non sono state tradotti le seguenti caratteristiche dovute ad un eccessiva
complessità:
• testi inseriti nei path;
• gestione degli archi nei path: approssimati (tuttavia anche nelle trasformazioni
tra SVG e VML vengono rappresentati in maniera approssimata).
Nelle trasformazioni in GIF non sono state tradotte varie caratteristiche dei linguaggi
VML e SVG, specificatamente tutte quelle escluse dalle traduzioni da SVG a VML e
da VML e SVG, indipendentemente dal fatto che fossero realizzabili o meno.
Per maggiori dettagli sugli elementi ed attributi non tradotti si rimanda alle sezioni
4.1.5 e 4.2.6 (caratteristiche non traducibili) e alle sezioni 4.1.6 e 4.2.7 (caratteristiche
non tradotte).
4.4 Da GIF a SVG e VML
Come specificato in precedenza, vedi 3.3, questa trasformazione non rappresenta una
traduzione vera e propria, ma un’inclusione. Infatti, per realizzare le conversioni da
GIF a SVG e da GIF a VML sono stati realizzati due semplici script PHP (gif2svg.php
120
e gif2vml.php) che creano un nuovo documento (SVG o GIF) che include l’immagine esterna passata in input. Quindi più che di traduzione in questo caso si parla di
inclusione.
Capitolo 5
Conclusioni
Lo scopo di questa tesi è quello di realizzare un convertitore tra formati grafici, nello
specifico tra SVG, VML e GIF.
GIF rappresenta un formato grafico di tipo bitmap, in cui l’immagine è rappresentata mediante correlazione tra colori e pixel. Rappresentazioni di questo tipo presentano alcuni svantaggi, in quanto: si perde di qualità con gli ingrandimenti; non sono
leggibili ed editabili e infine hanno delle dimensioni consistenti che ne rallentano il
caricamento.
I formati vettoriali, tra cui SVG (Scalable Vector Graphics) e VML (Vector Markup
Language), risolvono ampiamente questi problemi. Inoltre, data la loro natura di documenti XML, offrono ulteriori benefici, quali l’integrazione con gli altri standard web
(HTML, CSS, ecc.). Possono essere creati dinamicamente senza troppo carico per i
server, eventualmente mediante generazione da documenti XML o prelevando informazioni da un database. Un altro aspetto molto importante riguarda il testo, il quale
rappresenta effettivamente testo: questo permette di effettuarene selezioni e ricerche.
In quest’ambito si inserisce il convertitore realizzato, motivato dal fatto che VML
non è un formato standard (è rimasto una Submission del W3C), quindi è supportato
solo da pochi sistemi e prodotti (Windows con Internet Explorer). Per questo una
conversione in un formato vettoriale standard, quale SVG, o in un formato raster di
121
122
ampia diffusione, come GIF, risulta utile, per permettere l’utilizzo di figure VML in
molteplici piattaforme.
D’altro canto SVG è un formato abbastanza recente (la versione 1.0 è diventata
Recommendation nel Settembre 2001) e non ha ancora avuto un supporto completo:
ci sono solo pochi browser nativi. Altri richiedono opportuni plug-in, i quali non hanno
ancora una versione ottimale. Quindi risulta utile una sua conversione in GIF.
Gli altri convertitori sono stati realizzati principalmente per ragioni di completezza.
Nei capitoli 3 e 4 sono stati descritti i convertitori realizzati, elencandone le caratteristiche tecniche, la loro filosofia, i pregi e i difetti.
Nella traduzione tra SVG e VML (realizzata mediante due fogli di stile XSLT)
si è cercato di mantenere il più possibile la struttura logica del documento sorgente.
Questo non è stato sempre possibile perché i due formati, per rappresentare vari oggetti
grafici, usano una sintassi molto diversa.
Per molti aspetti, la traduzione è stata realizzata mediante un semplice cambio di
nome (di elementi e attributi). Per altri si sono presentate maggiori difficoltà, dovute
per esempio all’ereditarietà dei valori, o ai dati inseriti in stringhe di testo, per cui il
documento creato risulta in parte approssimato. Bisogna inoltre ricordare che non tutte
le caratteristiche dei due formati sono state prese in considerazione, o per scelta, vista
la vastità dei domini, o per la loro presunta intraducibilità.
I convertitori da SVG e VML a GIF sono stati realizzati con script PHP, sfruttando
un’opportuna libreria grafica, e implementano due parser che, per ogni elemento di
SVG (o VML), creano un elemento grafico nell’immagine GIF.
L’utilizzo di PHP porta alcuni benefici alla gestione dei documenti, come l’estrazione di sottostringhe, ma d’altro canto presenta alcune limitazioni, come la mancate
definizione dell’opacità (trasparenza) e della dimensione dei bordi. Per questo e per altri motivi (l’elevante complessità), alcune caratteristiche sono risultate approssimate,
mentre altre non sono state convertite. Inoltre, è stato deciso di non considerare le
caratteristiche non tradotte nel convertitore tra SVG e VML.
Capitolo 5. Conclusioni
123
Infine l’ultima conversione, da GIF a SVG e VML, è stata realizzata per completezza mediante una semplice inclusione di immagini.
Quella realizzata rappresenta una prima versione del convertitore, nel quale molti
aspetti dei due linguaggi non sono stati considerati.
Eventuali sviluppi di questi convertitori potrebbero seguire una duplice direzione.
Innanzi tutto si potrebbe migliorare la gestione, attualmente approssimata, di alcuni elementi. Esempi di questi elementi sono dati dai path, dei quali è gestita correttamente
la maggior parte dei comandi, mentre altri (in special modo gli archi) sono rappresentati medianti semplici linee rette. Un altro esempio è dato dai testi, i quali, dato l’alto
numero di opzioni disponibili, sono stati gestiti in maniera limitata e semplificata.
Inoltre si potrebbe iniziare a convertire le caratteristiche non tradotte. Tra queste
quelle di maggior rilievo sono i filtri (particolari effetti grafici, che comprendono le
ombreggiature) e le animazioni, le quali richiedono integrazione di VML con linguaggi
di scripting.
Un ulteriore sviluppo può essere la conversione in altri formati raster, quali JPEG
e PNG.
124
Bibliografia
[AAC98] Nabeel Al-Shamma, Robert Ayers, Richard Cohn, et. al., Precision Graphics Markup Language (PGML), Submission to the W3C, 10 Aprile 1998,
http://www.w3.org/TR/1998/NOTE-PGML-19980410.
[Ado01] Adobe Systems Incorporated, Using SVG with Adobe Illustrator, 2001,
http://www.adobe.com/svg/indepth/pdfs/illusag.pdf, ultimo accesso: 30 Gennaio
2005.
[Ado05] Adobe Systems Incorporated, Adobe SVG Zone, 2005,
http://www.adobe.com/svg/, ultimo accesso: 31 Gennaio 2005.
[And04] Ola Andersson, SVGT Animation Authoring, in: SVG Open 2004 Conference and Exhibition, 3rd Annual Conference on Scalable Vector Graphics,
Tokyo, Giappone, 7–10 Settembre 2004.
[Asm03] Paul Asman, Creating SVG Pie Charts through XSLT via a Web Service: An
Experience Report, in: SVG Open 2003 Conference and Exhibition, 2nd Annual Conference on Scalable Vector Graphics, Vancouver, Canada, 13–18 Luglio,
2003.
[Bak05] Stig Sæther Bakken, et al., PHP manual: capitolo 6, sezione 46: Image Funct
ions, http://www.php.net/manual/en/ref.image.php, ultimo accesso: 13 Gennaio
2005.
[BGLS03] Andres Baravalle, Marco Gribaudo, Vitaveska Lanfranchi, Tiziana Sandri, Using SVG and XSLT for graphic representation, in: SVG Open 2003 Con125
126
ference and Exhibition, 2nd Annual Conference on Scalable Vector Graphics,
Vancouver, Canada, 13–18 Luglio, 2003.
[BosWiu99] Bert Bos, Håkon Wium Lie, Cascading Style Sheets, level 1, W3C
Recommendation, 11 Gennaio 1999, http://www.w3.org/TR/REC-CSS1.
[BPSMY04] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François
Yergeau, Extensible Markup Language (XML) 1.0 (Third Edition), W3C
Recommendation, 4 Febraio 2004, http://www.w3.org/TR/REC-xml.
[BuiZim04] Rob Buis, Nikolas Zimmermann, et. al., KSVG: freedom for veKtors,
2004, http://svg.kde.org/, ultimo accesso: 28 Gennaio 2005.
[BWLJ98] Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Cascading Style Sheets, level 2, W3C Recommendation, 12 Maggio 1998,
http://www.w3.org/TR/REC-CSS2.
[ByrLys04] Antoniou Byron, Tsoulos Lysandros, Converting raster images to XML
and SVG , in: SVG Open 2004 Conference and Exhibition, 3rd Annual
Conference on Scalable Vector Graphics, Tokyo, Giappone, 7–10 Settembre
2004.
[Cap03] Tolga Capin (editor), Mobile SVG Profiles: SVG Tiny and SVG Basic , W3C
Recommendation, 14 Gennaio 2003, http://www.w3.org/TR/SVGMobile/.
[Cla99] James Clark (editor), XSL Transformations (XSLT) Version 1.0, W3C
Recommendation, 16 Novembre 1999, http://www.w3.org/TR/xslt.
[Cor03] Corel Corporation, Corel SVG Viewer, 2003,
http://www.smartgraphics.com/Viewer prod info.shtml, ultimo accesso:
28
Gennaio 2005.
[Csi02] Csiro, Csiro SVG Toolkit, 12 Marzo 2002, http://sis.cmis.csiro.au/svg/, ultimo
accesso: 31 Gennaio 2005.
BIBLIOGRAFIA
127
[Dan03] Alex Danilo (editor), SVG Print, W3C Working Draft, 15 Luglio 2003,
http://www.w3.org/TR/SVGPrint/.
[DewHar02] Thomas Deweese, Vincent Hardy, Introduction to the Batik project, in:
SVG Open 2002 Developers Conference, 1st Annual Conference on Scalable
Vector Graphics, Zurigo, Svizzera, 15–17 Luglio 2002.
[Edw02] ElShaddai Edwards, Introduction to Jasc WebDraw, in: SVG Open 2002
Developers Conference, 1st Annual Conference on Scalable Vector Graphics,
Zurigo, Svizzera, 15–17 Luglio 2002.
[Fer01] Jon Ferraiolo (editor), Scalable Vector Graphics (SVG) 1.0 Specification,
W3C Recommendation, 4 Settembre 2001, http://www.w3.org/TR/2001/RECSVG-20010904/.
[FerJunJac03] Jon Ferraiolo, Fujisawa Jun, Dean Jackson (editors), Scalable Vector
Graphics (SVG) 1.1 Specification, W3C Recommendation, 14 Gennaio 2003,
http://www.w3.org/Graphics/SVG.
[FroHar02] Max Froumentin, Vincent Hardy, Using XSLT and SVG together: a survey of case studies, in: SVG Open 2002 Developers Conference, 1st Annual
Conference on Scalable Vector Graphics, Zurigo, Svizzera, 15–17 Luglio 2002.
[GebGal00] John C. Gebhardt, Greg Gallant, Strategies for effective use of intelligent
graphics in Web applications, XML Europe 2000, Parigi, Giugno 2000.
[Gus05] Niklas Gustavsson, et. al., SVG.org, http://svg.org/, ultimo accesso: 10
Febbraio 2005.
[Har04] Elliotte Rusty Harold, The Vector Markup Language, in: XML Bible, Foster
City, CA, IDG Books Worldwide Inc., 1999, pgg 805–831.
[HauWen04] Tobias Hauser, Christian Wenz, SVG Editors: A Survey about the Market
of native SVG Editors, in: SVG Open 2004 Conference and Exhibition, 3rd Annual Conference on Scalable Vector Graphics, Tokyo, Giappone, 7–10 Settembre
2004.
128
[HUNW04] Georg Held, Torsten Ullrich, Andreas Neumann, André M. Winter, Comparing .SWF (ShockWave Flash) and .SVG (Scalable Vector
Graphics) file format specifications , Cartographic Perspectives, 29 Marzo
2004, http://www.carto.net/papers/svg/comparison flash svg/, ultimo accesso: 2
Febbraio 2005.
[Jac04] Dean Jackson (editor), Scalable Vector Graphics (SVG) 1.2, W3C Working
Draft, 27 Ottobre 2004, http://www.w3.org/TR/SVG12/.
[JBMOW03] Benjamin Jung, Jamie Brohan, Richard Maher, Laura O’Shea, Vincent
Wade, Stirring XML: Visualisations in SVG, in: SVG Open 2003 Conference
and Exhibition, 2nd Annual Conference on Scalable Vector Graphics, Vancouver,
Canada, 13–18 Luglio, 2003.
[Jol03] Christophe Jolif, Comparison between XML to SVG Transformation Mechanisms - The GraphML use case, in: SVG Open 2003 Conference and Exhibition,
2nd Annual Conference on Scalable Vector Graphics, Vancouver, Canada, 13–18
Luglio, 2003.
[Kap03] Lauris Kaplinski, Sodipodi - open source native SVG editor for Linux
and Windows , in: SVG Open 2003 Conference and Exhibition, 2nd Annual
Conference on Scalable Vector Graphics, Vancouver, Canada, 13–18 Luglio,
2003.
[KKS04] KK-Software, KVEC - raster to vector, versione 3.20, 9 Gennaio 2005,
http://www.kvec.de/, ultimo accesso: 31 Gennaio 2005.
[Kor02] Thierry Kormann, Developing SVG Applications with Batik, in: SVG
Open 2002 Developers Conference, 1st Annual Conference on Scalable Vector
Graphics, Zurigo, Svizzera, 15–17 Luglio 2002.
[Man02] Philip A. Mansfield, Common graphical object models and how to translate them to SVG, in: SVG Open 2002 Developers Conference, 1st Annual
Conference on Scalable Vector Graphics, Zurigo, Svizzera, 15–17 Luglio 2002.
BIBLIOGRAFIA
129
[ManFul01] Philip A. Mansfield, Darryl W. Fuller, Graphical Stylesheets - Using
XSLT to generate SVG, in: XML Conference and Exposition 2001, 9–14
Dicembre 2001, Walt Disney World Dolphin Hotel, Orlando, Florida, USA.
[MatLeeDis98] Brian Mathews,
Daniel Lee,
Brian Dister,
et al.,
Vector
Markup Language (VML), Submission to the W3C, 13 Maggio 1998,
http://www.w3.org/TR/1998/NOTE-VML-19980513.
[McKGri00] John McKeown, Jane Grimson, SVG: putting XML in the picture, XML
Europe 2000, Parigi, Giugno 2000.
[Mic98a] Microsoft Corporation, Introduction to Vector Markup Language (VML),
16 Novembre 1998,
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/vml/default.asp,
ultimo accesso: 26 Gennaio 2005.
[Mic98b] Microsoft Corporation, Microsoft VML Generator Version 1.0, 1998,
http://msdn.microsoft.com/downloads/samples/internet/vml/vmlgenerator/default.asp,
[Mor04] Brendan J. Morley, A Public Transport Mapping Example Using perl and
mySQL, in: SVG Open 2004 Conference and Exhibition, 3rd Annual Conference
on Scalable Vector Graphics, Tokyo, Giappone, 7–10 Settembre 2004.
[Moz05] The
Mozilla
Organization,
Mozilla
SVG
Project,
2005,
http://www.mozilla.org/projects/svg/, ultimo accesso: 29 Gennaio 2005.
[NeuWin01] Andreas Neumann, Andréas M. Winter, Time for SVG - Towards
high quality interactive Web-Maps, in: Proceedings of the 20th Internationals
Cartographic Congress, Beijing, 2001.
[Php02] phpBB Group, 2001, 2002, SVG Cafe - The Scalable Vector Graphics
Community, http://www.svg-cafe.com/, ultimo accesso: 10 Febbraio 2005.
130
[PMEB01] Steve Probets, Julius Mong, David Evans, David Brailsford, Vector
Graphics: From PostScriptand Flash to SVG, DocEnd, 9-10 Novembre 2001,
Atlanta, Georgia, USA.
[Sia03a] Siame Editions, CR2V - Celinea Raster to Vector converter, 12 Marzo 2003,
http://www.celinea.com/, ultimo accesso: 31 Gennaio 2005.
[Sia03b] Siame Editions, Vector Eye 2.0, Dicembre 2003, http://www.siame.com/,
[Sof02] Software Mechanics , VMLmaker, versione 1.10, 17 Giugno 2002,
http://www.vmlmaker.com/, ultimo accesso: 30 Gennaio 2005.
[Sof04] Software Mechanics, SVGmaker - The SVG Printer Driver, versione 2.01, 18
Novembre 2004, http://www.svgmaker.com/, ultimo accesso: 30 Gennaio 2005.
[Svg05] SVG Open 2005 Conference and Exhibition, http://wiki.svg.org/, ultimo
accesso: 10 Febbraio 2005.
[SVKHKP05] R.G. Steltenpool, S.J. van Tongeren, B.J. Köbben, D.K.J. Heylen, J.W.
Koolwaaij, R. Poortinga, organizzatori, SVG Open 2005 Conference and Exhibition, 4th Annual Conference on Scalable Vector Graphics, Enschede, Paesi Bassi,
15–19 Agosto 2005, http://www.svgopen.org/2005/, ultimo accesso: 2 Febbraio
2005.
[Vat04] Irène Vatton, et. al., Amaya User Manual, Ottobre 2004,
http://www.w3.org/Amaya/User/Manual.html, ultimo accesso: 30 Gennaio 2005.
[Vat05] Irène Vatton, Amaya Overview, 2005,
http://www.w3.org/Amaya/Amaya.html, ultimo accesso: 30 Gennaio 2005.
[Woo98] Lauren Wood (WG Chair), Document Object Model (DOM) Level 1, W3C
Recommendation, 1 Ottobre 1998, http://www.w3.org/TR/REC-DOM-Level-1.
[Zas00] Ilya Zaslavsky, A New Technology for Interactive Online Mapping with Vector
Markup and XML, Cartographic Perspectives, # 37 (Fall 2000), pp. 65–77.

ai miei genitori, ai miei nonni e ad Andy K.

Transcript

Documenti analoghi

Memoria

Roberto Fuso Nerini Esperto in Marketing e Comunicazione con una

Vettori, avanti tutta! - Linux Day

Stazione di Vercelli

Dati biografici Nome Alessandro Zanardi Nazionalità Italia Italia

lezione 29-05-13

Progetto Metro GTT linea 1

Yersinia pestis

Capitolo 7 – La traduzione automatica dei testi

Umberto Eco - source url