Ehi ragazzi, non potevo mica non intervenire eh…
Vorrei dire due cose:
1 – disegnare o programmare?
Con la grafica programmata si costruiscono oggetti grafici anche molto complessi scrivendo istruzioni che implementano algoritmi anche piuttosto strutturati. Con il codice testuale si generano quindi oggetti visivi, che siamo per natura abituati a maneggiare con penne e matite colorate. L’estensione informatica naturale del nostro modo di disegnare corrisponde ad un software visivo dove il foglio è sostituito dallo schermo e le matite sono sostituite dal mouse.
Utilizzare il codice produce quindi una difficoltà perché si disegna in modo astratto e concettuale e non visivo e ciò porta l’utilizzatore perfino a scartare quasi subito questa possibilità. Altri invece trovano grandi benefici codificando il disegno e non vi è dubbio che vi sono vantaggi nella gestione e nella precisione.
Quale strumenti usare dipende quindi da molti fattori che risiedono nelle aree:
– attitudine (ed abitudini) dell’utilizzatore all’astrazione (questo dovrebbe essere quasi certa per gli utilizzatori di TeX & C.)
– tipo del disegno da realizzare
– particolarità di tipo gestionale ed informatico del processo
2 – il linguaggio
Se si è scelto il disegno programmato quello che conta è il linguaggio perché la sue caratteristiche intuitive e d’efficienza possono essere fondamentali per far corrispondere la sintassi con i concetti grafici.
Del resto ho sempre ritenuto fondamentale il linguaggio in ambito TeX, e lo ripetuto più volte qui sul forum. Tutto quello che si deve fare per la diffusione di TeX è sviluppare il linguaggio. Del resto la nascita di LaTeX e ConTeXt e di migliaia di pacchetti ad hoc lo dimostrano.
3 – Tikz
La prima volta che ho visto qualcosa prodotto con Tikz stavo sfogliando la Guida GuIT, che poi ho acquistato un paio di meeting fa. Mi capitò il disegno delle palline colorate in shading, ricordate? ed ho subito cominciato ad usarlo.
Poiché ritengo che Tikz sia il linguaggio più efficiente e completo disponibile in TeX, lo consiglio sia per disegni semplici che per quelli complessi.
Non a caso Till Tantau è un professore di informatica teoretica…
Per aiutare nell’imparare Tikz, posso dire che conviene pensare alle strutture del linguaggio come oggetti grafici concettuali, ed è proprio questo che significa disegnare programmando.
Naturalmente giova crearsi un archivio di disegni Tikz magari pubblicati sul web (ricorro spesso al mio stesso codice che pubblico sul mio blog).
4 – sviluppi futuri
Penso che ci siano ampie possibilità di rendere il linguaggio ancora più efficiente e fornire all’utente strutture grafiche (e non solo) con cui è più semplice interagire e rapidamente disegnare.
Per esempio sto giochicchiando con esempi di linguaggio per il disegno parametrico ad oggetti. Un progetto molto interessante ed entusiasmante ma che è molto difficile da ideare ed implementare non solo per le difficoltà concettuali ma anche perché ci troviamo davanti l’evoluzione LuaTeX e non è ancora ben chiaro quale standard servirà mettere a punto.
Il codice Lua seguente potrebbe per esempio generare codice METAPOST in LuaTeX o codice Tikz in LaTeX o codice SVG, o file DXF ecc ma non è detto che sia la strada giusta:
`
% attenzione: codice teorico di sperimentazione
% interazione ad oggetti alla Lua
c1 = circle(10)
c1:color(“red”)
c1:linewidth(1pt)
% proprietà oggetto alla Python
c2 = c1.clone()
c2.r= 20
c2.color=”red”
% gli oggetti creati vengono poi “stampati”
% per esempio ripetutamente in un ciclo
for i=1,10 do
c1.printat(i*10,i*10)
c2.printat(i*10,i*10)
end`
Gli oggetti creati potrebbero essere assemblati in componenti e gestiti tramite parametri in modo anche molto complesso.
Grazie per aver letto fino a questo punto.
Eh ragazzi, non mi direte mica che stiamo disegnando le faccine sorridenti per i post?
ma stiamo scherzando?