Formule e grafica con MathML e SVG
In questa nuova puntata di Weblab trattiamo di Mathematical Markup
Language (MathML) e di Scalable Vector Graphics (SVG). Il primo è uno dei
linguaggi XML più complessi e completi finora sviluppati, disegnato per
permettere l'integrazione di formule matematiche in una pagina Web. SVG è
invece l’aspirante più accreditato a diventare lo standard Internet per la
grafica vettoriale
Il World Wide Web e l’HTML vennero inventati molti anni fa allo scopo
di consentire alla comunità scientifica mondiale di condividere l’enorme
mole di dati, informazioni e documenti prodotti da scienziati,
ricercatori, professori e studenti nelle università e nei centri di
ricerca sparsi su tutto il pianeta. Ma una delle carenze di HTML è proprio
la sua scarsa capacità di rappresentare le notazioni scientifiche e in
particolare le formule matematiche. A conferma di ciò, chi oggi ha la
necessità di pubblicare in una pagina HTML una o più formule matematiche,
si trova costretto ad utilizzare delle immagini GIF o qualche complesso
applet Java.
Formule e pagine HTML
In realtà gli scienziati hanno risolto da tempo il problema, grazie
all’utilizzo di appositi linguaggi, come ad esempio il TeX di Donald Knuth
o di speciali applicazioni, chiamate Editori di Equazioni, che generano,
per esempio, codice PostScript che si può poi facilmente integrare nel
testo di un documento. Tali linguaggi tuttavia non possono essere
utilizzati direttamente in una pagina HTML a meno di non usare determinati
plug-in, come si fa per i file PDF di Adobe. Anche l’utilizzo di
immagini GIF in una pagina HTML non è una soluzione particolarmente utile.
Il risultato finale è accettabile solo per quelle formule che sono
posizionate fra due paragrafi In secondo luogo, un’immagine GIF non si
presta a una ricerca all'interno di un documento. Per non parlare poi
delle considerazioni di carattere grafico, per esempio: in genere
un’immagine GIF viene salvata a 70 o 92 dpi. Questo fa sì che le equazioni
vengono stampate a quella risoluzione, mentre il resto del testo a una
risoluzione di 300 dpi, dando luogo a problemi di carattere estetico.
Inoltre, spesso l’equazione utilizza una tecnica di antialias (per
smussare i contorni dei simboli, specie quelli più piccoli) che viene
realizzato su fondo bianco. Se questo colore viene definito come
trasparente e l’equazione posizionata in una pagina con uno sfondo di
diverso colore, intorno ai simboli si vede una specie di alone chiaro.
Nasce MathML
Ecco perché, raggruppando vari sforzi precedenti, come quelli dello
standard ISO 12083 o quelli del progetto OpenMath, ed avvalendosi delle
potenzialità offerte dall'invenzione del linguaggio XML, un certo numero
di persone appartenenti a varie società e comunità scientifiche ha creato
un gruppo di lavoro, il W3C Math Working Group, che a partire dal 1997, ha
iniziato a sviluppare un nuovo linguaggio pensato per rappresentare
praticamente qualunque tipo di notazione scientifica e matematica: il
MathML o Mathematical Markup Language.
La notazione matematica
Perché è così complicato rappresentare una formula matematica? In primo
luogo va detto che il problema non sta tanto nell'utilizzo di simboli
particolari quanto nella composizione non lineare della formula, che
spesso si sviluppa su due dimensioni, come nel caso delle frazioni. In una
formula, infatti, i vari simboli non sono posti in sequenza, come in un
testo, ma si posizionano sul piano secondo schemi che si ripetono e si
sviluppano in tutte le direzioni. Pensate ad esempio all’elevazione a
potenza, come nella formula
I vari simboli, inoltre, possono assumere dimensioni differenti a
seconda del loro posizionamento, come nel caso delle serie e degli
integrali
Esistono poi aspetti non immediatamente visibili della notazione
matematica che spesso sfuggono anche a chi ne fa ampio uso, come ad
esempio, il fatto che la spaziatura fra i simboli non è mai la stessa, o
che molti caratteri vengano modificati in modo differente da come sono
riprodotti quando utilizzati in un testo. Infatti, mentre infatti dal
punto di vista tipografico la spaziatura fra le parole o le lettere ha
prevalentemente un valore estetico o è la conseguenza di considerazioni
pratiche tese a distribuire meglio il testo quando è richiesto
l'allineamento sia a sinistra che a destra, ad esempio, in una formula
matematica due simboli sono separati da uno spazio più o meno grande a
seconda del loro significato. Ad esempio, nella formula
la lettera «c» si discosta dalla parentesi quanto lo è la «a» dal
simbolo «più». Questa notazione indica una moltiplicazione implicita,
ovvero la formula sopra è equivalente a
Una formula scritta invece così
segnala a chi la legge che la «c» è una funzione a una variabile e
che quanto scritto rappresenta il valore che tale funzione assume nel
punto «a+b». Ma non è solo il contesto a determinare la
rappresentazione di una formula. Esistono convenzioni ben definite anche
da un punto di vista tipografico. Per esempio, il corsivo utilizzato per
le variabili non è esattamente uguale a quello utilizzato quando si vuole
evidenziare un certo termine in un paragrafo di un documento. Lo stesso
simbolo può inoltre essere rappresentato in modo differente a seconda del
significato. Per esempio, una sigma maiuscola viene scritta in modo
diverso a seconda che rappresenti una variabile oppure il simbolo di
sommatoria.
Rappresentazione e significato
Una formula matematica può essere descritta in due modi: il primo
descrive la sua rappresentazione, il secondo il suo significato. I due
sono equivalenti ma in parte complementari. Consideriamo una semplice
equazione:
Questa può essere letta come «y è uguale ad una costante k per la
funzione f di x diviso 2x». Questa affermazione descrive completamente la
formula, ma lascia un certo margine di interpretazione sul modo di
rappresentarla. Infatti, è possibile scrivere la stessa formula anche in
questo modo
Da un punto di vista matematico non cambia niente, ma le due
rappresentazioni possono suggerire considerazioni differenti, magari
legate alla natura fisica della formula. Nel secondo caso, per esempio, il
fatto che k sia evidenziata rispetto alla frazione la identifica come una
costante di proporzionalità fra y e la legge f(x)/2x, e quindi non
necessariamente significativa. Nel primo caso, invece, è parte integrante
della legge fisica almeno quanto lo è il 2 a denominatore. Vediamo ora
il caso opposto, quello cioè in cui la formula viene descritta in termini
di presentazione e non di semantica. Consideriamo la formula
Che cosa è «k»? Un indice o una potenza? La rappresentazione in se
non dice molto sul significato della formula. Questo perché la notazione
matematica non è sempre univoca, ma dipende dal contesto in cui essa è
utilizzata. È chiaro allora che esistono due modi differenti di descrivere
una formula matematica che portano con sé un’informazione differente e in
parte complementare.
La genesi del linguaggio
Consci di tutte le problematiche finora descritte e di altre ancora,
gli autori del Mathematical Markup Language si sono prefissati un certo
numero di obiettivi nel disegnare il linguaggio. Innanzitutto, il
MathML doveva permettere di rappresentare qualunque tipo di formula
matematica, in qualunque contesto tecnico e scientifico. In secondo luogo,
doveva essere in grado di descrivere una formula sia dal punto di vista
della sua rappresentazione sia da quello del suo significato. Un altro
obiettivo da raggiungere era permettere di convertire sia la
rappresentazione sia la semantica da e verso i formati matematici più
utilizzati, dove per formati non si intendono solo i linguaggi per la
pubblicazione di documenti come il TeX o il Postscript, ma anche grafici,
sintetizzatori vocali, sistemi di acquisizione dati, scrittura Braille e
così via. Il tutto con la garanzia di una buona leggibilità anche di
formule complesse e di grosse dimensioni, sia su carta sia a video,
permettendo di aggiungere facilmente estensioni e nuove notazioni. Il
linguaggio doveva inoltre essere facilmente leggibile e modificabile a
mano, come l’HTML, anche se – e questo è un punto importante – gli autori
hanno affermato fin dall'inizio che la programmazione in MathML si doveva
basare su appositi programmi di conversione e generatori visuali, e non
sulla programmazione diretta delle istruzioni, data la complessità
intrinseca del linguaggio e la facilità con cui si possono commettere
errori scrivendo a mano in MathML.
I marcatori (sono svariate centinaia) si dividono in due categorie:
quelli che descrivono la rappresentazione della formula, e quelli che ne
descrivono la semantica. Ad esempio, la formula
Si può scrivere così (marcatori di
presentazione)
<mrow> <mrow> <msup>
<mi>x</mi> <mn>2</mn> </msup>
<mo>+</mo> <mrow> <mn>4</mn>
<mo>⁢</mo> <mi>x</mi>
</mrow> <mo>+</mo> <mn>4</mn>
</mrow> <mo>=</mo>
<mn>0</mn> </mrow>
oppure così (marcatori
di contenuto)
<reln> <eq/> <apply>
<plus/> <apply> <power/>
<ci>x</ci> <cn>2</cn> </apply>
<apply> <times/> <cn>4</cn>
<ci>x</ci> </apply> <cn>4</cn>
</apply> <cn>0</cn> </reln>
Da
notare l'utilizzo della variabile ⁢ il cui scopo è
quello di fornire un’informazione semantica della relazione esistente fra
il 4 e la x nel secondo fattore, piuttosto che contribuire alla sua
rappresentazione grafica.
I marcatori
L'insieme del primo tipo di marcatori è chiamato Presentation Markup,
ed è formato da 28 elementi con oltre 50 attributi. Quello del secondo
tipo è detto Content Markup, ed è costituito da ben 75 elementi con una
dozzina di attributi. A questi si aggiunge il marcatore radice del
linguaggio, ovvero <math>. Si tratta, come si può vedere, di due
linguaggi differenti all'interno dello stesso linguaggio. La cosa
interessante è che i due possono essere mescolati, così come si possono
aggiungere ulteriori informazioni a una formula utilizzando il marcatore
di annotazione. Tali informazioni permettono di descrivere la formula non
solo con il linguaggio complementare, ma anche con altri linguaggi,
compreso il TeX o il Postscript. Ad esempio, la formula
può essere descritta così <semantics> <mrow>
<msubsup>
<mo>∫</mo> <mn>0</mn>
<mi>t</mi> </msubsup> <mfrac>
<mrow> <mo>ⅆ</mo>
<mi>x</mi> </mrow> <mi>x</mi>
</mfrac> </mrow>
<annotation-xml
encoding="MathML-Content"> <apply> <int/>
<bvar><ci>x</ci></bvar>
<lowlimit><cn>0</cn></lowlimit>
<uplimit><ci>t</ci></uplimit>
<apply> <divide/> <cn>1</cn>
<ci>x</ci> </apply> </apply>
</annotation-xml>
</semantics>
Una
descrizione in dettaglio del linguaggio MathML va oltre gli scopi di
questo articolo, anche perché, come già detto, difficilmente un
programmatore anche esperto scriverà direttamente in MathML, quanto
piuttosto esporterà la formula da un altro formato, come il TeX oppure
Microsoft Word, oppure genererà il codice corrispondente usando un qualche
editore visuale apposito. Per chi comunque ne volesse sapere di più, le
specifiche complete possono essere trovate sul sito del WWW Consortium
all'indirizzo http://www.w3.org/TR/REC-MathML
Un’applicazione XML per la grafica: Scalable Vector Graphics
La grafica rappresenta un elemento fondamentale per qualunque
pagina HTML. Se tuttavia l’utilizzo di immagini bitmap è più che
sufficiente a soddisfare le esigenze estetiche degli sviluppatori di siti
Web, non altrettanto si può dire per tutti quei tipi di grafica che
rappresentano dati ed informazioni specifiche, quali organigrammi
aziendali, diagrammi di flusso, alberi genealogici, istogrammi e grafici a
barre o a torta. Se poi pensiamo a disegni industriali, formule di chimica
organica, piante e cartine geografiche, progetti di architettura e
presentazioni professionali, ci rendiamo facilmente conto della mancanza
di uno standard per rappresentare grafica vettoriale di buon livello. A
maggior ragione oggi, in un momento in cui l’insieme delle intranet e
delle extranet supera o quasi l’Internet vera e propria e nelle aziende è
forte la necessità di condividere e distribuire una grande mole di dati in
formato grafico. Da questo punto di vista l’HTML è estremamente carente
e, per lo scambio di materiale di elevata qualità si deve fare ricorso ad
altri formati, come il PostScript e il PDF. Fra le tante iniziative
volte a colmare questo vuoto, si inserisce lo sviluppo del linguaggio
Scalable Vector Graphics (SVG) da parte del Consorzio W3C, che presenta
ancora molte sezioni in fase di discussione e altre soggette a continui
cambiamenti.
La realizzazione delle specifiche
È interessante vedere il modo con il quale ha operato il gruppo che ha
definito le specifiche. Per prima cosa, infatti, sono state raccolte tutte
le richieste e le esigenze che varie aziende e i singoli utenti avevano
identificato per un linguaggio di questo tipo. Queste caratteristiche sono
state poi discusse pubblicamente per un certo periodo di tempo finché non
si è raggiunto un accordo generale su come dovesse essere realizzato il
linguaggio. A questo punto si è iniziato a scrivere le specifiche. Un
approccio di questo tipo ha permesso di definire un prodotto valido e
completo ma soprattutto legato alle esigenze del mercato, e non il
risultato di un esercizio di teoria tecnicistica.
Le specifiche
La prima e più importante decisione è stata quella di non legare SVG a
particolari prodotti o a funzioni fornite solo da specifiche aziende. E
nemmeno di poterlo modificare senza il consenso del consorzio. Anche se,
d’altro canto un meccanismo per l'inclusione di dati specifici per
determinate applicazioni è stato considerato fin dall'inizio come
un’esigenza imprenscindibile. Il secondo criterio è stato identificato
nella necessità di far riconoscere SVG da tutti i browser, diventando cioè
un linguaggio standard come l’HTML. Ovviamente questo significa anche che
il risultato finale prodotto dall’interpretazione dei marcatori SVG deve
essere lo stesso in tutti i programmi di navigazione. Altro criterio,
l’unicità: un solo linguaggio piuttosto che una serie di varianti o di
moduli di estensione. SVG doveva inoltre essere il più semplice
possibile, in modo da rendersi riconoscibile da un’ampia gamma di
strumenti e applicazioni, tuttavia sufficientemente completo da fornire
tutte le funzioni tipiche di un buon strumento di grafica vettoriale. A
differenza di quanto avviene con MathML dev’essere, infatti, possibile
scrivere direttamente in SVG con un semplice editor di testi e ottenere
comunque risultati apprezzabili e privi di errori.
L’interdipendenza con altri linguaggi
Un altro aspetto riguarda la dipendenza da altri linguaggi e standard.
SVG dev’essere il più possibile indipendente da altre specifiche. Si è
deciso quindi di basare questo linguaggio su XML e di renderlo compatibile
con gli altri linguaggi collegati, come CSS, XSL, Xlinks, DOM, e via
dicendo. Cosa vuol dire questo esattamente? Facciamo un esempio: se DOM
è lo standard per la gestione via script degli elementi di un linguaggio,
allora deve essere possibile gestire elementi e attributi dei marcatori
SVG attraverso questo modello. Analogamente, determinate caratteristiche
dell’immagine finale devono poter essere specificate via CSS o XSL.
Inutile dire che l'SVG è stato ideato fin dall'inizio per essere
interattivo e dinamico. Vediamo ora quali criteri deve rispettare
questo linguaggio per quanto riguarda la grafica vera e propria. Una prima
caratteristica è la potenza, che dovrebbe caratterizzare il linguaggio al
punto da soddisfare le esigenze di grafici professionisti che vogliono
sviluppare pagine Web integrando immagini che possono essere rese in modo
migliore da elementi vettoriali piuttosto che da bitmap. Questo non vuol
dire che SVG voglia competere con AutoCAD o CorelDraw, ma che più
semplicemente possa raggiungere l’obiettivo di diventare quanto di meglio
si possa trovare per rendere grafica vettoriale in Rete.
Esportazione e resa grafica
In conseguenza di quanto appena detto, dev’essere comunque possibile
esportare in SVG i formati grafici più utilizzati, con la minima perdita
possibile di informazione, e viceversa. D’altra parte, SVG deve consentire
all’utente non esperto o al grafico non professionista di sviluppare
semplici immagini vettoriali con uno sforzo minimo e senza richiedere ore
di studio, utilizzando – al limite – editori grafici o appositi generatori
di codice. E queste caratteristiche candidano l’SVG anche come formato per
lo scambio di immagini vettoriali indipendenti dalla piattaforma. Un
altro aspetto importante è la resa grafica, sia a video sia su carta,
ovviamente anche a colori. Per quanto riguarda il video, SVG deve poter
operare a qualunque risoluzione e profondità, con elevate prestazioni
anche intese a minimizzare i tempi di caricamento. Fra gli schemi
investigati ci sono quelli che scaricano sul client la responsabilità di
funzioni avanzate (come quelle di riempimento a gradiente) permettendo
così di ridurre considerevolmente le dimensioni dei file che contengono il
codice sorgente. In pratica, invece di descrivere effetti complessi nel
linguaggio stesso, si dà loro un nome e ci pensa poi il browser ad
attivarli. L'uso di primitive e di tecniche di visualizzazione progressiva
fanno il resto. Per quello che riguarda invece la stampa, SVG si propone
con un vero e proprio metalinguaggio di stampa, analogamente al
PostScript. <g>
<defs> <gradient
id="MyGradient"... >
<!-- Qui viene definito
il gradiente -->
</gradient>
</defs> <rect style="fill:
url(#MyGradient)" .../> </g> Da più parti è poi arrivata
l’esigenza di una forte consistenza funzionale. Un linguaggio è coerente
dal punto di vista funzionale se una funzione applicabile a vari oggetti è
effettivamente fornita per tutti gli oggetti disponibili. Per esempio, se
è prevista la rotazione di forme, deve anche essere prevista la rotazione
di testi. SVG si propone così come un linguaggio atomico per la
generazione di grafica vettoriale, al punto da poter essere potenzialmente
utilizzato come supporto ad altri linguaggi come il MathML, visto in
precedenza. In pratica, non un linguaggio di alto livello, ma uno di basso
livello, come il PostScript, ad esempio Esso è tuttavia un linguaggio
per grafica a 2 dimensioni, e non affronta per ora il problema di gestire
immagini tridimensionali, anche se gli ideatori hanno ipotizzato la
possibilità di costruire al di sopra di SVG un altro linguaggio
appositamente pensato per la grafica 3D.
Gli elementi
Fra gli elementi riconosciuti, ci sono i cammini, ovvero combinazioni
di uno o più elementi atomici quali segmenti di rette e di curve di Bézier
di terzo e quarto grado, archi di ellissi e circolari. Si è invece evitato
di integrare altre curve non standard come le splines. I cammini possono
essere aperti o chiusi e, in quest'ultimo caso, contenere anche buchi.
Inoltre si è pensato di fornire una serie di forme predefinite quali
rettangoli con e senza bordi arrotondati, cerchi ed ellissi.
<rectangle x="100" y="100" width="100" height="100"
/> <circle style="fill: blue; stroke: red"s cx="200" cy="200"
r="100"/> <p d="M 0 0 L 200 0 L 100 200 Z"/> <!-- cammino
-->
Ogni forma può essere riempita, avere il bordo evidenziato o
meno, ed essere usata come maschera per ritaglio o
esclusione.
<g> <defs>
<image id="MyMask" ...
/> </defs> <rect
style="mask: url(#MyMask)" ... /> </g>
Per quello che
riguarda i testi, valgono le regole generiche per tutti i linguaggi XML.
In particolare è garantito il supporto internazionale grazie all’Unicode e
l'utilizzo dei fogli di stile. In più, ogni singolo carattere può essere
posizionato con precisione e gestito in termini di dimensioni, angolo di
rotazione e angolo di inclinazione.
<text style="font-size: 50"
string="L'alba di un nuovo giorno"/>
Ovviamente anche il tipo di
carattere può essere definito con precisione, così come le legature e i
glifi. In più il testo deve poter essere gestito come un qualsiasi altro
elemento grafico, e quindi, per esempio, essere soggetto a maschere,
riempimenti, e altre funzioni disponibili sugli altri elementi vettoriali.
<text x="100" y="100">co</text> <text x="120"
y="100"> <altglyph glyphname="FF-Ligature"
font-family="Protruda"/>ff</text> <text x="140"
y="100">a</text> Purtroppo manca ancora il posizionamento
relativo a un altro elemento, come ad esempio un testo centrato in un
rettangolo, o l’adattamento automatico delle dimensioni rispetto a un
elemento contenitore. In compenso è possibile raggruppare gli elementi e
specificarne la priorità. Il problema della gestione di veri e propri
livelli (layer) è in fase di
studio.
<g> <g
fillcolor="red"> <rect
x="100" y="100" width="100" height="100"
/> <rect x="300"
y="100" width="100" height="100" />
</g> <g
fillcolor="blue">
<rect x="100" y="300" width="100" height="100"
/> <rect x="300"
y="300" width="100" height="100" />
</g> </g>
Oltre agli oggetti vettoriali SVG prevede
la possibilità di includere nell’immagine anche mappe di bit in vari
formati (GIF, JPEG, PNG).
<image x="200" y="200" width="100"
height="100" xml:link="simple" show="embed"
actuate="auto" href="myimage.gif"/>
Ancora qualche nodo da sciogliere
Un altro problema aperto è la gestione del colore, problema delicato
anche perché deve fare i conti sia con esigenze di indipendenza dalla
piattaforma e dal sistema usato per rendere l’immagine, sia con
l'esistenza di specifiche già utilizzate in altri linguaggi, ma che non
sono necessariamente all’altezza delle aspettative. Per il momento viene
utilizzato il formato sRGB. A quanto detto si aggiungono la gestione
della trasparenza di un oggetto e le regole di sovrapposizione fra
oggetti, il supporto di vari sistemi di coordinate utilizzabili nei fogli
di stile, tecniche di trasformazione e antialiasing, filtri e la
parametrizzazione di alcuni elementi. Molti degli aspetti relativi
all'interazione con l’utente, per quanto fondamentali, quali
l’ingrandimento e la riduzione dell'immagine (zoom) o l'aggancio di uno o
più elementi a un URL, non sono ancora stati affrontati. Questo ci fa
capire che siamo di fronte ad uno sforzo indubbiamente valido e destinato
a dare i suoi frutti, ma in uno stadio in continua evoluzione. Altri
aspetti relativi all'interattività sono demandati al DOM, come ad esempio
l'animazione delle immagini. Per saperne di più, consigliamo di
visitare con una certa frequenza il sito del W3C e in particolare il
documento all’Url http://www.w3.org/TR/WD-SVG
|