Approfondimenti
di Michael J. Hammel traduzione di Antonio Cartelli

indent
Prosecuzione del servizio sui pacchetti per la grafica vettoriale in Linux
Un po' di sollazzo per gli occhi, per piacere (continuo)
approfondimenti ...



Prosecuzione del servizio sui pacchetti per la grafica vettoriale in Linux

Ho ricevuto moltissima posta in rispost al mio articolo sui pacchetti vettoriali per Linux.  Il che è senz'altro positivo - è forse l'unico metodo che conosco per sapere se qualcuno legge quello che scrivo.  Fortunatamente si è trattato sempre di messaggi positivi, alcuni elogi e moltissime richieste di aiuto sui pacchetti che ho presentato.  Di seguito riporto alcuni dei messaggi che ho ricevuto e le risposte corrispondenti.



Un pacchetto che ho dimenticato:  ImPress

Ammetto che ImPress ha qualche problema ma ogni tanto, per favore, dateci un'occhiata.
http://www.ntlug.org/~ccox/impress/index.html

Saluti,
Chris
ccox@acm.org

'Musa:  Whoa.  In verità non sapevo neanche che ImPress fosse un pacchetto vettoriale.  Mi scuso per le mie capacità di ricerca.  L'ho scaricato e gli ho dato un'occhiata molto superficiale, devo dire quindi che è forse il pacchetto più semplice da utilizzare di tutto il novero presentato.  Per coloro che volessero disegnare dei semplici diagrammi e stamparli questo potrebbe essere il pacchetto ideale.  Ha un'interfaccia molto semplice che comprende tutti gli elementi di base che si possono desiderare, più il supporto per il testo da inserire nell'immagine e l'output Postscript.  Non ha neanche lontanamente tutte le caratteristiche di un TGIF o di XFig, ma è semplice da utilizzare e non richiede particolari configurazioni.  Non richiede neanche di essere compilato - si tratta di uno script Tcl/Tk!  È impressionante. Di seguito riporto alcune schermate video.
 

Finestra principale di Impress
Toolbox

Sfortunatamente il pacchetto che si può scaricare non comprende molta documentazione.  Il sito web per converso contiene una versione HTML della documentazione che accompagna il software.  Anche se limitata la documentazione presente dovrebbe però essere sufficiente ad acquisire velocemente una sufficiente capacità di movimento all'interno del programma.  Ho notato, però, che almeno in una parte della documentazione è presente un errore:  cliccando due volte sull'immagine della palette dei colori, nella finestra principale, non si accede direttamente alla finestra di dialogo per l'editazione di colori.  Per far ciò si deve cliccare invece due volte sul pulsante Fill; si tratta comunque di dettagli secondari, il programma funziona infatti abbastanza bene.

Un solo dubbio mi assilla:  come ha fatto Chris ad ottenere le immagini di Tux e del dinosauro presenti nell'esempio? Il dinosauro si presenta come una clip art (grafica vettoriale), mentre l'immagine di Tux sembra più un grafico rasterizzato importato.  Nel pacchetto che ho non mi sembra di aver visto una caratteristica quale l'importazione rasterizzata, anche se potrebbe trattarsi di qualcosa in via di sviluppo. .



KIllustrator
  1. Killustrator richiede egcs 1.x O gcc 2.8 in quanto gcc 2.7.2 presenta più di qualche problema con il codice C++ (ie nessuna conformità con ANSI).  Nessun problema con la Redhat 5.x, poiché il compilatore naturale C++ presente su Redhat è proprio egcs, mentre gcc è riservato esclusivamente al codice C, soprattutto nelle vecchie serie stabili dei kernel 2.0.x.
  2. Con KDE già installato sul mio sistema, si è trattato né più né meno che di un'installazione standard di codice sorgente attraverso l'utilizzo di ./configure ; make ; make install che hanno funzionato senza problemi. (almeno con la versione 0.6.3 , ma ci sono versioni successive).
  3. Il pacchetto sembra importare disegni XFig mentre esporta i formati GIF, eps, ppm, and xpm (probabilmente può supportarne di più ma, ad esempio, sul mio sistema non ho installate le librerie di sviluppo tiff e png per cui può darsi che configure, molto semplicemente abbia selezionato per l'utilizzo soltanto quelle effettivamente installate). Il software salva poi le informazioni nel suo formato di base (XML?).
  4. Per l'esecuzione di applicazioni KDE si ha bisogno delle librerie Qt e KDE, nulla di più. Per compilare tale applicazioni si ha bisogno soltanto dei pacchetti Qt-devel e kdesupport.
  5. Per un'installazione completa di KDE occorre installare i pacchetti nell'ordine: Qt, kdesupport, kdelibs, quindi tutti gli altri {kdebase, kdegames, kdegraphics, kdenetwork, korgransier, klyx, kdeutils, kdetoys, kdemultimedia}.
  6. Killustrator è stato progettato fin dall'inizio come applicazione KDE per cui non è stato previsto di separarlo dal suo ambiente (a differenza di quanto accaduto per il GIMP che ha precedeuto GNOME). Ad ogni modo esso richiede soltanto le librerie kdelibraries e Qt - e funzionerà benissimo su ogni sistema X11 sul quale esse siano state installate. Si tratta anche del pacchetto di grafica vettoriale per il pacchetto Office KDE e credo che la versione 0.6.x sia l'ultima all'interno della quale sia prevista un'opzione in fase di compilazione che le consenta di funzionare senza il supporto koffice (potrebbe essere il caso di controllare il sito web per verificare questa affermazione).
  7. Trattandosi poi di un'applicazione koffice può essere immersa in altre applicazioni utilizzando KOM/OP corba orb, e quindi indipendentemente da Qt e KDE, pertanto è possibile immergere killustrator in altre applicazioni in grado di comprendere KOM/OP, proprio come accade mediante koffice (Suse 6.1 ne prevede al suo interno una versione alfa).
George Russell
george.russell@clara.net

'Musa:  Queste si che sono informazioni utili, soprattutto quelle sulle librerie necessarie a compilare applicazioni KDE.  Sfortunatamente, poiché sembra che KIllustrator sia destinato a collegarsi sempre di più ad un altro gruppo di pacchetti (KDE Office Suite), dubito che provvederò a provarlo in quanto non ho bisogno di tutti gli altri componenti di cui è costituito.  Nel caso in cui verranno inseriti nella prossima distribuzione completa che acquisterò allora gli darò un'occhiata.  In effetti non ritengo utile scaricare enormi quantità di materiale sapendo che comunque non lo utilizzerò.

La sua illustrazione di KIllustrator all'interno della Linux Gazette è fuorviante.  KIllustrator non è "dipendente da KDE" come dice lei, funziona perfettamente su ogni tipo di desktop.  Il pacchetto utilizza però KDE come ambiente di riferimento per lo svilluppo di applicazioni, che è cosa ben diversa.

Ciò non ha nulla a che vedere con "l'essere intriso di KDE", si tratta piuttosto della modalit` di scrittura di applicazioni.  KDE non è soltanto un dektop, è un insieme di applicazioni e librerie che rendono possibile oltre che agevole scrivere applicazioni. Chiedendo ai programmatori di non utilizzare i moderni strumenti di sviluppo per la creazione delle loro applicazioni è come se li si costringesse a reinventare ogni volta la ruota. Nel migliore dei casi ciò comporterebbe la creazione di applicazioni come xfig e tgif (che non possono competere con i moderni standard), nel peggiore dei casi non ne seguirebbe nulla.

Andiamo, installare software in un sistema linux significa oggi cliccare su qualche pulsante all'interno di pacchetti-k, cosa che non mi sembra poi così complicata ;-)

Matthias Ettrich <ettrich@kde.org>

'Musa:  Gli utenti finali non fanno differenza tra "ambiente di sviluppo per applicazioni" e dipendenza, è un problema di semantica. KIllustrator è dipendente da KDE perché si ha bisogno delle appropriate librerie KDE per mandare in esecuzione il programma e/o compilarlo e lo stesso accade per il Gimp - che dipende da Gtk.  La differenza sta nel fatto che Gtk è stato reso disponibile nella maggioranza delle distribuzioni Linux, oltre che per diverse piattaforme Unix, da un po' di tempo a questa parte (almeno dall'anno scorso).  KDE, dal canto suo, sta entrando a far parte di molte distribuzioni Linux soltanto ora, il che renderà un compito meno complesso per il futuro scaricare un eventuale pacchetto aggiuntivo occasionale dalla rete.

Ovviamente tutto ciò non lo dico con l'intento di asserire che KDE è un problema in più col quale misurarsi, quanto piuttosto perché attualmente esso non è conveniente per l'utente finale.  Le applicazioni Gnome hanno gli stessi problemi.  Per gli utenti di piattaforme non-Linux, però, per i quali né Gnome né KDE sono disponibili, queste applicazioni non sono di alcuna utilità.  Naturalmente è una scelta di cui ci si fa interamente carico in quanto sviluppatori.  Io preferisco scrivere software che funzioni su ogni piattaforma Unix, o almeno per il maggior numero possibile di esse che sono in grado di supportare.



XFig

Ho letto nel suo articolo che non è riuscito né ad esportare file né a stampare da XFig. Non è che non ha installato fig2dev?  Questo programma fa parte del pacchetto transfig (si veda la documentazione xfig).

Sinceramente suo,

Jeroen Nijhof
J.H.B.Nijhof@aston.ac.uk

'Musa:  Sembra che la ragione dei miei problemi sia proprio questa.  In verità non ho installato fig2dev.


Sketch

Ho appena letto il nuovo numero della Linux Gazette ed il suo pezzo della Musa della Grafica e sono stato molto felice di apprendere che ha effettuato un'indagine sui programmi di disegno vettoriale disponibili in ambiente Linux.

Come sviluppatore di Sketch, però, come può facilmente immaginare, ho provato un notevole disappunto quando ho letto che non è riuscito ad installare il pacchetto. Le considerazioni da lei prodotte sono perfettamente vere anche se la maggioranza dei problemi viene, almeno credo, da alcune righe fuorvianti all'interno del file README della PIL. Ritengo che chiunque non abbia molta esperienza con la compilazione di estensioni-C per Python incontri problemi analoghi anche se non so quante persone abbiano desistito dall'installazione di Sketch a causa di ciò.

Nel suo articolo lei scrive:

Sketch richiede Python v1.5.1 o versioni successive, la libreria delle immagini Python (PIL - Python Imaging Library) v1.0b1 e Tcl/TK versione 8.0 o successive.  Per compilare la libreria citata (altrimenti detta PIL) non si può utilizzare la versione RPM di Python - si deve compilare il pacchetto python a partire dai sorgenti ed installarlo, in quanto si deve compilare la PIL all'interno della directory "Extensions" delle aree Python 1.5.
Allo stato attuale ciò non è vero. Il file README di PIL, infatti, riporta che si dovrebbe scompattare l'archivio nell'area Extensions di Python, ma dice anche che la si può scompattare ovunque si voglia (ad esempio nella propria area di lavoro) e compilarla lì.
Sebbene nella mia macchina con RH 5.2 di serie io abbia installato Python 1.5 l'area Extensions non è presente.  Per di più creando la directory nel luogo in cui è installato Python 1.5 (/usr/lib/python1.5), ho dovuto compilare la PIL come superutente, il che non è una gran bella cosa.  Di conseguenza ho scaricato i sorgenti Python 1.5, li ho compilati ed ho provato infine a compilare la PIL.  Non ha funzionato - a causa di qualcosa connesso alla mancanza di un'area di configurazione.
Non si ha alcun bisogno dei sorgenti Python per compilare la PIL in quanto si dispone di una completa installazione dell'interprete Python e dei file di intestazione C, delle librerie e dei file di configurazione. RedHat ha spezzettato Python in tanti pacchetti; i file di intestazione e configurazione sono nell'rpm di sviluppo python-devel, per quanto ne so io (non utilizzo la RedHat ma dò spesso un'occhiata al loro sito FTP), per cui se si installa l'rpm si può compilare la PIL mediante i comandi:
% tar xvzf Imaging-1.0b1.tar.gz
% cd Imaging-1.0b1/libImaging/
% ./configure
% make
% cd ..
% make -f Makefile.pre.in boot
% make
ed installare il tutto all'interno dell'area /usr/lib/python1.5/site-packages come descritto nel file README di PIL. Fatto questo l'installazione di Sketch dovrebbe essere facile, o almeno così spero :)

Al di là di tutto, comunque, la ringrazio dell'articolo in quanto, come sviluppatore, mi risulta difficile comprendere dov'è che un utente può avere problemi e l'informazione che lei mi fornisce è esattamente ciò di cui ho bisogno per rendere Sketch più semplice da installare.

Mi auguro di cuore che vorrà dare a Sketch un'altra opportunità e scrivere di nuovo di lui e degli altri programmi in un prossimo numero della musa della grafica.

Bernhard Herzog <sketch@online.de>

'Musa:  Sviluppatori Attenzione - questo è esattamente il modo in cui dovreste rispondere agli utenti finali ed alle critiche riportate sulla stampa!  A Bernard va tutto il mio plauso per aver preso a cuore il mio lavoro sulla musa e per aver fornito un così utile messaggio di risposta.  Mi auguro, per quanto concerne i miei lavori, di riuscire a rispondere ad eventuali critiche nella stessa maniera professionale e pertinente di Bernard.

Oh, la risposta di Bernard, poi, è stata perfetta.  Grazie al suo aiuto sono riuscito a far funzionare tutto molto velocemente.  Va notato che ha perfettamente ragione rispetto agli RPM di RedHat - se si utilizza la distribuzione RedHat 5.2 può darsi che non si sia automaticamente installato il pacchetto di sviluppo Python, necessario per la compilazione della PIL.  Per scoprire se questo è il caso basta provare a far eseguire il passaggio previsto da Makefile.pre.in (descritto sopra) ed ottenere il messaggio di risposta

No rule to make target `/usr/lib/python1.5/config/Makefile
Ciò potrebbe accadere a causa del fatto che la directory "config" di Python è l'unica ad essere installata (se si utilizza RPM) con il pacchetto python-devel-1.5.1-5 RPM per i386.  Non si dimentichi di installare anche i tre file di intestazione della PIL nelle directory di include di python.  Il file INSTALL di Sketch descrive tutto ciò che va fatto in maniera molto semplice.  Dopo aver installato il pacchetto di sviluppo di Python e la PIL la compilazione di Sketch è cosa realmente molto semplice. Basta seguire tutti i passaggi indicati in README in quanto Sketch è realmente facile da installare, il problema è installare le parti che occorrono di Python.

Un'ultima cosa:  ci si accerti di compilare tutto con la versione 0.6.0; io ho provato con una versione precedente, la 0.5.5, ed ho avuto qualche problema di compatibilità con la mia installazione di Python 1.5.1.  Si può avere abbastanza facilmente ciò che occorre cercando qua e là ma è tutto più semplice se ci si procura direttamente la versione 0.6.0 (o successiva) del codice sorgente.

L'interfaccia di Sketch è abbastanza semplice da utilizzare.  A differenza di TGIF e XFig, Sketch è più di un pacchetto per artisti, è qualcosa di simile ad Adobe Illustrator (legge e scrive anche file di Illustrator).  Per la verità non dovrei neanche mettere sketch nella stessa categoria degli altri due - sembrano pensati per usi differenti.  Essendo più di un artista (o almeno un artista che non vuole esserlo) preferisco di gran lunga Sketch, almeno dopo essere riuscito a farlo funzionare.


Ah! Un piccolo elogio ...

Quella che invio è la lettera di un vero appassionato della Musa della Grafica!  Ritengo che stia facendo un grosso lavoro con i suoi articoli all'interno della Linux Gazette, soprattutto perché lo fa ogni mese.  Congratulazioni!

'Musa:  Grazie!

Talvolta penso che anch'io dovrei dare un maggior contributo per la comunità Linux ma il mio lavoro di tutti i giorni assorbe gran parte del mio tempo e delle mie energie.  Come fa a scrivere i suoi articoli ogni mese?  Da dove prende la sua energia? Dalla Kryptonite?  :-)

'Musa:  No, ma la mancanza di qualunque cosa che rassomigli anche lontanamente ad un barlume di vita sociale sicuramente aiuta.  Come nel suo caso si tratta di un contributo alla causa - lei lo ha fatto fornendo una risposta al mio articolo.  Non sottovaluti l'importanza che la sua risposta ha avuto.

Ma perché sto scrivendo questa lettera ...

Nel numero del mese scorso della Gazette lei ha messo a confronto tgif con xfig, in maniera molto sintetica: ben fatto. Un gran lavoro!  Mi è piaciuta in maniera particolare la frase con la quale ha asserito che la sua preferenza per tgif _non_ trova corrispondenza nel "test"-numerico; se ogni confronto/test fosse fatto con la medesima accuratezza avremmo molte meno discussioni accese (flame wars) nei newsgroup.

'Musa: Forse, ma l'istinto umano si muove verso una chiarificazione dal punto di vista del lettore.  Ciò significa che in qualche maniera un argomento è abbastanza garantito (almeno tra individui abbastanza motivati intellettualmente).  Ora però sto divagando.

Siccome sono un utilizzatore di entrambi i programmi da lungo tempo (forse troppo), vorrei aggiungere qualche ulteriore considerazione al suo attento giudizio.  Non ha pensato alla possibilità di utilizzare entrambi?  Una volta in barca si deve remare, non è vero?.

Quasi tutti i documenti che scrivo son realizzati utilizzando LaTeX.  Di tanto in tanto devo includere al loro interno qualche semplice disegno ma siccome TeX produce dei documenti che si presentano molto bene anche la grafica deve adeguarsi a questo stile.  Ciò significa che tutti i testi (in effetti titoli, etichette, legende) in un disegno devono essere scritti con TeX in quanto l'utilizzo di font di provenienza diversa non fa un bell'effetto.  Il problema sta nel fatto che le possibilità grafiche di TeX (l'ambiente grafico, per capirci) è molto limitato.  Ciò che un utente vorrebbe è la piena potenza dello stile Postrscript.  Tanto premesso xfig ed i suoi compagni transfig e fig2dev sono una manna dal cielo.  Essi consentono di realizzare esattamente ciò che ho appena descritto.

Il tipico diagramma di flusso si presenta come segue:

  editor                TeX                      dvips
|-------> doc.tex ---------------+----> doc.dvi ---+----> doc.ps
                                 ^                 ^
  xfig              fig2dev      |                 |
|-------> graph.fig ----+---> graph.tex            |
                        |                          |
                        +---> graph.ps ----------->+

Le dipendenze tra i file sono automaticamente aggiornate con un Makefile.  Bene, ora sa perché preferisco xfig: è il solo programma che riesce a separarea l'output di testo (leggasi: TeX) dall'output grafico (leggasi: Postscript).

Si immetta: file Postscript.

Si immagini che un collega venga e dica: "Dovremmo includere uno di questi divertenti output provenienti da XYZ [si inserisca pure il nome del programma], come si sa questo programma può produrre anche file Postscript."  Oh, oh -- brutte notizie.

  1. Strano e triste ma vero: Postscript non sempre è Postscript.  Alcuni programmi hanno un'idea molto particolare di quello che è lo standard Postscript.
  2. Sicuramente, l'output del programma si presenta molto accattivante ma non può essere pubblicato senza qualche correzione.  Come fare, però, a correggere un file postscript?  Può essere divertente se si possiede il programma pstoedit di Wolfgang Glunz [attualmente alla versione 3.03].  pstoedit traduce un file ps con l'help di ghostscript in un file tgif-compatibile.  Per un bel po' di tempo il driver tgif di pstoedit è stato il solo in grado di consentire il passaggio da un file non-editabile in formato Postrscript ad un formato editabile.  Poi ha rappresentato il miglior driver a consentire questa trasformazione.  Oggi il driver xfig lo fa altrettanto bene del driver gif.  Siccome ho iniziato ad editare i miei file ps molto tempo fa ho sviluppato una naturale propensione per tgif: era il solo pacchetto che facesse ciò di cui avevo bisogno.
Come vede le storie che sottendono l'utilizzo di un pacchetto piuttosto che un altro possono essere alquanto complesse.  I numeri di un arbitrario test possono non dire ciò di cui si ha bisogno.  È per questo che il confronto xfig contro tgif rappresenta un esempio da manuale di quello che si dovrebbe scrivere relativamente a prestazioni, utilizzabilità e quant'altro.

Christoph L. Spiel
cspiel@ccmr.cornell.edu

'Musa:  Ineccepibile in tutto e per tutto!  Troppo spesso siamo soliti effettuare confronti oggettivi di pacchetti sulla scorta di quelli che riteniamo confronti assoluti di velocità e prestazioni, dimenticando di misurare l'apparentemente intangibile valore del comfort che si può trovare in un pacchetto per l'utente finale.  Molto probabilmente dovremmmo guardare al software un po' meno come ad astratti pezzi di pseudo-apparecchiature ed un po' più come ad estensioni della nostra vita quotidiana.  Siamo capaci di personalizzare le nostre auto riferendoci ad esse come "Lei" ma se un'auto non dà alcun piacere al suo possessore ha per lui ancora un valore?  Sembra che la comodità, il piacere, (comfort) debbano essere una parte indissolubile della nostra misura dell'utilità di un prodotto software per un individuo.



Un po' di sollazzo per gli occhi, per piacere (continuo)

Nel mio file fvwm-menu ho aggiunto le seguenti righe da utilizzare nel mandare in esecuzione xscreensaver:

AddToMenu XScreensaver "Screen Saver"    Title
+      "Matrix"        Function    ScreenSaverMatrix
+      "XSaver On"     Function    ScreenSaverOn
+      "XSaver Off"    Function    ScreenSaverOff

AddToFunc ScreenSaverMatrix
+ "I"   Exec      exec xscreensaver -no-splash &
+ "I"   Exec      exec xscreensaver-command -select 1&

AddToFunc ScreenSaverOn
+ "I"   Exec      exec xscreensaver -no-splash &

AddToFunc ScreenSaverOff
+ "I"   Exec      exec xscreensaver-command -exit&
+ "I"   Exec      exec xset s on

La prima riga, Matrix, manderà immediatamente in esecuzione soltanto lo screensaver xmatrix e lo lascerà attivo.  La seconda riga fa partire lo screensaver utilizzando la prima riga della lista contenuta nel file in $HOME/.xscreensaver e gli permette di continuare scorrendo tutta la lista.  Ovviamente la partenza del programma avviene al termine dle periodo di inattività previsto dalla configurazione.  L'ultima riga disabilita lo screensaver e restituisce le schermate annullate del server X.

I tre programmi che accompagnano lo xscreensaver - xscreensaver daemon, xscreensaver-demo e xscreensaver-command - prevedono anche un esteso numero di pagine di manualistica in formato HTML.  Può sembrare superfluo che ci siano tante opzioni per qualcosa di così semplice come uno screensaver ma si tratta comunque di opzioni utili.  Ci si assicuri di leggere attentamente la documentazione prima di tentare di mandare in esecuzione lo screensaver dal gestore delle finestre come ho fatto negli esempi riportati di seguito.

Alcuni degli altri hack interessanti che ho configurato sono:


Schermo di decadimento


Punto luce



Radar

È qualcosa di divertente con la quale giocherellare, ma nulla di più.  Qualora si dovesse decidere di immergersi nel codice di qualcuno di questi hack (o nello stesso xscreensaver), ad ogni modo, si potrebbe apprendere abbastanza sul come funziona la grafica di basso livello in ambiente X.

Buon divertimento!
 
indent

[ La pagina della Musa ] [ Indice ]


Per l'articolo originale: © 1999 Michael J. Hammel - Pubblicato sul n. 42 della Linux Gazette
Per l'edizione italiana: © 1999 A. Cartelli - Pubblicato sul n. 3 anno III di LGEI a cura di un gruppo di volontari