aimieigenitori,aimieinonnieadandyk. -...

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

Indice

1 Introduzione 1

2 Contesto: what the world needs now... 112.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

2.3 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

2.3.4 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

2.6 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

iii

iv

3 Descrizione ad alto livello: analyze this 413.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

3.1.5 Da VML a SVG . . . . . . . . . . . . . . . . . . . . . . . . 59

Conversione di base . . . . . . . . . . . . . . . . . . . . . . 59

Punti “sottili” . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Problemi e limiti . . . . . . . . . . . . . . . . . . . . . . . . 66

3.2 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

3.3 Conversione da GIF a SVG e VML . . . . . . . . . . . . . . . . . . . 76

4 Descrizione a basso livello: into the code 774.1 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 v

4.2 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.3 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.4 Da GIF a SVG e VML . . . . . . . . . . . . . . . . . . . . . . . . . 117

5 Conclusioni 119

Bibliografia 123

Capitolo 1

Introduzione

Con questa tesi si e voluto realizzare un convertitore che permetta di tradurre docu-

menti 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 vetto-

riale.

VML, Vector Markup Language [MatLeeDis98], e anch’esso un linguaggio, pro-

posto al W3C, per rappresentare figure bidimensionali in grafica vettoriale, basato su

XML.

GIF, Graphic Interchange Format, e un formato raster, cioe rappresenta un’imma-

gine 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 rap-

presentazione 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 con-

siderazione per la traduzione, e diventata una Recommendation il 14 Gennaio 2003.

In seguito sono stati sviluppati dei profili per la rappresentazione di immagini su dis-

positivi 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 (Casca-

ding 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 op-

portuni 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. Es-

sendo 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 docu-

mento 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 for-

mato. 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 documen-

to 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 ob-

ject, 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 scri-

vere documenti tramite un semplice editor. Ovviamente non e spesso conveniente,

specie per disegni complessi. Sono disponibili numerosi applicativi per ottenere ot-

time immagini SVG, in una maniera semplice e potente, tramite interfacce WYSI-

WYG. 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 del-

l’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 Macro-

media al W3C, nel 1998. E usato per includere immagini all’interno di documen-

ti 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 de-

finite 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 propos-

to 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


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, permetten-

do 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 ne-

cessita 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 dimen-

sioni effettive;

• sono sostanzialmente indipendenti dal sistema, possono essere quindi visualiz-

zato 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 ingranden-

dola, 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 del-

l’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 grup-

pi 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 ot-

tenere 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; inol-

tre una volta generate, queste si adattano alle varie esigenze (risoluzione,

ecc.), mentre le figure bitmap devono essere rigenerate per ogni esigenza

dimensionale.


• editabilita semplificata: e possibile modificare l’immagine mediante un sem-

plice text editor e senza particolari conoscenze; le modifiche sono inoltre molto

piu semplici da effettuare: ad esempio per cambiare la dimensione di un quadra-

to 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 effettiva-

mente 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 rap-

presentazioni 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 iper-

testuali 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.


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 realiz-

zati. 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 caratteri-

stiche 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 coe-

renza supportando le stesse caratteristiche in ogni convertitore.

Come accennato in precedenza e stata realizzata un’ultima applicazione per pas-

sare 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 con-

vertitore 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.

Capitolo 2

Contesto: what the world needs now...

In questo capitolo verra fatta una panoramica sull’uso delle immagini nel Web e sul-

la 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, veni-

vano combinati linguaggi di markup testuali (HTML prima, XML poi), con immagini

raster, cioe immagini rappresentate mediante una matrice che associa i colori ai rispet-

tivi 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 stan-

dard 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, adat-

tandosi alle esigenze dell’utente e consentendo un effettivo risparmio di bandwidth.

Essendo in formato XML, tutto il disegno e rappresentato in maniera testuale, quin-

di facilmente indicizzabile, eventualmente anche da motori di ricerca. Inoltre va sot-

tolineato 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].

1W3C: World Wide Web Consortium, il consorzio fondato da Tim Berners-Lee al fine di “sviluppareprotocolli 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], pen-

sate 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 re-

strizioni;

• SVG Basic: realizzato per palmari (PDA).

Ogni profilo contiene una serie di moduli, e per ognuno specifica il grado di com-

pletezza (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 Otto-

bre 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 ingrandi-

menti.

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"

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 (rettan-

goli, ellissi, ecc.) il cui utilizzo e molto semplice, come si evince dall’esempio: bas-

ta 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 (ele-

mento 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 in-

formazioni 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-


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 in-

clusi in un contenitore, per rappresentare le varie figure. Sono tuttavia presenti al-

cuni elementi contenitori (shape e group) che permettono di raggruppare varie figure

definendo un nuovo sistema di coordinate, specificandone dimensioni (tramite le pro-

prieta 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 mostra-

ta 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">


<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 fi-

gure, 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 generi-

ca. Presenta una serie di attributi per specificare il posizionamento e il dimensionamen-

to, 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 re-

lazione ai tool che li supportano, alla struttura dei documenti e al tipo di figure realiz-

zabili.

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 strut-

turalmente 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 specifi-

cate 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 gra-

dienti o filtri, definibili separatamente e richiamati tramite riferimento. Anche i testi

sono definiti tramite un semplice elemento che ne specifica le caratteristiche ed il con-

tenuto. 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-


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 visua-

lizzazione 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’elemen-

to 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 al-

tre 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 esis-

tono attributi specifici per realizzare trasformazioni, si realizzano o tramite proprieta

CSS (rotation) o dimensionando opportunamente gli altri attributi. Inoltre sono presen-

ti 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 stan-

no 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 presen-

ta 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 mate-

matiche 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 addirit-

tura 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 rappresen-

ta 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’in-

tenzione 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.


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, specifi-

cando 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 name-

space 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 per-

mettono 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 ver-

sione 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 presen-

ta 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 brow-

ser, 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 anco-

ra esclusi, specialmente l’integrazione con altre tecnologie; per ulteriori informazioni


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 comple-

tamente la gestione delle animazioni e degli effetti grafici, ed e presente una ges-

tione 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 Bezier, con-

sistenti 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 esi-

guo 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 ap-

positi strumenti di disegno di questi programmi; quindi Office non rappresen-

ta 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 mer-

cato 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 attribu-

ti, 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.


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 pre-

sentata 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 visualiz-

zare pagine web sia per crearle. Inizialmente supportava HTML e CSS, in segui-

to 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 WYSI-

WYG, 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 ges-

tione delle curve di Bezier. D’altra parte la versione attuale presenta delle limi-


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 for-

mati, riguardanti SVG, per VML il numero e molto piu esiguo. Queste applicazioni

permettono per esempio di trasformare documenti PDF o SWF in formato SVG. Tut-

tavia si e preferito privilegiare la descrizione di programmi che traducono formati

grafici.

In questa sezione saranno presentati alcuni tra i principali convertitori per conver-

tire immagini raster in grafica vettoriale e viceversa; la maggior parte si riferisce esclu-

sivamente al formato SVG. Oltre a questi sono presentati due applicativi per ottenere

documenti SVG o VML da qualsiasi input.

SVGMAKER e VMLMAKER

Questi due programmi [Sof04] [Sof02], realizzati da Software Mechanics, rappresen-

tano delle stampanti virtuali.

32

Sono realizzati esclusivamente per sistemi Windows (dal 95) e consento di conver-

tire 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 e-

sempio 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 SVGma-

ker 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 com-

pletamente tramite path, i quali sono molto precisi, e “a differenza di altri program-


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’im-

magine 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 program-

ma 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 e-

sclusivamente 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 mo-

duli 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).

ARCHITETTURA

Batik si struttura in tre moduli:

• Applications: illustra le funzionalita che Batik offre;

• Core: contiene i moduli per manipolare, generare, creare, convertire e visualiz-

zare 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:


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.

ESEMPI 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 con-

vertire 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 ap-

plicazioni 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 va-

lori 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 ap-

plicazioni in ambito scientifico di SVG. Tramite alcuni dispositivi vengono re-

cuperate informazioni, in tempo reale (per esempio riguardo alla meteorolo-

gia) 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].


• 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 tem-

pi di attesa per generare le mappe dal server;

– ogni mappa veniva generata in base alle esigenze degli utenti, non permet-

tendo 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 on-

the-fly, permettendone l’utilizzo simultaneo. Inoltre, con SVG, e possibile ef-

fettuare 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 grafica-

mente informazioni testuali. Ad esempio in [JBMOW03] viene mostrato come

convertire i seguenti formati:

– MusicXML: formato XML per rappresentare musica (definizione di spar-

titi);

– BioML: descrive informazioni biomolecolari (rappresentazioni del dna);

38

– CALCS: formato per memorizzare informazioni su acquisti, da cui si pos-

sono 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 ani-

mazioni 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 conver-

tire 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’eve-

nienza;

• 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-


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 manua-

le piu agevole;

• alcuni applicativi di Office 2000 (Word, Excel, PowerPoint), permettono di “sal-

vare” 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 ges-

tione di questo tipo; la limitazione piu forte riguarda la mancanza di un coman-

do 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 univer-

salmente accettato, sia dalle applicazioni grafiche sia dai web browser. Come e stato

specificato in precedenza ha dalla sua molti svantaggi (non scalabile, dimensione con-

sistente, 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 conver-

sioni 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.


In conclusione si puo affermare che una conversione dal formato VML e neces-

saria 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 comple-

tamente altre, ottenibili in future versioni. Nel capitolo successivo verranno descritte

piu nel dettaglio le conversioni realizzate.

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, realiz-

zata in PHP tramite una semplice inclusione di immagini.

In questo capitolo verranno descritte le traduzioni realizzate specificando gli stru-

menti 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]. Tut-

tavia, 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 rappre-

sentare 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 strut-

tura 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. Tut-

tavia 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 parti-

colarita di un dato linguaggio e quindi si perdono molte possibili ottimizzazioni. Per

esempio SVG e VML hanno varie caratteristiche rappresentate mediante la stessa sin-

tassi, 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 tras-

formare documenti XML in altri documenti XML, la versione 1.0 e una Recommen-

dation 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 ricor-

sione, 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’op-

portuna 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 sem-

plificato, 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 po-

sizionare 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 se-

condo; 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.

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 “problema-

tici” ed elencando le principali limitazioni di questo traduttore. Ricordiamo che questa

conversione e stata realizzata mediante un foglio di stile XSLT (svg2vml.xsl).

CONVERSIONE 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 sis-

tema di coordinate usato per posizionare le figure. Da questo viene creato un documen-

to 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 ele-

mento 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 pro-

prieta, in quanto le ereditano, mentre in VML bisogna impostarle (e il caso per esem-

pio dei gruppi). Per gestire queste situazioni, bisogna scorrere l’albero del documento

dall’elemento corrente, all’indietro, cercando le opportune proprieta negli elementi

precedenti.

PUNTI “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


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 coordi-

nate utilizzato.

3. se all’interno di un elemento contenitore che definisce un sistema di co-

ordinate, 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 sis-

tema 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 am-

mette 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 caratteris-

tiche 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 del-

l’elemento, si cercano le proprieta all’interno di elementi style, controllan-

done i selettori;

4. per le proprieta mancanti si ripetono i primi tre passi per gli elementi ances-

tor, 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>


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 espressinella forma:

comando valori

in cui comando rappresenta il tipo di percorso (linea retta, curva, arco, ecc.) evalori rappresentano i punti o i parametri per disegnare la linea. Sfortunatamentei due formati utilizzano una sintassi diversa (diverso nome del comando o diversagestione dei valori) e dal momento che sono memorizzati in un attributo, cioe inuna stringa di testo, la loro estrazione e traduzione risulta piuttosto difficile e nonsempre realizzabile. Comunque sono stati tradotti il maggior numero possibiledi 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 tracciatauna linea, con C, una curva di Bezier, con S, viene tracciata una seconda curvabasandosi sui valori della prima curva. I primi tre comandi hanno una corrispon-denza in VML, S no. Per tradurre quest’ultimo comando si dovrebbero prendereil terzultimo e quartultimo valore della curva precedente (se e presente una cur-va precedente); vista la complessita di queste estrazioni, oltre al fatto che non sipuo sapere a priori se il comando S segue il comando C, la gestione viene ap-prossimata, prendendo gli ultimi due valori del comando precedente. Il risultatodella 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 puocontentere altri elementi (tspan, tref, textPath) per rappresentare e posizionare inmodo 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


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’ap-

plicazione 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 trasfor-

mazioni quali traslazioni, rotazioni o cambiamenti di scala. In VML non e pre-

sente 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, impo-

stando 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 ri-

chiamare 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’elemen-

to 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.


ESEMPI

Sono presentati due esempi che mostrano sia le potenzialita, sia alcuni limiti del con-

vertitore.

Il primo esempio (figura 3.3 e conversione in figura 3.4) mostra trasformazioni

(rotazione dei rettangoli e ridimensionamento delle stelle), gestione dei gradienti, sfu-

mature (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 nu-

merosi 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

58

PROBLEMI 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 ogget-

ti grafici; tuttavia, in alcuni casi, utilizzano una sintassi molto diversa, rendendo la

traduzione non sempre possibile. In questi casi sono state ottenute delle approssi-

mazioni. 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 pro-

prieta, che pur rappresentando la stessa funzione, vengono gestite in maniera

diversa. Di seguito sono elencati i principali aspetti dei testi gestiti con approssi-

mazioni:

• 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


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 conver-

titore, 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 imma-

gine 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, op-

pure 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).


3.1.5 Da VML a SVG

In questa sezione verra illustrata la conversione da VML a SVG, spiegandone breve-

mente il funzionamento e soffermandosi sulle diversita rispetto all’inversa. Verranno

descritti alcuni punti sottili, riguardo la traduzione di varie caratteristiche; si mostre-

ranno un paio di esempi, per illustrare la potenzialita ed alcune limitazioni del tradut-

tore e verranno descritte le caratteristiche non tradotte perfettamente (dal punto di vista

visivo).

CONVERSIONE 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 raggrup-

pare 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 tradu-

zione 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 fonda-

mentale poiche contiene tutte le proprieta di posizionamento e dimensionamento. In

SVG le stesse proprieta sono definite tramite un opportuno attributo; quindi per rea-

lizzare la conversioni, si devono estrarre tutte le proprieta contenute in style e inserirle

nei corrispondenti attributi.

PUNTI “SOTTILI”

In questa sezione vengono presentate le principali caratteristiche di VML che richie-

dono 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 on-

the-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 vienecreato 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:


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 presen-

ta 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 carat-

teristiche direttamente nell’elemento opprotuno (tramite attributi). Per gestire

queste situazioni, la prima operazione, dopo aver creato l’elemento svg conteni-

tore, 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.


ESEMPI

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) an-

ch’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

68

PROBLEMI E LIMITI

La conversione tra VML e SVG non e risultata completa ed esaustiva, in quanto: al-

cune caratteristiche non sono state tradotte, altre non sono state tradotte correttamente

ma solo approssimate ed altre ancora appaiono intraducibili. Di seguito vengono pre-

sentati i principali aspetti che rientrano in queste categorie.

Alcune caratteristiche di VML presentano una gestione diversa rispetto alle cor-

rispondenti 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 comples-

sita 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 caratte-

ristiche 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:


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 descrit-

to 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, uti-

lizzando un’opportuna libreria grafica, contenente funzioni di gestione di immagini.

Tramite queste funzioni e possibile creare un’immagine GIF, specificandone le dimen-

sioni, inizialmente vuota (bianca) e in seguito inserirci oggetti grafici (figure, testi

o altre immagini raster). La parte piu complessa riguarda la gestione della dimen-

sione 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


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 del-

l’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 prece-

denti. 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 control-

la 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 speci-

ficare 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 specifi-

carne 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 rag-

gruppamento, quindi si impostano i valori di dimensionamento e posizionamen-

to 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 richia-

mare successivamente nel documento, shape la richiama ridefinendone eventual-

mente delle caratteristiche.


La gestione e simile a quella precedente (il contenuto di shapetype viene man-

tenuto 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 strut-

tura, 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 al-

la 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 sec-

ondo 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 corretta-

mente. 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 conver-

sione 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

76

Figura 3.13: Esempio VML

Figura 3.14: Conversione in GIF della figura 3.13


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 rap-

presentazione 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 com-

plesse 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’im-

magine 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 thecode

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’uti-

lizzo, 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 presen-

tate 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 per-

metta, 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 coord-

origin 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 co-

ordinate usato (definito tramite l’attributo viewBox). Cioe, se abbiamo, per esem-

pio, un rettangolo di 400x400 e viewBox definisce le dimensioni con 400x200, senza

PreserveAspectRatio (o meglio, impostato a none) il rettangolo risultera schiaccia-

to; 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 tra-

ducibile) e la possibilita di fare clipping (anch’essa non traducibile).

g

Quest’elemento rappresenta un contenitore di figure. La traduzione in VML e ab-

bastanza 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’ele-

mento 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 ef-

fettuare 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’ele-

mento, 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.


image

Inserisce un’immagine esterna in un rettangolo definito dai suoi attributi. Per la tradu-

zione 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. Proble-

mi 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’ at-

tributo 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’in-

terno 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 va-

lori 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 fonda-

mentale 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 ope-

razione (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-di-

valori”, 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 pre-

sente). 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.


La traduzione e stata effettuata per il maggior numero possibile di operazioni, al-

cune sono tradotte correttamente (effettuando vari aggiustamenti), altre invece ven-

gono 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 Descrizione TraduzioneM move to (assoluto) corretta (M)m move to (relativo) corretta (t)Z, z close path corretta (x)L line to (assoluto) corretta (L)l line to (relativo) corretta (r)H horizontal line to (assoluto) corretta (L)h horizontal line to (relativo) corretta (r)V vertical line to (assoluto) corretta (L)v vertical line to (relativo) corretta (r)C curve to (assoluto) corretta (C)c curve to (relativo) corretta (v)S smooth curve to (assoluto) approssimata (C)s smooth curve to (relativo) approssimata (v)Q quadratic Bezier curve to (assoluto) approssimata (qb)q quadratic Bezier curve to (relativo) approssimata (r)T smooth quadratic Bezier curveto (assoluto) approssimata (L)t smooth quadratic Bezier curveto (relativo) approssimata (r)A elliptical arc (assoluto) approssimata (L)a elliptical arc (relativo) 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 es-

trazioni 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 uti-

lizza 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 conver-

sione. 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 differen-

ze: 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.


4.1.2 Testi (elementi text, tspan, tref e textpath)

Questi elementi servono per scrivere del testo con vari effetti grafici. Qui appare evi-

dente 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 posizionamen-

to. 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 no-

mi; alcuni attributi non sono proprio gestiti da VML (font-stretch), altri rivelano prob-

lemi 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 va-

lore, 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 (sottoli-

neature, 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 di-

mensione 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,


quindi la traduzione viene effettuata creando un gruppo per ogni operazione di trasfor-

mazione, 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 ro-

tation, 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 per-

mette 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 ven-

gono 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 pro-

porzionatamente. 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 an-

cestor. 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 di-

mensioni 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-


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 dimen-

sione 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’in-

terno 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 proprieta 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, feCompo-

nentTransfer, feComposite, feConvolveMatrix, feDiffuseLighting, feDisplacementMap,

feDistantLight, feFlood, feFuncA, feFuncB, feFuncG, feFuncR, feGaussianBlur, feIma-

ge, feMerge, feMergeNode, feMorphology, feOffset, fePointLight, feSpecularLight-

ing, feSpotLight, feTile, feTurbulence.

Elemento script

Non supportato.


Animazioni (elemento animate ed elementi associati)

Non supportate. Elenco completo degli elementi: animate, animateColor, animateMo-

tion, 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 converti-

tore.

Elemento marker

Quest’elemento inserisce delle figure (definite tramite path) nei vertici di alcuni ele-

menti (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.


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 partico-

lari (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 raggruppa-

to all’interno di uno o piu tag svg, mentre VML non ha un tag contenitore obbli-

gatorio, 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 verraebbe visualizzato).

• Il secondo motivo riguarda l’uso dell’elemento defs. Quest’elemento (di SVG)

rappresenta un contenitore che contiene tutti quegli elementi che saranno richia-

mati piu volte nel documento (il suo contenuto non viene visualizzato diretta-

mente, 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 proba-

bilmente 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 elemen-

to. 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; nel-

l’elemento g di SVG invece attributi di posizionamento/dimensionamento non sono

ammessi.

Inoltre group puo contenere gli attributi coordorigin e coordsize per ridimensio-

nare 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 an-

ch’esso un path. La differenza tra l’utilizzo dei due e che l’elemento path permette di

definire piu caratteristiche.


La traduzione e abbastanza naturale: si utilizza l’elemento path di SVG che pre-

senta 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 Descrizione Traduzionem move to (assoluto) corretta (M)t move to (relativo) corretta (m)l line to (assoluto) corretta (L)r line to (relativo) corretta (l)c curve to (assoluto) corretta (C)v curve to (relativo) corretta (c)x close path corretta (Z)e end path corretta ( )ae angle ellipse to approssimata (L)al angle ellipse approssimata (M)at arc to approssimata (l+l+l+l+l)ar arc approssimata (m+l+l+l+l)wa clockwise arc to approssimata (l+l+l+l+l)wr clockwise arc approssimata (m+l+l+l+l)qx elliptical qaudrant x approssimata (Q)qy elliptical qaudrant y approssimata (Q)nf no fill non supportatans no stroke 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 riempimentoe del bordo delle figure (oltre all’utilizzo dei semplici attributi fill e stroke). In presenzasia 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 preceden-

za (nell’esempio il rettangolo viene riempito di rosso). In SVG ci sono solo gli attributi

fill e stroke.


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 in-

serire 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 an-

ch’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 in-

serire 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’in-

terno 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 fonda-

mentali, 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.


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 al-

cune 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 im-

magini. 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 an-

ch’esso rappresentato con un elemento svg: nel caso si riferisca ad uno

102

shapetype, si utilizza l’elemento use per effettuare il riferimento (use per-

mette di richiamare un elemento definito all’interno di defs).

– Problema: quando sia shape che shapetype definiscono gli stessi elemen-

ti 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 appro-

priatamente 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 esclu-

sivamente 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’in-

terno di un elemento text). Quest’elemento contiene un riferimento ad un

elemento path (che contiene, naturalmente, il path). Il path (visto che e un


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 ele-

menti 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 eventual-

mente 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 gra-

dient o gradientradial, viene creato un elemento linearGradient o radialGra-

dient, 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 sinis-

tra 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 in-

grandire 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.


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 ridimensiona-

menti 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 dimen-

sionamenti, 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 ap-

propriati 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 matemati-

che 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’im-

magine 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, endar-

rowwidth, endarrowlength.

Attributi di imagedata e image: gain, blacklevel, gamma, grayscale, bilevel.


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 imagecoloral-

locate 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 su-

perficie (imagefilledrectangle). Si possono creare ellissi (imageellipse, imagefilledel-

lipse), linee (imageline), archi (imagearc, imagefilledarc) e poligoni (imagepolygon,

108

imagefilledpolygon). A queste funzioni vengono passati come parametri, oltre all’i-

dentificatore 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. Succes-

sivamente, 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 ori-

ginario, 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 spe-

cificate. 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


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 fun-

zioni 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 rispet-

tivo 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.


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 in-

crementa 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 even-

tuali 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 ven-

gono visualizzate al momento, ma alla fine della gestione di text. Ven-

gono gestite singolarmente e memorizzate in un array multidimen-

sionale (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 considerandola 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 varia-

bili (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’im-

magine 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


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’at-

tributo 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 nel-

lo 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 rap-

presentare 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), con-

siderando 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 para-

metri 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 visua-

lizzati 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 modi-

ficare) e si scorre interamente piu volte.


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 del-

l’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 og-

ni 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 even-

tuali 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 im-

postare le pile per il dimensionamento.

4. Figure predefinite: per ogni figura si chiama la funzione predef che impos-

ta 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 reim-

postano 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, chia-

mando l’opportuna funzione.

5. gestione elementi stroke e fill: per questi elementi vengono gestiti gli op-

portuni attributi. Si controlla se questi elementi sono contenuti all’inter-

no di una figura predefinita o all’interno di shape, impostando (o meglio

sovrascrivendo) le varie proprieta di painting, visto che i valori degli ele-

menti 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 rife-

rimento 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 contenu-

to all’interno di shape (puo essere solo in shape o shapetype). Si chia-

ma la funzione per la sua gestione (path) che inserisce il path nell’ar-


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, font-

size, 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 dimensionamen-

to 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 ar-

ray (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 oppor-

tuni 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 suddi-

vide 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 colo-

re (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 fun-

zioni (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;


• 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’immagi-

ne 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 rappresen-

tata mediante correlazione tra colori e pixel. Rappresentazioni di questo tipo presen-

tano 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 docu-

menti 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 infor-

mazioni 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 carat-

teristiche 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’estra-

zione 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 al-

tri 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 completez-

za 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 e-

lementi. 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 rappresen-

tati 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.

Bibliografia

[AAC98] Nabeel Al-Shamma, Robert Ayers, Richard Cohn, et. al., Precision Gra-

phics 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 Con-

ference 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 Annu-

al 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 San-

dri, Using SVG and XSLT for graphic representation, in: SVG Open 2003 Con-

125

126

ference and Exhibition, 2nd Annual Conference on Scalable Vector Graphics,

Vancouver, Canada, 13–18 Luglio, 2003.

[BosWiu99] Bert Bos, Hakon 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, Francois

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, Hakon Wium Lie, Chris Lilley, Ian Jacobs, Casca-

ding 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/REC-

SVG-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 sur-

vey 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 An-

nual Conference on Scalable Vector Graphics, Tokyo, Giappone, 7–10 Settembre

2004.

128

[HUNW04] Georg Held, Torsten Ullrich, Andreas Neumann, Andre M. Win-

ter, 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 Mecha-

nisms - 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 tran-

slate 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, Andreas 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. Kobben, D.K.J. Heylen, J.W.

Koolwaaij, R. Poortinga, organizzatori, SVG Open 2005 Conference and Exhibi-

tion, 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] Irene Vatton, et. al., Amaya User Manual, Ottobre 2004,

http://www.w3.org/Amaya/User/Manual.html, ultimo accesso: 30 Gennaio 2005.

[Vat05] Irene 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.

aimieigenitori,aimieinonnieadandyk. -...

Documents