- Questo topic ha 9 risposte, 9 partecipanti ed è stato aggiornato l'ultima volta 15 anni, 3 mesi fa da
tobaz.
-
CreatoreTopic
-
29 Maggio 2011 alle 7:20 #59355::
Occupo un piccolo spazio domenicale con una domanda molto semplice.
Mi piacerebbe avere in testa un po’ di chiarezza sull’argomento dichiarato nel titolo.
Spesso, almeno così capita a me che insegno, poter fare un semplice schema, del tipo rettangolo?ovale – freccia diritta/curva – rettangolo/ovale, risolverebbe alla grande giri di parole improbabili.
Avete voglia di precisarmi esattamente “quello per cui il pacchetto tal dei tali è indicato” nell’ambito del disegno?So, per esempio, che l’ambiente picture permette già di fare molto, ma TiKz, per esempio, è adatto particolarmente per i grafici tipo istogrammi o a torta, o cosa? Insomma, una cosa così. 😀
Rischio, altrimenti, magari, di usare un pacchetto complicatissimo per fare cose che si sarebbero potute fare altrimenti. A me servono principalmente schemini del tipo che ho detto, grafici di vario tipo (istogrammi, a torta, esplosi e non, eccetera) .
Grazie per la pazienza.
Ciao
Tommaso
-
CreatoreTopic
-
AutoreRisposte
-
-
29 Maggio 2011 alle 17:09 #59356::
Occupo un piccolo spazio domenicale con una domanda molto semplice.
Mi piacerebbe avere in testa un po’ di chiarezza sull’argomento dichiarato nel titolo.
Spesso, almeno così capita a me che insegno, poter fare un semplice schema, del tipo rettangolo?ovale – freccia diritta/curva – rettangolo/ovale, risolverebbe alla grande giri di parole improbabili.
Avete voglia di precisarmi esattamente “quello per cui il pacchetto tal dei tali è indicato” nell’ambito del disegno?So, per esempio, che l’ambiente picture permette già di fare molto, ma TiKz, per esempio, è adatto particolarmente per i grafici tipo istogrammi o a torta, o cosa? Insomma, una cosa così. 😀
Rischio, altrimenti, magari, di usare un pacchetto complicatissimo per fare cose che si sarebbero potute fare altrimenti. A me servono principalmente schemini del tipo che ho detto, grafici di vario tipo (istogrammi, a torta, esplosi e non, eccetera) .
Grazie per la pazienza.
Ciao
TommasoCiao Tommaso
approfitto anch’io di questo angolo domenicale, anche se, come sai, su questo tema non sono tanto ferrato.
La mia opinione è questa: ci sono molti pacchetti per disegnare, ognuno con la propria sintassi. Visto che con tikz (e vari pacchetti associati) si può fare praticamente tutto è meglio usare quello anche per disegni semplici, così se in futuro hai la necessità di fare disegni più complessi sei già alfabetizzato. Questo sulla carta. Poi in pratica usare tikz fa venire tendenze suicide. Ma come dice qualcuno, è scritto da tedeschi, gente che mette il verbo alla fine… 😉 Ogni volta che lo uso devo ricominciare da zero. Non capisco nemmeno i codici dei disegni che ho già fatto 🙄Ciao
Ivan
-
29 Maggio 2011 alle 17:35 #59357::
Ciao,io, per la mia esperienza, consiglio TikZ per fare tutta la grafica 2D, in quanto con questo strumento è impossibile fare del 3D a meno che non si usino programmi esterni come Sketch che generano codice TikZ di una scena 3D.
Per quanto riguarda la conoscenza di TikZ, certo è impossibile ricordarsi tutti i comandi. Bisogna invece sapere cosa è capace di fare, perché una volta che si ha una soluzione per ottenere un determinato disegno, basta cercare i comandi sull’ottimo manuale.
Inoltre stanno incominciando a nascere diversi pacchetti basati su PGF/TikZ. L’autore più prolifico è comunque il francese Alain Matthes, raggiunbile qui.
Questo è quello che ho da dire.
Saluti
Michele
-
29 Maggio 2011 alle 17:48 #59358::
Tommaso,
come sai ho disegnato quasi tutti i disegni della GuidaGuIT con picture; TiKZ è eccellente e lo uso spesso, ma ritengo che picture sia sottovalutato, specialmente oggi che dispone del file di estensione promesso e annunciato da Lamport nel 1994 e apparso solo nel 2003; nel 2009 è uscito l’ultimo aggiornamento e mi fa piacere di venire citato come persona che ha messo a disposizione alcune sue macro per quest’ultima estensione.Il vantaggio di usare picture rispetto a TiKZ è che il manuale di pict2e (texdoc pict2e) ammonta ad una decina di pagine (trascurando il codice commentato) mentre il manuale di png/tikz è di diverse centinaia di pagine.
Il vantaggio di usare TiKZ (TiKZ ist Kein Zeichen…; il solito acronimo ricorsivo come GNU) è che fa praticamente tutto; volendo anche diagramma 3D proiettati sul piano, visto che consente di usare senza estensioni le tre coordinate cartesiane x, y, z; certo bisogn lavorare non poco per fare disegni 3D, perché che io sappia non c’é ancora un file di estensione che faciliti il compito. Ivan ha ragione a dire che non fa diagrammi 3D, non parché non si possano fare, ma perché è difficilissimo farli senza interfaccia adatta.
Però devi sbobbarti le centinaia di pagine e senza dover ricordare tutto devi saper dove andare a leggere le istruzioni quando vuoi fare qualche cosa; l’importante è quello di avere una certa dimestichezza con la terminologia di Till Tantau, poi la cosa non è così difficile.
Ciao
Claudio
-
29 Maggio 2011 alle 19:16 #59359::
Ogni volta che lo uso devo ricominciare da zero. Non capisco nemmeno i codici dei disegni che ho già fatto 🙄
Commentare il codice serve anche a questo 🙂
Per quanto riguarda il 3D, in questa discussione ho scoperto l’esistenza del pacchetto tikz-3dplot. È ancora in fasce (come scritto anche nel manuale), però sembra interessante
-
29 Maggio 2011 alle 20:32 #59360::
Ivan ha ragione a dire che non fa diagrammi 3D, non parché non si possano fare, ma perché è difficilissimo farli senza interfaccia adatta.
Il problema, secondo me, è la mancanza del rendering dell’immagine 3D.
Qualcosa si sta muovendo appunto con la CVS di PGFplots e con Sketch i quali disegnano per primi i poligoni più lontani dalll’osservatore, disegnandoci sopra quelli più vicini.
Purtroppo lo svantaggio di geometrie più complesse è la visibilità dei lati dei poligoni che compongono il modello. Si può ovviare a questo come fa De Marco nelle sue figure, ma comunque, anche se ottime, si ha un senso di piattezza che non si avrebbe se il sistema di rendering riconoscesse i bordi da disegnare.
Ho provato a cercare qualcosa a riguardo, ma ho scoperto che ci fanno dei corsi interi all’università, quindi è una materia che non si può imparare velocemente.
La cosa bellissima(la butto tanto per…) sarebbe fare qualcosa con LuaTeX: immaginate di scrivere una scena 3D dentro un ambiente e lui te la renderizza e te la disegna come fa il programma Sketch.
Saluti
Michele
-
29 Maggio 2011 alle 22:25 #59361::
Salve a tutti, ecco la mia esperienza al riguardo:1.
La scelta dello strumento più adatto dipende dalla complessità
del disegno da realizzare. A volte, nel mio caso, dipende dal mood del momento
(potrebbe sembrare una battuta fine a sé stessa ma in effetti alcuni strumenti
ti incoraggiano ad usarli più di quanto facciano altri).2.
Per il motivo di cui sopra mi sono reso conto nel tempo che un disegnatore
finisce col disporre di una ‘batteria’ di metodi diversi. Alcuni sono stati scelti così,
tanto per fare una prova, altri per necessità. A tal riguardo ho imparato che bisogna
fare i conti con gli aggiornamenti di questo o quel pacchetto oppure di questo
o quel software. Ciò si traduce talvolta nel fatto che alcuni disegni realizzati
in passato con un dato metodo non compilano più al primo colpo oggi.
Esempio 1: disegni eseguiti qualche anno addietro con pstricks e con il pacchetto
ausiliario pstricks-add sono senz’altro da revisionare, soprattutto se ci si vuole
basare su di essi per produrne di nuovi. Ciò è dovuto al fatto che alcuni aggiornamenti
di pstricks-add hanno soppiantato vecchie opzioni di alcuni comandi con nuove opzioni,
diverse dalle precedenti.
Esempio 2: i disegni eseguiti con Inkscape, versione precedente alla 0.48a, allo
scopo di usare il pacchetto psfrag non sono più riproducibili se si usa una
versione recente di Inkscape. Per chi è interessato a questo metodo, che spiego
nel mio articolo su ArsTeXnica http://guit.sssup.it/arstexnica/download_ars/articoli_ars_06/Gestione%20avanzata%20delle%20figure%20in%20LATEX.pdf,
ho trovato un workaround per utenti Matlab qui: http://www.mathworks.com/matlabcentral/fileexchange/29649-make-inkscape-postscript-files-compatible-with-psfrag-in-latex.
Questa tecnica si presta all’implementazione in altri linguaggi (perl, python, ecc.).
Qualche dettaglio si trova qui: http://tavmjong.free.fr/INKSCAPE/MANUAL/html/File-Export.html.3.
Personalmente la mia tendenza è quella di produrre separatamente i miei
disegni, anche se questi richiedono l’uso di LaTeX, anche se questi sono del tutto
semplici.
In pratica creo sempre una sottocartella in cui metto il sorgente dell’illustrazione
e tutti i file necessari per produrla. Successivamente, una volta pronto il PDF lo
includo nel mio documento principale con \includegraphics.
E’ una tecnica che adotto come autodisciplina e mi permette di mantenere una certa
struttura organizzativa nei miei documenti. La consiglio a tutti.4.
Per i disegni semplici tendo ad usare Inkscape, esportando un PDF e allo stesso
tempo un file sorgente LaTeX con le annotazioni (che sfrutta l’ambiente picture per
posizionare correttamente gli elementi testuali). Per gli interessati a tale tecnica di
lavoro si veda questa discussione: http://www.guit.sssup.it/phpBB2/viewtopic.php?t=7965&highlight=inkscape.
Devo ammettere che non sono del tutto soddisfatto di come funzioni questo approccio,
nel senso che esso è molto meno potente di quello preesistente basato sull’uso di
psfrag. In ogni caso la semplicità d’uso di Inkscape vince su tutto, secondo me,
nel senso che non mi fa venir voglia di usare Xfig+psfrag.5.
Qualcosina sul 3D. Se si accantona il rendering — che come si è detto è un capitolo a
sé della Computer Graphics — il metodo basato su Sketch dovrebbe essere quello
che fornisce risultati migliori: usa un linguaggio descrittivo della scena 3D, permette
di inserire codice LaTeX a basso livello, non presenta ad oggi problemi di
back-compatibility. L’autore di Sketch, Eugene Ressler, dichiara che nella lista delle
nuove features c’è anche la possibilità di programmare il rendering degli oggetti in una
scena. Ma non ci si aspetti che questa nuova caratteristica arrivi nell’immediato futuro.
Il 3D è gestito anche da Asymptote come ho spiegato qui: http://www.guit.sssup.it/arstexnica/download_ars/articoli_ars_08/Produrre%20grafica%20vettoriale%20di%20alta%20qualita%20programmando%20Asymptote.pdf.
Infine, non si trascuri Blender, http://www.blender.org/. Esiste uno script in
python che esporta elementi di una scena da Blender in un sorgente Tikz:
http://blenderartists.org/forum/showthread.php?125866-Export-Blender-curves-to-TikZ-format-for-use-with-(La)TeXBlender ha ovviamente il suo motore di rendering e si può produrre in output un PDF
della scena. Mi chiedo se sia possibile riutilizzare o modificare il codice che esporta
curve in formato Tikz per annotare scene complesse, con oggetti dotati di shading…Ciao,
Agostino
-
30 Maggio 2011 alle 8:00 #59362::
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 processo2 – 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?
-
30 Maggio 2011 alle 10:29 #59363::
salve a tutti, scusate se mi riallaccio a questa discussione ma cade proprio a fagiuolo…Dovrei fare dei disegni vettoriali, forze su aste e schemi di corpo rigido per intenderci, e non ho mai fatto disegni con latex in quanto per me questo stupendo linguaggio è nuovo…
allora ho letto gli interventi precedenti anche se non ho ben capito tutto, per questo volevo chiedere mi conviene utilizzare qualche programma esterno e poi introdurre i disegni come figure?se si quale programma? oppure usare Tikz anche se non so nemmeno di cosa si tratta e come imparare ad usarlo?Inkscape invece cos’è?
scusate la mia ignoranza, spero qualcuno mi sappia un pò spiegare, ciaoooooo
-
30 Maggio 2011 alle 13:32 #59364::
Dipende sempre da quanto tempo vuoi investire sui disegni. Tikz a mio avviso è complicato, però il risultato che ottieni è eccellente.
L’opzione Inkscape non è male, questo software permettere di ottenere immagini in formato vettoriale e funziona tipo Paint o Photoshop per intenderci, niente codice solo mouse
-
-
AutoreRisposte
- Devi essere connesso per rispondere a questo topic.