weblab.gif (771 byte) WebLab.jpg (12417 byte) Dario de Judicibus mailto:ddjudicibus@tecnet.it

 

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

formula1.gif (2214 byte)


I vari simboli, inoltre, possono assumere dimensioni differenti a seconda del loro posizionamento, come nel caso delle serie e degli integrali

 

formula2.gif (2988 byte)


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

 

formula3.gif (501 byte)


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

 

formula4.gif (554 byte)


Una formula scritta invece così

 

formula5.gif (494 byte)


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:

formula6.gif (2109 byte)


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


formula7.gif (2272 byte)

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


formula8.gif (1703 byte)


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

formula9.gif (445 byte)


Si può scrivere così (marcatori di presentazione)

<mrow>
<mrow>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<mrow>
<mn>4</mn>
<mo>&InvisibleTimes;</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 &InvisibleTimes; 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


formula10.gif (563 byte)


può essere descritta così
<semantics>
<mrow>
<msubsup>
<mo>&int;</mo>
<mn>0</mn>
<mi>t</mi>
</msubsup>
<mfrac>
<mrow>
<mo>&dd;</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


Internet News è un mensile della Casa Editrice Tecniche Nuove S.p.A.
© 1995/99. Tutti i diritti sono riservati.
Internet News non risponde di eventuali errori e omissioni.
Commenti a: inews@tecnet.it