Documentation de GD

Le
Jeremy JUST
Bonjour à tous,

Je vais devoir faire quelques dessins en Perl. Jusqu'ici, pour ça,
mes programmes généraient du code TikZ, que je compilais avec LaTeX,
mais ce système est un peu lourdingue pour mon nouveau projet.

La bibliothèque de référence pour le dessin semble (toujours) être
GD.
Est-ce que vous avez des documentations ou livres qui vous ont bien
plu à propos de GD et de son utilisation en Perl, en plus du manuel de
référence et de la perldoc?


J'ai trouvé une petite introduction sympa ici:
http://linuxgazette.net/81/padala.html
mais il existe peut-être de quoi aller plus loin. Notamment, j'aimerais
connaître les bonnes pratiques pour écrire du code maintenable avec
cette bibliothèque.


Merci pour vos retours d'expérience!

--
Jérémy Just <jeremy_just@netcourrier.com>
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #21590741
Jeremy JUST wrote in message
La bibliothèque de référence pour le dessin semble (toujours) être
GD.



J'aurais plutôt dit Cairo. Un bref survol de l'API de GD sur le web semble
m'indiquer que celle de Cairo est bien meilleure, avec au moins la
possibilité de dessiner sur plusieurs éléments à la fois et des surfaces
dans des formats vectoriels.
Paul Gaborit
Le #21591991
À (at) 19 Apr 2010 12:10:05 GMT,
Nicolas George
Jeremy JUST wrote in message
La bibliothèque de référence pour le dessin semble (toujours) être
GD.



J'aurais plutôt dit Cairo. Un bref survol de l'API de GD sur le web semble
m'indiquer que celle de Cairo est bien meilleure, avec au moins la
possibilité de dessiner sur plusieurs éléments à la fois et des surfaces
dans des formats vectoriels.



Je « plussoie ». Ou alors voir du côté des modules produisant du SVG
(combiné à inkscape pour un rendu dans d'autres formats).

Il faut si possible rester en vectoriel et retarder au plus tard le
passage en bitmap !

--
Paul Gaborit - Perl en français -
Jeremy JUST
Le #21596021
Le Mon, 19 Apr 2010 18:24:30 +0200,
Paul Gaborit
J'aurais plutôt dit Cairo.


Je « plussoie ».



Merci pour el conseil, je regarde Cairo. Son rendu semble plus joli
(anti-aliasing, support des transparences...), mais utiliser un outil
concurrent d'un de Lincoln Stein va faire grincer certains des dents
autour de moi... J'ai imprimé les Perldocs.

La question semble rester valable: existe-t-il une documentation pour
se mettre rapidement le pied à l'étrier? Un livre que vous auriez bien
aimé?


Ou alors voir du côté des modules produisant du SVG
(combiné à inkscape pour un rendu dans d'autres formats).



Bof, je n'ai pas vraiment envie d'apprendre à scripter Inkscape juste
pour la beauté conceptuelle du XML comme langage graphique (beurk). Et
lancer un outil plutôt orienté interface graphique (et relativement
instable) alors qu'on pourrait tout faire en Perl me semble
contre-productif.


Il faut si possible rester en vectoriel et retarder au plus tard le
passage en bitmap !



Si on va dans ce sens, le SVG serait déjà une version dégradée de mes
données. Ta phrase devrait être « Il faut si possible rester aux
données brutes et retarder au plus tard le passage à un graphique ».
Mais il y a quand même un moment où on veut du confort, et pouvoir
publier quelques PNG plutôt que 13 Go de données compressées.


--
Jérémy Just
Nicolas George
Le #21596151
Jeremy JUST wrote in message
mais utiliser un outil
concurrent d'un de Lincoln Stein va faire grincer certains des dents
autour de moi...



Je vois qu'il est l'auteur de CGI.pm, dont j'ai trouvé le code source
franchement moche. Je pense que tu peux laisser les dents grincer.

La question semble rester valable: existe-t-il une documentation pour
se mettre rapidement le pied à l'étrier? Un livre que vous auriez bien
aimé?



Il y a un tutoriel pour Cairo L'API est suffisamment simple pour que ça ait de bonnes chances de suffire.

Bof, je n'ai pas vraiment envie d'apprendre à scripter Inkscape juste
pour la beauté conceptuelle du XML comme langage graphique (beurk).



Il y a d'autres outils qu'Inkscape pour faire le rendu de SVG, heureusement.
Paul Gaborit
Le #21596261
À (at) Tue, 20 Apr 2010 11:25:59 +0200,
Jeremy JUST
Le Mon, 19 Apr 2010 18:24:30 +0200,
Paul Gaborit
J'aurais plutôt dit Cairo.


Je « plussoie ».



Merci pour el conseil, je regarde Cairo. Son rendu semble plus joli
(anti-aliasing, support des transparences...), mais utiliser un outil
concurrent d'un de Lincoln Stein va faire grincer certains des dents
autour de moi... J'ai imprimé les Perldocs.



Je ne comprends pas cette remarque. À ma connaissance, Lincoln Stein n'a
jamais créé d'outil gérant des graphiques *vectoriels*...

La question semble rester valable: existe-t-il une documentation pour
se mettre rapidement le pied à l'étrier? Un livre que vous auriez bien
aimé?



Personnellement, je n'utilise pas Cairo.

Ou alors voir du côté des modules produisant du SVG
(combiné à inkscape pour un rendu dans d'autres formats).



Bof, je n'ai pas vraiment envie d'apprendre à scripter Inkscape juste
pour la beauté conceptuelle du XML comme langage graphique (beurk). Et
lancer un outil plutôt orienté interface graphique (et relativement
instable) alors qu'on pourrait tout faire en Perl me semble
contre-productif.



Il n'y a pas à apprendre à scripter inkscape. Il faut juste l'appeler
pour convertir du SVG en xxx (où xxx est PDF, PS, EPS... ou même PNG
mais on retombe vers du bitmap). Cela se fait par une seule ligne de
commande du genre :

inkscape --export-pdf=image.pdf image.svg

L'interface graphique ne se lance même pas... Et si inkscape te
déplait tant que ça, il existe d'autres convertisseurs.

Les modules Perl génèrent eux-mêmes le SVG. Ils n'utilisent pas
inkscape. Il existe même un module GD::SVG qui fonctionne (presque)
comme GD mais qui produit du SVG au lieu d'une sortie bitmap (PNG).


Il faut si possible rester en vectoriel et retarder au plus tard le
passage en bitmap !



Si on va dans ce sens, le SVG serait déjà une version dégradée de mes
données. Ta phrase devrait être « Il faut si possible rester aux
données brutes et retarder au plus tard le passage à un graphique ».



Lire un tableau de chiffres bruts est souvent plus difficile qu'un bon
graphique.

Ma remarque sur le format vectoriel/bitmap concerne la qualité de
l'image produite. Si on sait exactement l'usage *final*, on peut choisir
le bon format bitmap. Mais si on ne sait pas si les images vont être
juste visualisées à l'écran ou modifiées voire imprimées, le format
vectoriel est le meilleur.

--
Paul Gaborit - Perl en français -
Publicité
Poster une réponse
Anonyme