Je vais devoir faire quelques dessins en Perl. Jusqu'ici, pour =E7a,
mes programmes g=E9n=E9raient du code TikZ, que je compilais avec LaTeX,
mais ce syst=E8me est un peu lourdingue pour mon nouveau projet.
La biblioth=E8que de r=E9f=E9rence pour le dessin semble (toujours) =EAtre
GD.
Est-ce que vous avez des documentations ou livres qui vous ont bien
plu =E0 propos de GD et de son utilisation en Perl, en plus du manuel de
r=E9f=E9rence et de la perldoc?
J'ai trouv=E9 une petite introduction sympa ici:
http://linuxgazette.net/81/padala.html
mais il existe peut-=EAtre de quoi aller plus loin. Notamment, j'aimerais
conna=EEtre les bonnes pratiques pour =E9crire du code maintenable avec
cette biblioth=E8que.
Merci pour vos retours d'exp=E9rience!
--=20
J=E9r=E9my Just <jeremy_just@netcourrier.com>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Jeremy JUST wrote in message <4bcc45f4$0$28671$:
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.
Jeremy JUST wrote in message <4bcc45f4$0$28671$426a34cc@news.free.fr>:
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.
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
À (at) 19 Apr 2010 12:10:05 GMT, Nicolas George <nicolas$ écrivait (wrote):
Jeremy JUST wrote in message <4bcc45f4$0$28671$:
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) 19 Apr 2010 12:10:05 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Jeremy JUST wrote in message <4bcc45f4$0$28671$426a34cc@news.free.fr>:
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 - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) 19 Apr 2010 12:10:05 GMT, Nicolas George <nicolas$ écrivait (wrote):
Jeremy JUST wrote in message <4bcc45f4$0$28671$:
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
Jeremy JUST
Le Mon, 19 Apr 2010 18:24:30 +0200, Paul Gaborit a écrit :
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
Le Mon, 19 Apr 2010 18:24:30 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> a écrit :
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.
Le Mon, 19 Apr 2010 18:24:30 +0200, Paul Gaborit a écrit :
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
Jeremy JUST wrote in message <4bcd7327$0$20669$:
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 <URL: http://cairographics.org/tutorial/ >. 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.
Jeremy JUST wrote in message <4bcd7327$0$20669$426a74cc@news.free.fr>:
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 <URL: http://cairographics.org/tutorial/ >.
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.
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 <URL: http://cairographics.org/tutorial/ >. 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
À (at) Tue, 20 Apr 2010 11:25:59 +0200, Jeremy JUST écrivait (wrote):
Le Mon, 19 Apr 2010 18:24:30 +0200, Paul Gaborit a écrit :
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Tue, 20 Apr 2010 11:25:59 +0200,
Jeremy JUST <jeremy_just@netcourrier.com> écrivait (wrote):
Le Mon, 19 Apr 2010 18:24:30 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> a écrit :
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 - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Tue, 20 Apr 2010 11:25:59 +0200, Jeremy JUST écrivait (wrote):
Le Mon, 19 Apr 2010 18:24:30 +0200, Paul Gaborit a écrit :
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
